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 … ;)

Over the past few days I’ve been trying to build a number of Windows server administration scripts – you know, for adding users to the Active Directory, creating new IIS websites, doing various stuff – and I get the distinct feeling that this is not something you normally do.

Whereas Linux has tools that do the job pretty much for you – everything is script-based anyhow, there is no point-and-click GUI – Windows requires you to dig into scripting, PowerShell, WSH objects, or any similar methodology to try to automate the task.

It’s almost like no one has ever done this before. And the few who have managed to penetrate the API’s enough to do so, have gone on to become employed at the Microsoft Scripting department as technology gurus.

There is a short clip from Monty Python that summarizes my feelings about this. It’s available here, in MP3 format.

This seems to be the state-of-the-art way to change access rights on a file in PowerShell:

$colRights = [System.Security.AccessControl.FileSystemRights]“Read”

$InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None
$PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None

$objType =[System.Security.AccessControl.AccessControlType]::Allow

$objUser = New-Object System.Security.Principal.NTAccount(“domain\user”)

$objACE = New-Object System.Security.AccessControl.FileSystemAccessRule `
($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType)

$objACL = Get-ACL “c:\testfile”
$objACL.RemoveAccessRuleAll($objACE)

Set-ACL “c:\testfile” $objACL

Funny… The unix version would be something like

chmod 600 /testfile

I… uh… I don’t know. I’m tired. I want to go home now.

We started getting spurious temperature fluctuations in our server room a while ago. Each night, temperature would rise to above 30C for about half an hour, and then go down again.

Over the past couple of days, it grew increasingly erratic and threatened the entire server room functionality — outages grew more and more frequent and finally we had to put another A/C unit in there, with open doors (because of the vent pipe) to try to contain it.

With something like 15-20 servers, it’s incredible how much heat a server room can generate.

The problem is that once temperature starts rising, some servers start malfunctioning. We had one server stop responding to TCP/IP, so it had to be restarted. And hard disks start crashing soon if temperature doesn’t go down again. One colleague of mine had backup tapes literally melt inside the backup unit once, he told me. So it’s been with a mild state of panic that we’ve watched the temperature go up and down this past week.

Of course, we tried to make repairs and isolate the error. Is it a malfunctioning control board inside the unit? The compressor? Is the current on to the contactor in the external unit? … Digging into a 380V external appliance to measure voltages was a first for me :)

In the end, it turned out to be a current protector that was faulty. It’s designed to shut off if the current grows too strong, to protect the compressor, and it was misbehaving. It was replaced, and voila, everything ran perfectly again.

It’s amazing how such a small little cheap thing can affect so much.

Just a little note to those of you who keep track…

NiftyCMS 0.9 (“Händel”) is now finished. Or at least entering a beta stage.

I plan to continue with the 1.0 (“Chopin”) release in a short while. The roadmap can be found here.

My services.exe process was consuming a lot of CPU resources this morning, for no apparent reason.

If I examined this process, I saw that it had created three different threads that were equally busy in working on some unspecified task. No I/O performed, no network activity, just a lot of CPU resources on three different threads.

In Linux, this would have been less of a problem, because in Linux, each process is designed to perform one single job, and do it well. When task A needs to be executed, /usr/bin/taska is started. When task B a little later needs to be carried out, /usr/bin/taskb is run. But in Windows, one process can host a vast multiple jobs, and frequently, a number of different roles are included in one single application. Of course, since process creation is an expensive task in Windows, it makes sense to use threads instead. But you lose out on clarity.

Well, I don’t know why my computer disbehaves like this. I guess I’ll go over it with my antivirus utility and then reboot, to see if the problem goes away. That’s about all I can do.

Reasons why I love PHP:

• It’s quick.
• You can build your own framework. (Or use someone elses.)
• The whole PHP distribution can be compiled into one single, distributable binary.
• It’s got a rather sweet mix of raw power, raw utilities, caches, add-ons, and dangerous things you can do with it. If you know what you’re doing. Kind of like C, but without the hassle.
• If you’re careful enough, you can actually develop new features directly in the production system.
• A nice mix of classes, reflection, and syntactic sugar.
• The same source files can be deployed anywhere – Windows, Linux, Web hotel A, Web hotel B, localhost… no additional configuration necessary. Painless distribution through xcopy.
• Small footprint.
• No System.Web.Utilities.Page.PageHelper.Random.Help.ImLost.RandomAccessAttribute.VeryImportantSetting.
• It doesn’t use Xml and helper classes to configure a website. Just make an include file. Or use parse_ini_file.
• …and you can edit the darn thing in notepad. (No big Visual Studio to install. No dependencies. No dlls. Nuff said.)

Sure, there’s no strict typechecking, it’s not binary, and you need one or two tricks to make it really fast. But the easiness with which you set projects up, the power behind it, and the fact that you can pretty much beat it into doing anything you want – while at the same time being able to distribute it anywhere and it just works right out of the box… Yep, PHP won my heart.