Op de Engelstalige editie van deze weblog heb ik een kort bericht geschreven over 010php, de PHP User Group die we deze zomer hebben opgericht. Als je een PHP developer uit Rotterdam (of in de buurt) bent, neem dan eens een kijkje! We zouden het allemaal tof vinden als je ook eens naar een meeting komt.

For a while I have been wondering about the existence of a local PHP user group for the city where I live; Rotterdam. A user group is a local community of PHP developers who, through formal and informal regular meetings, share knowledge with each other, organize social events and provide a nice way to expand your network. It seemed that there wasn't one for Rotterdam, which led me to the idea to start one myself.

During the last Dutch PHP Conference, where a keynote speaker brough up the subject of user groups, I again wondered about a local group, now having decided that there probably isn't one, currently. So I proposed to start one to Ron van der Molen, who suggested we set one up together. And so we did. After some brainstorming, we decided to call it 010php, as a reference to both the Rotterdam area code and the "bits & bytes" association one has with ones and zeroes.

In july, we held a 'bootstrap'-meeting; a get-together for those who are interested in a user group and who would like to contribute. For the location, we picked Dudok, which is a thematically ideal place to start a community based in Rotterdam. The meeting didn't have a strict agenda: the goal was to get things going by going around the group and talking about ideas. We quickly agreed on a starting format: a monthly meeting with talks and some drinks, and at a later stage perhaps the additions of workshops in separate events. There were over twenty developers from around Rotterdam attending, which was more than we expected. That was a nice start!

The second monthly meeting for 010php took place on the 8th of august. We rented a space in De Machinist, near the iconic Euromast and the city center, where we could have some drinks and retreat into a screening room, where we did the first talks for the user group.

The first talk was A Crazy Little Thing Called Scrum by Ron, who is a Scrum Master and PHP developer. He explained a couple of very clear aspects of scrum and extreme programming, which seemed to spark the interest of quite some attendees. The talk was very informative and served as a good starting point for those wanting to get into agile programming.

The second half of our program was the talk Stop searching in the dark, start finding in the light by Roberto Gardenier. He has a lot of experience with the implementation of Apache's Solr family of products and gave a well balanced talk about these subjects, which again served nicely as a first step for those unfamiliar with the subject.

For our third meeting, on september 12, we're again using the facilities of De Machinist. With the user group still in the early stages, we're only doing one talk, but we're already planning new talks for the fourth monthly meeting. 

If you're from around Rotterdam, or if you're interested even if you're from somewhere else, please have a look at our calendar and consider joining us at one of our meetups. We're a small community wanting to grow, and welcome everyone to attend or to come and speak about a subject.

If you've been visiting this blog for the past half decade, then, firstly, wow. I haven't written anything new since 2009. I feel like I should give you an award! But if you did visit, and returned now, then you might notice a change of layout on this site. I thought I'd celebrate it by, well, blogging about it.

This blog sort of died somewhere between 2009 and today. It was running on Wordpress (after I migrated from Radio UserLand, which is even more ancient but still gets me excited about blogging and technology every time I think about it), because I didn't feel like adapting the home-brewed software I use on my Dutch blog to facilitate two blogs, and apart from the fact that I didn't write on it anymore, I fell behind in keeping the installation up to date. Wordpress has had some leaks over the years, and this site has fallen victim to some of those, causing the blog to be a big bad motherf*cker of a spam infestation. Not good.

But I always felt like I should whip up something new, migrate the content and restart the blog to have a place where I could write down some notes, every now and then. So I've done what I was always too lazy to do: adapted the Breuls.log software to run on multiple domains and run multiple sites from one CMS. It wasn't all that hard, after I rewrote the blog CMS last year to work in a well respected framework instead of using decade-old spaghetticode scripts. It took me litte over one saturday morning to export the entire blog from Wordpress (it exports in RSS, which is nice), write a script to import it into my own database and point the blog.breuls.org-domain to the new location. The blog you're looking at is now simply part of my other blog, and serves as an English language branch of it. And I can manage the entire thing from the same CMS. Me likes.

