Thursday, September 22, 2016

A modest proposal on solving the problem with developer latin

Latin is considered a dead language, as it has no native speakers any more. Whether this is true or not depends on your definition since it is indeed learned and spoken all over the world by a minority of speakers, mostly for use in esoteric rituals or for academic studies.

In either case, Latin is incidental at best to gauging the proficiency of (say) an English-speaker of today. However, Latin is really clearly defined with lots of interesting grammar and is probably kind of a cool language to ask questions about and to see how well English-speakers are able to articulate themselves in it.

Also, some English words and syntax derives directly from Latin and that can be quite interesting to follow in itself.

But if you were to hire a journalist, a tech writer or perhaps a person working a lot with written communication in general, how useful would a throughout test on Latin be? Not very? I thought so.

So, what has this to do with developers?

Every two or three years I forget past experiences and think how nice it would be to work at, for example, Google, where I know lots of people and which seems to be an OK place to work. This often coincides with the re-evaluation of going it all alone in my own company and sometimes not having the kind of traction I'd like with what I do.

And I realize this is a flogging a dead horse which has seen quite a lot of action throughout the years, but the main gist of all this is that I realized, mid through an interview, that the technical details we were discussion were very similar to Latin knowledge for an English-speaker.

Even worse, I have it from the horses mouth (the very same) that in actual practice, there an awfully little Latin being spoken inside Google after you've been hired.

Ho often do you re-balance a red-black tree? How often do you map a tree according to certain criteria onto an array? It sounds like you might, at some point. I guess.  I'm using a lot of priority queues and trees when coding, but implementing them myself? Has never happened. Or, I did make my own quad-tree once. tbh.

So how hard can it be? These are super-easy programming problems from university, after all. If you don't know them, what do you know? Right?

Do you remember learning that new library or framework recently? The one where you sort of understood what it did but still made lots of silly mistakes the first week. And you, who have been coding for more than ten years (or 20 or 40, you get it). Isn't that embarrassing?

It turns out that never mind how experienced you are or how smart you are, unless you are experienced in the specific area in question, you're not so hot anymore. You don't get that extra days or week or whatever.

That's all fair, but to train specifics of implementing certain classical algorithms and edge-cases thereof that will never ever at all be used in production is indeed a bit like asking for knowledge of Latin for a position where a thorough, current knowledge of (say) English is required.

And of course you can spend those extra days and weeks and read all those websites and books that train you what the current slew of Latin is hot, people do it all the time.

But - and here comes the modest proposal btw - wouldn't it be a better approach to actually test people on the skills they are supposed to use at the position they are supposed to be hired for?

As a company you are certain to hire people who are smart - smart enough to read up on a number of very odd and old, basic algorithms, learn their edge-cases and actual talk fairly fluently about it all at the end of the interview. So you're sure to get both unnecessarily motivated and very smart people to hire.

That's great!

And you won't get the people who quite frankly are tired of all that Latin.

How about this;

- You already know the devs you've sourced and filtered out are the top 5% or so
- You know what they've been working on, which companies and github projects and so on
- Go over one of their projects one-on-one
- Ask them how they feel about testing
- Ask them the worst bug or problem they've been responsible for
- Ask them to write something on their own machine, on their IDE of choice, that is applicable to the position they're hiring for.


You already know very well what you've got to lose, because you're losing it every day, by the tonnes. First company to go non-bonkers wins. :)

Monday, December 28, 2015

Getting started with visual programming using Evothings Studio


Last post I described how this crazy idea came about, but I realized that I really needed to write a short introduction, for two reasons;

1. The Evothings node-red front-end parser works a little differently than the usual node-red run-time.
2. It's not really clear where to go next when you've downloaded and started the node-red version of Evothings Studio.

But why?

Yes, why would you anyway? My hope is that many people would welcome an even easier route to getting started doing IoT  apps. Evothings studio is the quickest route that I know of at the moment, given that you don't mind doing cross-platform JavaScript development and baking your app with cordova at the end.

