I’ve been trying to config our Apache server today.

These are the requirements:

• We want PHP version 5.
• All users accounts are separated through virtual hosts.
• PHP should be run with the same user rights as the user, this means either CGI or FastCGI with suexec; because when frameworks create files in the home directory, they should be owned by the user, not by apache.
• PHP should be locked down with open_basedir, and session storage should be in the user’s own home directory.

What an enormous, unbelievable mess this has been to set up. We’re also doing this with CentOS 5.1.

suexec is a bitch to set up, but, in the end, it works.

There is practically no documentation on FastCGI and how it works. There is a ton of user-submitted scripts, all of which are crazy in one way or other, and don’t seem to work on my box.

Many of these methods seem to rely on patches, and I want to maintain my yum compatibility.

The most difficult thing was to make PHP default to different values for each user account, and in the end, I had to make a cgi-bin/php5 file, setting PHPRC to the user’s home directory, and build a small shell-script that copies /etc/php.ini, tacks on a few custom settings at the end, and puts that where the cgi-bin php script can find it.

Unbelievable. But, the good news is, with a plain vanilla suexec + php-cgi setup, it now works.

A motorbike driver is “speeding along” on the congested freeways in Tokyo.

Nyligen upphittat.

Om du försöker hitta hem men istället hela tiden kommer tillbaka till samma gamla sandgrop, kan det faktiskt vara så att sandgropen förföljer dig.

Titta in till någon när som helst om du känner för det. Säger de “Usch, är det du!” kan du ju titta ut igen.

Alla kan inte och somliga vill inte. Så är det bara.

Ibland är en båt en båt och ibland är den närmast en Olyckshändelse. Det beror alldeles på om du är över eller under den.

Ibland, när man står på den nedersta slån på bron och lutar sig fram och ser ån långsamt flyta fram under sig, vet man plötsligt allt som finns att veta.

Fastän det är väldigt gott att äta honung, så finns det ett ögonblick alldeles innan man börjar äta den som nästan är ännu bättre.

När man är en Björn med Mycket Liten Hjärna och Tänker Ut Saker, upptäcker man ibland att en Idé som verkade vara riktigt Idéaktig inne i hjärnan, är helt annorlunda när den kommer ut i det fria och andra människor ser på.

Bra visdomsord att leva efter. :)

I’m sitting here wondering if I should go public with the PHP framework I’ve built over the past couple of years. It’s gone through a couple of iterations and is now something that I’m regularly building internal and external websites on top of.

No, it’s not the same thing as my Nifty CMS, but that one is built on top of what I now shall call the Nifty System Library.

It features

• MVC-based mechanisms, including templates, controllers, and database mapping
• A simple, custom built templating class, using pretty much PHP’s own template system with a few enhancements sprinkled in
• Page caching
• Basic application configuration
• Automatic call routing, including friendly URL rewriting, call-to-method dynamic invocation, and parameter filling
• Several wrapper classes for Request, Responses, Sessions etc
• Complete PHP5 OO design
• Minimalistic and intuitive class design, using static calls for shortcut class operations
• Database abstraction, including a simple class-to-table POPO persistence layer
• Simple module layer
• Clean separation between pages requiring authentication and public pages
• Zend-like directory layout (separated system, application and public_html folders for instance)
• Utility classes for…
  • Excel/Delphi-style DateTime handling (DateTimeEx)
  • Image manipulation (GD)
  • HTML and database escaping (database agnostic)
  • Password-checking
  • TCP/IP connections
  • Uploading functions
• ~40 files, 141 kilobytes total.

Once you’ve learned the basics, the system is very efficient, allowing you to build clean, efficient web applications with database integration using a minimal effort.

Is this something that people might be interesting in using, you think?

Lights. Must get lights.

I’ve never been one to make a cozy feeling at home, what with furniture and curtains and stuff. My place has been decorated in a kind of classy, comfortable way with a heavy bachelor tone. Sometimes I wish I had that homely touch, but the cleaning-up spirit always disintegrates shortly after I sit down at the piano to just “brush off some of these old songs I found”.

Now, it’s the lights. I don’t have any lamps. The few ones that come preinstalled with the apartment are far too garish and crude, and only sit in the kitchen anyhow. And during the summer, it’s so light outside anyway that I hardly need lights. So the two lamps I had in the living room, well, one kind of developed an electrical fault (!) and in the other, the lightbulb went and I forgot (repeatedly) to buy spares.

But now that fall is upon us, and it gets really dark, I suddenly realize that I’m all out of light! It kind of gets bad when I have to turn on the TV set and set the channel to some light entertainment (pun intended) so I can see what I’m doing in my living-room.

The ironic thing is that I feel so … cliché. I have laptops. I have a home theatre entertainment system. I have wireless broadband, a Linux server in the basement that hosts my PHP development projects, and am connected with all the knowledge of the entire world at my fingertips.

But I sure don’t have any lamps.

Sometimes I really think my life could use a bit of a female touch.

