Uncategorized

No news is good news

Wow, I just realised that I haven’t written anything here in more than two years.

I’m still alive and well, just very short on time with several small kids and my new role as CTO at Eyeo. I’ve learned a lot in the past two years and there are dozens of posts I’d love to write, but never quite got around to.

My open source projects have also suffered from my lack of time, I’ve become incredibly unresponsive, and since I review all contributions thoroughly, it can take a long time for me to merge patches. I’m really sorry for that. If you’ve contributed to one of my projects before and would be interested in becoming a co-maintainer, please drop me a line, that’d be awesome.

I’ll make it my 2016 resolution to write at least a couple of posts this year, stay tuned.

Why asm.js is a big deal for game developers

I’ve been following Emscripten for a while now. It was pretty solid months ago, and it keeps getting better. Now that asm.js is beginning to show pretty impressive results and Chrome is apparently considering to implement optimisations for it, things are looking pretty good for native code in the browser these days.

So, why would anyone want native code in the browser? Legacy code, you might think, but that’s not really it. Games is the biggest reason.

C++ is the single most important language in (professional) game development, and before that it was C. Before that various assembler dialects. See the pattern? Many game developers, especially indies, use engines where they can work in higher-level languages, but you still need to run these on everything that calls itself a gaming device. And they’re of course almost all written in C or C++. So there’s really no way around native code execution if you want games on your platform, that’s why every notable mobile platform has added them, sometimes reluctantly.

Why C++?

There are numerous reasons why most of the game industry is still using C++. One is that it’s pretty much the only language you can use on every single platform that runs games, from desktop to handheld consoles. Another is that, as opposed to desktop applications, games usually have the exact same user interface across platforms. So rewriting it in the platform’s native frameworks, as is a popular approach to mobile apps these days, does not make much sense. You usually want one code base that runs everywhere. C and C++ are the only reasonable options for that right now. And even though many atrocities have been committed with C++, you can actually write nice code in it – look to the likes of Stroustrup and Carmack for that.

Why not JavaScript?

But couldn’t people just use JavaScript and ship their game with an app that embeds WebKit? Hardly. Browsers and mobile browsers are becoming faster, but the bleeding edge is still barely able to deliver the kind of games that were running fine in Flash ten years ago. Yet current desktops and smartphones are capable of so much more than that. WebGL could arguably fix this, but even if mobile browsers weren’t so slow to implement it, and Microsoft wouldn’t refuse to adopt it, you’ll still end up with significantly more overhead and stricter hardware requirements than if you just make a native game.

I’ve thought long and hard about whether I should make web-based games. I’ve been developing web applications during my day jobs for more than five years now, and JavaScript has been my main language all the time, so it seemed like a no-brainer. But I want to use proven libraries like SDL and Box2D, I want to support older operating systems and hardware, and I don’t want to spend my time optimising every little algorithm I write (which is what I ended up doing for pretty much all browser games I worked on so far). It’s C++ for me.

So, why is asm.js a big deal?

Because the browser is suddenly a feasible platform for game developers, most of which previously ignored it. It’s not a huge investment anymore, you can still ship the same code base to desktop, mobile and consoles. You can even feasibly have a web-based demo and then deliver the full game as a native application, or make an MMORPG free to play with a limited browser client, and have people pay money for the gorgeous native client. We’ll probably see all the big third party engines compile to asm.js in no time, Unreal Engine having already taken the lead. Browsers will either support WebGL or lose users. I’m betting my money on the former. This is very likely the dawn of the browser as a proper gaming platform.

Working remotely: the best thing I’ve ever done

It’s been six months since I switched jobs and began to work from home most of the time. It’s downright amazing, the best thing I’ve ever done. Seeing my kids grow up and being able to support my seriously overworked wife (our boys are 2 and 1, that’s quite the challenge) is great for all of us.

