If you are reading this, you probably kept my old feed in your RSS reader. Using Google Webmaster Tools, I got reminded that people actually subscribed to that. Right now, you lucky (ha!) few are the only ones reading my blog, the greater Internet is being deprived of the privilege because Google is not indexing it. For example search "john kleijn closures", you'll get Eli White's blog because Serendipity created a trackback for it, instead of my own post about closures. Search simply "John Kleijn" and you'll get my company website, some other links such as my PHPFreaks.com profile, and also some other guy called John Kleijn twice my age (okay, 1.5 times -- I'm getting old).

I am getting soo tired of Zend Studio for Eclipse. On large projects, or rather projects with large libs (e.g. Zend Framework and Doctrine) code suggest and "building" is just too slow. It is since about a month impossible to blame hardware imitations either.

When PHP 5.3 came out, I was ecstatic. Namespaces, finally! Actually some parts of the implementation were a bit disappointing, but we'll leave that for another time. In that same enthousiasm, I jumped on closures like a hungry dog on a steak. Only to find the steak to be an old shoe.

Of all the well known design patterns related to ORM, the Proxy pattern (or more specifically, Virtual Proxy) is perhaps the most under-appreciated (with Unit of Work Controller and Value List Handler coming in second). This may be because it's not strictly a data source pattern, and you won't find in PoEAA chapter or Core J2EE Patterns. It is actually in the GoF, which doesn't contain any data source patterns. For me personally, Virtual Proxy will always be directly associated with data loading, as that is what I first used it for in 2006, although since then I have used for other occasions where object initialization was abnormally expensive. It is a pretty versatile pattern.

In a nutshell, a Virtual Proxy is a "lazy loading" pattern that defers initialization of an object until it needed. The proxy does not contain the actual resource, but "knows how to get it". It does this by extending a subjects class while delegating to an instance of that same class, the subject. Basically this is what a Decorator does. But instead of overriding methods to add behaviour to a decorated object, it overrides them to trigger initialization of the subject (loading from the database in the case of an ORM), before delegating to the subject. Like with a decorator you'll have to override every method so that it is delegated to the subject. This makes manually writing proxies a pain.

Yet again.

Actually, using bits and pieces from previous works of art and a lot of red bars that turned green eventually, it is actually already a usable framework. Which allows me to focus on the more interesting stuff that are going to set this framework apart. Starting with the data layer.

I tried my hand at poetry. It's deep, philosophical, it is the best poetry ever. Actually it is probably as good as my skills on the guitar.

My development server hosts Trac instances, SVN repos, and private testing/staging websites/applications. All of these use one htpasswd file with users and passwords in it.

But the build server, using Hudson, doesn't natively support that. Here's how you can have Hudson check a standard htpasswd file, and have project based security so one client or subcontractor wont mess with the builds of a project they are not involved in.

That's right, I decided to join Jimmy Hendrix and.. Some other guys who were pretty good? As soon as I can play anything with more than an E and A minor, maybe I can play some Staind or System of a Down at your wedding (or funeral, same game). But seriously, I'll record something sometime so the Internet can have a little fun at my expense.

(The Stratocaster was "borrowed" from http://technabob.com/ btw).

Hello World,

After I stopped blogging at johnkleijn.nl about a year ago, I recently decided I wanted to start again. While johnkleijn.nl was purely about Web Development, this time I want to get other thoughts off my mind as well. I'm also going to try to write a little more often than once a month, it's not like I don't have a ton of incredibly interesting things to say, even if no one really cares about half of it.

When I write something that makes you want to hire me for PHP or JS development, go over to my company website. But this is also a personal blog, with opinions, bad and poor humor and stuff. When I write something that makes you want to pull my head through your monitor by my (fairly large) ears, troll about it in the comments.

I'll import some of the old posts, not sure if it's worth the trouble. If you visited my old blog and want a specific old post back, comment below.

I may also become active on Twitter, Facebook and LinkedIn, who knows. Before long, you could find yourself reading more John Kleijn than you can stomach.

John Kleijn.