You’re still here, reading this article?

Well, that means you’re probably like me a few years ago. You think “I don’t have time for that” or “I am not good enough to contribute” or “I can’t code at all”.

All of those things are no excuse.

First: About the time.

I guess you have a lot of things to do then, right? And I bet you wrote a few scripts (be it a tiny 2 liner or a huge collection of shell scripts) to speed up the chores, right?
Publish them. Now.

There’s no need to polish them or write 100 pages of manual texts. Just throw in a readme with two lines (what it does and how to execute it) and publish it.

If you don’t wanna “clutter” your account with a repository or the script is just one clever line of shell code, you can also use Coderwall or a Gist.

Why you should publish things like that, you ask? Because even if you think it’s a very specific solution for a very special problem, others may encounter it. And if so, your tool can help them get it done quicker.

Another case is when you do a little modification to an existing tool, because it makes it a little easier to use or a little faster or even fixes a bug - publish it, so that others can benefit just like you did by using the tool in the first place.

Contributing often only takes a few minutes and often you just need to put it online somewhere (with things like Github available, this is no big deal anymore!) - and you should do so, even if it’s not polished.

I see it pretty often that people postpone their contribution, because it needs to be cleaned up, documented or polished in whatever way. Publish the raw gem that you have - and then you can polish it later. Maybe even other people polish it for you.

Next one: You are good enough and you will learn something from contributing.

There’s really just two things that can happen: Your code is good enough. And it’s a great feeling, when it gets accepted into a tool or library you use in your daily work.

The other case is, that your code isn’t good enough. In that case you get invaluable feedback on why it isn’t good enough and how to improve. That, in the long run, makes you a better programmer. It’s pretty much free training. Use this opportunity by contributing code.

Alright - last one.
You can’t code? So what?
Often the documentation of a project has missing or outdated parts. Fill them with the knowledge you gained while using the tool.

Another way of contributing is joining the forums, mailing list or user group or stackoverflow of the project to answer questions of others.

You should understand that contributing is a small thing to do with a big impact.

Don’t hesistate, contribute today.

After reading Sebastian Anthonys article about why Firefox OS does not have a chance in the mobile market, I’d like to give my opinion.

First of all: The article says, that even if Firefox OS would gain interest and market acceptance for making web applications run like native applications on mobile devices, others like Android or iOS could just do the same.

I don’t see any problem. In fact, that would be great.

Firefox OS is not just an operating system, it is a philosophy.

The web is a powerful and fast-progressing platform and has already started to take the world of software and services by storm.

As the web advances further from web sites to web applications, it is only natural to step into the mobile market, where applications are the center of the ecosystem, while the platform below them does not matter much anymore.

The first few have made this step and with success!

But all of them are just “packaging” the web into a native veneer - so they build something around that, what is already part of the platform: The web.

Mozilla is only consequent in taking it further: The web is the platform in Firefox OS.

When this attempt is successful, it does not matter, if the web as a mobile platform is called “Firefox OS”, “iOS”, “Android” or whatever - it’s the web.

The web is open. The web is everywhere. The web is built upon HTML, CSS and JavaScript. Three powerful and yet emerging technologies that I love. Market shares of Firefox OS? I can’t care less, as long as the web wins.

For the impatient readers: If you run into this, try sending the POST params in the querystring instead of the body. This does not only apply to node.js twit, but is generally valid.

The longer version:

I was playing around with twit lately. It’s a wonderful node module that allows you to interact either with the Twitter REST or the Streaming API in a very easy way, possibly the easiest way I’ve ever seen.

I tried to post a new Tweet saying “Hello World!” which didn’t work.

The REST API responded with “Status 401, Could not authenticate you” and I started googling.

The first hint that came up, was trying to use v1 instead of v1.1 of the API. This resolved the issue! But as v1 is going to deprecate soon, I didn’t want to go that way, but find the root cause.

I ran the tests for twit and found, that it actually was abled to tweet. Even with v1.1.

The only difference was the text for the new tweet: The (successful) example from the tests did not contain an exclamation mark, while my (failing) example did.

So I removed the exclamation mark from my example - and it worked.

I looked through the many discussions of the “Code 32” issue on the Twitter developer portal and finally found https://dev.twitter.com/discussions/11280 that answered this:

If you, for some reason, send the parameters for the POST via the querystring - instead of the “right way” for HTTP POST where the parameters go in the HTTP body - it works!

I changed that and it worked surprisingly well - my pull-request to twit is currently pending.

In our office we had a spare TV and wanted to use it as an information radiator in our room.

As our setup involves Github where pull requests are built with Jenkins to verify everything is working as expected, I wanted to put the success rate of the builds, the build health and the latest open pull request on the screen.

The screen is hooked up to a Raspberry Pi, so I had a vast amount of possibilities to get something on screen.

After having a look at Dashing, I decided to go for it and build the project-cockpit project on top of it.

It uses the Jenkins API to get the ration of successful / non-successful builds as well as the latest build state. It also calls the Github API to get the latest pull request to display the name and picture of the author and the title of the pull request on the dashboard.

This is how it looks like in action:

In case the latest build is broken, it plays a Youtube Video of an exploding nuclear bomb.

The next step will be to show the JIRA tickets in the different stages (open, in progress, done).

Abstract

I wasn’t happy with the flash-based “Draw my thing” and built my own version with node.js, HTML5 an socket.io and deployed it on nodester. Its open source. You can play it here or on Facebook.

It works on modern browsers and I tested it with Android Opera Mini and the Android browser, too.

Here is the whole story:

