A Whole Lot of OSes at Once

I realized I haven’t talked yet about my workspace setup, including the choice of computer(s) and operating system(s) which I prefer. A topic like that is a perfect opportunity to provide fuel for countless flamewars raging through the Internet forums, so it seems like a no-brainer if you want to round up some passionate readers ;)
So, what’s the best these days? Is it Windows or Linux? Or maybe OS X? Should you get a Mac or a(n other kind of) PC? Make it a desktop or just a laptop? Or perhaps subscribe to the post-PC doctrine and grab a tablet?…

Well, I don’t know. I won’t really advise anything here. Myself, I take more… holistic approach. I just use all of these things :)

Desktop split in two

As I see it, desktop PC is the place where stuff gets done. Be it “work” or play, you cannot easily forfeit the conveniences of big monitor(s), full keyboard layout, snappy mouse that fits your palm, and a comfortable chair.

Thing is, those two activities require two completely different operating systems. When it comes to games, Windows is still reigning supreme, with only some small glimpses of what might shake up this status quo. Sadly, I have little hope much will change here in the foreseeable future.
On the other hand, it’s pretty much given that the best system for most kinds of development work is some flavor of Linux, preferably sporting such powerful a package manager as apt-get. There are no (good) alternatives for certain vendor lock-ins (*cough* iOS) but if you are not forced to comply with them, anything else is almost certainly an inferior choice.

How to reconcile those requirements? There is dual booting, of course, but the need of frequent resets would get old very quickly. So instead of that, and after conducting a bit of a research, I opted for virtualization, choosing a simple solution of running Linux as guest OS through VirtualBox.
This turned out to be super easy to set up; the only “trick” was to flip a switch in BIOS in order to enable CPU virtualization features, required to run a 64-bit system as guest. With these on, performance is a non-issue: it feels like running directly on the hardware, for all intents and purposes – including running Android emulator inside the VM :)

Laptop as versatile substitute

Now, if only all that goodness could be made available on the go… Although some may pretend it is, most (sane) people cater to their mobility needs by getting a laptop. This is immediately a compromise because of the form factor alone, but even more so because of inevitably inferior hardware specs one could cram into it.

So no, I didn’t try to replicate the VM-based setup described above :) While possible, it seemed way more sensible to try and kill two birds with one stone by getting a computer that:

• adequately (though not perfectly) substitutes Windows for gaming and Linux for coding
• runs the third major operating system, in case that ever comes handy e.g. for testing purposes

As you’ve likely guessed, that description accurately fits a MacBook. Of its virtues and woes I have already written elsewhere, so let’s just say it fulfills its purpose pretty well.

And even when it doesn’t, there is always Chrome Remote Desktop to bridge the gap :)

Getting Back in Sync with Time

Many a hardships are constantly plaguing the hard working IT folks. For example, you may find out that the nearest fridge is out of your favorite drink! But among the so-called First World Problems, there are few that constitute actual, you know, problems – even if you should consider yourself very lucky facing them.

The prime example is this peculiar situation when you’re standing bathed in glaring sunlight, while your body is clearly telling you it’s the middle of the night – or the other way around. I’m talking, of course, about the physiological condition known as jet lag.

It’s pretty stubborn beast, too. There isn’t really a way to avoid it, short of reverting to old fashioned and slow means of transport. And you cannot count on having many innate adaptation to deal with it, either. It would require for our savannah ancestors to have been hopping continents in a few hours on regular basis, which – as far as we know – is not something they used to do.

Nevertheless, the symptoms of jet lag and their severity may vary greatly by person, so most of the advice about dealing with it will not necessarily work for everyone. But among the dubious statements you can find around the Internet, there are also some solid facts here and there.

Flying sucks

Although it’s not technically the cause of jet lag, spending many long hours in closed, cramped, crowded space (also known as “taking a flight”) is certainly a factor that could make its symptoms worse. To reduce that impact, there are few things you can do.

Drink

The air in aircraft’s cabin is typically very dry. In such an environment, you will lose body water faster than on the ground and eventually experience dehydration. I suspect this is also the reason why many people feel the jet lag as a condition similar to hangover.

The solution is, obviously, to drink more. You should never refuse a cup of water whenever the flight attendant offers you one, and you may actually want to actively bug them for even more. This isn’t likely to win you friends but it’s totally worth it, and also conveniently coincides with the next point.

Move

While on the plane, your options to move around are naturally quite limited. It’s never a bad idea, however, to get up, take a few steps and do some stretching. But what’s more important is to actually move around way before stepping on board.

As you probably know very well, the average airliner has a hermetically sealed cabin that keeps the air inside of it at much higher pressure than the surrounding atmosphere it soars through. Unfortunately, the pressure cannot be kept too high, lest the strain on fuselage’s integrity would be too severe and risk implosion. As a result, the density of air (and thus oxygen) in the cabin is usually comparable to that of about 2 kilometers above the sea level.