Still, Evothings Studio is all about JavaScript, and if it's not your first programming language, there can be a lot of sharp corners to cut yourself on. 

By packaging access to some of the Cordova and JavaScript BLE APIs as visually composable modules (in the node-red editor), I hope that it becomes even easier to create and experiment with apps the communicate with sensors or other Bluetooth devices.


1. Download the Node-red branch build of Evothings Studio here;

2. Unpack it in your home directory (*NOT* under C:\program files or the like, if you're running Windows)

3. Make sure it runs, and looks reasonably like this:

What you're running now is essentially the latest beta of Evothings Studio 2.0, but with a couple of modifications, so everything you'd like to do with the original studio (and it's quite a lot), you can do here as well. The modifications cooks down to a new button for each of the projects under 'My Apps' (any front-end project, really, that can be anywhere on your machine) that let you launch a node-red editor and create+edit a flows.json file in the directory where the index.html of your project resides.

4. Go to the Examples tab, and note the two projects 'Hello Node-Red World' and 'Node-Red Front-End TI Sensortag'.

The two examples are the only ones that you can actually use directly, if you want to see how the node-red editor works together with the studio to push out incremental changes to your mobile.

5. Speaking of which, it's time to install the viewer on your phone. Here's the link for iOS and Android, and make sure it runs and looks like the image below;

6. To connect your phone and the studio, you generate a one-time key in the studio and enter it on the phone.

7. Now, you should have one client connected at the lower right status field of the studio. You re now ready to rock! If you want to avoid entering a new code every time you have crappy connectivity, you can log in (using github, google or plain email) to the proxy to make it preserve the session.

8. Now copy the example project 'Hello Node-Red World' from the examples tab and by clicking the 'COPY' button next to it. When you are done, you're taken to the 'My Apps' tab where the new project will show up.

By clicking 'CODE' the studio open a system file browser that shows the root of the directory, to let you edit the files using your favorite editor. These files are a bit doctored to load and parse node-red flows.json files and to populate the mobile web page with the widgets that are defined there. You can of course edit the index.html and everything as you wish, and do both classical and node-red development at the same time (as long as you don't bork the node-red front-end stuff).

9. Click the 'RUN' button to push out your project to your mobile phone. It will (hopefully) like a bit like below when it lands;

Not a beauty, by any means, but does contain a bare-bones examples of what a simple node-red front-end app could look like.

If you have any Bluetooth devices around, you can click 'SCAN' which lists all found (until you press the button (now saying 'STOP SCAN') again). Clicking on one of the found devices will list its services in a separate list.

OK, not very impressive.- Seen it before - yawn, right? But what I want to highlight here is not actually the functionality of the app but how it was made. 

10. If you go back to the 'My Apps' tab on the studio, now click the 'NODE-RED' button, which should bring up the visual node-red flows editor for the current project.

All node-red front-end apps must begin with a 'Page' module, which has connections to all other visible widgets under it, normally organized by 'Section' modules. Visible stuff like sections, buttons and so on are connected to each another sort of like a DOM tree, but after that, the connections between modules actually defines message-passing.

For example, the 'Scan' module is actually a Button module, which has been renamed to Scan. it will implement a Material Design Lite Button and when it is clicked, a message will be passed to whatever other module(s) it is connected to.

This button connect to two other modules - a function and a module called 'blescan'. Let's look at the function;

All modules (including functions) gets passed one argument object called 'msg'. The convention is to have a property of msg called 'payload' which contain the important parts. 

The payload passed by a button is the DOM event object of the click, which is then used to determine which new text caption the button should be set to. So buttons also can receive messages, and will change caption to that of the payload.

But the interesting thing with functions is that you can add them anywhere and use them to debug messages being passed. And now we come to a very nice thing with Evothings Studio itself - that you gets logs back from the running app on the phone, continually.

11. Click on the blue button named 'Tools' in the main Studio app window. you now get a new window with two parts - a small editor at the top (already populated with examples to try out) and at the bottom an area which display the logs from your app.

So if we add a log statement to the function, like this;

It will result it some logs in the Tools window when the button is pressed.

And, it turns out, quite a lot of my own silly happy-go-lucky developer logging while I'm making the nrfe-widgets. I should probably clean those up a bit. :) But what I wanted to show here is ..

1. You can develop apps visually in the node-red editor and still get quite a lot of functionality.
2. The widgets will look sort of OK without *any* efforts at styling.
3. The program that scan for BLE devices and then list the services of a selected one contained only three lines of code, over two functions (the other picked a property of the incoming message and sent it as output).
4. Three lines of code that you write yourself, for a bespoke app, is a sweet small number to maintain.

The modules have documentation included in themselves, so when you select a module in the node-red editor, the documentation comes up in a sidebar to the right. This is a very nice way of doing things from the creators of node-red, and helps a lot when just getting started. I haven't documented very well, but I hope that it is enough to get started.

Again, please let me know what you'd like to see next and if you've managed to make anything yourselves using the editor!

Over and out, for now.

Friday, December 25, 2015

All tomorrows lines of code

(That you don't have to write)


I've extended the open-source IoT web-app development tool Evothings Studio by slapping on the open-source node-red flow-based editor and a number of custom modules to let you generate mobile web-apps with little or no coding, that let you connect to and communicate with Bluetooth devices.

Downloads per platform;


OK, so the short version goes like this; I work as a lead developer at a small startup called Evothings.
We mainly do two things; a number of cordova plugins for BLE access to weird things and sensors, and an open-source developer tool for IoT mobile web-apps called Evothings Studio.

The idea is to provide a workflow where you as a developer can iterate quickly using the Evothings Viewer app (from either app-store) that connects to the Evothings Studio desktop application (both are open-source and on Github) so that the studio pushes any changed files in your projects out to the viewer, which reloads and send logs continually back to the studio.

OK, so far? Good. About now you'll wonder how we make money :). Currently we're just providing open-source projects and a free service (we have a proxy that let you connect your viewer(s) and your studio avoiding any client-isolation issues with local WiFi).

The basic service will always be free for small usage, but we're busy creating cool stuff on top of it that we hope people will find valuable early next year, or thereabouts.

Notice that the studio comes packed with a lot of IoT app examples, some geared towards specific hardware like Arduino, Eddystone beacons or the TI Sensor-tags. That's all open-source too and easy to copy to your own project to get a head start.

So, about these visual boxes and stuff.

Right, right! OK. We got invited to IBM in Winchester a while back and while we talked about a lot of stuff, where one of the presentations got stuck in my head. It was a walk-through of another open-source project that IBM had created, called node-red.

Node-red is a flow-based editor that let you compose node.js programs visually, that then runs on the back-end when deployed. It's easy to install and try out and comes with quite a lot of cool components, like postgreSQL access, XMPP, MQTT, regular sockets, lots of other stuff - and at the end of the day you can deploy everything as a npm package.

What I was thinking was how cool it would be if one took node-red and added on top of it stuff that made it possible to create web apps, mobile, bluetooth enabled web-apps, specifically, and run them on a phone, incrementally while you're building it.

So I did that.

Or, more correctly, I started doing it. node-red has come quite a along way and it would have been a tall order to just implement all modules to work on the front-end, so I started creating custom modules instead. Modules are those boxes that show up in the visual editor that you string together to create flows.

I needed a hierarchy of modules both to organize visual widgets and to define how messages are passed between modules (widgets or non-visible modules, like the bluetooth scanner), so I used the flow graph in node-red for both.

The output of node-red is a single file called 'flows.json' which defines which modules are in the flow and any settings they have, in addition to how the modules are wired. I configured node-red to save the flows.json file in the home directory of the project being edited, and created a couple of open-source Github projects to make everything work together:

nrmodules (Which are mostly just filler plugins for node-red that makes new modules show up in the visual editor, published also as a npm module):

nrfe (node-red front-end. Yes, I suck at naming things. Welcome to the club. This is the web-app side parser for the flows files)

nrfe-widgets (where the actual functionality of the modules happens. These widgets is what the parser wires together according to the flows file)

The 'widgets' depend on the cordova-ble plugin to be present in the mobile app running the web-app (in addition to cordova itself), so the following example app can't run by itself in a mobile browser - you either have to load it from the Evothings studio into the Evothings viewer app, or build it as a proper cordova/phonegap app:

The hello-world project also includes the nrfe and nrfe-widget projects as bower installs, so rmember to run 'bower install' at first and then 'bower update' to get any new widgets being authored.

Some of the widgets are visual and are copied wholesale from the Material Design Lite library, and some (like the BLE scan) are not visual at all. Visual widgets need to be connected to a page or a section widget to be visible on the page, so for those kind of relations, the wires means something like a DOM hierarchy.

For non-visual widgets and for visual widget outputs, the wires mean something else - they define how messages are passed between widgets/modules. So the Button widget 'OK' is wired to the BLE scan widget, which will toggle scanning for bluetooth devices, and in turn send a small JavaScript object defining the found device as output message, and so on.

Please take this baby for a spin and let me know how hard you don't like it :) Or maybe what you'd like to see next. I'm planning to finish building modules for all bluetooth stuff like descriptors and next up is a module for MQTT.

And if I don't find time to write a mode detailed follow-up article before new year's eve, here's some festive inspiration:

EDIT: I *did* find some time. So here is that 'how to get started' kind of article:

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


Monday, November 12, 2012

Full Frontal 2012

Except for Google I/O, I never go to large or corporate conferences anymore. Since years back, I have by pure luck (or by being interested in the right things) found this complete gems, like the JSConfs in different reincarnations and regions, but closely snug together with them in my heart is the Sharp family's Full Frontal in Brighton.

I was lucky enough to attend the very first one in 2009, just weeks after attending the first European JSConf in Berlin, being completely floored by Jake Archibald's deadpan, on-the-spot humor and Simon Willison's last talk who he had completely rewritten after seeing (as I did) Ryan Dahl present node.js for the first time at the previously mentioned JSConf. The energy and the passion of these guys completely floored me and I later found myself talking about them and the conf very often and for way too long.

The boring terms for the magic sauce of Full Frontal is probably 'meticulously curated', but I really think that's what it is. It's a one-day, one-track conference with just the best of everything. I don't like all talks at all times, but most, I do, and not a little.

I could go on about great moments from other years, but will instead just applaud this year's choices like Chris Wilson (above) who talked about his days creating the Mosaic browser and working on most versions of IE at Microsoft before joining Google two years ago. It was history. My own, incidentally, remembering downloading NCSA Mosaic from a local university FTP site and all things that have happened since.

But the speakers are one thing and the context and environment is another.  The event always takes place at the Duke of Yorks' picture house, and old cinema in the middle of Brighton. For me it's very much a Groundhog day experience, but in a nice way. The weather is always coldish but not like it would be in Sweden, there's always a war memorial celebration about and I always stay at the same hotel.

Also, my friends are there, new and old. There's lots of drinking (well, I am drinking anyway :) and gapping about important things (programming and SF&F). It's a very, very welcoming atmosphere (again very much like the JSConfs) with warm quirks like the sponsor Dharmafly who set up a rack with small potted plants to take home.

I was nearly unable to go this year since I've done so much flying to promote the Escape from /dev/null programming competition (it sounds slightly meaningless at the surface but is really cool when you know more - hence the need to fly about) and I'd like to thank my wife for letting me fly *again* to goof off at a wonderful conference with my pals. I love you.