I think I might have been listening to music all my life. I remember listening to the radio when I was too young to actually know what music is, I remember having my first Walkman, Discman, radio Walkman, MiniDisc Walkman, all the way up to my current iPhone. I have always listened to music on tape, CD, radio or digital files. And I have used a lot of ways of getting the music from its source to my ears, the most recent being a set of wireless earbuds that connect to my phone via bluetooth.
The choice for wireless came from a personal preference: the wires were getting in the way of my movement, as were the buds themselves. They fell out of my ears during a run. That annoyed the hell out of me. And when I'm on the go, I usually carry a backpack or some type of shoulder bag, and that didn't always work out too well with the wire from my earbuds, ripping them out of my ears with some force whenever I wasn't paying attention when moving my bag around.
So wireless I went. And I like it. As it turns out, this seems be have been an inadvertent preparation for Apple's next innovative move: eliminating the headphone jack from their next iPhone model. It surprised me that they would just cancel a feature that's been around in audio devices for as long as I can remember, and that has existed for even longer than I'm alive. But I already use the alternative: I am already using wireless earbuds. So I already know that it kind of works to remove the ancient headphone jack. But I wonder if it wouldn't be better for Apple, or any of their competitors, to wait just a little bit longer before making this move.
Because wireless isn't perfect. It never has been, for anything. There are always problems. When I was young, the tv remote didn't always work or my FM radio would lose it's signal. Do you remember using an FM radio in your childhood bedroom and noticing that the signal was interfering? And then you would walk over to the stereo set to adjust it, and it would turn back into perfect sound because your body was blocking the interference? That's over now, for me, but it might be because I no longer listen to FM radio when I'm not in a car. In later years, wireless stuff would fail me when I wanted wi-fi in my house. The house I grew up in had three floors and I was on the top, while the wi-fi access point was on the ground floor. That didn't always work.
And now, there's bluetooth for a lot of stuff. I use it to connect my mouse and keyboard to my computer, to connect some device to another, and to listen to music on my phone when I'm on the go. It works really well, for about 95% of the time. The other 5% are countless moments where the music stutters for a fraction of a second, every few minutes, or when my own body interferes with the signal coming from my phone to my earbuds. Because I have my phone in my pocket, usually my right one, and my earbuds don't agree with that.
If you have never used wireless earbuds or seen them in a picture, they're basically regular earbuds, but the only wire they have is between the left and the right ear. My earbuds are from the Powerbeats Wireless line, which means they are actually made by Apple. They have a receiver in the left ear and the wire takes care of the audio in the right ear. But when I carry my phone in my right pants pocket and I look over my left shoulder, it moves the receiver away from my phone, causing the signal to stop. It stops! Just because I move my head. That shouldn't happen. It certainly shouldn't happen if, in the very near future, this technology becomes the main way of listening to music on your phone (I know; there might be a way of listening to music using an adapter for the lightning jack, but come on, we are pretty much expected to go wireless).
When I move my phone to my left pants pocket, it doesn't happen as much (but it still does), by the way, proving that the signal needs as much support from the user as it can get. It's not ideal. Also, it's not very versatile. When I just bought the earbuds, I tried using them at work, to listen to music from my computer. Connecting them wirelessly was no trouble, but switching between my phone and my computer is a lot more effort than just taking out the jack plug and plugging it into another device. Sometimes, older technologies are just more convenient than new ones. When I use my regular Apple Earpods on my phone, I don't have to worry about there being enough battery charge for my entire journey. The wireless ones need a new charge after about six hours of use. This means you can't use them all day.
I really wonder if it's Apple's intention to force users to use technology that might need another iteration of development before it's good enough. I don't think it is. They might just want to force the issue; force companies to come up with better technology. That's not a bad thing, but I'm a little worried about end users becoming guinea pigs for the next couple of years. Maybe, just maybe, we should wait a few years before making this move.
Knock is een handige app die ervoor zorgt dat je niet je wachtwoord hoeft in te typen als je je Mac wilt unlocken. In plaats daarvan klop je gewoon even op je telefoon. Superhandig! Maar er zijn een paar kleine verbeteringen nodig om deze app echt goed te laten werken. Welke dat zijn licht ik hier toe.
Thanks to a tip coming from one of my favorite podcasts, I've started to give the Mac/iPhone application Knock a try. I'd like to tell you why it's awesome, but also why it's not there yet. So it's not awesome, yet, but it's promising.
What Knock does is really simple: it lets you unlock your Mac by knocking on your iPhone. That's it. And it's brilliant. When you're at the password screen for your Mac, instead of typing your password, you just knock on your phone and the Mac unlocks itself. No password hassle needed.
In theory, this is absolutely perfect. You can protect your Mac with a really strong password that you'd (almost) never have to type yourself. In practice, however, it doesn't work as well as it should, which is why it "almost works", therefore it's "almost awesome" or "actually not awesome at all".
The application works as two apps: a free OSX background app that sits in your menu bar (yet another icon up there? yup) and an iOS app that costs a couple of euros. You install the OSX app first, to check if your Mac is recent enough to support Bluetooth Low Energy, which is the technology that's used by the apps to communicate. The OSX app tells you if your Mac is supported. If it is, you can go ahead and buy/install the iOS app on your phone. You run both, they tell you about how to do the setup, you follow it and you lock your Mac.
Then, you knock on your phone twice. If everything's going as it should, your Mac should now unlock. Yay! But there are cases in which this doesn't work.
You have to be logged in The first case is mentioned in the FAQ on the Knock website: your Mac needs to already have been running before locking. So a fresh boot, leading to the login screen, won't work. But to be fair: that's also not an 'unlock', that's a 'login'. So there's that.
Hello? Someone there? The second case is a variety of situations in which you're actually better off just going ahead and typing your password, making the app obsolete. I've experienced quite a lot of times, when I wanted to unlock my Mac, that the Mac and the iPhone hadn't found each other yet. There's a green ring around the avatar in the login screen that circles around until there's a connection. When the connection has been made, the ring turns completely green and I can knock. But it can take a couple of seconds before the connection is made. Seconds I could have shortened myself by just typing my password. And that action is almost second nature for me, so why bother waiting for my phone to connect?
Nobody home Sometimes, there's no connection at all. I just wait and wait, and give up. Turns out, and this is not so much surprising as experience-lessening, the Knock iOS app has to be up and running. When I close it, there will never be a connection between Mac-Knock and iPhone-Knock. It's perhaps understandable; iOS doesn't like stuff happening in the background, but to be honest, having to make sure the app keeps running kind of defeats the purpose of the application. This stuff needs to "just work" for it to be really powerful.
Additionally, sometimes when the iOS app is running, my Mac still can't connect to it. That just feels buggy.
Just keep knocking The final annoyance might just be a bug, so let's hope it is so it can be fixed quickly. Sometimes, just knocking twice won't work. The unlock screen shows that the knocks are registered, but there's no unlockin' happenin'. So I knock again, twice. And again, now harder. And then I knock thrice, or four times, before Knock registers the knocks as valid and unlocks me. It's annoying; again; that time could have been spent just typing the password.
So, in summary, Knock is a brilliant app, in theory. I hope it's possible to fix some of these issues, because those are the only things keeping me from absolutely loving the app.
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.
Looking back at old posts on this blog, I found my list of tools that I used on a daily basis, back in 2008 when summer in this country lasted longer than a day. Since I'm still doing some of the same work as I did then, let's see how much of it has kept its place in my toolbox.
I'm still working on a MacBook Pro, although of course a more recent model. In 2008 I wrote that I had the Mac as an 'extra' machine next to an Ubuntu desktop. That's no longer the case and hasn't been in a long time. The desktop is gone, and I've completely adopted OSX as my main platform. In the meanwhile I have started using an iPhone and an iPad, partly because I like how stuff fits together.
I'm no longer using Zend Studio. After being bummed about the 300 euro price tag for an upgrade, I switched to Netbeans for a while. That was about four years ago. Recently, I have started using PHPStorm, which is awesome and will probably have completely replaced Netbeans in my workflow within a month from now. Still using Textmate, by the way, for the quick-and-easy edits.
Still using Transmit for (s)FTP. No changes there, although I have added some hooks to the Git repository for this site so that when I push edits from my editor, the software is deployed to production. So FTP is out when it comes to updating my website.
iTerm has stuck as well. No CVS anymore, of course, and Subversion is almost completely out of the picture in favor of Git. But I don't think that last step will take long.
Query Browser is out, Navicat Lite is in. Works fine. 'Nuff said.
Zend Core has been succeeded by Zend Server.
XDebug is still firmly placed in my toolbox, now also including the actual debugging, of which I didn't even realize how powerful it was, five years ago.
As I've switched to Google Chrome as my browser, I no longer use the FireFox/Firebug combo. However, what Firebug adds to FireFox is something that Chrome has by default, and I couldn't imagine working without it.
YSlow: out. I'm way less involved in frontend work, so this has become less of a focus point.
CSSEdit: out. I'm just using Netbeans or PHPStorm now.
OPML Editor: out, unfortunately. It just runs sluggishly, doesn't work (or look) all that well. Pity, because I'd still love an app like that to be part of my workflow. For notes, I now usually use Evernote. Hell, I'm writing this blog post in it.
VMWare Fusion: out. I have a Virtualbox install with Ubuntu (and Windows), but I'm only rarely using it. I have enough tools in OSX to replace what I did in 2008.
So that's the status of those older tools. What I have added:
Git. It's awesome. Any developer who doesn't see the added value of switching from a regular VCS to a DVCS isn't being serious about their work. And Git has a plethora of unbelievably useful features. In addition to Git, I use SourceTree from the fine folks at Atlassian for graphical support of my version controlling.
Kaleidoscope. This is the visual diff tool I have been looking for since I lost Kompare when I stopped using Linux as my OS. In version 2 it gained merge capabilitites, which prompted me to buy a license immediately. It's a delight to use this, as it plugs in nicely with version control, my editors and even the OSX clipboard. Big recommendation here.
I used Versions as my SVN client for a while, but with the drop of SVN for version control, that has slowly gone. Pretty nice Subversion client, though.
iA Writer. Next to writing PHP code, I also often write for FOK!, where I'm an Administrator and Editor. I write reviews about movies and tv shows, and iA Writer is a nice, clean writing interface that just lets me write without distraction. I can really focus on the text and worry about markup and layout later.
TicToc: a simple time tracker that helps me keep a tab on what I need to bill clients. When I leave my computer and forget the timer, it notifies me when I return that I might have forgotten the timer and offers to reset it, which is nice.
And all kinds of smaller stuff. On the personal front, I'm still using VLC for video, although I'm mostly streaming video to a receiver (my PlayStation) to watch video, using the Twonky app. RealPlayer has been replaced by the flash widget on the BBC Radio 1 web site and Twitterific has been replaced with Twitter for Mac. Still using iTunes, but I've also become a Spotify Premium subscriber.
So not much has changed, software-wise. Just refined. I'm not expecting a lot of changes in the next five years.
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.
Zend Developer Zone: "Drizzle is a new, lightweight fork of MySQL specifically designed for cloud applications. Although Drizzle is still under development, it's attracting a lot of attention from developers around the world. This article introduces you to Drizzle and shows you how to use the Drizzle PHP extension to perform queries, retrieve result sets and handle errors in your Drizzle+PHP application."
There's been a lot of buzz about Drizzle lately. Need to check that out some time.
I reset the time on our mailserver, because NTP wasn't working (or at all running, I guess). Immediately my mail client started complaining about the connection. The above error message was the cause. It's both funny and explanatory. I like it.
To increase performance at the site I work for, we started separating static webfiles from dynamic pages using a separate hostname and web server for static files a while ago. For this, we placed almost all of the images, style sheets and Javascript files on a separate server and installed Cherokee for light and fast web serving on that server. And it worked. Loading of images became easier, and we could apply some of the server-related suggestions from Yahoo!'s Exceptional Performance.
However, Cherokee didn't always try its hardest to serve us well: sometimes it decided to pull the server's load to a performance-decreasing number, configuration of much needed features was "not yet implemented" or buggy and the software is overall not done yet. Also, the developers have, weirdly, decided to use exclamation marks as separators within the configuration, which is just plain annoying.
So we started looking towards other solutions. And we decided to go back to our other option before we chose Cherokee: Lighttpd. With Lighty, as it's pronounced, we can apply these performance rules:
I'd like to show you which configuration options we used. The following applies to a default Lighttpd (version 1.4.19) as shipped with Ubuntu 8.10. If you're using a different OS or if you've downloaded Lighttpd yourself, I assume you understand enough of it to translate the following to your own situation.
Add an Expires or a Cache-Control Header For this, we need mod_expire. With that module, we can instruct Lighttpd to include both the "Expires" and the "Cache-Control" headers in the response. To enable the module, we uncomment this line:
# "mod_expire",
This line is mentioned in a list of modules at the top of lighttpd.conf. If it's not, you should look for the list somewhere else in the file and uncomment the line or simply add it, but without the hash sign.
Next, look up a line that says 'expire.url'. It should be there and commented by default. Uncomment it and configure it to do what you want it to do. For us, Lighttpd is entirely dedicated to serving static files, which all need to be cached by the client for a long time. Let say, for documentation's sake, we choose two weeks as the caching time. This would then be our configuration:
expire.url = ("/" => "access plus 14 days")
This leads to these two headers when a URL from the Lighttpd-server is requested:
Expires: Thu, 25 Dec 2008 13:30:31 GMT Cache-Control: max-age=1209600
And that's it! Enable the 'expire' module, configure the expire time, and you're done.
Gzip Components To apply gzip encoding of the repsonse body, we use mod_compress, which is enabled and confgured by default. However, not everything we want to compress is actually being compressed, so we change this:
Over time, we might add other mime-types we forgot to include, but the above covers most of the requests.
When requesting an image with any regular browser, it will be sent to us, gzip-encoded. If you're using FireFox with the Live HTTP Headers extension, you can find these in the response headers:
Vary: Accept-Encoding Content-Encoding: gzip
This confirms that it's working.
Configure ETags This is the easy one. In our default installation, a request to the server gave us this as one of the response headers:
Ivan Zoratti: "The content can satisfy the appetite of a technical audience and of more business-oriented IT managers at the same time. We will have sessions on performance, on scalability solutions and on Proxy, with hands-on the servers, difference parameters and tools. IT managers will probably find interesting a renewed set of HA solutions and some renewed views on the infrastructures used to power the Web."
I'll be attending the London conference, after having been there last year, and I'm looking forward to it. Am I again going to be one of the few Dutch folks in the crowd?
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.
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?
I've got lots of content in my RSS aggregator that I "want to read, but not right now". And I keep skipping over it, making sure I don't accidentally mark those items as read, and that is starting to annoy me. So I'll just do what every sensible guy does: make a note of those items and move on.
Lore Sjöberg: "here's what I often do: I put my laptop back into my satchel, put my iPod back into my coat and bring my entire life with me into the bathroom"
Lore ponders what to do if you're working in a cafe and have to use the bathroom. I think I would take option 4: pack it all up, emty my bladder, and unpack everything when I return. Fortnunately, when I'm in a cafe, doing some work, it usually is only for a short time so I actually never have this problem.
I don't use my iPod when working on my laptop, by the way: i just plug my earpods into the laptop and use iTunes or RealPlayer to listen to music.
Eric Bergen: Have you ever executed a query from the MySQL command line client only to find that the output wrapped and the result is unreadable?
I have. A lot.
In the past you have to run the query again with \G instead of ; or \g to get it to display the output in a vertical mode. My feature in MySQL 6.0.4 fixes that.
I am standing up and cheering. No, really. I love those little things that make life (yes, I said life) easier:
The auto-vertical-output option tells the command line client to display the results in vertical format if the results are going to be too wide to display horizontally. It does this without re-executing the query because MySQL passes the length of each column in the result set.
It's a shame MySQL 6 is still so far away, but still: nice feature!
When I work, I usually use two computers: an Ubuntu-powered PC and my MacBook Pro. Of those, the Mac is my main machine: I have all my development tools and environments running on it, I use it for mail and documents, my music is on it (because I can't work in silence), etcetera. It has this value to me because I can carry it to wherever I need to, which means I can use it at both of my two jobs, plus on location if I ever need to (and sometimes I do).
But there's one thing missing: although Mac OSX is a very nice OS, probably the best I've worked with, I still need Linux to complete my wishlist. The combination of Krusader and Kompare, for instance, is a golden one if you need to organize your development projects. Krusader is a two-pane file manager, with the option to use FTP and SFTP or just local files. Whenever I need to examine the difference between two versions of the same file (and I need to do that a lot: before commiting my changes to version control, I want to know exactly what I'm doing), I set up Krusader to have a folder with one version of the project on the left and one version on the right. I then select the files I want to compare and the magic happens: Kompare starts.
Kompare is a frontend to the diff tool and as such not that special: if I just want to quickly see the difference between foo.php and it's current state in CVS I can just use the built-in comparison tools from Zend Studio for Ecplise. But: Kompare is so much better! It has coloring to differentiate between additions, removals and changes, is more precise (due to the tried-and-tested diff being the backend) and has the ability to apply some of my changes to the other file, which enables me to be more exact in what I commit (you know, sometimes you have several changes in a file, but just a few of them belong to that relevant bugfix and the others are for that new feature that's still unfinished, so you want to do a partly commit).
So, I need Linux next to Mac, because those tools don't run on Mac OSX. When at home (for Job #1), that's no problem. My only PC is an Ubuntu machine. But at work (at Job #2), I have an old PC which is kinda slow which I use for this. And the slow part, that's annoying. Because whenever I need to use Kompare, I need five to ten minutes to boot the thing, and every action after that needs a lot of patience.
But, I share my desk with a colleague who sits there when I'm at Job #1. And he has his own PC, stalled under the desk next to mine. A new, fresh one, nice and fast, running Windows, and I already discussed making that one a dual-boot so we can share not just the desk, but the PC as well. But I don't have the time to go and install Ubuntu next to Windows, carefully selecting partitions, making sure I don't nuke his installation, and whatnot. So even months after "Hey, can I make that one a dual-boot?" - "Sure!" I'm still working on the slow machine.
Enter Wubi. Shipping with Ubuntu 8.04 next week, it's an Ubuntu installer for Windows. And it does exactly (exactly!) what I need:
When I rebooted my machine, an option to boot Ubuntu was added to my Windows boot list, and after selecting it, Ubuntu started loading just as it would if installed on a dedicated drive. I was even given the normal GRUB menu. (Linux.com)
So now I can just boot my colleage's machine, put in the Ubuntu CD, click through the installer and enjoy Ubuntu. No need for me to run the Ubuntu installer, carefully selecting drives, doing all kinds of stuff that costs me time. Just click-click-install, the Windows way.
Life really does get better with every Ubuntu release.
I don't get this. I've had this on servers, on desktops, now I have it on my Mac: a process froze, didn't do a thing and just ignored the hell out of me. So what do you do? Kill it!
In Mac OSX, there's a little interface which allows you to choose an application and force it to quit. Works every time. So far. But how do you solve the frozen-process problem with a fullscreen application that won't let you switch to another application, like Front Row?
Tonight, my Mac froze on Front Row. I was comfortably sitting in bed, ready to watch an episode of a tv show on DVD, when Front Row just froze up. Silent. Nothing. No response. So I got out of bed, walked to my Linux PC and logged into my Mac using SSH. And I looked up the logs. And there it was:
Mar 31 22:41:46 Yoda2 diskarbitrationd[43]: Front Row [4394]:40707 not responding.
Non-responsive. That's fine, I thought, I'll just kill it, get back into bed and start over. But Front Row didn't let itself be killed:
breuls@Yoda2: ~ $ ps aux | grep Front breuls 4435 0.3 0.0 590472 84 s005 R+ 10:43PM 0:00.00 grep Front breuls 4394 0.2 3.8 430184 78816 ?? U 10:39PM 0:11.11 /System/Library/CoreServices/Front Row.app/Contents/MacOS/Front Row breuls@Yoda2: ~ $ kill 4394 breuls@Yoda2: ~ $ ps aux | grep Front breuls 4394 0.0 0.0 0 0 ?? E 10:39PM 0:00.00 (Front Row) breuls 4440 0.0 0.0 590472 204 s005 R+ 10:44PM 0:00.00 grep Front
That's right. Didn't listen to the kill command. Now, I know about the several options to kill. I tried several, including the -9 switch. Didn't work. Front Row ignored me, all the way through my giving up and pressing the reset button.
I hate that. That's not supposed to happen. Kill -9 is supposed to be the last way out of trouble. It-should-work. But it didn't. Why am I not in control of my own laptop? Why is there an afterlife to kill -9?
According to Baron Schwarz the second edition of High Performance MySQL (the first edition being written by Jeremy Zawodny and Derek Bailing, which I read twice and still often use as reference) is in production, meaning that it's written and being prepared for print.
That's good news! As a MySQL developer and DBA, I'm very interested in knowing every piece of information about how to make MySQL perform well, and as soon as I can, I'll order a copy.
Canonical: "Landscape provides users with a hosted web interface on which all machines are registered. From this single interface, packages and security updates are deployed to the entire network of servers and/or desktops with a single click. Additionally a wealth of monitoring data is provided graphically to the administrator showing process and resource use as well as flagging any available security fixes for the system."
Wow. Cool. Seems like a real time saver; currently, when I have to apply changes to a group of machines, I find myself logging in and out of each of them and that's not very funny when you know your server farm increases in size regularly...
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.
I'm working on a piece of PHP-code, and I need to examine if there are any bottlenecks in it. It's not much code, about 170 lines, but there are quite some includes, object instantations, conditions, etcetera, and I can't easily oversee if there's anything that might cause a web server's load to rise too much if this particular piece of code gets executed hundreds of times a second (I know that that is certainly going to happen).
So, what do I do? I do a quick check: do I have any debuggers or profilers running in the background which I can use to learn about this code? And I find there's a Zend Debugger present, because I run a development version of Zend Platform.
Using get_extension_funcs() I know that the debugger has six functions I maybe could use, but I don't know what they do. Can they give me some useful information? I don't know. So I just call the functions to try them out. Nothing of use comes of it. So I decide to look up some documentation on these six functions.
Nothing on PHP.net. Nothing on Zend.com. Nothing on weblogs where Zend Debugger is mentioned. Nothing on forums. Nowhere can I find documentation on how to use Zend Debugger from my code. Doesn't anyone use the debugger? Is it only meant for use in Zend Platform and IDE's like the Eclipse PDT thing?
Okay, this annoys me. Since a few hours, the wireless connection on my MacBook Pro is gone. No reason given. Of course I'm trying to connect back, while I'm using Google to find solutions when it seems I can't solve this on my own.
The problem is, my Mac recognises my wireless network. It can see my accesspoint, read its name and it asks me kindly if I would like to connect to it. Sure I would, so I press Yes. It then tries a couple things and comes up with the message that tells me connecting failed. No reason given.
Being both a Linux desktop user and Linux server admin, I have seen my share of failing pieces of software or equipment, and one of the reasons I like Unices to much is that there's a whole bunch of logiles being kept in the /var/log folder, providing me with the how and why of these errors. Mac runs on a Unix-type OS, so during my wireless-problem I'm listing the files in that folder, sorted by date and time, and I'm using tail to view the latest entries in what seems to be the only active log file: system.log. Indeed it shows me some errors, but there's nothing corresponding to the pop-up message that told me the connection to my accesspoint failed. Nothing! Not a single logfile seems to have updated with information I can use to solve this problem.
And I've seen that before: software that's dealing with its problems all on its own, without asking for help or enabling the user, me, to find out more using Google or my own knowlegde. That is a mistake. If you create software, make sure you have nice friendly error messages for the average user. That's important. But the "extra mile" in this is just as important: make sure you write every error into a log file and point me to it in case it's not system.log (or syslog or messages or anything that can be considered a default). Make sure enough information is in there to enable me to exactly understand what's going on. I am a technical user. I understand technical information if it's described in a human-readable way. I can think for myself and come up with solutions, or spend time pasting the log entry in search boxes to I can find other people's solutions.
To me, having enough information is very important. So, software developers, please log all those information somewhere.
Paolo asks whether it's a good choice to start a promotial site for Italy with some flash intros. I think it's not. This is what I posted as a comment:
I don't like the flash intro. It has no use whatsoever and it makes me wait. So if they could drop that one, it would be great.
Second, I get the intro with the language choice. Now, that one does have a function, but I would guess that the majority of visitors speak English, so it's probably better to open with the English site and make it clear that an alternative language can be chosen.
I don't really mind the third flash thingy on the site itself. After all, it's a tourism site, so some sights of the country are okay, as long as all the information can still be easily found.
Flash intros really are something from the past. Or at least, that's what I thought. When people started discovering this 'new easy way of creating animations on the web', people built entire sites in them. That was okay, back then. As were the intros. But please, it's 2007. We know that flash intros have no additional value, what-so-ever, to a site that centers around giving information.
So to all you webdevelopers out there, pondering on the possibility of a flash intro: don't. Please don't.