Thursday, July 10, 2014

Application routing, message busing and the irritating impossibility of programs as graphs

I had a hard time writing that title. What I want to write about is a simple thing, but somehow it is quite hard to express.

But to begin, I think that many programmers, like me, have a dream to some day do some or all of the following;

1) A multi-user d&d inspired game
2) A WYSIWYG web widget editor that 'just works' and create websites that can be generated in any of n languages or frameworks
3) Some kind of 'mini-SOA' framework where the program is broken down into parts which are wired up with some kind of bus system.

These things usually crash and crash and crash again, again and again. I keep trying, keep crashing and even though I realize what I want to do is still a laughably long way beyond my skill level, it's still something that I strive to achieve.

A couple of years age, thinking on one of these things, the application-routing, mini-SOA or, to call it by it's wiki-official name, dataflow programming framework (, I realized that it was practically impossible to create what I wanted.

It might seem obvious to anyone else, but what I realized then was that if you wire up your application like a kind of graph, how do you define connections between dynamically created objects?

Well, you can't, of course, or at least you have to break the circuit model, using some kind of API to programatically create connections, incidentally defeating the whole purpose of the framework.

So dataflow wiring would only work for programs made up of singletons, which was a bother and made me retreat from further experimenting. Until yesterday.

Again, this is probably super-obvious for anyone but me, but I just wanted to share my epiphany on why it's actually feasibly an indeed a very, very good idea to use dataflow abstractions for programs that create non-model objects dynamically (which most tend to do).

What I realized was that in an UI (for example) there can be many levels of multiple objects created in hierarchies, but for every level, all objects can be treated as singletons, thus simple to wire up with a dataflow template.

If one of these objects create a dynamic list of other objects, each of those objects will define a new 'level' or island, if you will, where all the relations can be wired up again using dataflow. So we have stable islands of instance relations, where one or more can create more islands, with implicit connections to them.