So here we are, brand new. Now to find something to write about...

Within PHP, the current Big Thing, in a way, is namespaces. However: it's brand new and not every PHP developer knows how, if at all, to use then. Good thing there's tutorials about that. Sitepoint has one in three parts: 1, 2, 3.

When I started out PHP'ing, I bought a little PHP book called 'PHP pocket reference'. It was one of those small O'Reilly books and it was written by Rasmus Lerdorf himself. I still have it, although of course I don't use it anymore.

The book focused on PHP3, although PHP4 was already released. So, basically, I learned PHP with version 3. I started out writing scripts with a .php3 extension, something I still don't understand; why was the version number included in the extension?

Anyway, not long after I started PHP'ing, my environments switched to PHP4 and I became a PHP4-developer. And I still am. One of my employers still uses PHP4 and although today is PHP4's death date, there is no indication that there's an urge to speed up the upgrade process (which thankfully is in place and being worked on).

The problem with PHP4 and PHP5 is that the upgrade process actually is a big step. For the software, because not everything 'just works' when you upgrade to 5, but also for the developers. Some of my co-workers still consider the features that were introduced or improved in 5 'new', although they've now been included with PHP for years. And that's understandable; when working heavily on projects in PHP4, and without having the opportunity to check out what's ahead and trying to use newer features, you'll never get a taste of it. Of course, developers should take those opportunities themselves, checking out new features and developments in their own time, but not everyone does that.

So today is the end of PHP4. Not really of course, because lots of developers will probably still spend months working on PHP4 code. It will work just fine and do just what you want forever, it just won't have any updates anymore, But if you consider the fact that some servers (even those of my employer) still run a 4.3.X-version of PHP, that hardly matters.

I'm glad I switched the projects at my other employer to PHP5 at the start of 2008; not only are we up to date, but the new features (or simply the small improvements in existing features) make working with PHP a lot nicer. And we're ready for the future; PHP6 is upon us, and I hope it will be adopted (and adoptable) a lot faster than its predecessor.

PHP4, you've served us well. You paved the way for PHP5. Thanks! Now get out, and stay out.

It's always fun to compare tools. Who works with what and especially, why? Following the example of Flickr and some others, let me list my tools, see if you match:

Working:

• Main machine: MacBook Pro. I have an Ubuntu PC, but that's just 'extra'. I do everything on my Mac, from working to living.


• Editors: Zend Studio 6 for all the main development tasks, completed by TextMate (and the handy 'mate' cli-command) and vim for serveral minor things.


• Transmit: used for access to (s)FTP code locations, and to manually check whether (s)FTP import applications do what they should


• iTerm with usually about six tabs. I traverse folders, grep through them, use CVS/SVN commands and access MySQL from the commandline. And of course I connect to development and production servers using ssh, but that goes without saying.


• MySQL Query Browser: I can usually do what I want by just using the commandline client, but every now and then I need a little more visual help.


• Zend Core: used as an all-in-one package for Apache and PHP. I also use MAMP to run a good old PHP4 environment because at one of my employers we're still in the midst of upgrading to PHP5 (I know, shut up).


• Xdebug: I use it for profiling and I love the way it adapts var_dump() to a more usable way of displaying variables


• FireFox and FireBug: very important indeed. I can't image having to work without FireBug. I still remember trying to think really hard about my HTML/CSS and placing alerts in my JS as a way of doing some poor-mans-debugging. FireBug is a godsend.


• YSlow: a man needs performance, and YSlow helps me determine what to do. Very nice!


• CSSedit: editors for CSS don't do a lot more than text editors, but they help a little and a little is enough.


• OPML Editor: I keep my notes, todo's and more in outlines. The best outline editor used to be the one from Radio UserLand, until Dave Winer took the tool and released it apart from the weblog editor.


• VMWare Fusion: although I love working on my Mac, I'm still missing what I already mentioned before: the combination of Krusader and Kompare (and to a lesser degree, Cervisia) for development work. For that, I am trying out using an Ubuntu virtual machine which uses the three beforementioned apps and sshfs to mount the (development) servers I'm working on. Works like a charm!
  

