Of course the blog is still there, so old content doesn't get lost, but it's no longer the primary purpose of my site. I'll blog again when it makes sense, but where RSS feed subscriptions were once the preferred way of keeping track of a blog, that has moved to social media too (the RSS feed is still there though for those who still want to subscribe). Follow me on Twitter if you want to stay up to date with what I'm doing.

I do still value blogs for howto's, tutorials, opinion pieces etc; but since for me this is mostly an overlap with my Egeniq activities, you'll find those posts on the Egeniq blog instead of here.

In my enterprise PHP book I mentioned 5 major goals I wanted to accomplish in life: one of them is to found and build a company of my own. And although Ibuildings has always felt a bit mine, that's not the same. So I slowly started thinking about starting from scratch and building a new awesome company. Over the course of the next few months I searched for reasons to leave and reasons to stay, but eventually I knew that in my heart I had already made the decision in March, and all I was doing was finding reasons to validate that choice. There's a saying that in the end, you'll only regret the things you DIDN'T do, so finally I made the decision to go for it.

What am I going to do? I'm going to found Egeniq, a company centered around a number of mobile products, concepts and related services. Over the course of the next few weeks it will become more clear what exactly we will be doing, but in short it's doing cool stuff with iphones, ipads and android devices (and whatever device makes sense). I've found partners in crime: Bas is going to look after the commercial side of the business, and I'm going to look after the technical side together with a person that I've known and trusted for years (but it will take a couple more weeks before this person's able to announce it).

So far I've been a member of the PHP community; will this change when I am working with mobile devices? No, on the contrary! I'm both proud and happy to be part of this community, and you can bet that the products we will be developing will have loads of PHP in them (for backends, apis, webservices and the occasional web frontend). I'm still speaking at Zendcon in November, have a new book coming out soon and I hope that Egeniq will be able to contribute to a couple of open source projects.

I'm very thrilled to finally have this out in the open. I have very supportive friends and family, but I'm still both excited and scared at the same time; I'm giving up a great career for a lot of unknowns, and this may very well be one of the most important decisions I've made in my life so far. So any words of wisdom, encouragement or just plain 'you are stupid for doing this' feedback is more than welcome!

And to start plugging my new company right away: send all your ideas, project requests and CVs to ivo at egeniq dot com.

I will be with Ibuildings until the end of September, mainly to hand over my responsibilities and make sure that we part ways smoothly. My job at Ibuildings has been amazing and I'd like to thank everybody I worked with, every client I worked for and everybody at Ibuildings for a great time. This is not the end, it's a new beginning. A beginning I'm very much looking forward to!

I'm trying to find out the proper position to take this weekly picture, to ensure that the complete tower will fit in the picture precisely when it's finished, so that I don't have to move back after a while and can remain in the right spot for the duration of the project, and I'm close enough to not waste much pixels.

My camera has a certain viewport, so plain old Pythagoras won't be sufficient; so I'm trying to figure out what the best position will be, and how I can determine this using nothing more than math, some experimentation and educated guesswork. I'm relatively lazy, so it has to be a simple practical method that doesn't take ages or enormous amounts of effort. Also, it has to be a verifiable method so I don't end up moving the position halfway through the project; they're only going to build this tower once.

The position of the tower will be:

View Larger Map

Ideas? I'll throw in a signed copy of my enterprise php book for the most creative or pragmatic approach, or an amazon gift certificate for those not into PHP.

Bonuspoints if you point out the spot on the map, taking into account buildings or other structures

More details (if relevant):

• The camera will be this Canon Ixus 95
• I am able to use a tripod
• Most roads near the construction site are at the same level as the start of the tower (to my knowledge, anyway)
• The A2 highway north of the tower has elevated soundproof walls, so anything on the other side of the A2 is not an option.
• Details on the tower are here.

Have fun!

Update: I might actually use my Canon 450D for this project. Based on this blogpost, the construction company has contacted me that they are interested in the project and would like to cooperate.

