I’ve previously worked with Microsoft MFC, which was designed that way (but remember, that was back 1992) – as was the class hierarchy that makes your Unreal Tournament tick. I’ve seen object hierarchies spreading over 15 levels, and more.

The only problem with code written that way is that it sucks. A lot.

The point is that while subclassing makes it easy to re-use code in multiple places, but it isn’t very modular. One of my first jobs involved moving one class from a branch in a convoluted inheritance tree to another branch. This meant changing some of the superclasses and – you guess it – it exploded in all the wrong places. Speak about pain.

The problem with subclassing is that each subclass depends on all its superclasses. You can’t take the code out and re-use it elsewhere, especially since most sane languages don’t allow true multiple inheritance. The larger your subclass tree grows, the bigger the dependencies grow and the less flexible it gets. Stuff from the lower rungs of the hierarchy cannot be re-used in any useful way, and the whole hierarchy may not fit easily into other projects either.

So, if you want to be extra nice to your fellow developers, including your future self, try building your application out of simple, independent blocks. The architecture astronauts have made up lots of names for that, but the concept is actually refreshingly simple.

What you can do depends on which environment you’re in: In Java (and Java-like languages, say, C#) you can make small components and tie them together using Interfaces, which describe how you can interact with an object. Which allows you to replace one component for another that uses the same interface.

In Ruby, you don’t need the interfaces since the communication between objects is pretty much free-form already. However, you get a nifty feature called “Mixin“, which allows you to write some methods in one place and then re-use same code in different places.

In any case, watch out that you keep things simple, stupid. And remember that sometimes plain old inheritance may be the simplest thing.

Photo: flickr/mendhak licensed under Creative Commons

But what if you just have a list of things that you need to submit? In this case, just name multiple form fields something[], and the params will contain an array.

Quick Tutorial

To use Rails, you will have to have the Ruby programming language installed. You can either use the native version for your environment or JRuby. For Windows there’s the one-click installer; JRuby should run everywhere, follow the instruction installations on their homepage. You will also need the “gems” program which is included in most systems, but an optional download for some Linuses (There was a git repository for the course, I deleted it because it was too large)

To follow through the tutorials, clone the git repositories and follow through. Each step is explained in the checkin message.

Once you have got Ruby installed, you should be able to just call

gem install rails

to download and install Rails. For further instructions follow the pointers on the Rails homepage.

Getting Started with your first rails App

To get started with your very first, very simple app you’ll just need to do this (the commands in [brackets] may be needed for jruby users):

[jruby -S] rails my_first_app
cd my_first_app
[jruby] script/generate scaffold User name:string birthday:date
[jruby -S] rake db:migrate
[jruby] script/server

Your application will now be available at http://localhost:3000/users
(If you use JRuby, you may also need to install a Java database and configure the database through database.yml)

Pointers to what happened:

• generators are used by Rails to create the templaes and files that are the starting point of your application
• rake is a “make”-like program that you can use to run maintenance tasks from the command line
• scripts are some Ruby programs/scripts that come with Ruby
• migrations are define the schema of the “database”. Migrating will create your database tables and fields

On the Ruby language

You can have a look at the introductory book (available online), or have a look at why’s more anarchistic “poignant” guide. There’s also a number of books available in print form

On Rails

Many resoures on Rails can be found through the home page, and there are tutorials and video instructions available on the web. It also pays to follow the Rails Edge blog and the Railscast if you want to stay up to date on new techniques. Mailing lists exist in almost any country or language, and are a good point to ask questions.

A good introduction is the book “Agile Web Development with Rails“, and there are also others.

Other

If you’ve got any more questions you may also leave a comment her.

And then, there’s the business of “informing” people with a weenie blog post. It wouldn’t have been so hard to send a single email to all users of that service that, um, it had been discontinued? Or am I obliged to follow their blog to be on top of all the newest stunts? On the blog post also note the “we broke it, but you can help someone else fix it” punchline.

In any case, my own gems will be available from github for the while being and when I push a new version they’ll probably go to gemcutter. Follow this blog to be on top of my stunts

Adding another git repository as a submodule couldn’t be more easy:

git submodule add <other_repo> <local_path>

This will clone the “other_repo” and put it at the given path. The first thing to note is, that this is a completely independent repository. It will not be pushed, pulled or commited automatically when the “parent” repository is modified.

Unlike a svn external, the submodule is a “pointer” to a specific revision instead of a URL. This means that, even if development on the submodule repository continues, your project will always use the exact same version of that module until you change that version.

But how does it work?

When creating the submodule, git creates two new things: A file called “.gitmodules” and a “fake” entry in the repository, which represents the submodule in the file system. Just think of that as a symbolic link to a specific revision.

When someone clones the project, they will get the “.gitmodules” file and will have to do the following drill:

git submodule init
git submodule update

First catch: The “init” command will read the “.gitmodules” file and simply add it’s content to .git/config”. That’s right, it will copy the configuration, and the “.gitmodules” file will not be used any more. Changes to the “.gitmodules” file will have no effect after you called “init”. The only way to re-update your configuration is:

git submodule sync

Second catch: The submodule is a full-blown git repository. Its contents are completely invisible to the parent repository, but the parent repository tracks the “pointer” to a specific version. When you do a “submodule update”, the system will always fetch that particular version.

But if you modifications to the submodule, by checking out another version/branch (or something like that) and then commit the parent repository, you will modify the “pointer” in the parent directory (assume the submodule is in ./submodule):

git submodule init
git submodule update
# -> ./submodule now points to revision ABCE
cd submodule
git checkout XYZ
# or hack, push, whathever ;-)
cd ..
git commit 
# -> ./submodule now to points to revision XYZ
# Once you push, all other users will get XYZ when they
# do a "git submodule update"

Third catch: Updating submodules is not automatic. When you do a pull or merge, the “pointer” might be updated – but the submodule repository is not.

# submodule is currently at ABCE
git fetch
# submodule now points to XYZ, but the repository is unchanged:
cd submodule
git status
> ... repository is at ABCE
cd ..
git submodule update
# submodule repository is updated to XYZ

(Disclaimer: I compiled this to the best of my knowledge, but I didn’t have time to verify that it works as I promised…)

GitHub has a link next to the comment box that says “Parsed with GitHub Flavored Markdown“. When you click it, you end up on a page that tells you how their flavour is different from the standard one and then…

If you’re not already familiar with Markdown, you should spend 15 minutes and go over the excellent Markdown Syntax Guide at Daring Fireball.

They’ve got to be kidding me. Not only had I to follow a link with a totally unhelpful label. But then they have the balls to tell me “please waste 15 minutes of your time reading some external documentation before posting a comment. Thank you very much.”

I tell you what I’d have expected: A link called “Help” that shows you a popup with a summary of the most important markup tags. Even the most retarded forum software can do that.

It shows in other places, too. Their help pages consist of a kind of wiki with a semi-random collection of help articles. You’ll only reach them if you figure out the difference between “Help” and “Support” in their ever-changing footer. Once you get there, the only way to go back to to home is to click their logo in the header. Unless you accidentally went to “Support”, where you have to use the “Back to github” link. I usually rather use Google to find something on their site, wondering how you can violate such basic rules on a commercial, professionally designed page.

But my problem isn’t really with GitHub or with a new product having some teething problems. I guess my problem is with the attitude of that blogosphering, Twitter-following, Web 2.0-hyped geeks that are around at the moment.

It dawned on me that it’s 1999 all over again again. The “Web 2.0″ really is the new economy with the new kids thinking that the old rules don’t apply to them any more. The hubris is the same, just with less funding: We will make the old world obsolete. We’re the avant-garde of the how the future will look like. Our software is opinionated, and we’re proud of it.

And, above all, the new kids want to look cool, and I suppose that reflects in the interface: “Help” is boring. But look, Ma, I can parse my own flavour of Markdown – how cool is that? And I’ve even have a page showing you how it works! Supercool! With source code!

That’s how things like RESTful authentication are born. There’s no actual reason why authentication should have a REST interface. There are no resources involved, unless you subscribe to the mind-boggling notion that a user session is a “resource”. Still, all the other cool kids have REST interfaces in all the wrong places, so you want one too. Totally cool.

You may even get away with it – people don’t care what’s inside, as long as it works. Still, you’re walking a dangerous path. Although it’s possible to make a living by creating cool stuff that make people look cool – just look at Apple – it doesn’t happen that often. If you can pull it off, more power to you. Otherwise beware.

Guess what: The old rules still apply. Those of us old enough to remember the world 10 years ago have seen it before. Your bosses, customers and financiers give a flying fart about whether you look cool. They just care if your stuff is useful to them. And if it’s not, they’ll probably get annoyed and blog about it.

Or they just walk off to work with those boring people who actually care.

• gokdok – automatically upload your rdoc documentation as github-pages
• watchdogger – a little watchdog daemon that’s quite configurable

The gokdok thing addresses fact that github offers you a space for project pages, but in no way helps you to build your documentation or upload it. It’s just a small rake task, but it works fine for me (and we finally have fresh rdocs online again…)

The watchdog was made to monitor our instance of Tomcat. At the moment it does exactly what I need it to do, which is monitoring some web pages and the log file and killing the server process in case of trouble. It should be very easy to extend.

Image Rights: http://www.flickr.com/photos/pleeker/ / CC BY-ND 2.0

I’ve moved the project to github now, and the gem is not broken anymore. This means that you can

sudo gem install averell23-assit

from gems.github.com. The old gem (assit) is still around on rubyforge for some reason, but it’ll remain on 0.0.3 forever. If you use this, better get the github version (averell23-assit) now.

Clicking normally will not connect to the server, while shift+reload will force a re-download in all cases.

No, not the broken scheme from that article, but I had needed to use some crypto functions to verify some data that had been handed to the user before.

The problem was similar to the one above: I had to stuff some session data into a hidden field on the page. When it was re-submitted, I needed to make sure that the incoming data blob had been tampered with by the user. Meaning that I needed to verify if a given piece of data actually came from a trusted source.

Reviewing my code, it doesn’t look too bad: I didn’t use some strange shared-key encryption scheme. In fact, I didn’t use encryption at all – if your data is “secret”, you probably shouldn’t send it out to the user in the first place. Instead, I’m just encoding and zipping the data and then slab a MAC (Message Authentication Code) on it. I’m passing the whole stuff of to OpenSSL, so the implementation should be reputable enough.

It’s more or less the same mechanism that Rails uses for it’s session cookies. I even added a nifty little feature that the secret key is automatically generated on the first startup, so there’s no default value that you have to change.

Still there could very well be a bug, and the evil thing about crypto bugs is that you never notice them, and you can’t test for them either. So I’m posting the code below – have a go and see if you find an exploit.

The weaknesses I’ve seen so far:

• I’m still using MD5, as it is the most portable at this time. While it has been successfully cryptanalysed, cracking it will still take more effort than it’s worth for the sites I’m working on. Plus there, are probably more promising angles of attack. Nonetheless, it’s a no-brainer replacing the algorithm when needed.
• There’s no protection against replay attacks, as I simply didn’t consider it important for the application.

Luckily, someone already posted on how to weed out this crap, and prevent Google Earth from ever reinstalling it…

Obviously, Microsoft did this to avoid actively offering competing products on their platform. And I honestly wonder if Opera is really expecting MS to do the marketing for them. But in the end, even if the this move makes a bit more sense than previous ones, not much is going to change in the grand scheme of things.

It’s funny how everybody is speaking about the browser “market” and “vendors” – as if it existed. There is no market for browsers, and never has been, because no one is paying for them. The browser has become a piece of infrastructure, that people expect for free. As infrastructure is important, everyone wants to be a player – but that doesn’t change the fact that it’s near impossible to make money on (desktop) browsers. I’d guess that’s even true for Opera – they probably live of their embedded products, for which they can charge.

This basic setup is not going to change, no matter if Microsoft pulls IE from Windows, offers a choice or whatnot. And it means that if you make a browser, you’ll have to put in money that you got from somewhere else. That’s how Microsoft won the first browser war: They could afford to sink shitloads of money in IE, even after the first crappy versions didn’t swim. Netscape just dropped the ball once (but then, did they drop it hard), and they were out. Once the competition was done for, Microsoft ceased development.

Once Firefox rose from the ashes, they gained real market share (in spite of all “monopoly”), because they could offer a superior product once again. Interestingly enough, they also overtook Opera easily.

So from the consumer point of view, things don’t look so grim. Enough competition is around now to keep Microsoft on their toes, and ensure that browser technology continues to develop. Browsers are also pretty standardized by now, preventing a vendor lock-in. As far as I can see, the time for a useful intervention has passed.

Of course Microsoft (and pretty much every other player) would still like to lock us in. But I doubt they’re still playing the browser game – rather they’re already starting to push new technologies (like Silverlight) to that end.

But one statement caught my eye (unrelated to any evil plan):

I’ve often wondered if eBay would implement this [random feature], as it would effectively end last second sniping, a huge problem for auction sites.

This is utterly untrue. Sniping isn’t a huge problem for eBay. It isn’t even unfair in any meaningful way.

But the really interesting fact is that, although eBay’s system is dead easy, even reasonably intelligent people like Jeff Atwood only get it when thinking it through. I didn’t do any research, but I guess that around 80% or 90% of the eBay users don’t know how the auction system really works. And although they may be aware of “sniping”, they don’t know how it works (or doesn’t work), either.

I suppose this is because it’s really hard to rewire our intuitive understanding of “auction”.

Even people who haven’t been to an actual auction will know how it works: You call out bids, each one higher than the previous, and the last one wins. Say we’re bidding for those old Chinese vase: I’ll call out €20, Jeff raises to €25, I raise to €30. And so on, until Jeff gives up and I win. The last bid wins.

Everyone knows this scheme, it became hardwired in our brains to the word “auction”. And then eBay comes along and makes a slight (but crucial) change to the game: Instead of entering a straight bit, I put the maximum amount I want to spend.

Let’s take that vase again, with a minimum bid of €20. I enter my “bid” first, at €300 – but the price will now stand at $20. Jeff comes along and bids $250. Since that’s less then my €300, eBay will increase my “bid” to €251. If Jeff raises to €1000, the system will raise his bid to €301 – just high enough to beat me. And so on, until the auction expires.

In theory, each user should place exactly one bid with the maximum amount he wants to spend. The “bidding agent” figures it all out and the person who wants to spend the most wins. Sniping is not a problem.

In reality, there are these psychological things happening: First off, many people aren’t aware of how bids work. They won’t read the instructions either – “I already know what an auction is, thank you very much”. These people bid like they would in a traditional auction – if they see a bit for €20, they go to €22 and watch the page to see if someone goes higher.

Other people will actually know the scheme and will bid their “maximum” amount. But when they see that they are loosing, they decide that maybe one could go up to €450 instead of €400. And in the heat of the auction, they go higher than they actually planned to.

People don’t act rationally on eBay. They interact with each other, based on how they think the system works.

This is nice if you play eBay as a game. It’s also nice for sellers, because the only possible interaction in this game is “raise the price”. But the eBay psychology doesn’t help the people who just want to buy things. That’s why they use sniping.

The only thing sniping does is to remove the interaction. If you bid ten seconds before the timeout, no one will be able to react any more. But it’s not important that you enter the last bid – just that no one can react any more.

Example: Joe bids €20 initiall, Jeff bids €300. If I snipe ten seconds before the end for $300, I’ll get the thing for $22. If Zed also snipes, 5 seconds before the end, for $200, I still get the thing for $201. Jeff can’t react (and decide that he’d go up to $500 – but if he had bid that initially, he would still win. And so on…

Morale: If you design software, deal with people’s preconceptions.

We are seeing a lot of similar reports from various developers who’s applications were abruptly removed and banned from the AppStore without any violations of the terms of service.

This behaviour (on part of Apple) is incredibly arrogant and unprofessional, and it discredits the platform for developers. Would you invest in the development of an app if you knew that someone else could later pull it off the market on a whim?

The most amazing thing is how they manage to pull this off – obviously the Mac fanboys are willing to go through anything…

Edit: It continues: Apple also refuses applications for no other reason than that they compete with iTunes. It even stirred up some bad press. Apples solution: Make the rejection letters confidential.

And even more: Seems that email clients aren’t allowed either. Oh, and not only do they want to have the last word on the App Store, but they’ll also rescind your ability to distribute your application by other means.

Usually the preferred installation (and deinstallation) method on the Mac is drag-and-drop, which is really the best method I’ve ever encountered on any operating system. But for packages that need to be integrated into the system, such as ours, Apple has a built-in-installer package mechanism.

The installer itself is not too bad, although it doesn’t even consider that you might want to uninstall anything. But the worst part is definitively the “PackageMaker” application that comes with Apples developers’ tools.

I’ve seldom seen such a sorry excuse for a tool – it will actually loose settings if you uncheck a certain box in the UI, and more fun like that.

Fortunately, I found a nifty tool called Iceberg, which let’s you build Apple-compatible installer packages. Though it’s still a bit rough in some places, it’s already richer in features and works much better than the default Apple solution. Check it out if you need to create any Mac installer package.

Still I admit that Apple, as a company, is probably one of the most evil there is.

This post from Coding Horror sums up some of it: People give up control over their devices, trading it in for a good user experience.

But even if people will flock on the side of coolness instead of freedom: Locking down your customers’ devices is an unacceptable practice and ought to be outlawed.

Update: It seems they can even remotely kill applications from your device. In the, it’s much preferable to have a solution like Nokia/Symbian that is based on technical criteria. It also asks for confirmations of sensitive operations. Apple goes the path of “give us full control, we take care” – after you go through their “review” you can do things like accessing the address book without the user ever noticing.

This problem is hardly limited to Apple, but the new iPhone sets a new trend. Although it’s finally “open” to 3rd party software, you can only install it through Apple’s App Store. Which is convenient for developers and users – except that each application has to be “approved” by Apple.

Read again: Your ability to run a certain program is subject to the approval of Jobs’ company.

And there is a first victim: NetShare, a great little software that lets you use your iPhone as a modem. It got on and off the App Store for a while, currently it seems to be down. It seems that it didn’t even violate any of the outrageous terms of Apple’s “agreements” – they just provided a basic functionality that is built into most “normal” smartphones in the first place.

Rumor has it that this is because AT&T got pissed – they don’t allow people to use their iPhone plans for tethering. Which would basically mean that Apple randomly fucked over their customers and cheated an independent vendor out of their investment. Just so. It’d make perfect sense to them, and they’ll probably get away with it.

And Apple aren’t the only ones doing it. There is a Wii game console on my shelf. Nintendo went to a lot of trouble to make sure it only runs games that they approved; they even charge developers to be able to use that platform.

The common point about all these “solutions” is that their are driven solely by business interests and have nothing to do with customer needs. They protect business plans.

So when the Free Software Foundation gives you five reasons to avoid the iPhone, they are surprisingly right.

Their alternative will, unsurprisingly, fail: Yes, I could get a Neo FreeRunner – a cool little toy that gives me all the freedom I want, even looks cool, and probably only requires an hour of yak shaving in order to place a call. This is the problem of open-source “alternatives”: They give freedom, but only to those that are able to grasp the system and are willing to go through all the pain.

The sad thing, however, is that people seem to take this state of affairs as a given fact – even if they are aware of it. They don’t challenge the very idea that companies have the right to do evil to protect their business plans.

I think that this behaviour should be simply outlawed, just as other harmful practices. The European Union actually did some good steps in that direction – interoperability is protected by law, and they even made Microsoft publish lots of their specs as a result.

And as much as I appreciate “hacker” efforts to open those devices I’d rather see the concept itself torn to pieces. The companies should be forced to grant their customers full access to the devices that they paid for in the first place.

> jruby script/console
>> ActionController::Routing::Routes.recognize_path('/my/path', {:method => :get})