At Vemble we’re all into using new technologies that just work better. We’ve switched to Mercurial, then soon after to git and moved our code base to GitHub. We’ve stopped writing JavaScript and started using CoffeeScript instead. We’ve converted our CSS to LESS, then to SASS and Compass. Every new tool or framework that works better than the previous one is highly welcomed.

If you’re part of an innovative start-up or work on a team that encourages the use of new technologies, you may not even realise how awesome that is, until you see other people (especially programmers) stuck in spaghetti-code.

I came across this video while looking a question on StackExchange programmers about the Principle of Least Astonishment.

A textbook formulation is “People are part of the system. The design should match the user’s experience, expectations, and mental models.” What is least surprising may however depend on the expected audience, e.g. end users, programmers or system administrators.

Lately John and I have been working on improving the Vemble API. We came to a conclusion to use HTTP PATCH for updating only parts of an object (like GitHub’s Gists API does), and the Prefer header for selectively retrieving objects.

Real science is all about critically appraising the evidence for somebody else’s position.

Recently I’ve come across a ruby irc server called camper_van. What it does is pretty simple: it communicates with Campfire while acting as an IRC server. That, combined with irssi makes it much more fun to use Campfire for work.

The following is a simple script that starts the server (if not already running) and then opens up irssi in a new gnome-terminal session.

Below is a sample irssi config file (merge it with ~/.irssi/config).

I’ve recently learned that App Engine chokes on HTTP DELETE requests that contain a request body. While developing locally, everything works just fine, but when deployet, the production server drops these “malformed” requests with a “400 Bad Request” status line, so that it doesn’t even reach the application in the WSGI pipeline.

After reading the specs I couldn’t find where it would state that a body is not allowed for DELETE, it does state however that the request URI should be enough to identify the resource and that no extra parameters should be required (so I guess many servers just ignore the body there).

Anyway, since App Engine is so strict about requests (which is a good thing anyway), it would be cool if Sencha Touch 2 could be somehow forced not to send an XHR payload when deleting a moel instance using the REST proxy. There seem to be no config option to prevent a request body, and when I asked in the forum, I got no decent reply.

After reading the source, I came up with an override that fixes this behaviour.

UPDATE: Since overrides are now deprecated in favor of Ext.define, the following is a correction to the above fix:

My old domain name, aatiis.me, is about to expire. I registered it at GoDaddy last year, but later on I’ve changed my mind to not paying another dime to them.

The plan is now to move all the posts to the Aiur blog (i.e. this blog). Since all the old posts are written in markdown, the idea was to move to a Github-hosted Octopress-based blog. Octopress is a great platform. Quoting the website, it is:

[…] a framework designed by Brandon Mathis for Jekyll, the blog aware static site generator powering Github Pages. To start blogging with Jekyll, you have to write your own HTML templates, CSS, JavaScripts and set up your configuration. But with Octopress all of that is already taken care of. Simply clone or fork Octopress, install dependencies and the theme, and you’re set.

And the favourite part about Octopress is that I could keep writing my posts in the [greatest text editor ever made] :)

But then I’ve decided to try something different: [Tumblr]. It seems to be simple enough, it’s free, and it supports custom-tailored themes (will be trying to play with that in the future). Downside is that I now have to write my posts directly for the web, and I can’t use git for that (well, I could just keep writing posts in markdown & compiling them using Jekyll, committing them to the website’s repo & pasting the generated output here in Tumblr — that’s something to try.)

UPDATE: it appeared to me that tumblr now supports markdown, so that makes life a lot easier. All I have to do now is copy the posts.