In April, Apple banned the use of Adobe third-party tools for the development of iPhone apps. Developers and companies watched in terror how their investment in the iOS platform was declared illegal overnight, for no understandable reason other than that Apple said so.

This week Apple reverted that ban. If you are among those applauding the move, you might be suffering from a case of Stockholm Syndrome.

The next time Apple nullifies your development efforts in order to shut down a competitor, you cannot cry foul. This time you knew what you were getting into.

• Christian Aust said 9 days later:
  

  Starting a business on the back of some other company’s products? Well, screwed you are. If Apple/Microsoft/Adobe/SAP/Oracle/… withdraw the basis of your revenues, it’s you who’s suffering. That’s the price for entering a huge ecosystem with considerably low investments.

  Flash is last millenium’s technology, no mater what. It’d be nice if it was on devices like the iPhone, but admit it: It really sucks. Big time. What’s wrong with a decision which aims at protecting the overall quality of a product?

The notion that non-technical people should write Cucumber scenarios for later implementation by a programmer needs to die. Only because someone can fall on their keyboard and produce a document that Cucumber considers valid does not mean the result is in any way useful to the process that follows.

Programmers want non-programmers to better appreciate the complexities revealed by the execution of seemingly simple ideas. But creating more artefacts disconnected from the actual implementation is only a rehash of failed techniques from the 90s. Tight integration, not increased division of labor is the way to go.

BankSimple's attempt to build a better bank intrigues me. But I do wonder if the innovative new banking frontend they announced will be a Web 2.0ish affair with lots of modal dialogs and spinner wheels. Because I don't want AJAX in my online banking.

Not too long ago, the form oriented, Web 1.0 approach to application design was lauded as one of the reasons why software was moving from the desktop to the web. Web 1.0 applications had to play by a strict set of rules defined by limitations of browser technology at the time. This was considered a good thing, for it gave users a way to understand and control their interaction with a service.

But in order to satisfy the hunger for richer interfaces, applications have come into vogue whose screens cannot be bookmarked, saved to disk or navigated with the back button. Submitting a form or following a hyperlink are no longer transparent mechanisms for the user to understand their interaction with an application. Opening links in new tabs gives us a blank page, reloading a screen takes us to a different place, and an ever-busy loading indicator reminds us of our browser constantly performing requests we never initiated.

Most of the time, the productivity gained by rich interfaces makes up for the loss of control and transparency. But when it comes to my finances, control and transparency is all I care about. When I transfer money, I don't want the transaction form show a cute spinner wheel that may or may not update parts of my screen. I want the form to do a stupid POST request. 1995 style.

• Henning said about 10 hours later:
  

  There is actually a service called Blippy which shares your credit card transactions with your friends. This is great because more promiscuity for my personal finances is exactly what I need.

• Kevin Ansfield said about 12 hours later:
  

  In fact many, if not all of those shortcomings you describe are perfectly capable of bypassing in AJAX these days. Numerous libraries are available (both for frameworks or stand-alone) that can manipulate the url’s via javascript to allow history, refreshing, tabs, etc to remain usable. It’s also possible to allow standard fall-backs when javascript is turned off.

  Condemning forward progress due to poor programming practices that have been used in the past seems like quite a backwards thought process. Surely it would be better to campaign for web applications to be done right?

• Henning said about 12 hours later:
  

  @Kevin: I understand that workarounds and graceful fallbacks are available. Few applications go through the pain of actually implementing them, due to the added complexity in code and testing (which are legtimate concerns).

  But even with those measures implemented, AJAX applications inherently have more moving parts than their form oriented counterparts. They are harder to test and more prone to errors caused by browser quirks or concurrent user input.

  Frameworks nowadays do a good job of hiding the underlying complexity. But for use cases such as banking, I’m happy about every moving part I can remove from my design.

For over six years I've been posting bookmarks to my Delicious site. Right now there are 4576 links in my account. I've occasionally felt uneasy about bookmarks becoming unavailable because of a site closing down, or a site operator who doesn't know that cool URIs don't change. This process is called link rot.

In order to find out whether I'm having a problem with link rot, I wrote a script that goes through my bookmarks and checks for dead links. The results look like this:

Since I posted at a somewhat constant pace for those six years, the following chart is meaningful:

It turns out that as far as my bookmarks are concerned, link rot is much less of a problem than I thought. When I look at posts from the last two years, only 1.38% of them are dead links. The number grows to 5% after 4 years, but I stop caring about links long before that.

Although having a strong focus on Ruby on Rails development in Germany we occasionally have a look at legacy code for friends of us (or some few customers having those dark spots and willing to pay compensation for pain and suffering usually coming with those requests).

What I saw yesterday nearly made me fall off my chair. It started with (a friend) sending me a document with hostname and credentials for FTP access. The username (of course) nearly was the password. But that’s okay, I’m almost used to it. As pure FTP is obsolete and should not be used due to several reasons anyway I don’t even care about that too much.

