While the Seinfeld calendar greatly helped me to get the habit of doing something productive, the service I used has its flaws. First, it’s restricted to GitHub. Also, since it only counts commits, and not the fact that I can work without any finished product, it made me prefer short work and postpone doing stuff I wasn’t sure I would finish before 00:00 (the fact I start late does not help either). The notion of a day is also wrong — committing at 00:30 should not be counted for the current day but the previous one.

The basic idea is to start a server without any central configuration to maintain, and no need for any root access, hence generic virtual hosts features of Apache or lighttpd are not complete alternatives, as they at least require editing /etc/hosts.

It uses the FastCGI backend (or “SAPI”) and can by default handle 3 concurrent requests, which is more than enough for development. On the production side, I only use symfttpd to generate the rewrite rules (since lighttpd is also my production server of choice). If you have an opcode cache installed (for instance APC or xcache), it will be used, as fastcgi processes are seldom restarted (by default every 100 requests, I use a higher number on production though). It also does not rely on any hacks to simulate a web request in the CLI: you are doing real requests using a real PHP HTTP backend.

One of the future improvements could be using FPM instead of FastCGI.

Symfttpd can optionality use the fork function to provide two nice features: automatically restart when rewriting rules change, and display the access and error log. However, if you do not have fork support compiled in (it is enabled by default in at least Gentoo, Debian and Ubuntu), it does not mean only one request can be answered at a time (lighttpd does not need fork() by the way, which is one of the reasons it is very fast).

I don’t like to listen to stuff loud. People usually listen loud because their setups are bad and it compensates somewhat. Well, I’d like to preserve my hearing — already imperfect — as much as possible. With my current IEMs, the outside noise is actually louder than when I wear them and play music. In a way, it’s even better for my hearing!

The issue is that nowadays, pretty much all portable players are crap. They rarely support interesting formats. Their amplifier stages are tuned for loudness and sacrifice the dynamic range. Their interfaces are animated and shiny, yet don’t get shit done.

The most popular remedy to bad amplifiers is to use an Apple device, as the proprietary connector provides line out, which is an unamplified signal, and to use an external amplifier. Some other devices provide line out, but are much harder to find. The recommended choice is an iPod 5.5th generation or below, as their DACs are of reasonable quality, but mostly because they are not as locked down as the new ones.

Hopefully, you can replace Apple’s horrible software by Rockbox, an open source alternative that will allow you to get rid of the iTunes dependency or support open and high-quality formats such as FLAC and Ogg Vorbis. One of the perks I get with it is the speaking menus — you can more or less control the device without looking at it, which is not easy to do when there are no buttons but only the ergonomic absurdity that is the “clickwheel”. It can also announce the battery status. The ReplayGain feature prevents me from having to adjust the volume between albums.

Another issue with iPods is the usage of an hard drive. While cheaper than Flash memory, it is much more unreliable and requires more power. You can however replace the hard drive by a CompactFlash card.

My current setup consists of an iPod 5.5g 30gb, with the hard drive replaced by a 32 GB flash drive (it wasn’t much of a choice, given the horrible noise the drive was making). It uses a SendStation Line Out and Micro USB adapter (no need to use a proprietary cable!), which is then hooked to an iBasso T4 amplifier. The amplifier provides me with an hardware volume potentiometer which for that reason alone is worth it. The final stage is handled by the Future Sonics Atrio M5.

Am I happy with it? Well, the sound quality is more than enough. I doubt I could enjoy my music more by upgrading to something else. However, I have a lot of unrelated complaints:

I spent 80€ on the iPod yet much more to make it suck less. And it still sucks. The build quality is shoddy, I frequently have to open it to reconnect components. It powers itself on even when the “lock” switch is activated, draining the battery needlessly. The clickwheel is a pain to use and I can sense it dying. The screen is shiny and obviously unreadable under the sun. Dust is getting inside. It is very slow to power on. The battery isn’t in a good shape, but the Flash memory and usage of an external amplifier compensate for now.

