subscribe via RSS
For the last two years, I’ve been one of the organizers of an elective Rust course in Sofia University. Last semester, one of the homework assignments we came up with was to build several kinds of “logger” structs with buffering, multiple outputs, and with tagged logging. (The full assignment is here, but all the instructions are in Bulgarian.)
It was a pretty good exercise on using
RefCellthat wasn’t a linked list or a similar data structure. The goal was to ensure a logger can be cloned, with the copies sharing both the same buffer and output.
Testing the code seemed easy at first glance, but I did run into a bit of a problem when simulating loggers printing to “the screen”. The solution is not exactly complicated, but I think it’s a good pattern to share.
I recently wrote a tool to manipulate images embedded in mp3 tags: id3-image. To be able to make changes to the code with confidence, I needed tests. Rust comes with the very sensible
Writetrait that could have allowed me to mock any IO (a blog post for another day), but in this case, the project relied on the excellent id3 crate, so I wasn’t doing any file-writing myself.
Instead, I wanted to have an actual mp3 file and an actual image, apply my code to them, and inspect the results. This generally isn’t difficult to do, but I ran into a few unexpected gotchas, so I’ll summarize how I ended up implementing it.
Okay, this is going to be a bit bikesheddy. It’s about a code style rule that some people love and some people hate, and I have an ✨opinion✨ about. It’s not a particularly strong opinion, as in, if the team I’m working with disagrees with me, I have no issue following the popular vote. It’s a small enough thing that it might not matter in the long term.
Let’s start by examining some code:
I recently started working with ember.js. It’s a nice framework, but, like most newish technologies, Vim support is minimal. So, as I usually do in such cases, I started working on some tools to help me out with navigation. Tim Pope’s projectionist helped a lot, but I wanted more, so I started building it up in what would later be published as ember_tools.
The biggest feature was the
gfmapping (“go to file”), which was inspired by the one in vim-rails. Using
gfin a rails project almost always does “the right thing” for whatever you can think of. So, I poked around in that one, tried to figure out how it was implemented. In the process, I learned a few things and had a bunch of pretty good ideas, which I’ll talk about in this blog post.
Facebook changed their authentication process fairly recently. Instead of using a global user id, users would now get an app-specific id instead. This took me by surprise, and I had to jump through some hoops to get stuff to work with our setup. This is a short post that outlines what we did to work around the problem.
A common piece of advice for dealing with bad rails code is to avoid making huge rewrites all at once. Instead, make small fixes whenever you see a problem. An often-cited variant of this is the “boyscout rule” – leave the code better than you found it.
This is solid advice. Putting hacks and workarounds would only make things worse. Rewriting swaths of code for even small features would take a long amount of time and introduce risk. The best approach is to make small refactorings and build new features with new, better, code.
As with most good advice, this can still backfire. Ever seen an app with five different caching mechanisms and seven different event tracking approaches, all slightly different? This may have been a result of multiple developers going “this is horrible, I’ll fix it”. In the end, they created an even larger mess, despite their good intentions. How did this happen?
OHM was a place full of amazing ideas and clever hacks. In this atmosphere, a friend and I started talking about our education system and the age-old promise of “multimedia” in the classroom. It’s a popular topic these days, education. Startups like coursera are providing free online lessons, clever tools like geddit are trying to improve teacher-student interaction. What Vloo and me discussed was using presentation slides in class in order to improve engagement.
Something like this is already in use in my home country of Bulgaria. There are specialized classrooms equipped with computers and projectors, and every once in a while, the students have an “interactive class”, where they watch videos and perform quizzes. However, this is something that happens rarely and is considered a “special” lesson. I was more interested in turning any lesson into an actual lecture. Just as lecturers at tech conferences teach me about the latest, greatest web framework, it should be perfectly possible to use the same tools for a chemistry, or biology, or history lecture.
As we were describing what a lesson would look like, we realized we could actually prepare one. We dubbed the event “Back to School” and I started working on a chemistry lecture to present at the local hackerspace, initLab.
I went to OHM (Observe, Hack, Make) this year, a hacker festival in the Netherlands. It was a fun week of camping, freedom talks, technology, retro-gaming and all sorts of other cool stuff. Since I was going there anyway, I decided to make a Vim event to spread word of the One True Editor.
In ActiveRecord, you can use the
selectmethod to run the underlying database query with a
SELECTfor particular fields. As a result, the object simply doesn’t have the rest of its attributes. Depending on the particular table and the use case, this could speed things up. Even without the performance argument, the idea to “get only the things you need” seems perfectly reasonable. This has never quite clicked with me, and I recently realized why. I’ve never encountered the problem viewed from this angle, so I figure it might be worth sharing.
I recently participated in RogueConf, a small Bulgarian conference. I talked about documentation, how and when to write it, how to write tools to help you out. The video is on youtube, and the slides are on speakerdeck, though it’s all in Bulgarian. This post is the TL;DR of the talk. I’m going to run through my main points, skipping over the demos and most of the examples. Eventually, I’ll extract some simple documentation tools from work in the dawanda/doctools repository, but there is still some effort needed to make them generally usable, I’m afraid.