As a programmer, I’m in a very good position to work remotely: We tend to be quite good at communicating online (especially those with an open source background), we can improve the tools we use or build our own, and we’re in high demand right now – many of us can just leave for greener pastures when their company doesn’t let them work from home. Even if you think your company is awesome and it’s reasonable of them to ask you to be in the office every day, it’s probably not. What this really says is that your boss thinks you won’t work properly when not being watched. Do you really want to work for someone like that? I sure don’t. (Sometimes it’s really difficult: my last job for example involved programming for huge, expensive parcel machines. But that seems like a rather unusual case.)

How we do it

My company employs some people in Europe and some in the US, and most of us don’t work fixed times, so synchronous communication is not always possible. We have an IRC channel where we usually announce when we’re there and when we’re gone, and have quick technical discussions, but it’s not really enough. So a lot of our communication was happening via email, which can get messy. We have recently set up Discourse for internal asynchronous communication, and it’s working much, much better.

We use Trello to communicate what we’re working on. It’s voluntary, but most people do it. It is quite important to communicate what you’re working on when remoting. But the single most important thing we do to make remoting work is mandatory code reviews. We use Google Code Review (it’s basically Rietveld on a Google Apps account), but there are other promising options like Gerrit or GitHub pull requests. If you’re not used to doing code reviews, I really think you should try it. I’ve never seen any other process increase code quality and communication like reviews do. And it’s not really much overhead, even a review containing one or two days of work is usually done in 10 to 30 minutes. And time spent understanding the code base is not at all wasted time in my book.

Since we’re a distributed team, we need all that to work. You can get away without tools for asynchronous communication or code reviews in an office, but I’m convinced setting these things up is quite beneficial even there. What if your developers are sitting in more than one room? In my experience, there’s a lot of walking and phoning and meetings going on, that’s highly distracting. Stuffing lots of people into a single big room is a common solution, but that’s a change from bad to worse: I found it insanely distracting to work in a room with more than two other people in it.

Not all of my new colleagues work remotely, but almost all of the developers, incuding the lead developer and CTO. The remaining people usually work in the office, and everyone living close to the office is encouraged to join the weekly status meeting there. I’m almost always going, it’s really good to get together and see some people in person or do some brainstorming every now and then.

All the remotees have a call the day after the status meeting in the office, to have someone who’s been there talk a bit about what’s going on in the rest of the company, and for everyone to share their status.

How I do it

Before I started my current job, I had to leave home almost every day for about 20 years straight. So I was a bit nervous that this big change in my life would confuse me, or that I wouldn’t be motivated enough to do a good job, or that I just wouldn’t like it. Turns out none of that happened, it’s been the happiest time in my life so far. Getting to see my wife and kids whenever I want to, not missing any milestones and doing my share of parenting is brilliant beyond words. If you’re a parent, please consider trying this if you have the chance.

Even after six months, I haven’t fully gotten used to this vast new freedom yet. I just need to do about 40 hours of work per week, it doesn’t matter when or where. Yet I still usually work about 4 hours straight, have a lunch break and then work another 4 hours, just as I used to do it in an office. But when the weather is really amazing, like when it first snowed last year, I do leave for a while. Or when one of us needs to go see the doctor, that’s much less stressful now then it used to be.

I’m not really working in a fixed place anymore, I’m frequently moving from the study to the living room, from the table to the sofa, or onto the balcony when the weather is nice. I also sometimes work at a cafe close to the office when I arrive early for the status meeting (didn’t feel the need to ask for a key so far). I think if I didn’t have a family, I’d be working in a cafe on a daily basis. Even if there’s lots of people in it, it’s quite different from a crowded office. Don’t really know why, maybe because I can be sure that nothing that’s being said is relevant to me.

I also noticed changes in the way I consume information. I hardly read Twitter as thoroughly as I used to anymore, and I’m seriously behind on my RSS feeds. I’m not on a crowded train with a crappy internet connection anymore, I’m here at home where all the things I like are. Why read Twitter for 10 minutes when I can use the time to play with the boys, or play video games, or work on a private project? The same goes for procrastination – why surf aimlessly around when I need a break from work? There’s so many better things I can do.

All in all, I’m really enjoying the remoting, I’m quite determined that I won’t work in an office again, if I can help it. And given how the number of remote offers for developers seems to be rising steadily, I don’t see why.

Settling down with ClojureScript