Living and working:
I take my Mac everywhere. I work on it at work, even though it is a private machine. At home, I use VLC to watch video's and DVD's, NetNewsWire for the daily read, Celtx for screenwriting, Mail.app for.. well duh, RealPlayer to listen to BBC Radio 1 or iTunes for my music collection, Twitterific for Twitter and Unison to eh, browse newsgroups.

Well, that's most of it. What about you?

I like conferences. They bring a combination of information, context, some discussion and all kinds of impressions to you in audible form. In a form that doesn't require you to browse through blogs or magazine articles. Also, you can reflect on the subjects with others during the break times. Or just reflect on it by yourself. In some way, it differs from just reading about the topics on weblogs or online manuals, it's got a different vibe. One I like.

So last weekend I went to the Dutch PHP Conference. I went last year, and I liked it, so attending this year's edition seems logical. But after a day of listening to some interesting talks I'm wondering: who is the indented audience for this conference? Am I even in it?

Let me explain by walking through the day. After @ijansch's opening, we were welcomed into the history of PHP by Zeev Suraski, one of the founders of Zend and with that, one of the people who made PHP what it is today. It's nice to hear the story from someone first-hand, as opposed to reading it in the PHP Manual.

He gave his view on PHP today: it's mostly done, and our focus as a community has been, and still is, shifting to frameworks. In a way that's like saying "we've been building the car for a few years, now it has become time to do some driving". And he's right. PHP is never truly done, of course, but it is fairly done, and now it's up to the frameworks to mature and become the highly useful, production-ready toolkits we all need (yes, need, even though some of us might not know it yet). In my view: some parts of frameworks wille eventually become more attached to the core of PHP, as often-used parts will grow into the extensions area.

