Everybody Should Learn to Code!… Wait, What?

You may have seen this video, starring Mark Zuckerberg, Drew Houston (from Dropbox) and a couple of other tech stars. They promote the Code.org initiative, advocating that every school kid in the U.S. should have programming classes as part of their educational offer.

It’s a recent development, but the whole idea of promoting computer programming among broad audience is in the spotlight for quite some time now. Not only in the U.S., mind you. In Estonia, for example, children are to be offered coding classes starting from early elementary school.

The message seems to be pretty clear: everyone should learn to code, the earlier the better. In the future, it will be an obvious part of basic literacy, like reading and writing natural language. Everyone will get to do some really cool and useful things with their computers.

Sounds great, doesn’t it?…

So why I can’t help but to roll my eyes when I hear about this? Am I just an obnoxious, elitist jerk who doesn’t want others to experience the feeling of empowerment and satisfaction that creating your own computer programs can evoke every so often?… D’oh, I really hope not.

So maybe there are some actual problems with this idea. I would hesitate to say that it just doesn’t, ahem, compute, but I can certainly see a few issues, misconceptions and dubious assumptions.

Slides from My Talk at Name Collision

Last Friday I had the pleasure of attending the Name Collision hackathon in Warsaw. I haven’t actually taken part in the competition but I served as a mentor, trying to help the teams get stuff done as much I could. It was really fun experience.

Before that, though, I gave a short lightning talk about the Git version control systems. I showed a few (hopefully) lesser known tricks that may prove useful both in everyday workflow and in some exceptional situations.
The slides from this talk are available here. They might be a bit uninformative on their own but I suppose the liberal use of memes can make up for this somewhat ;-)

Ego-Driven Technologies

Last week – while still on the other side of the pond – I attended a meet-up organized by the local Google Developers Group. The meeting included a presentation about Go, aimed mostly at newcomers, which covered the language from the ground up but at very fast pace. This spurred a lot of survey questions, as people evidently wanted to assess the language’s viability in general and fitness for particular domain of applications.
One of them was about web frameworks that are available to use in Go. Answer mentioned few simple, existing ones, but also how people coming from other languages are working to (re)build their favorite ones in Go. The point was, of course, that even though the language does not have its own Django or Rails just yet, it’s bound to happen quite soon.

And that’s when it dawned on me.

See, I wondered for a while now why people are eager to subject themselves to a huge productivity drop (among other hardships) when they switch from one technology, that they are proficient in, to a different but curiously similar one.
Mind you, I’m not talking about exploratory ventures intended to evaluate language X or framework Y by doing one or two non-trivial projects; heck, I do it very often (and you should too). No, I’m talking about all-out switching to a new shiny toy, especially when decided consciously and not through a gradual slanting, in a kind of “best tool for the job” fashion.

Whenever I looked for justification, usually I’d just find a straightforward litany of perks and benefits of $targetTechnology, often having a not insignificant intersection with analogous list for the old one. Add the other, necessary part of risk-benefit calculation – drawbacks – and it just doesn’t balance out. Not by a long shot.

So, I notice that I am confused. There must some be other factor in play, but I couldn’t come up with any candidates – until that day.
As I speculate now, there is actually a big incentive to jump ship whenever a new one appear. And it seems to be one of dirty secrets of the hacker community, because it directly questions the esteemed notion of meritocracy that we are so eager to flaunt.

Now That’s What I Call a History Lesson

“Museums are boring!” If you hold such an opinion, it’s quite likely you haven’t been in those really interesting ones yet. Today (or yesterday, depending on PoV) I happened to be in such a place, and I can assert its awesomeness with unparalleled confidence.

It’s the Computer History Museum in Mountain View, CA. If you ever find yourself in northern California, I definitely recommend paying a visit there.
Inside, you can find all sorts of extremely cool exhibits from the somewhat short but wildly interesting history of computer science. Anything from early vacuum tubes, through Commodores and up to iPhones, with all the surprising stuff in between.

I couldn’t spend a whole day there, sadly, but I took a few pictures. Apologies for the low quality of some; although I took them with a device that won’t land in this museum for quite a while, it’s still just a phone.

Complex Stubbing with Mockito for Java

Mocks are used to “fake” the behavior of objects to the extent required by tests. Most of the time, they can be pretty simple: when calling a method with given set of (constant) argument, then return some predefined value. Mocking frameworks actually strive to translate the previous sentence directly into code, which can be seen in Java’s Mockito library:

What is evident here is that this mock doesn’t maintain any state. As a result, all stubbed method are completely independent and referentially transparent: they always return the same value for the same set of arguments. In reality, that property is even stronger because they are simply constant.

Simple mocks like those work for a good number of cases. Some may even argue that it’s the only way to mock properly, because anything more complicated is a sign of code smell. We can counter that by saying that some complexity is often unavoidable, and it’s up to developers to decide whether they want to put it test or tested code.

And thus more complex stubbing may be needed if, for some case, you prefer the former approach. When that happens, it’s good to know how to fabricate a bit more sophisticated behavior. In Mockito, it’s very possible to achieve almost arbitrary complexity by capturing arguments of stubbed calls and routing them to callbacks. This is done with the help of ArgumentCaptor class and the Answer interface, respectively.
When combined, they can result in pretty clever mocks, as illustrated with this example of some imaginary API for SMTP (e-mail sending protocol):

Note that it doesn’t implement the real SMTP. That, presumably, would mimic the SmtpConnection class exactly, which of course is not the point of mocking at all.
The point is to provide sufficiently complete behavior so that code under test can proceed, reaching all the execution paths we want to exercise. In this case, something can call getOutgoingClientData and rely on certain string being present in the output.

Let’s just hope that this “something” actually has some good reasons to expect that…