RJHarrison.org

I’ve worked at some small companies as both employee and freelancer. I’ve also started my own business a number of times. In all these experiences, the company in question was never been termed a “startup”. It was always just “a business”.

To me, defining yourself as a startup is a mistake. It smacks of drinking the Silicon Valley Koolaid and the almost desperate business models that follow. On TechCrunch today there was a good example of this; the company described themselves as “a fast growing tech company with a deep product backlog, high growth on our core web and email offerings and an overwhelming desire to invest in our customer understanding and in our technology“. You know what I smell? BULLSHIT!

There is often bitching about how there isn’t a Valley culture anywhere in Europe, today I started to wonder if that isn’t such a bad thing. Perhaps there are just fewer rich idiots over here prepared to fund stupid ideas?

Calling yourself a “business” forces you to think about… BUSINESS! If you went around saying you ran a business, people would expect it to do something: to provide a service or product, but when you call yourself a Startup it’s like you have a license to ignore common sense.

In fact, I do now talk about one of my past businesses as a Startup: I spunked $50,000 up the wall on an unproven idea that crashed and burned with zero customers. Truly, a Startup ;-).

Facebook have released HipHop, a piece of software that converts a PHP script into C++ and then compiles it into a static binary. That binary operates it own HTTP server.

About a year ago I wrote a couple of posts about my thoughts on Apache and how we don’t really use it much and actually why I think it’s still relevant. In one fell swoop Facebook has provided an answer/solution to my ruminations; it is now possible (I think) to run PHP as a standalone application server (kinda like Rails with Mongrel, or Python with CherryPy et al).

Most of the applications I write have a single entry point that bootstraps the framework and handles all the routing - my “index.php”. For this scenario, using HPHP sounds like a win: you compile your index.php and instead of using .htaccess to route a set of urls to it, you just configure Apache to reverse-proxy those requests to your backend HPHP instance/s (not sure yet if it will thread, fork or block yet). You could also still run regular php scripts on that Apache server, and just offload some requests to the HPHP daemon.

It sounds like it will really come into its own when you’re essentially running Apache as a container for a monolithic PHP application. Instead of running Apache+PHP on a backend server, you just run the HPHP application. Win! (This is going to rock for API/REST services.)

Some questions:-

• How will it handle autoloading and dynamic classes? Presumably we’d have to give the compiler a list of directories of libraries to include in the compilation?
• What about 5.3? I’ve personally switched, does HPHP support it? (Also, will HPHP and PHP releases be synced?)
• How does the HTTP/server stuff work? Is it a single process that manages worker-pools, does it thread or what?
• How will multiple applications work? I’m guessing each one will need a new HPHP daemon.