After Zeev, Marco Tabini, publisher of php|architect (which I'm subscribed to), explained how important mayo is to the PHP world. No, wait, that wasn't it. He wasn't very PHP-specific, but his keynote was quite interesting nevertheless.

Lunch came and went, and the breakout sessions started. I attended the ones presented by Gaylord Aulke, Lorna Jane Mitchell and Ivo Jansch.

Gaylord talked about how you would go about creating, maintaining and using an infrastructure when you're working in a team. He explained about development locations, version control management, test- and staging servers and deploying your work to a live server. This very much connected with Lorna's talk, which focused on deployment in general, and on doing that with subversion in particular.

Both talks were interesting, but only small bits of it were giving me new information or a perspective I didn't think of before. Both gave me the impression that the intended audience would not include people already working in teams, with version control already very much in place and several live projects to maintain. Those people would already have invented (and/or implemented) the proverbial wheel for their own situation. Which is the case for me: at both of my jobs, an infrastructure is in place and working nicely. Nevertheless, both talks were interesting, and some viewpoints offered, along with a nice feeling of confirmation, some food for though and/or Googling.

After the break, the choice was to be made between Stefan Priebsch's session on the upcoming PHP releases, a session by Matthew Weier O'Phinney about best practices within Zend Framework (this description is not as accurate as it should be, but we'll get to that) and Ivo Jansch's presentation about Enterprise PHP.

Because information about PHP 5.3 and 6 can be found on the mailing list, wiki pages, blogs and the slides Stefan posted before the conference, that one was an easy choice: no need to attend. The session on Best practices within Zend Framework would only make sense if you were actively using ZF, I thought, so that would not be very practical at this very moment (I was wrong, as you can see by reading the actual description on the site, it's not 'within' Zend Framework, but 'inspired by' it, if I understand correctly). So I entered the room in which I would be very cautious about product placement (kidding).

Ivo's session had 'Enterprise PHP Development' as its title. Because I work in a couple of teams/environments where the label 'enterprise' might, in some way, be a suitable one, I thought I'd attend this session. It's always nice to get some tips, attention points and such. But, the session was basically about the same as Gaylord's and Lorna's. Not that he covered the same topics, but again I felt like I knew a lot of it already. He covered ten main points you need to be thoughtful of when working on your projects, of which some were very obvious, and others inspired some thinking while in itself not being new (to me, at least).

After all this, my colleagues and me were interviewed for a Bachelor ICT video, in which we expressed our concerns about the lack of depth in the sessions. Terry Chay had already started his keynote by that time, so after missing the beginning, we hurried in and stood in the back, while listening to a very interesting and nice keynote. Chay is a wise man, I said to myself.

Looking back at the day in its entirety, I think I expected more. I already called my feeling about the sessions a 'lack of depth'. This of course isn't necessarily a bad thing. A PHP Conference, especially one in a community that's still growing and has a lot of people still learning how to be the best, should be aiming for a wide audience and not exclude beginners. However, if some f the sessions would last longer, maybe the contents could become more hands-on and give you more the feeling you're walking away with lots of information to research in the days or weeks after the conference.

I'll probably attend next year's edition, but can I silently hope for some more advanced content?

» MacGDBp - a PHP debugger using XDebug
» Dutch PHP Conference 2008 - The Video - I was interviewed. Did I make the cut?
» DPC'08 review by Rick Buitenman
» It's About Time You Learned Javascript (for real) - I think I'm gonna read that book
» The Top Ten Subversion Tips for CVS Users
» The Subversion Book
» Running multiple FireFoxes on your Mac
» PHP Performance Series: Maximizing Your MySQL Database
» Which is the fastest browser?

» Download FireFox 3 and install it on my Mac (my Ubuntu machine switched to FF3 weeks ago)
» Download this possibly very interesting PHP Debug thingy for the Mac

Hmm, nice step: the Zend Framework will be included in the repositories for Ubuntu Hardy Heron, scheduled for release in April. Not that the average developer wouldn't be able to obtain a copy of ZF otherwise, but it's nice that it will be included.

Let's hope updates to the Zend Framework will be ported rapidly into Ubuntu, so Ubuntu/ZF users wille be able to truly depend on the packaging system.

It's those little things: in PHP 5.3, the constant __DIR__ will be available. Of course, this is the same as the output from dirname(__FILE__), but it makes life just that little bit easier.

The Dutch PHP Conference, which I went to last year, is getting its second edition. It's a bit more expensive than last year, but I'm certainly going to consider attending.

For the last two months, I have been using a new Zend product as my default PHP editor. I haven't blogged anything about it, because until last week, it was a closed beta.

At ZendCon '07, however, the beta of Zend Studio Neon (with Neon being the beta-name) was released to the public, inviting everyone who's interested to the party. So now it's okay to blog about it, and I would like to take this opportunity to name a few things that might cause Neon to become my default editor, permanently.

1. Custom formatting
In the classic Zend Studio, you can select a piece of code and have Studio re-do the indenting of that section for you. Very handy when you've messed up your code in some way, or several CVS commits from different people have thrown the structure out of whack. In Neon, this feature works even better:

I can configure exactly how I want my code to look: where I want my spaces, where the braces should be placed, how the code needs to be indented and lots more. I can configure the formatter to follow my personal coding standards, select a piece of code and have Neon apply my standards to the selection. Brilliant!

However, Neon doesn't remember my preferences, so I have to export them whenever I make a change and import them every time I start Neon. Also, a few bits of my prefs cannot be configured, such as the way arrays should look when you divide the declaration over multiple lines. But I expect Zend to be looking into that, as several of the closed-beta testers have already mentioned it in the testers group.

2. Easy compare and CVS-integration
When Neon recognises a project to be a checkout of a CVS-module, several options are added to the navigator (the outline of files and folders on the left side of the screen). To name a few:
- Every file that has been changed is visually marked as being different from CVS. This makes it easy to find what you have changed and might be ready to be commited into CVS.
- I can update and commit from the navigator. The classic Studio had this as well, but it was useless because the following feature was missing:
- Compare! I can right-click a file and compare it to the latest version from CVS, or a specific revision, or just compare it to another file I also selected. The ability to compare makes it possible to check if the file I want to commit is ready to be commited: I can see all the changes and if I left in some junk (an echo, some commented-out code, you name it), it shows up as a difference and I can edit it while still in the compare screen. Brilliant! I'm used to the way Kompare works, and frankly that one has a better overview of the changes, but Neon makes a good second best, especially when combined with the CVS options.
- Neon acts as a complete CVS client. I can change the revision of a file, create branches, browse the history of a file, commit several files at once and more.

3. It's more than a PHP editor
Apart from writing PHP code, I do a lot of work with Javascript, XML, Webservices and such. I can open a Javascript file and it opens in a specific JS editor, complete with a preview screen which exectutes the file as if it were loaded in a browser. Or I can open a .xsd file and the XML Schema in it is shown in graphical form, complete with all kinds of functionality for altering the schema. It even shows errors I made in either type of file. Very, very nice.

4. Choose the PHP version per project
In the classic Zend Studio, I have to change the PHP version from 4 to 5 and back when working with different projects. In Neon, I can configure this in the project-specific settings, instead of editor-wide. Quite a time-saver, as it prevents me from looking surprised at my editor, wondering why it thinks a bit of code has an error when it clearly doesn't.

5. Project-wide error checking
When I open a project, Neon checks all the files, both PHP and other types, for errors. When it finds them, the erroneous file is marked as such in the navigator, and so are all the folders above it. I can easily follow the path in the navigator to find the file with the error, fix it and when saved, the mark disappears. And of course I can commit it immediately.

The downside to this is a heavier editor, though. When a project resides on a remote server, and Neon startes opening and parsing them all, my computer gets very, very slow due to the heavy traffic. In fact, Neon already is very memory-consuming and needs to be shut down if I want to open something else that's big in memory (a video player, for instance). I really hope Zend is able to do something about that.

There you have it, five things I like. There are also things I don't like: the memory Neon consumes, the multitude of 'perspectives', editors, outlines and other screens I don't really 'get' yet, the fact that even a closed project shows up in the navigator and some other minor things. But those are all little bumps in the road, and as Neon is still in beta, I'm not really worrying about it.

Whenever I need to make large (laaaarge) changes in code that has been sitting in its place for a while, an exciting and a bit frightening thought enters my mind: "throw it all out and start from scratch". Exciting, because starting to build something that you know is gonna be great simply rocks. Fresh, clean code without months or years of editing history is just lovely to work with. Frightening, because you know how long it took to create the existing code, you know how long other rewrites took to do and you know that this is no exception. Also, you know you are gonna have to address all the problems you had in the first run.

But the feeling that you should start from scratch is always there. In my own forum software, Replique, I already did this twice (although the second was a partial rewrite). With reasons and, fortunately, the desired result: a better application. In a CMS that runs at a website I work for, we also did it twice. And it will probably happen again in a few years.

And this is why. Just this afternoon, I stumbled upon Derek Sivers's weblog, who tried to rewrite a website in Ruby but failed miserably. Rafe Colburn replied to his and linked to a piece by Joel Spolsky, from which I quote:

There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It's harder to read code than to write it.

And that is so true. As is probably true for most developers, my coding style has evolved over the years. Indentation, the placing of braces, the naming of variables and so on, when I look at how I did in a few years ago I scare myself. Did I really write this? Yes I did.

And it's not just the style. Over the years, if you're (aiming to be) a professional developer, you learn more and more new stuff. And every now and then there's the urge to try out those new things. And every now and then one of those urges makes it into your code and stays there for years. When you look at it, years later, you know that you should have resisted the urge. Not that it's bad code, of course not, you're a pro. No, it's just.. silly. The old method of doing whatever it was that that code did was just as good. You didn't keep it simple, stupid. ;)

The Big Question you should ask yourself before starting a rewrite is: am I doing this because I want to, or because the changes I want to make need me to? Is it so damn hard to make the changes in the existing code? Does it hurt to just refactor the bits and pieces you are going to use? Will it hurt the performance when you don't do the rewrite? Okay then, do it. If not: just make the changes and be happy about it not costing you time you could use for really new, fresh projects.