Occasionally updated personal site and blog

Tag Archives: Programming

Slides from WJAX

If you’ve seen my talk about web application architecture at WJAX 2015, and would like to download the slides, you can download them here:

WJAX 2015 – Mobile, microservices and multichannel.pdf

If you are interested in learning more about some of the topics mentioned, I’ve previously collected a list of blog posts, articles, videos and other resources here:


And if you’d like to talk about any of these topics, I’m always happy to talk shop on Twitter (@elmarschraml), via email or whenever we meet in person.

Slides from my talk at MobileTechCon 2015

Thanks to everybody attending my talk “Mobile, Microservices und Multichannel – warum Web-App-Architektur sich ändern muss” at the Mobile Tech Conference 2015 in Munich.

Feel free to download a PDF of the slides used in the talk:
MobileTech2015 – mobile, microservices, multichannel (images compressed)

Images are compressed to reduce the file size; if you’d like a high-res version, or just to talk about any of the topics mentioned, get in touch with me.

Javascript I love you, but you need to clean up your mess

We are finally reaching the point where dropping support for IE7 is pretty much a given, and the time when IE8 support can be dropped for even conservative audiences draws nearer. So we can finally join the brave new world of fully dynamic rich client applications written in cross-browser supported standard javascript. Well, not quite so fast…


Too many global functions pollute the global namespace, and your code becomes a mess, so after coming up with an only slightly less messy object structure, you decide to use a module system. Except javascript has no module system. Luckily, some people created substitutes. There’s AMD/require.js, or commonjs on node which you can use on the browser using browserify. Or you roll your own. Or the language itself will introduce a module system with the next version. Of course, any library you use may use either of those solutions, or none at all, and may or may not play nice with your choice. Anybody reminded of the Java logging situation, and what a joy that is?


JS is a mess. So everybody clean it up and extends it in his own way. Until ES6, which might clean that up once it’s ratified and widely supported, some time in 2016 or 2017. In the meantime, you can use some ES6 features, and transpile to ES5 using Traceur. Or use Coffeescript and compile to JS. Or TypeScript, which is almost like some parts of ES6.


How many ways does one need to say “Take this text file, add code/params/data according to the keywords present in the text, and have the outcome be HTML”? According to the javascript world, at a minimum a choice of Jade, Handlebars, Mustache, Underscore templates, EJS,… – and those are just the ones most frequently seen in the wild.


I love Jquery, and so does anybody who ever had to do DOM manipulation without it. And at least DOM manipulation is an area where everybody seems to have come to the same conclusion, which is to use JQuery rather than Prototype, Dojo or whatever else was briefly popular. So since everybody uses JQuery, you might also use it for utility functions, handling Ajax calls, providing UI components, and so one. Or not, or just for some of those. So for every kitchen sink query adds, any project might now do it the standard javascript way, the jquery way, or use some other library.

New Flavors of the month

So you found out that Jquery makes it really easy to add cool effects and do dynamic changes, and all was good. Then you added so many of them, that pages had several hundred lines of spaghetti code, and that was unmaintainable. So people came up with Backbone as a way to structure applications, and you rewrote your site, which was a lot of work, but was good. And then other people became more ambitious, and created Ember and Knockout and Angular, and now you’re tempted to throw away your 6 months old rewrite, and rewrite again.

It’s hard to promote Javascript (and when I say Javascript, I really mean the whole JS/HTML5/CSS/Client-sideMVC/browser-as-real-application-platform shebang) as a valid development platform as long as the platform is a rapidly moving target.

In the long term, betting against Javascript is usually an error, and I look forward to using cross-browser EcmaScript6 with a common stack of stable libraries. In the meantime: learn, experiment, prototype, promote and use the brave new Javascript world for the most compelling use cases.

(Post was inspired by somebody else’s decision to needlessly re-implement an existing, pretty conservative web application with AngularJS – something which the techie imp sitting on my left shoulder would just love to do, while the business imp sitting on my right shoulder cries…)

My experience with pair programming

It spreads knowledge about the codebase
Since two people worked on the code, two people know intricately how it works, and can fix bugs in it without first having to spend time to learn the inner workings. Yeah, I know, in theory everybody should be familiar with everything, but in time-constrained practice you often have the same people fix bugs who wrote the code, keeping the others from getting to know the code of a feature. But even if only the people who wrote it know the code, if it was created by a pair, you already have two people who know it.

