Thursday, November 26, 2009

Mexican Fire Bean Soup (Actually not as spicy as the name, for 20-24 people)

Wondered what that awesome soup was on my parties?

Here's the recipe!

Prepare/add in that order:

400gOnions. Fry with 200g butter.
280gTomato puree and some Paprika powder.
400gRed and green peppers.
150-400mlSweet Chilli sauce. Try less first, maybe add more as you like.
2lMeat stock.
1lSweet cream bound with 4 table spoons of flour.
4Cans of red beans.
2Cans of sweetcorn.
1kgLean pork or beef. Cut in slices, fry with salt and pepper, add it.

Maybe add a little starch if it's too thin for your taste.

Serve with 0.5l sour cream.

Wednesday, April 1, 2009

Short URLs are so 2008. Long URLs for the win!

Do you find it annoying when you receive URLs which are completely meaningless?

How many times have you clicked on a link and would've known from the web page's title that it's not of interest to you or that you've even read it already? That happens a lot to me and so I present the solution:

It's simple: You enter a website, and get a URL that contains the page's domain name, title and optionally an excerpt of its content. If you now share that descriptive URL the recipients will me much happier receiving it instead of the cryptic original URL.

The URLs above will be converted to these much more descriptive URLs:

Also, everybody seems to create URL shortening services at the moment. A URL enlarging service is just the next logical step!

Summary: Descriptive URLs are nice, but unfortunately not every website uses them. fixes that.

Oh, by the way, there is a bookmarklet for the service, too: Long "R" Us

Saturday, March 7, 2009

FOWA Dublin Notes: Doing a Startup in the Real World - by David Heinemeier Hansson (37signals)

This was the last and probably most enthusiastic presentation. It was really good fun watching David's talk.

Fuck the real world

A lot of ideas "will not work" in the real world — or at least most of the people will tell you that they won't.
On of David's example was that a few years ago Java and PHP dominated the market for web application development and "in the real world" out wouldn't work challenging them. Despite that, he wrote Ruby on Rails anyway and it was a huge success.

Too simple

Often people will say that it's not worth implementing seemingly trivial tools. David's counter-example are the 37signals applications which are dead simple. And in fact a lot of people have simple problems and appreciate simple solutions to them.

Another example was the camcorder. This "problem" seems to be solved for years and it seems to be impossible to challenge the big players with years of experience in that area. Until tiny cameras with nothing more than a USB port conquered the world and were sold millions of times.

No plans

You need good plans to get things done and working.

Wrong! You cannot predict the future. Plans are often obsolete very early and rarely ever work out. 37signals products are very successful without any business plan.

Say no

"No we're not going to implement your feature request".

Yes, you should listen do your customers, but you need to be able to say "No!". Otherwise you not only spend much more time and money but also risk to lose the focus of your product.

All rock stars

To have a successful company you need to hire rock stars.

That's not the case according to David. There are no rock stars! What counts is a rock star environment, where everyone can live up to their potential. Trust your employees, give them responsibility, they are not stupid!

Easy domain

Simple tools are too simple to imitate and it's likely that a big company will copy it and win the battle because of their enormous resources.

In fact, easy tools are not necessarily easy to develop. Simplicity is very hard to achieve. Even the biggest companies often have a hard time challenging a well done, simple product.

Pitch the killer idea

It's all about the idea!

No, it's not. Successful businesses are much more than just an idea.

An idea is so small part of a business that it's almost a rounding error.

David Heinemeier Hansson

Friday, March 6, 2009

FOWA Dublin Notes: Web application security horror stories - by Simon Willison


Simon started his both entertaining and informative presentation by talking about the probably most commonly known Web Security threat: Cross Site Scripting (XSS).

An XSS attack is possible when others can inject JavaScript into your page (e.g. via forms or URLs). The attacker is then able to perform virtually any action on the attacked site, just as if they were you.

Myspace Worm

The MySpace Worm was a result of an error in the sanitization of user-provided HTML. The injected code caused the visitor to add a friend request to the attacker and put the attacker's code on the victim's page as well. That way, the attacker had more than a million friend requests after 20 hours, finally bringing MySpace down.

Google UTF-7 hole

A missing character encoding header in Google's redirect pages allowed the users to inject a string into the page which caused Internet Explorer to interpret it as UTF-7 content and execute included JavaScript.

Don't trust CSS

CSS is not executable, is it? Well, you can include active components into CSS by using HTC in Internet Explorer or XBL in Mozilla. Also a position: absolute hack allowed an attacker to steal 30,000 MySpace accounts.

SQL injection

You never ever glue user-provided strings together with your SQL queries. Instead, use parameterized queries or an ORM. This is much safer and also easier to maintain.

A nice variation is to use SQL injection to create a mass XSS: You can insert JavaScript into a database which will then be potentially displayed on every page of the attacked website.