I noticed earlier that our helpdesk system (written in PHP) became somewhat slower after we upgraded to the new version, 1.1. I always thought I’d look into it but never got that far. Of course, I’m using a self-written framework, and I’ve known that it hasn’t been profiled for speed, so I knew there’d be a few things in there that could use a tweaking. So, I fired up a debugger/profiler today and went to work.

XDebug is the premier choice for PHP debugging/profiling. It is available both on Windows and Linux. Just plug it into PHP as a Zend extension, set the configuration to enable profiling, and voila!

zend_extension_ts=”c:/program files/php/ext/php_xdebug.dll”

[xdebug]
xdebug.remote_autostart = 0
xdebug.remote_enable = 0
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = “c:\home\temp\xdebug”

It creates a nice little output file in the output directory. And using WinCacheGrind, it was easy to analyze the logs and see what functions took most of the time.

One little caveat, though – it seemed as though the actual execution time reported by PHP and by XDebug varied by a factor of 10 – a huge difference. But the relative time between function calls indicated by WinCacheGrind was still useful in isolating the time hogs. Just pretend that 466 ms actually is 4.66 s, and there you go.

The result: I discovered that one single function, DateTimeEx::getDateTime, which decodes Excel numeric dates into actual date/time values, stood for a whopping 90% of the total execution time. In this case, there are about 200 objects instantiated from the database, and each of those database objects are called several times to extract date values. So there was a lot of date calculation going on. However, there is no advanced stuff going on (like loops) inside the function, just a bunch of float arithmetic – the only conclusion I can draw is that PHP really sucks when it comes to complex float calculations.

First, I was able to cut down on a few things inside the actual function; and then I made a self-populating date-value cache, holding 300 calculated values.

The result: Execution time for the entire browser request went down from 4.8 seconds to about 650 milliseconds.

Lessons learned:

• Profiling is invaluable, especially with an interpretative language like PHP, where you never really can be sure what costs time and what doesn’t.
• XDebug and its companion WinCacheGrind are essential tools and work well on a Windows/Apache platform.
• The DBGp plugin for Notepad++ is also useful, and allows you to debug PHP scripts live, but has some limitations. However, it doesn’t require a full-blown IDE, like Eclipse or NetBeans, and can be useful as a little drop-in tool.
• PHP is fun, especially when you have powerful tools. :)

I switched places at work today.

The desk opposite my old one is adjustable in height, which makes it possible to stand up or sit down while working. In realizing that I’ve been sitting down for basically the past 33 years (okay, exaggerating), I thought it’d be a nice change.

And it is. I’ve been standing up nonstop since switching, and it’s a wonderful difference. It feels just great, being able to stand up and work and not constantly sitting on my butt all the time :) Now that I have tried it, I think it should be a mandatory requirement at all workplaces, to have adjustable desks.

I’ve also started walking: Twice a week I now try to take at least one-hour walks, which feels great. I miss the outdoors actually, and the long walks I used to go on many years ago.

Perhaps this is the start of a healthier life. I hope so.

In the surge of hurricane Ike in Texas: $5 Gas Prices.

It seems absolutely horrible, for anyone who’s followed the gas price fluctuations in American news lately. But I wondered what that would be in Swedish terms: Not expressed as dollars/gallon, but in kr/liter.

It turns out, it comes to about 8,85 kr/l.

I cannot remember the last time we had those kinds of prices (80’s?). Currently, the Swedish gas price is about 13 kr/l, which would be about $7,35 per gallon. Of course, a large part of that is tax, but still.

I guess everything really is relative.

At work, we’re using MediaWiki as both an internal and public wiki (we have two different ones, separated, to provide watertight bulkheads between them).

Recently, the administrator of the public wiki has been looking for ways to automatically generate PDF files. One extension in particular, Extension:Pdf Export, seemed to be useful; but on closer inspection we found out that the component it relied on, htmldoc, could only handle HTML 3.2.

Thus we were stranded. We tried PHP dompdf for a while, but it threw a fatal exception on the code output by MediaWiki, so that was a no-choice either.

But it seems like MediaWiki always generates XHTML-compliant output, which means that it’s possible to use a XSLT/XSL-FO parser. And Apache FOP seems to be a good choice right now; it’s Java-based, meaning that we can run it on the unix box with no problems (we hope!).

So, essentially, the way this could work would be to take the output from the PHP code described in Extension:Pdf Export above, but instead of running it through htmldoc, we run it through fop, kind of like this:

fop -xml generated.xhtml -xsl mediawiki-to-fo.xsl -pdf output.pdf

“generated.xhtml” is the file saved from the MediaWiki plugin, mediawiki-to-fo.xsl is a stylesheet that converts HTML into suitable XSL-FO definitions, and output.pdf is the generated result. FOP turns out to be quick and expedient.

Of course, this leaves us with generating the .xsl file, which is going to take some time. An excellent start is available at IBM DeveloperWorks.

All that remains now is putting the pieces together and we should have a simple, efficient plugin that generates beautiful PDF documents. If everything works as expected, that is … ;)