iTunes wasn’t able to restore the iPod properly when I changed the drive, so I had to mirror the drive exactly to the CompactFlash card (losing the additional 2 GB of space), contrarily to what was stated on the adapter’s website. Since I’m probably not the only one with the same issue out there, here is a raw copy of the drive with Rockbox installed as the only OS. It also was a bitch to open, even for an Apple product.

Uploading files to the iPod is slow as hell, and sometimes fails. It seems it doesn’t like writing more than a few gigabytes in a row. And the dock adapter has a tendency to come out.

To sum up, I’m using an iPod but discarding its software, and half its hardware.

The iBasso T4 uses a proprietary cable to recharge. Other than that, it caught many shocks but still works flawlessly. And it can be opened with a screwdriver.

As for the Atrio, for 100€, they were a solid choice. Now that they cost twice as much (and still are the same product) there probably are better options. I use Comply T100 foam tips, and they are generally compatible with Shure eartips (which motivated my choice since I have a bunch of them in stock). One nice touch is that the user’s manual recommends against any artificial bass enhancements: you know you’re not dealing with crappy phones.

So, what would I recommend instead? Well, I’d probably get a FiiO E7 or another iBasso model. But for the media player, I’m stuck. Hence the title.

There might be some hope on the side of the PDMI connector, though.

You can now use genconf without linking or copying it inside the project. It also makes the usage of mksymlinks more or less optional if you just want to use spawn.

Not much else too see apart from small bug fixes and documentation improvements.

Download symfttpd 1.1.1.
More information on GitHub.

There is also a adaptation of the current code for usage with Symfony2. However, it removes support of 1.x versions; a multiple-application update of symfttpd is coming soon.

This version brings one huge usability change: you don’t have to restart spawn anymore when a file is added in the web/ directory root. Enjoy being truly lazy!

Along with some miscellaneous enhancements, the output of the tools is now colored, and you can display lighttpd’s logs in the terminal with the -t option.

As always, suggestions and contributions are welcome.

Download symfttpd 1.1.0.
More information on GitHub.

If the activity of my blog leaves you frustrated and demanding for more, rejoice! I am also writing on my employer’s blog.

I have grown very fond of Symfony 1.4. It’s pretty much Symfony 1.2 with all the quicks ironed out. It showed me how much polish is important in a software project.

It’s almost all I have been doing in my own little project after the main features were implemented, symfttpd: making it less annoying to use, less unpredictable, etc. And I must say, the current stable version has at least one very annoying quirk (but if it’s documented, does it count as a feature?).

Sometimes, the code looks good, but it doesn’t mean that the whole project in itself is good.

First, a project should be simple to install. The install documentation should exist and always be up to date. I encounter too many projects where “inside knowledge” is required to install the application, and you don’t know if it doesn’t work because you didn’t install it right or it just doesn’t work. There should be a single command (makefiles or shell scripts are here for that) for a single task. It should not require weird system settings (this is very annoying with PHP when a lot of the language is customizable through php.ini).

On a similar note, the architecture should be simple to comprehend. When it feels too much like “magic”, when a simple action has too many unsaid consequences, something is wrong. There should not be hundreds of classes and inheritances when an option would be enough (this is an idea found at least in Python and Symfony 1.4 that I quite like). Names should be readable and short, not everyone has or likes using auto-completion.

I’m not sure what creates this kind of WTF. Inexperienced but talented programmers? Programmers who think too high of themselves? Programmers that are not lazy enough?

Well, chmod 666 is the true evil obviously, but people who use the chmod 777 trick really don’t want to bother with the different signification of x for files and folders, so they mark all files as executables. This makes ls in my terminal quite ugly, and is what motivated me to write yet another rant!

Traditionally, the web server runs with a special, underprivileged user. Now, this is totally fine — I’ll get back to that later. However, when a developer starts a project, he naturally does it with his own account. This is fine, too. When he wants to test it, he installs a web server (let’s say Apache and mod_php¹), and tells the web server to use the project directory. However, the web server’s user can’t read, or at least can’t write in the directory. And here, our web developers asking for help gets recommended to “chmod 777″. Symfony even has a command for doing it, and it is a real shame.

