The Keyboard in Dishwasher Project
January 16th, 2009 by Ivo
Last saturday the sun was shining into my room and it nicely enhanced the gross state my keyboard (a wireless Logitech natural keyboard) was in, after years of typing, which must be zillions of key presses (and having breakfast while reading my daily portion of websites):
At that point I thought that either I would go out and buy a new one, or I'd try something radical. I remembered from childhood that you can put LEGO bricks into a washing machine if you put them inside a pillow cover, and I planned on doing something similar with the keys of the keyboard. While googling if that wouldn't erase the print on the keys, I actually found a guy that used the dishwasher to clean the keyboard.
This could be a bit tricky, but given the state it was in, I thought 'oh well, why not'.
So, after removing the batteries and taking off the wrist pad, I put it in the washer:
I just tossed it in the washer with the rest of the dishes; upside down so the keys would get the most thorough treatment. I added a normal 3-in-1 cleaning tablet, and had it run at the 50 degrees Celsius 2-hour Economy program.
When it was finished, I took out the keyboard, and it was completely soaked:
I poored out the water, took out all the keys so the keyboard would dry more easily, and left it to dry:
After 5 days (it may look dry, but you have to make sure all the inner parts have dried too), I put all the keys back in. This was an interesting puzzle; I had pictures of the layout but I managed to put in everything without looking at them
. I inserted the batteries and voila, it worked out of the box!
The end result:
So, YES, you can put a wireless keyboard in the dishwasher!
Disclaimer: This may or may not work for you. If you give it a try, it's at your own risk. Do share your experience in the comments, but don't complain that it's my fault if it fries your keyboard.
P.S. I expected the stickers on the back to come off, but although they have a few small bubbles now, they came out fine.
2008 in retrospect
January 11th, 2009 by Ivo
I never did any posts looking back at a previous year, but 2008 has been such a great year that now might be a good time to start such a tradition. I already did a 2008 lookback on our company blog, so I'll stick to more personal things here.
- In 2008, I had my first book, php|architect's Guide to Enterprise PHP Development published. So far it's been quite succesful, in November it got a spin-off in the form of a monthly column in php|architect magazine.
- I never traveled so much in a single year. According to Dopplr I did 19 trips. The trips included many conferences (phpUK, InternetWorld, php|tek, DPC, ZendCon, PDC, php|works, phpNW, mswds), visits to customers throughout Europe, an Ibuildings UK/Ireland roadshow and many visits to our London office). Only one of the trips was a short vacation to Paris. Next year should have less travel and more vacation time. Drawback: I gained 12kg in weight from all the trips and conferences. This should come back off in 2009.
- In April of last year my girlfriend and I bought a house. It was supposed to be finished by December, but it's still under construction and the current estimate is April. I'm really looking forward to the moment it's finished. At the moment we're still busy trying to decide how to decorate it.
- I wrote 37 blogposts on this blog, the majority of which are in the PHP category. At an average of 3 posts per month, I think that is a good frequency to stick to in 2009. The most successful post has been the Chicken post with over 40 comments.
- I started using Twitter in January last year. After a year of using it, I can say I really like the service. Despite its many shortcomings and frequent instabilities, keeping in touch with a large number of people in efficient, short messages has a significant added value on top of all my other forms of communication. A good article on why Twitter is not a waste of time, is this one.
- Back in September, I launched the Elephpant World Tour together with Cal Evans. It's been quite a fun project and the 2008 contest is almost over. (The phpwomen are currently judging the entries.)
- Also in September, I managed to convince Cal to come work for Ibuildings and move to the Netherlands. Although I am extremely happy to have a once remote friend now close, I feel a little bit guilty for throwing his life upside down like that!
That wraps up some of my, part professional, part personal, highlights of 2008.
2009 should be an interesting year as well. If it's only half as eventful as 2008, it will still be a very good year. We'll see!
Client side Java, Take Two
October 23rd, 2008 by Ivo
Back in the late nineties, when many websites still looked like this, the people at Sun had a vision that the web could be so much more than static HTML. They created the concept of Java Applets that could be placed on webpages to make them richer and do stuff that HTML just couldn't. Like adding animated menus and hideous buttons.
This was quite the cool thing to have at the time, but there were a few fundamental problems. One: it was horribly slow. Nobody really cared because at 28K8 modem speed on a 486, anything was slow, so the few extra seconds it took to load the Java stuff was accepted, at least for a while. But the second problem was that it was quite unstable. More often than not, it would crash your browser. (There's actually about a 1 in 4 chance that the above link still crashed your browser today, 10 years later; the significant improvement is that Firefox will have remembered what page it crashed on and will let you re-experience the crash upon restart. Twice the fun.)
So with most Java developers not getting beyond the 'L33T, I HAZ CREATED A BUTTON!!' stage and HTML, CSS and JavaScript gradually becoming rich enough to create hideous buttons without Java Applets, the technique more or less died. (Well, Java itself didn't; it firmly grasped on to the enterprise software market because the former button developers had kids to feed.)
We then had a few years of plain HTML/CSS/JavaScript happiness with the occasional Flash animation, when suddenly the big guys thought it was time to enrich the web again. Not with Java of course, which people still associated with fancy buttons and crashing browsers, but with new shiny technologies like Silverlight and Flex. (Sure, both Microsoft and Adobe are in favor of open standards as long as they can each have their own standard).
The concept is very much the same, both Flex and Silverlight allow you to create buttons! But this time, we use a Three Letter Acronym, because *THAT* was what Java failed, the lack of a proper Three Letter Acronym!
We call this modern variant of user interface richness: RIA, for Rich Internet Application (maybe it was supposed to stand for 'Rather Implemented an Applet' though). Like in the past, the idea is to do stuff in the browser that HTML won't let you.
Sun, who years ago created the RIA avant la lettre with their Java applets, must have watched this trend in amazement. And now that RIA's are in the early adopter stage and have enough momentum to become mainstream, it's time for them to give it another try. They are relaunching the applet idea with what they call 'JavaFX' (come on, that name just sounds like 'fancy button' all over again). Details on this can be read in this article on TechCrunch.
Interesting times are ahead. With Google Chrome possibly igniting the Third Browser War, we'll also see the RIA wars, where JavaFX, Silverlight and Flex will battle to become the dominant technology to create rich internet applications. One potential outcome: they all fail and the outcome is an improved, richer version of HTML and plain old JavaScript. Another potential outcome: they will all find their niche and we'll get incredibly cool apps. Back in the days of the Applet, the web was relatively immature. We weren't ready for real web applications. Maybe that is why Java Applets didn't survive the Button stage.
This time around however, more and more applications are webbased, so there's quite a big chance that this time, RIA technologies will catch on and outgrow their Button stages and give us some really compelling browser experience.
Time will tell. Let's look back at this in another 10 years or so.
The Twitter Model – the modularized service
August 15th, 2008 by Ivo
I've been using Twitter for a while now. It's one of those things that if you don't have it, you don't know why you should, but once you use it, it becomes so common it's hard to imagine life before it.
There's quite some controversy surrounding Twitter. For a while, everybody was complaining about its stability (or rather the lack of it), but people continued to use it regardless, and lately, it's been a lot more stable (it still has bugs but at least it's up).
Another popular subject is the apparent lack of a business model. Twitter seems to follow the 'find an audience first, find revenue later' model. But this has its problems. On wednesday, twitter dropped the popular SMS feature because they could no longer afford it. While this feature hasn't been working properly for me anyway, this has made a lot of their users angry.
But rather than being a symptom of the lack of a business model, I think this sheds some light on the way Twitter's model actually works. What I've noticed about twitter is that they develop their service in such a way that it is completely modular. Take the posting of messages. You can do that on the twitter website, but the majority of its users use third party tools that connect to twitter's API to post messages. (Some of these even have their own business model, like injecting ads between the Twitter messages).
Another such modularized feature is searching tweets. Twitter didn't have a useful search feature, but because of the API, a company called Summize was able to build a very good twitter search engine. There were others, but the Summize service was so good, that Twitter bought Summize and the feature is now available at search.twitter.com. (There seems to be a bit of irony here; Summize also didn't really have a business model, but they sold their stuff to twitter. Twitter on the other hand, paid a lot of money for a feature that they should have built in the first place and that they're giving away for free now.)
The modularity of a service such as twitter really became apparent when Twitter announced they would drop the SMS feature. Within about 2 minutes, TweetSMS was founded by a third party, to offer the users what Twitter had just taken from them. And recognizing that this feature is something that people would want to pay for, they even have a business model. If it's successful, twitter could easily acquire them in the future.
The interesting thing here is that it works like a formula. You let others develop features and business models, and you buy back the successful ones and incorporate them into the service. So you sow, then you reap.
Here are some characteristics of this approach, that I derived from the way Twitter currently operates.
- Even though there are many parties and many tools involved, you remain the center of the technology. Sort of like the 'hub'.
- Even more than building a product, you build a concept.
- It's more efficient than investing in the product yourself, as this way, there can be many parallel developments, and you pay only for the succesful ones. (Evolution)
- It takes a lot of venture capital to make sure this model works, as you have to buy a lot of things. On the other hand, researching and developing it yourself is expensive too.
- You basically outsource the risk. All the failed twitter clients and twitter services are not your problem. You just make sure you deal with the successful ones and keep those close.
- You outsource research. Many third parties have built tools on twitter based on ideas that the founders may never even have thought about.
- Every successful third party has a certain value (that Twitter will pay for when buying back the feature). However, with all those successes combined, the total value of Twitter will be more than the sum of its parts.
- This is a business model. One that may be carefully hidden, or one they may not even be aware of themselves.
In the past year, many alternatives to Twitter have seen the light of day, and most of them have died, even though some were better than Twitter. Their biggest problem: They are not Twitter. Since Twitter is more an idea or concept and not so much a product, it's hard to fight. It's easier to build a tool on top of Twitter than to build an alternative to Twitter. And this is its strength.
And with the above business model, I think that even though people are sceptical now, they will be highly profitable at some point.
How does your door open?
July 28th, 2008 by Ivo
In my country (the Netherlands), most front doors of houses open inwards. Most back doors however open outwards.
A friend of mine noticed that in a television program about Sweden, the front doors and back doors were both opening outwards.
A quick survey on IRC revealed that in the US and the UK both front doors and back doors open inwards.
It's totally irrelevant, but things like this intrigue me. How do the doors in your country open? And do you know why?
Functional loops
February 6th, 2008 by Ivo
My girlfriend switched health insurance companies last week. Everything can be taken care of online, most insurance companies in The Netherlands have elaborate customer portals.
When applying, we encountered a nice 'functional loop'.
We used an online form to apply for the insurance. You just fill out a form, click submit, and off you go. The insurance company has to go through a process to accept your application, so it might take a while before you actually have the insurance. We got a confirmation email which contained a 'status code'. In the mail it said we could use this code to track the status of the application. All we had to do was click a link and enter the status code.
So far so good. After a day we tried to check the status. What surprised us: to enter your status code, you need to enter your customer number. To get a customer number however, you need to be insured. Hmm. Funny. So once the insurance will be accepted, we get a customer number, which we can use to enter our status code, to see if the insurance was accepted. Interesting loop.
Unable to actually check the status, I called their helpdesk. Told the guy about the loop, which I might have skipped because he had no clue what I was talking about; told him the status confirmation code and then the guy said something funny:
"It's Saturday today so I cannot verify your status code. If however you give me your zipcode and name, I can check your status."
I'm not making this up. These guys actually have a software system that apparently hides the status code search field for them when it's Saturday? What GUI principle is behind that? "Oh, it's weekend, present less options"?
No wonder insurance rates are this high.