First, I got pissed off…

Some weeks ago I came across “Draw my thing” (via the app version “Draw something”). I like it and my girlfriend and I wanted to play it together. When I was on my phone and she was on her laptop, we wanted to start. “Its the same game vendor (OMGPop) and its the same thing. Should work, I guess” way my initial thought. It didn’t. “Draw something” and “Draw my thing” - while being named similarily and utilizing the same game principle, it was not possible to play together using both versions.

“Meh, okay - I just get my laptop and use that.”, I continued. Nevertheless, being flash-based it was pretty slow on my laptop (which is now 4 years old…) and even when trying to play together it was a bad user experience (“Okay, now I’ll send you this game’s link via google talk and then you open it in your browser” “But I am already on OMGpop in the “Draw my thing” screen. Can’t I just get a notification or something?”… and it never really worked to play this game together.

So I rebuild it with HTML5, node.js and socket.io

“Come on, that can’t be THAT hard!” went through my head. And so I started.

I used an HTML5 canvas element, socket.io and node.js for the whole thing.

When the first player connects, she sees “Waiting for other player” until a second player connects. The two then get in the game, they can save and share their drawings and the game ends, when one of the players disconnect.

My experience

It was all so easy and works like a charm. It even works on my Android phone - I just had to write a little wrapper for touch-events.

The server code is 119 lines Javascript (node.js / socket.io), the client-logic is 195 lines javascript and a bit HTML / CSS.

I made this open-source, you can find it on GitHub.

The deployment with nodester was simple, easy and awesome.

Preface:

Some weeks ago, I set up a local StatusNet server on my server.

StatusNet is an open-source, decentralized microblogging-platform like Twitter.

But you can host it on your own system, or just join a running one (for example the famous identi.ca). The nice thing is: Whatever server you are registered to, you have the possibility to subscribe (which is the StatusNet equivalent of “following”) to any user on any server. It doesn’t matter if that user is on the same server or on any other, as long as its StatusNet.

This idea seemed shiny to me: I do not need to rely on one single point of failure (which we all know as the “failwhale”) - if some server goes down, only the users registered there are affected. And if I want to make sure, I’m having the service available - I can host it on my own which makes me the one being responsible for the service available of my own account.

If some server may go down, a part of my subscribed users may not be able to update their status - but all the others not on that particular server still are.

Thus, the whole infrastructure is more reliable in general.

As I host my own StatusNet-Server (here, to mention again) I ran into a small issue, that took me some time and help from the IRC and the forum to get it fixed.

This post should be a help for anyone encountering this…

The reality

But here comes the twist: Many of the people, I’m interested in having status updates from aren’t on any statusnet-server.

They’re on twitter, mostly. And not only do I want to keep up with their updates - no! I also want to keep them up to date with my own updates.

Both of this should be possible without having to check&post on twitter and statusnet simultaneously - here comes the nice thing: It is.

The solution

StatusNet ships with a Twitter-Bridge. You can import the twitter-timeline and you can make the system post your updates to twitter automatically. This was exactly, what I was looking for. I can use StatusNet, have people from other StatusNet-Servers subscribed directly, benefiting from the decentralized, open infrastructure and have the well-known functionality of twitter inside, without having the double effort.

So I configured it to do its task.

This is pretty easy. Just follow the README for that (situated in plugins/TwitterBridge/README) - et voilá - it imported my timeline like a cake.

Pretty! But trying to post to twitter from houston did not work!

To fix this, turn of the queuedaemon. and start daemons again. This fixed the issue for me.

So, the code is public and its time to tell you about the project.

Its something pure educational. Mostly for my own education, but I think some of you may be interested in this and use it for their own experiments.

If you want to, feel free! Just fork it and play.

Nomen est omen. Simple3D is a very, very, very simple 3D engine.

Its goal is not performance, but clean, structured and portable code and my goal with this is just my own education.

With this project, I wanted to use my knowledge of computer-graphics theory to build a real thing. I decided I would like to go from a pretty low level.

This is the reason, the library can easily been ported to everything, that is abled to draw some sort of pixels. Nothing more, nothing less.

There is plenty of work in this and as this is a freetime-project, I’ll only work on this whenever there is time for it. Change frequency may vary between minutes and years, probably.

However to me this is an interesting project. I learnt alot already and I am sure there is much more to learn from it.

Currently the engine allows the following:

• Create a window for drawing
• Creating different entities (some of them aren’t up to date with the new version. These are S3DCube, S3DRect and S3DTetraeder. I’ll get on this soon)
• Primitives S3DPoint, S3DLine, S3DTriangle and S3DMesh
• S3DMesh allows you to load a complex entity, consisting of different colored triangles, from a file.
• Rotating, scaling and moving entities.
• Rendering your entities on screen, of course :D

I concentrated the platform-specific code (i.e. X11-related code) in as few places as possible, thus its not a hard job to port it to other systems.

However, as I am currently trying to get some features into it, there is really much room for optimization. And its lightyears away from a “state-of-the-art” engine, of course! So if you’re just looking around for a good 3D engine you could use one of the dozens of other engines for productive use. This thing really is for educational purpose ;)

But if you wonder, how 3D graphics can be done - Simple3D is the right thing for you, maybe. Its well documented (I’ll improve this further.) yet but you still need some theoretical knowledge to understand the code.

Anyway, I like the idea of sharing knowledge, so here you go.

Its licenced using the MIT licence, so you’re pretty free with it - but I’d welcome it, if you give me feedback on what you do with it, okay? Thanks.

Have fun with it :)

So long and thanks for all the fish!