It will work. It will also make an ugly git commit, and an ugly ls. Il will create files owned by the web server, and the developer is likely to use sudo before every command to work around the problems that will ensue, and it just gets insane.

Separation of privileges is what makes UNIX systems great. Let’s understand them and use them, please.

The obvious solution here is to run your development server under the development user. There is no need to separate when it’s for your own usage. There is a even better solution, embraced by almost every language but PHP: a way to start a web server on demand. I believe it was started by Ruby on Rails with WEBrick, and now every non-PHP framework has it. Python, by using WSGI makes it very easy. I simulated this feature for Symfony by writing symfttpd. It’s actually simpler for the developer as there is no configuration or installation at all.

Enough about developers; it’s not their job to setup daemons and manage UNIX systems. Let’s talk about the real accomplices of the Devil: system administrators.

Yes, there are system administrators that don’t use permissions properly. And they are legion. I’ve seen horrors, up to “sudo svn up” on the production server, because half the files ended being owned by root. And then “chmod 777″ on millions of files.

There are many solutions there; group inheritance with the setgid bit, forcing the users to su as the web server user, or a deployment script (I’ve used the three of them for different situations).

Why is this important? Because it is often useful to separate users (one should not have access to the other’s projects in reading or writing), or to separate projects for security (one hacked project should not give access to the others).

I’ve seen it… done wrong:

• safe_mode for PHP. It doesn’t work and will disappear in newer versions anyway.
• Only allowing FTP access to users, who can still upload a PHP script which will have access to everything (if run through the web server). Oh, and FTP sucks. Same issue with SSH and chroot.
• Add the users to the group the web server is running as. Allows SSH access. Nice, but the PHP script trick will, again, defeat it.

There is only one solution: use the “group” solution, but run a different PHP instance for each user. It is quite rarely used because the convenience of Apache and mod_php. But running PHP in the same process as the web server feels quite dangerous for me too. I think mod_php is an abomination.

I’ve done it for years with Lighttpd, PHP and FastCGI with a few alterations to Gentoo’s spawn-fgci init script (which is now able to handle multiple configurations without any alteration since a few months). My setup is very similar to that one.

Note that while I mention PHP, this issue is not strictly related to PHP, yet seems widespread in PHP communities.

1. I don’t like much both of them, but more on that later

I see on a lot of projects stuff like this:

function getStuff()
{
  try
  {
    return $this->retrieveStuff()
  }
  catch (Exception $e)
  {
    return null;
  }
}

The issue, in this example, is not that we silence an error. It should be logged, but there could be a legitimate use for this. For instance, it requires a connection to a remote server we have no control over, and we still want to serve the rest of the content to the user, as the information is not vital.

No, my issue it that we catch all errors, when the aim was to catch only one error (for instance “unable to connect to that remote server”). Imagine now there is a real bug in retrieveStuff(), it would still be interpreted by developers as a connection errors.

The solution is to have one exception type per error type (it sounds obvious said that way, doesn’t it?), and only catch the specific error, for instance ConnectionError.

PHP’s error handling is historically bad, and even though new features use exceptions, the legacy ones don’t. Or sometimes functions should trigger a fatal error but it is only a warning, and the code continues, which can trigger unwanted and hard-to-debug results. There are amazing plugins for Symfony that convert errors to exceptions (and warnings seem to be handled properly, i.e. they are logged and don’t cause the page to fail). It’s a start.

However, even when you get exceptions, you can’t always filter them easily. For instance, in Symfony, there are many different errors that would throw the same class. Symfony has a handful of exceptions, Doctrine has a bit more (though they can be quite meaningless!). Overall, there are defined “by module” than “by error”.

Comparatively, Python’s handling of exceptions is exceptional¹. There are exceptions for everything, and most of the time errors are handled by only checking the class and not the contents of the exception. It is probably the feature I love the most about Python. With the else, finally, and with statements, it is almost a pleasure to handle errors.

1. sorry