What kept me busy mostly the past months is my new home. I moved to Utrecht (which is more in the center of The Netherlands, so I can get around more easily) with Leoni, and as developers say, the house is "90% done". So it'll keep us busy for a few months.

Things at Ibuildings are hectic as always. Our UK office is growing like crazy and is nearly half the size of our NL operation already. And we're working hard to get our Italian office up and running. Behind the scenes we're already working on things there, so if you're looking for a cool PHP job in Italy, drop me an email (ivo at ibuildings dot com). (Actually Ibuildings NL and UK are looking for senior developers too, if you're interested). After a succesful DPC back in June, we're planning a few more events so keep an eye on the Ibuildings website for news on those.

Another thing that has kept me busy is one of my personal pet projects, Flackr, a twitter based breaking news aggregation site. It has fairly basic functionality at this point (we've been mainly working on the news aggregation and event detection algorithms), but will eventually grow into a 'newsroom 2.0' type application with pro features for journalists. Here's an example of how it tracks tweets related to the Hurricane Bill including pictures. Contrary to many twitter aggregators, it doesn't follow the masses, but trusted sources only.

Finally, I'm happy to announce that I've started work on a new book. Enterprise PHP sold very well and it's not outdated yet, but writing it was addictive and now I just feel like writing another one. The book will be about PHP and Cloud Computing. This time around I'm not working on it alone, I'm co-authoring it with Vito Chin, author of the GMagick PHP extension, among many other things. The expected publication date is early 2010.

That's it for now; I hope to pick up blogging with more actual content after summer.

I see this as a threat to Google, and it wouldn't surprise me if they finally manage to buy Twitter, because Twitter helps them become more 'real time'.

To give an example, I was just trying to update my profile picture on Twitter, and this didn't work. For some reason it refused my pic without an apparent error messsage. Possibly I'm uploading something wrong, so first I googled for 'twitter profile picture' and got this result:

Then, I did the same search on Twitter Search and the result was this:

As you can see, this tells me that in the past 22 minutes, multiple people had this problem. (Ironically you can also see from their avatars that it actually is a problem). The Google results on the other hand, have nothing that is relevant if you take into account the 'now' factor.

This is just an example. Searching for 'current content' is getting more and more relevant. Comments on a live show on tv or an address to the nation by the president; Google is useless in finding these things.

So it is my humble opinion that either a) Google will buy Twitter, Facebook or another 'real time' content site, or b) Google will release an updated Google Search that takes the whole 'now' into account in its search results.

For those that don't adhere to this best practice, here are the most important reasons for doing so:

• You only have 140 chars on Twitter. The shorter your tag, the more actual content you can add.

• Many attendees use a phone to tweet, and many phones use a T9 editor. Again, the shorter the better. Also, entering a year such as '2009' not only requires 4 key presses, it requires 4 'hold' keypresses on many phones, or it requires the T9-editor to be set to numeric mode first.
• Findability. This morning I was trying to find blogs and pictures from #phpuk2009. Because the same tag was used on all media, the blog posts were hard to find between hundreds of tweets in the Google results. While it's interesting to find those as well sometimes, their real-time nature makes it much less interesting as a search result once the event is over (and it's far more easier to use search.twitter.com to view them in the correct order.

To sum up a few counterarguments:

• When you search it's hard to distinguish between different installments of the event. While I'd say that in blogs and Flickr and other things you would search through Google that is true (I recommend always adding '09' to tags there), for Twitter that is not an issue, because your search is always in order of date anyway.

• "I have phone X, it's really easy to add the year to any tag." Sure, but not everyone has phone X.
• For conference organizers, it's harder to scan the web for relevant content if different tags are used. Actually that's not the case: it's easier to find relevant non-realtime content and relevant realtime content when 2 different tags are used. See 'Findability' above.

There is a group of people that takes this a step further; they argue that a date should never be added to any tag, because appending a separate year tag makes it much more flexible (e.g. #dpc #2009). That's an interesting approach too, but makes it slightly less convenient for my taste (and generally requires even more characters), so I'll stick to #short for real-time content and #full09 for normal content.

What do you think?

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.

• 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!

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.

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.