I’ve been coding since I was ~13. I can understand why people who haven’t might have valid reasons to wish they’d started earlier. I’d just say: beware self-fulfilling prophecies and selection bias. Lots of really excellent software people I’ve worked with got late starts. Lots of people who started early coasted or are still coasting. In the 25 years I’ve been coding, only a few years worth of that time really grew me as a developer, so what you work on has just as much impact as how long you’ve been working on it.

Work with a bunch of different enterprise L.O.B. developers to get a sense of what I’m saying here. The average age of a backoffice developer is higher, meaning they have more experience. Hiring in enterprises is regimented, meaning that they tend to come from CS backgrounds. Are they uniformly high quality developers? No. In fact: there’s a stigma attached to coming from a long stint in enterprise development.

As a lever for getting more women engaged with startups, the idea that an early start is important makes even less sense. Much of the day-to-day work that happens even at companies with difficult problem domains is rote and uncomplicated. A few years experience is more than enough to lead a typical web project, and, more importantly, to have a sense for whether a dev team is firing on all cylinders and to authoritatively manage it.

Obvious subtext/bias here: I do not believe that starting women in software development earlier is going to resolve the gender gap. By all means, start early; there’s nothing wrong with that. It’s just probably not the root of the problem.

About a month ago I got the request to create a video from one of the WebGL demos on this site (the rotating earth cube, showing population density). So, of course, I said yes, but creating high quality output of this animation wasn’t as easy as I thought. I looked at a couple of screen recording tools, but none were available for Mac that were free, offered a good resolution and high enough frame rate. To be honest, I didn’t really look that long since I thought it a good opportunity to see how I could get the content of just the single canvas/webgl element and export it to a movie.

So basically, after some looking around, I came across this link where someone used websockets to export the content of the canvas and save these captures individually. Finally at the server side we can use ffmpeg to convert these captures to a movie. This looked like an interesting approach, so I did pretty much the same thing. I, however, used a simple vert.x backend for the websocket server.

This piece of code uses the toDataURL() function to get the data from the canvas element, next it converts it to a bytearray so we can easily send it as a binary websockets message. Making it binary is a bit of overkill for this example I guess, but this was the approach I had the best result with. And this is it for the websockets client part. One last important thing to note here, is that you should make sure you cal the “sendToServer” after the canvas is rendered. This might seem obvious, but costed me a lot of time bug hunting. I assumed that it wouldn’t matter if I added it before or after, since there is always something rendered on the canvas, and thus available to be sent to the server. Well… this isn’t the case. The canvas is apparently cleared at the beginning of the render loop, which caused a lot of black screens to be sent to the server.