Unless you live at least that high up and are used to reduced oxygen pressure, you may experience some adverse effects which are curiously similar to the effects of jet lag. Though moving into some elevated area to make your breathing and circulation more efficient is certainly an option, the less radical way is simply to exercise regularly to achieve a comparable effect.

Sleep (probably)

This is hint is a bit more controversial, as some people will recommend staying up for the whole travel. Personally I envy those who are in the position to even consider this as an option. But even then, getting into the more relaxed state by closing your eyes works as acceptable substitute should you choose to do so.

Principles of time travel

The practical effect of moving rapidly to a far away time zone is to make your “day” artificially shorter or longer. Coping with that change therefore requires a temporary adjustment period with altered sleep pattern. To put it simply, you will need to either sleep when you normally don’t, or stay awake when you normally do.

While this is really a matter of your typical habits, I’d wager that for the average reader – who is likely no stranger to coding sessions that drag well into the night – the latter path would be the one of less resistance. Note, however, that especially on eastward flights the total duration of “daytime” may exceed 30 or more hours. Taking a nap while still on the plane would then serve to cushion the blow of having the “evening” moved well past the normal time.

We Don’t Need No Enums (in Python)

Last weekend I attended the PyGrunn conference, back in the good ol’ Netherlands. It was a very enjoyable and instructive event, featuring not only a few local speakers but also some prominent figures from the Python community – like Kenneth Reitz or Armin Ronacher. Overall, it was a weekend of some great pythonic fun.

…Except for a one small detail. As I’ve learned there, Python will apparently get to have enums in the 3.4 version of the language. To say that this was baffling to me would be a severe understatement. Not only I see very little need for such a feature, but I also have serious doubts whether it fits into the general spirit of Python language.

Why so? It’s mostly because of the main purpose of enumeration types, derived from their usage in many languages that already have them as a feature. That purpose is to turn arbitrary data – mostly integers and strings – into well-known, reliable entities that can be safely manipulated inside our programs. Enums act as border guardians, filtering out unexpected data and converting expected data into its safe representation.

What’s safety in this context? It’s type safety, of course. Thanks to enumeration types, we can be certain that a particular value belongs to specific and constrained set of elements. They clearly define all the variants that our code should handle, because everything else was already culled at the conversion stage.

Problem is, in Python there is nothing that would guarantee those safety promises are actually fulfilled. True, the basic property of enum types is retained: given an enum object, we know it must belong to a preordained set of entities. But there is nothing that ensures we are dealing with an enum object at all – short of us actually checking that ourselves:

How this is different from a straightforward membership check:

except for the latter looking cleaner and more explicit?…

This saying, I do not claim enums are completely out of place in Python. This is untrue, if simply because of the fact they are easily implemented through a rather simple metaclass. In fact, this is exactly how the proposed enums.Enum base is supposed to work.
At the same time, it is also possible to provide some of the before-mentioned type safety. Just look into various libraries that enhance Python with support for contracts: a form of type safety which is even more powerful than what you’ll find in many statically typed languages. You are free to use them, and you should definitely do, if your project would benefit from such a functionality.

Incidentally, they fit right in with that new & upcoming enumeration types from Python 3.4. It remains to be seen what it means exactly for the overall direction of the language design. But with enums in place, the style of “checked” typing suddenly became a lot more pythonic than it was before.

And I can’t say I like it very much.

Here Be Dragons: Game from IGK Compo

Last weekend I had the pleasure to attend the game development conference IGK in Siedlce, Poland. Although gamedev is not something I normally do, it was a fun experience.

One thing I was especially looking forward to was the one day-long game programming contest called Compo. Like last year and the one before, I formed a team with Adam “Reg” Sawicki and Krzysztof “Krzysiek K.” Kluczek, guest starring Kamil “Netrix” Szatkowski. That’s four coders in total, so we kinda had some problem with, say, more artistic part of the endeavor :)

Nevertheless, the result was pretty alright: we scored 4th place out of about dozen teams. The theme this time was an “artillery” game with few mandatory features: two types of energy-like resources (HP & MP), achievements and multiplayer gameplay.
We nailed the last one by implementing support for two mice at once. This allowed us to come up with an interesting idea inspired by the Atari game Rampart: two castles that expand and attack each other in a fast-paced duel full of frantic clicking. And because the attackers, or guardians of each castle are dragons, hence the game’s title: Here Be Dragons.

  [2013-04-07] Here Be Dragons (3.2 MiB, 1,724 downloads)

In retrospect, we should probably have narrowed the scope of our project more. Doing it 3D was ambitious in itself, but packing it with all the features we planned the night before turned out to be slightly too much :) In the end we didn’t even have time to code any sound effects or music!… That’s certainly a lesson to learn here.

But all in all, it was great fun. It certainly inspired me to maybe try and brush up my gamedev skills a bit more :)

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.