PHP

This year some folks at Mayflower decided to make an advent calendar with a daily blog post, and today was my turn to write.

So here's One-click Deployment (with Jenkins).
Comments are welcome over there or via twitter to @anderiasch

About a week ago I stumbled upon this post by Syp about the reception of betas in gaming.

It sums it up quite clearly, when you release a new game (especially, but not limited to MMOs) - the beta phase has to be awesome. Unless you're working on a major intellectual property (like Warhammer Online) or got a huge fan base (Blizzard) you can make or break your influx of users with the beta of your shiny new game.

Now where's the point for software developers, and especially open source developers?
Ever heard "Release early, release often."? - bet you did.

I'm not really seeing this in open source development. OK, some people don't really want to make money with their disclosure and free licensing of their code, they're happy about any feedback and just hope for a patch or bug report by people playing around with it.
Still many of those people then offer the product in any way or consulting/paid feature implementation - they get real benefits by short release cycles, even if it's only to be present in the news and not amass too many security holes by years-old installations. (Yes, that's speculation and a bit of faith in humanity...)

Bzt the same case stands for software-as-a-service vs. games with subscription costs. You're not making any big shots with the original software package or the game box (if it costs something at all) - no, you're relying on recurring payments by (hopefully happy and not disgruntled) customers.

So, where's the difference?
Is it because you're not making your money by selling the box and then forgetting about it?.
Is it because people using open source software are less demanding (i.e. happy something fixes half of their problems and they only need to solve the other half) than gamers who get to use the beta for free?
Are gamers in the hopes they can make an impact by reporting bugs in the beta so those might be fixed at release?

I recently ran into a problem that stopped me from having 100% test coverage on a file.
This is the piece of code, the overall reasoning for it can be found on the microtime manual page:

This function is only available on operating systems that support the gettimeofday() system call.

In case you did not spot it, the else path is never accessed if your system has a "microtime" function available. Additionally the change can be non-trivial because time() returns something like 1012314124 and microtime() returns "0.80057400 1257872321" or "1257872326.3036".

My first idea was something like this in the test case:


Then the idea was to use variable functions, but in the end I think it's not worth to change the source code to something less intelligable only to achieve 100% test coverage for a trivial case.

Of course you could always invoke a CLI php with a special php.ini if you have bigger chunks of code to be tested depending on the availability of certain functions.

Another idea could be to create a wrapper for microtime that you can mock and in your mock object always return the output of time() instead of microtime(), this would probably be the best tradeoff between readability and testability.

Any ideas?

Yes, it's the new hype - URL shorteners (mostly for use in Twitter).
Some use the classic tinyurl, then there's is.gd and bit.ly and a fair bunch of others.

As some people already wrote, and I feel no different here, broken links are baaad, mkay?
So the easiest way would be to get a short domain for yourself and run your own url shortener.
I am happy enough to have secured myself a not yet publicly announced 3-char .de domain which I'm planning to use for that. This and being bored for 2h led me to roll out my own shortening service.

Enter Shortcore - 259 lines of php code, working already.
It needs PHP 5.2.0+ (I think :P) and sqlite and I've put it up on github - it's BSD licenced and comments and patches are very much appreciated.

How to use it when it's installed:

• http://example.org/_[uniqueid] redirects to what you saved.
• http://example.org/_[uniqueid]_ shows a preview
• So I have "xxx.de/_ab" - as low as 10 chars for an url (excluding http://), that's not less than a bit.ly url (currently at 5+ chars after the /) and I can still put normal content (not starting with a "_") on the domain - fair deal I think
• there's a bookmarklet for easy saving, either provide the [uniqueid] or let it be generated automatically
• it's not meant as a public shortening service, so probably some basic auth has to be added

You might skip this entry if you don't speak German - but you're still welcome to help translate the PHP manual to *your* language :) news.php.net shows you the documentation mailinglists as php.doc.*

Sammy posted a little reminder (and an addendum) for the German PHP documentation team, how to update your outdated files, so at least the technical barrier won't be a reason.

If you did some translation work in the past you're very welcome to join again and if you didn't, feel free to give it a try, it's really not hard and there's always a lot of stuff to do.