I recently blogged about using ClojureScript for a new internal application at work. After some initial difficulties, I’m finally up to speed with it. I thought it’s about time I shared some more insights.

Since the application we’re building offers a REST API to be consumed by multiple clients, we decided to eat our own dog food from the start and make the web frontend use the same API. So what we’re doing with ClojureScript is a pure client-side web project.

Generating HTML

Since we’re making a pure client-side application, we needed some kind of client-side templating. I didn’t feel like bothering with HTML after getting accustomed to Hiccup in Compojure, so we used the dom-helpers namespace from the TwitterBuzz ClojureScript demo. Now we can generate markup like this:

(dom/build [:div#content
            [:h1 title]
            [:div#messages
             [:div#message-input
              [:div
               [:label "Your name:"]
               [:input#author-name-input {:type "text"}]]
              [:textarea#message-textarea]
              [:button#send-button "Send message"]]
             [:div#message-list]]]))

The dom-helpers are basically a nice abstraction for Google Closure’s DOM manipulation utilities. I’m sure that ClojureScript will include something like that in the future.

Avoiding Google Closure

Knowing that amazing web applications like Google Docs use it, I really wanted to give Google Closure, which is included in ClojureScript, a chance. The utility functions are actually quite handy, but the lack of documentation makes using most parts, e.g. the UI widgets, a royal pain. Add to that the fact that it feels more like using a cumbersome Java framework than a JavaScript library, I decided to avoid it where possible. Google Closure is technically sophisticated, but lacks elegance and convenience.

Building with Leiningen

When we started to use ClojureScript, we built it from source and invoked the ClojureScript compiler from a Makefile. I can’t begin to tell you how weird this felt. Since we’re using Leiningen to build the backend, we decided to use it for the frontend as well, so I wrote a custom Leiningen plugin that performs the tasks we need, e.g. calling the ClojureScript compiler and packing the output into a WAR file. We’re not planning to release this plugin, it’s pretty hard wired towards our needs and not really thought through.

Instead, I started to contribute to lein-clojurescript, first making it work with a stable release of Leiningen. The author likes my ideas about offering multiple modes for development and production, and making the respective options configurable in the project.clj, so that’s the plugin you want to use.

Promising stuff

REPL in the browser

When ClojureScript was first announced a while ago, the REPL used Rhino for JavaScript evaluation and DOM manipulation was not possible. The ClojureScript developers have addressed that problem and made it possible to use the Browser as evaluation environment. It looks promising, but I didn’t really find the time to play around with it yet.

Compiling automatically

Compiling without optimizations is pretty fast, but manually invoking the compiler before refreshing the browser still feels wrong when doing web development. cljs-watch attempts to solve that problem by watching your ClojureScript sources, recompiling as soon as anything changes, e.g. you save a file. I trie it, but couldn’t make it work right away, so I postponed that. I guess something similar can be build into lein-clojurescript.

Problems

As I told you at the beginning of this post, I’m pretty happy with ClojureScript by now. We had to put some extra energy into setting up our development environment and build system, but now we’re up to speed. A few problems, however, remain.

No unit testing

I haven’t yet invested the time to figure out how to execute unit tests for ClojureScript code, it will probably be easier now that we build with Leiningen. This is something I’ll have to approach soon, working without tests feels really bad.

Still no release

I really don’t know why the Clojure/core folks announced ClojureScript without having a release candidate of ClojureScript ready, or even a tag. That hasn’t changed. At first, we forked the ClojureScript project on GitHub and created a tag to ensure reproducible builds. Now that we use lein-clojurescript, we use the ClojureScript version from Clojars, but that doesn’t feel much better – it’s still an arbitrary snapshot.

Conclusion

Despite the problems, ClojureScript made a very good first and second impression. It proved very stable (I didn’t come across a single compiler weirdness, of which I’ve seen plenty in GWT), which made me take languages that compile to JavaScript seriously again. Instead of whining about programmer inconvenience and immature tooling, I’ve decided to contribute, starting with lein-clojurescript. Once that’s powerful enough to replace our custom plugin, I’ll see if I can help out with ClojureScript itself, it really needs an initial release.