It spreads good practices
Even if you keep up with news about tools and practices, you can never know everything. Almost every time I pair, I learn something new – e.g. some eclipse keyboard shortcuts, a firefox add-ons for debugging, or a useful library class.

The code is better
You rarely write sloppy, “good enough for this one time” code – after all, the other guy will see what kind of code you write, and you don’t want to be embarrassed. And if you do, the other guy will point it out and correct it.

The design is better.
Two people have more ideas than a single person. If both are competent, they will agree to throw away the bad ideas, and combine only the good ideas of two people. As for APIs, two programmers think of different use cases, and make sure the API can handle them.

It avoids being stuck.
A lot of time is wasted when you’re stuck – situations where you’ve tried pretty much everything, and still can’t get your design or implementation to work. A second person will bring a fresh pair of eyes (and brain) and often think of exactly those things that you forgot. Or, in a case where you painted yourself into a corner, and have secretly felt that you should throw your efforts away as sunk costs and try a different approach, he will prod you to finally do just that.

It’s exhausting
I can program solo for long stretches of time, but when doing pair programming I usually take a break after two hours max. Paired sessions are much more intense, since they move faster, since (see above) you’re never stuck.

It’ only suitable for certain occasions
It’s a total waste to use two highly-qualified programmers to do simple, well-defined and understood tasks – examples: Defining a web form, setting up the base configuration for a project, or fixing selenium tests. It’s great, in short, for anything that is hard and new.

It’s expensive
A pair of programmers does move faster than a single programmer, but not twice as fast, so you spend more programmer time on a piece of code when doing pair programming. You do gain all the advantages mentioned above, though – so if it’s worth it really depends on the kind of work you do. In my experience, it’s best for integrating new developers in a team, and for anything that involves designing/implementing an API.

Game development, 1986

Found a fascinating read: Jordan mechners development journal from 1986.

Some excerpts:

He spent most of a day trying to get vhs video (taken on a $2000 video camera) into the computer. He ended up photographing every single frame with a photo camera, waiting for the prints to be developed, and then scanning the stills.
Today: $150 Flip camcorder, 5 minute usb transfer, done.

Orignially, he planned to have no enemies in the game, since there wasnt enough memory for two figures with different animations.
The enemy was created by xor-ing the hero’s animation, so it was black with a white outline

When he started on it, nobody was sure if by the time it came out there would even be a video games market. Likewise, by the time he was about to finish, the original platform it ran on, the Apple II, was declining, so he needed to port to DOS immediately.

He alternated between goofing off for weeks, and doing nothing but work and sleep.

Back then, games were expected to sell for years, not weeks like now. That prince of persia only started to sell well a few months after its release was perfectly normal back then. By the time he made real money from it, he had already moved on to other projects, switched careers and written it off as a learning experience.

Technology radar, fall 2011 edition

Rising stars:

iOS Development
The iphone is still hot, the iPad is hot and established by now, plus now the mac app store gets Joe Sixpack buying applications on the mac. What’s news is that due to the success of the iphone, even large conservative companies are really starting to realize they need to “do something with mobile”.

Android development
The phones still suck, but it gets used on tablets, ebookreaders,and all kinds of other devices. Two years ago it was “cool, we have an iphone app”, last year it was “of course we have an iphone app”, now it’s increasingly “of course we also have an android app”.

Most people talking about HTML5 actually mean ajax web apps. Or “by now we can actually replace desktop apps with web apps”. The most important factor are probably not the new javascript and media APIs, but simply the fact that with IE9, MS finally mostly gets their shit together.

Amazon Web Services
Spot instances, cheaper S3, beanstalk, aws for government – it’s hard to even keep track of all the innovations coming out of amazon. Most enterprises are still extremely suspicious of cloud hosting, but for a start-up it seems almost more unusual not to run on EC2.

Seriously. There’s a lot more to it than window.open, and libraries like jquery or extjs make it non-painful to use. It’s not like you have a choice when it comes to client-side scripting (except, more or less, for coffeescript). And the browser is only the most widely deployed platform in the world. Also: quasi-native mobile web apps. Also: node.js for js on the server. Also: Rhino, and, in Java7, invokedynamic, to run js on the JVM. Also: couchdb for js within databases.