After logging in it took some time for me to realize that they’re doing some really weird stuff in their .htaccess:

RewriteEngine On

RewriteCond %{HTTP_HOST}           ^example.com$               [NC]
RewriteRule ^(.*)$                 http://www.example.com/$1   [R=301,L]

RewriteRule ^$                     /files/index.php                          [L]
RewriteRule ^([^/]+)\.html         /files/$1.php                             [L]

It makes the httpd deliver /files/foo.php when /foo.html is requested - I did not find out what’s the purpose of this rewrite condition (and I definitively will not ask anyone to explain).

After deeply breathing I looked at the actual file (/files/contact.php) that “causes trouble” as mails sent from the contact site do not contain special characters:

And there we jump on the failtrain…

$handle = @fsockopen("hostname.tld", 25);

Those of you familiar with TCP ports might guess what’s next…

At the end the script re-implemented (parts of) php.net/mail. Regardless to say that the “implementation” was not really complete and the broken special characters resulted from that.

A final

header("Location: ./kontakt.html?done=1");

finalized the glorious piece of code.

Lessons learned: If you plan to start a feature by opening a socket (be it listening or connecting) at least think twice and maybe ask a colleague about your idea. It’s very likely that you’re about to reinvent the wheel.

Once a week I help out on the Rails Forum. This involves me bringing up the list of unanswered topics which I will then answer to the best of my ability.

Most of the time I'm enjoying the forums. People are thankful and polite, free karma for me, everyone wins. But then there are the posts where the author pastes 10 pages of confused code with no context whatsoever and then demands to know why they're getting funny errors. I find this sort of behaviour offensive to all the people who are basically dealing out free support. I'd rather spend my time helping people who actually give a damn.

Here is some meta-advice from the people who know best:
Microsoft Support KB 555375: How to ask a question

Bugs ain't fun. Except when they are. This is the story of the greatest bug I never fixed.

In an earlier life I wrote addons for World of Warcraft. Aside from being addicted to the game at the time, it was a mindblowing experience for someone obsessed with plugin architectures and the evolution of public APIs. It was also a great excuse to learn Lua, which is a fun language.

One of the better addons a friend and I built during that period was FriendNet. FriendNet helped to deal with the greatest challenge in the game: Finding people to play with who aren't dicks. The addon took your in-game friend list and shared it with all your friends. In return, they shared their friends with you. As a result the number of people you could trust weren't dicks increased.

Because any form of network communication was forbidden by the addon API, we had to come up with a hack to distribute those friend lists. What we did was serialize those lists into in-game chat messages and whisper them to the receiving player's avatar.

Yes, years before your Mom discovered Facebook we were tunnelling social graphs over the chat channels of a virtual world. We should have gotten funding.

Anyway, FriendNet did have some quality issues. P2P applications are hard to get right, and you can't just make people upgrade every time you release a bugfix. So we had all those different versions talking with each other, resulting in a lot of emergent behaviour and hard to reproduce bugs.

One bug was especially hard to pin down: Once every few days FriendNet would encounter a corrupt message, resulting in parts of the addon GUI to be messed up. We received enough bug reports to believe that the issue was real, but we could never reproduce the bug no matter how hard we tried. It was the bug from hell. Eventually we gave up, blamed it on a buggy API and moved on.

The solution came to me years after I stopped playing the game. When I realized what had gone wrong, the light almost blinded me.

You know, your character can get drunk in World of Warcraft. After drinking enough virtual booze, your screen will start to blur and your character will no longer move in straight lines. Also when you type something into the chat like

Penelope says: I'm so wasted

It will come out like this:

Penelope says: I'm sho washted ...hic!

Because FriendNet serialized all of its communication into chat messages, it sent corrupted data whenever the broadcasting player was drunk.

FriendNet has long since disappeared from the addon sites you could once download it from. I doubt it would even boot up in a current version of the game. But even though I never got to fix that bug, I still remember it with fond amusement.

• Henning said 24 days later:
  

  @Kevin: I can’t say if there are addons like FriendNet since I stopped playing World of Warcraft along time ago. I have heard that the game has become much more casual since, and that finding a group of people to play with is now very easy. So maybe the pain we tried to fix with FriendNet is not as as strong as it used to be.

  The synchronization code itself was rather simple. When FriendNet discovered someone on your friend list also had FriendNet installed, the two instances would exchange lists and also notify each other of people logging in/out (because the game would only notify you of logins/logouts of people on your own list).

• synack said about 1 month later:
  

  This isn’t really a problem anymore. Addons now have access to an “Addon” subchannel for each normal chat channel, allowing addons to communicate. The “drunkenness” status of the character does not influence the text of the messages being sent between addons.

• Kacper said 3 months later:
  

  Wow! It’s really great bug ;)