Cross Site Research Forgery is probably one of the most wide-spread vulnerabilities as a lot of developers are not aware of it or don't care about it. If you haven't taken any action to prevent CSRF your site is most likely vulnerable to it. Popular examples are the Digg-exploit (a self-digging page) and the Gmail filter hack.

Just using POST requests for your forms doesn't help. Instead, you have to use hard to guess transaction tokens which the server checks for every action. This, of course, can be useless if your site has an XSS vulnerability as the attacker can then steal your token.


Clickjacking is tricking the user into clicking on a certain link or button. This can be done for example by showing a button which to user wants to click on (e.g. in a game) with an Iframe that has the CSS opacity: 0.0. That way, the Iframe will actually receive the click although it's not visible to the user. The Twitter Don't Click This hack was an example for a Clickjacking attack.

You can prevent this attack by using JavaScript to check whether your page runs in an Iframe. Unfortunately there is no standard way to prevent this when the user has JavaScript turned off, what makes this attack quite dangerous.

Insecure admin accounts hack

The recent Twitter hack was actually caused by a dictionary attack on a popular user's password. The password was "happiness", the user was a Twitter employee with admin access. So you should make sure that admin accounts get an extra protection like limiting the access to users on your local network only.

FOWA Dublin Notes: How to build desktop apps that help your web app succeed - by Matthew Ogle (

Most of's data comes from desktop applications tracks ("scrobbles") the songs that people are playing. The Scrobbles come from iTunes, WinAmp, Windows Media Player, the iPod, Zune, Spotify and even Emacs. So's desktop applications are one of the most important data sources for the service.

This adds up to about 8,000 Scrobbles per second or about 30 billion Scrobbles in total until now.

Desktop technology is moving to the browser

Desktop applications and and web-based applications converge. Desktop applications contribute data to web-based services and browsers gain offline functionality (Google Gears) or run as as desktop-like applications (Adobe AIR, Mozilla Prism).

Another example from is Boffin which shows a tag cloud for your music and allows you to play songs for the tags that you selected.

Some tips for your applications

  • Make it selfish: The users should use it for their own benefit.

  • Make it open: Provide APIs which can enlarge the audience by new applications.

  • Create on-ramps to your web experience. Data from desktop clients can be very valuable.

  • Befriend local desktop developers, trade notes. Desktop development knowledge gets more relevant as technologies converger.

  • Use your web smarts to make the desktop exciting again. The web doesn't end at the browser.

FOWA Dublin Notes: Apps for All in a Web 2.0 World - by Robin Christopherson (AbilityNet)

Robin Christopherson from AbilityNet, a UK based charity helping disabled people to use computers and the internet, opened our eyes for seeing (or rather hearing) how a visually impared person is using the Web and what obstacles they face.

CAPTCHAs are telling disabled and non-disabled persons apart, not only humans and computers

CAPTCHAs are most often implemented using images. A screen reader is obviously not able to read the letters in the image (that's the purpose of a CAPTCHA...) so people using screen readers are locked out.

Fortunately, a few sites offer audio CAPTCHAs. Unfortunately these are so heavily distorted so that not only computers fail at understanding them, but humans fail, too. An entertaining example is the Google account sign-up page.

Text-only versions help

There is a non-advertised HTML version of Google Maps which provides usable text-only directions. Often, less can be more.

Automatically starting video/audio sequences are annoying

If an audio sequence (which can be part of a video) starts automatically it overlays the screen reader's voice making it very hard to navigate the page. One of the most popular examples might be YouTube.

I find this very annoying myself even without having to use a screen reader. I use Flash Block to prevent this.

So it's much better to have a user-driven start of animations. Also, it really helps to have audio descriptions for videos that explain the scenes.

Websites are getting unusable when changing the font size

Many websites use fixed sizes for their layout. When you resize the text it can largely overlap as the layout doesn't adapt to the new font sizes -- making the content unreadable.

A more accessible alternative are Liquid Layouts where the layout adapts to the font size.

Flash is next to unusable...

...unless you use the Flash Accessibility Layer and make sure a keyboard navigation is possible.

Overall, this was a very interesting presentation and the first time I've actually seen somebody using a screen reader to browse the Web.

Tuesday, February 3, 2009

What's this about?

This blog is part of my personal website

I'll use it to write about things that catch my attention and that might be worth sharing. Topics will likely be related to software engineering, web technologies, design and (electronic) arts.

My website itself features much more than this blog, though. It contains updates about what I do on the web ("lifestream") as well as some static pages about this I created.

For the technically inclined: That page is built using Pylons and jQuery, runs on Google App Engine, uses my Friendfeed and my wiki as data sources. Besides caching it doesn't store any data itself, the page lives completely in the cloud.

There you can also find more information about my website.