Even Microsoft says Html5 is the future.

Duh. Kind of kept alive with government funds, but Nokia finally realized it’s dead.

Google Wave
Already pretty much killed by google by now. Too bad, I kinda liked it.
In the short run, not going anywhere. But what does the fact that Adobe published an animation tool for Html5 tell you about the long-term future chances of Flash?
A very long way from dead, since it’s used everywhere in the enterprise. But very few people would willingly use it over REST, and new deployments or standardizations on SOAP are rare. Strange for me to say, since I do a lot of work with Soap, but good riddance.

Question marks:

It looked like the next Rails for a moment in 2008 or so, then was not really heard from again. Rule of thumb: languages with weird-looking syntax rarely go mainstream (see also: Lisp). Also: really sucky string handling. But the concurrency stuff is still super neat.

Finally a Lisp that will spread beyond Lisp fans? I wouldn’t bet on it. Still too many parenthesis for my taste. But seems to gain a lot of traction lately.

Finally a new systems language. Too bad there’s not a whole lot of new OSs being written right now. But seems to spread into non-system applications, like AppEngine web apps.

Is there any web startup that does not use it? But it’s not clear yet if a single one, and which one, and which kind, will dominate.

By far the most prominent DVCS, and the most pure implementation of the DVCS concepts. There’s a lot of submarine projects, like single developers using it locally as a subverson proxy. But will a tool designed by and for kernel hackers go mainstream? I like Git, but it’s using up too much complexity-handling brainpower that I’d rather spend on the code itself.

Try any language in your browser

Pretty much any new language has an online interpreter these days, so you can try it without even having to install anything.

For future reference, I collected all the links here:

Clojure http://tryclj.licenser.net/
Scala http://www.simplyscala.com/
Python http://try-python.mired.org/ (or http://trypython.org , but that one needs Silverlight)
Ruby http://tryruby.org/
Go http://golang.org/
Erlang http://www.tryerlang.org/
Groovy http://groovyconsole.appspot.com/
Lua http://www.lua.org/demo.html
NodeJS http://jsapp.us/

Why Erlang will be the next language I learn

Keeping to the pragmatic programmer’s mantra of learning a new language every year, I’ve picked Erlang as the language to learn in 2011.

(For reference – 2010 was Groovy (verdict: very nice, but if I want JVM + a dynamic language, I’d rather user JRuby), and 2009 was Javascript (yes, of course I knew Javascript before, but you can go a very long way beyond “hide a few elements of the DOM”))

Erlang is borderline practical right now – getting enough traction that is has a real chance of one day becoming mainstream (I think on the hype curve, Erlang right now is about where Ruby on Rails was 5 years ago), but still far enough out there that knowing it sets you apart.

It’s a functional language, and I’ve always wanted to learn one of those, but it’s less academic than Haskell, and has fewer parantheses than Lisp.

It’s a nice contrast from Java, which I do most of my current work in. Unlike Java, it was not originally intended to go mainstream, therefore being safe and easy enough for any joe programmer was not a design goal. And unlike Java, which is useful for anything from web apps to desktop software to being embeded in Bluray players, Erlang is rather opinionated software with a focus on concurrent network servers.

There are two good reasons to learn a new language: Either you expect it to become useful in day-to-day work to solve the problems you’re currently working on, or you expect it to broaden your horizon and teach you new concepts.

Erlang should do both.

Erlang is all about developing highly concurrent, highly available network servers, with a focus on scaling, debugging, faul-tolerance and performance tuning. In other words, building systems that scale by making use of the inevitable (or should I say already happened?) switch to multi-core hardware. Not so much a problem I have right now, but a problem that every programmer will have sooner or later.

But coming from curly brace-dominated languages, Erlang also feels really weird – and I mean that in a good way. The syntax is inspired by Prolog, Strings have several possible representations, none of which seem particularly string-y to me, the typing system is kind-of-optional, instead of exceptions you have supervisor hierarchies of processes, and so on. And of course, all that is on top of the fact that it follows a completely different programming paradigm. I might or might not end up liking those features, but I’m looking forward to learning more about them.

Alright, got the book, bookmarked the tutorial, found the online REPL, let’s get started!