One of my favourite dataflow architectures has been JDA (JavaScript Dataflow Architecture) which recently has re-emerged as ( I think what I'll do now is have a drink, look over JDA/ again and see how it can be applied to Polymer, because Polymer.

Thursday, April 24, 2014

Five things your company should do with developer communities (but probably doesn't)

Being a long-time developer community manager (Google Developer Groups) I'm often struck with how little companies care how they interact with the programming community, especially when it comes to sourcing and recruitment activities.

Most companies today are becoming more and more dependent on recruiting good developers, yet the way they communicate with the developer community remains very last-century.

In essence, if you're letting your HR department or an external recruitment agency be the first point of contact with developers, chances are you're scaring away a good deal of them, who might have fit and thrived inside your company. You're essentially paying to become isolated from the very community you're increasingly becoming dependent upon.

If you think this is a bad thing, here are my five top tips on how to interact with a developer community (I hope they will seem obvious after you've read them):

1. Do proper research on which developer communities exists in the towns where you have offices ( is a great tool here), see which fit best with the technical skills you have the need for and consider asking your developers to create a new group if none exists.

2. Create incentives for your developers to a) talk at developer community events, b) host such events at your offices. This can be anything from perks to paid overtime.

3. Host at least one Hackathon each quarter in your offices. Make sure this is entirely planned and communicated by your developers.

4. Have your developers identify interesting / famous external developers who can be invited as speakers and let the developers invite as many people as can fit. This can be done perhaps once every quarter as well.

5. Create or host a developer game, where your developers interact with, evaluate and gets to know all other attending developers as part of the game mechanic. One great example is (full disclosure alert :) my own Escape from /dev/null series of events.

If you do all these things - good for you! If not, know that many companies do and that they will get ahead of you in getting to know the best and the brightest developers.

All of these things are related to developer branding, could be argued to be developer branding, but the more important thing is that they make your developers meet and interact with other developers. Everything else is details.

You can have the best workplace in the world, but if you don't get the word out on a personal developer level, no one will know.

Saturday, February 8, 2014

Developer games - how do they work?

If you're going to a developer game you might wonder how they differ from other kind of programmer pastimes like Hackathons, Programming competitions, just having a beer, talking and so on.

My definition (and as far I can tell I was the one calling these things 'developer games' in the first place) is this; 

A developer game is a combination of a programming competition and a computer game, where the challenges focus on the practical and fun rather than on algorithmic obscurity.

There are some algorithmic challenges from time to time, sure, and they can be quite tricky too. But the core concept is to have a welcoming, inclusive, little bit crazy event which you can attend to have fun and maybe win some prizes, but it's totally up to you and your team.

OK, so that's the overall picture, how does it work in practice?

All my 'Escape from /dev/null' developer games have taken place with everyone in the same room, or at least building, so that it's easy to ask questions and to interact with other people during the event.

When you arrive in the morning, you get login details to the game system and a reserved place to sit with your team. Then comes a general presentation about game mechanics, rules and how to play it in general, and then the system opens and off you go.

To the right is a picture from the presentation at a game I did at Valtech in Stockholm a year back or so.

There are two different games, though; The outer game looks like something like this;

The red text icons are team markers so that everyone logged in to the system can see where all other teams are on the map.

All teams begin at the same (or similar) location and can choose different paths to traverse the game-board to (hopefully) be the first team to snag the prize and the final node.

The nodes are the numbered circles and each node contains a programming challenge. Some nodes also contain prizes, so that the first teams to reach a node get the prize it contains (until there are no more prizes left on that node).

You can also see which nodes the teams are solving at the moment (white arrows) or if they have submitted a solution to the judges (red arrows) and how many minutes they have spent solving the problem (yellow numbers). The above game is an old game I've taken up to take a screenshot of, so the minutes numbers are quite huge, which is not normally the case.

OK, so say that your team gets a challenge, what does one look like and how does it work? I won't show you an actual challenge, but I will say that the challenges are thematic and most of them revolve around using a live web-based API where the inner game can be accessed.

For example the inner game can be (and have been) a multi-user space simulation where the team build a system one challenge at a time which controls a starship which can explore solar system, mine them and repair or build new things. 

The current inner game scenario is a multi-user rogue-like dungeon crawler, however. If you have ever played games like rogue, nethack, angband and the like, you know more or less what to expect - except it's in realtime, so monster do move even when you are not.

So let say that your team have solved a particular challenge, using the web-based interface you will then send of a short message to the judges who will then stroll down to your table and check out your solution.

If they spot a mistake or something that you've forgotten to do, the decline the submission and you have to give it an extra go or they accept the submission and your team is moved to the node which challenge you solved and you're free to choose a new one.

To the right is a blurry picture (I am so not a photographer) of what it looks like on everybody's screen when a team win a prize on a node.

You get to name your teams as you sign up and these guys decided to call themselves NullReferenceException (and was randomly assigned team code A02).

Another team in the same recent game called themselves "; DROP TABLE INFORMATION_SCHEMA; --", which was very optimistic :) I'm running Couch on the node.js back-end.

But the judging part takes us to the question of how and why the developer games exist at all. To fly all over the world setting these things up (not to mention buying prizes) costs a bit of money, so all events need sponsors.

And the whole reason I started doing these events was that I was so frustrated and dissatisfied with how development branding works when it comes to programmers. A lot of the communication is often done by a non-programmer who can't really represent the company properly and tend to brush programmers the wrong way.

What I would like companies to do (who absolutely depend on programmers) is to have more laid-back communication between their programmers and the actual programmer communities, and any evaluation should be done as respectfully and nicely as possible - and the best way I could think of was to create a cool, geeky and unique kind of game where programmer (the judges from the sponsor) meet programmers (the attendees) in a natural way.

The judges check out how you code and you get a chance to ask them how it's really like at the company they work for - if you want to. Many people just show up for the game and isn't really interested of the sponsor at the moment, but in a year or two that may change, and now they know who to contact.

Also if you live in or near Seattle, the next game will have Hulu as a sponsor. More information can be found here;

That's all really. Please ask any question you'd like in the comments if there is anything more you'd like to know