Smokes your problems, coughs fresh air.

Month: April 2009

Some new (upcoming) PostgreSQL features

These are some random new PostgreSQL features that I’m interested in:

  • The EXECUTE USING feature in PostgreSQL 8.4 will allow the use of more secure dynamic SQL in PL/PgSQL.

  • User defined exceptions in PostgreSQL 8.4 are a very exciting feature to me. In our unit tests we often check if an exception is properly raised. However, for exception that we raise ourselves, we’ve never been able to check which exception is raised.

    Another exciting possibility is that this will allow us to come up with a very clean validation scheme that produces exceptions that we’ll be able to use in the client web GUI.

  • WITH queries in PostgreSQL 8.4 will allow some very cool things, the coolest of which is something that I’ve wished for on more than one occasion: recursion.

  • The introduction of proper support for the SQL standard XML Type makes me wish that my favorite web hosting provider would support a real database besides their standard MySQL offering.

  • Enumerated Types will make some of my table definitions slightly clearer.

    -- This isn't too shabby (thanks to the CHECK constraint):
    CREATE TABLE persons (
    the_gender CHAR(1) CHECK (gender = 'm' OR gender = 'f')
    );
     
    -- But, I like this much better:
    CREATE TYPE gender AS ENUM ('male', 'female');
    CREATE TABLE persons (
    the_gender gender
    );

Extra kudos to the PostgreSQL development team for their accelerating pace! 😀

Blog posts don’t need a point

I take blogging very literal. For me, the primary use of a weblog is to keep a log of (complicated) thoughts and activities. The reason to keep a log is very self-evident: to be able to find out how and why I came to some solution or how far I was in the problem-solving process. This becomes ever so clear to me when I find myself confronted with finding out something which I’m sure I already did.

Most of the time I still don’t think about blogging my thoughts because I associate writing with making a point and supporting that point well. That association is a mistake. Instead, I would like to cultivate the following reasons to blog:

  1. Writing is fun because sharing is fun.
  2. Writing is fun because reiterating an experience is liberating.
  3. Redoing my research and problem-solving is not fun.
  4. Receiving comments to your writing is fun.
  5. The very act of writing down an unsolved problem often reveals the solution.
  6. If it doesn’t, some visitor will.
  7. Often a problem is really not a problem at all. Trying to formulate such a problem will make this painfully obvious.

Blog posts don’t need a point, blogging is the point.

Writing a MediaWiki Gravatars template

This is a tutorial for MediaWiki users who want to learn how to create and use templates.

One day, I was looking for a MediaWiki extension to include a Gravatar (globally recognized avatar) in my user page on one of my MediaWiki installations. I did find an extension, but I thought it to be no better than writing a template myself.

A MediaWiki template

In a MediaWiki installation, if you find yourself repeating yourself in a lot of pages, you can turn the repetitive content into a template. This template can then be included in any page where you’d otherwise duplicate the content. In fact, you can include any page, but most templates will live in a separate namespace: Template.

To include a template, put the template name inside double curly braces, like this: {{My template}}. For templates inside the Template namespace (most templates), you can omit the namespace part. This means that if your template page name is Template:My template, you will call your template as in the previous example ({{My template}}).

Template parameters

Parameterization is a fancy word for what programmers do when they don’t want a function to return the same value on each invocation. They add parameters to the function. MediaWiki templates support parameters.

If you have a template called Template:My template which contains “I say this very often, but not {{{1}}}.“, you can invoke it with “{{My template|quite often enough}}“, you’ll get the text “I say this very often but not quite often enough“.

Template parameters are preceded by a pipe symbol (“|”). If you add more parameters, each in turn has to be preceded by the same symbol. Whitespace (even newlines) may be used before or after the pipe to increase readability.

To indicate where in the template you want the parameter value to appear, triple curly braces are used with the number of the parameter inside.

Named parameters

When your template accepts a lot of parameters, you might find it convenient to name the parameters instead of numbering them. Named and numbered parameters can be mixed (but the numbered parameters must come first):

{{Fruit|apple|color=red}}

Referencing the named parameter in the template is as easy as referencing a numbered parameter:

When I need vitamins, I can eat an {{{1}}}. This fruit is {{{color}}}.

Default parameter values

Parameters can be made optional, by adding a default value:

When I need vitamins, I can eat an {{{1|orange}}}. This fruit is {{{color|orange}}}.

Now, you can call the Fruit template with no arguments if you just want an orange.

Gravatar API

Gravatars are retreived by using a very simple URL API. The URL is constructed using the MD5-sum of your email address:

-n $EMAIL|md5sum
77eca8beb1df91ca21e6c781e62630f8

http://www.gravatar.com/avatar/77eca8beb1df91ca21e6c781e62630f8

Optional parameters can be given in the URL. For now, I’m only interested in s (for size). This defaults to 80 pixels, but I want a bigger image:

http://www.gravatar.com/avatar/77eca8beb1df91ca21e6c781e62630f8?s=200

A working Gravatar template

On my Hardwood Investments Wiki, I have made a template that is meant to be used on a user page (such as my own) to display a Gravatar similarly to how captioned images are normally formatted:

<noinclude>
This template shows a Gravatar for the given e-mail address belonging to a given MD5 sum.

== Example ==

<pre>
{{User Gravatar|41165a7e7126d616a0ae0762e00718e2}}
</pre>

</noinclude><includeonly><div style="margin: 0 0 1em 1em; float: right; border: 1px solid #ccc; background-color: #f9f9f9; padding: 3px;">
<div style="border: 1px solid #ccc;">
http://www.gravatar.com/avatar/{{{1}}}?s=200.jpg
</div>{{PAGENAME}}
</div></includeonly>

This template introduces a two new concepts: the <noinclude> section is only used when viewing the template page and the <includeonly> section is used only when viewing the page that includes the template; {{PAGENAME}} is a magic word that is used to display the username as the image caption.

Now that I’ve demonstrated a practical application of MediaWiki templates, I can finally publish this draft. 🙂

Finding a decent GeSHi plugin for WordPress

I like GeSHi (enough even to have written a language file for it). For ages now, I’ve used a WordPress plugin by Dan Peverill. But for as long as I’ve been using the plugin, I’ve been looking to get rid of it.

Dan Peverill’s GeSHI plugin sucks for two reasons:

  1. It’s no longer being maintained. It doesn’t even seem to justify a page on Dan’s website anymore (for which reason I’m not going to give him any link-juice).
  2. It breaks HTML. With the plugin enabled I can no longer use the <code> tag to mark in-line elements as being code. Frankly, this is annoying and I find myself typing <tt> often when I mean <code>.

A search for WordPress plugins tagged GeSHi reveals a number of results: Sniplets, CodeColorer, Developer Formatter, and WP-SynHighlight. WP-Syntax is a plugin that is missing from the tag search.

Sniplets seems much too generic to my taste. I just want a GeSHi highlighter, period.

CodeColorer says it does what I want, but if I ever want to use the TinyMCE editor again, I won’t be able to with this plugin. Shouldn’t be too much of a problem, but still…

Developer Formatter is very thoroughly written and even sports a TinyMCE plug-in for copying/pasting the code. It is pretty big, though, and, as a rule, I tend to avoid plug-ins that complicate the database schema. I also don’t really see how these extra tables are an advantage feature-wise.

WP-SynHighlight uses a custom BBCode-style tag, [codesyntax] I like this (if you’re going to use pointy brackets, at least keep out of the HTML namespace), though I don’t like the attempt at a generic name; what’s wrong with calling the tag [geshi]? Seriously… I’m sure I’m going to forget this name billions of times if I’ll use this plug-in.

WP-Syntax uses the <pre> tag with a few custom attributes. This at least is better than the officially inline <code> tag that my current plugin uses, because most of the time that I’d use a <pre> tag I really do want syntax highlighting. Just wondering: will it also allow my to use it normally for that other rare occasion? Sadly, the plugin will doubtlessly wreak havoc with the visual (TinyMCE) editor.

So, which plugin will I choose? I am somehow inclined to want a plugin that can play nice with the visual editor because I keep telling myself how much nicer it would be to switch to the visual editor for all my posting. (That this will be difficult because I disabled WP’s ‘wpautop‘ filter to rid myself of its eagerness is a story for some later time.) This requirement rules out CodeColorer and WP-Syntax.

That leaves Developer Formatter and WP-SynHighlight. Both seem to fit my purpose. Developer Formatter sports a nice TinyMCE plugin for inserting code, but I don’t think that switching to TinyMCE will suddenly and unexpectedly make me afraid of typing. Besides, I really don’t want the extra tables in my database without a very good reason, so, for now, I will try WP-SynHighlight.

wmsystray, a notification area DockApp for WindowMaker

Many X apps these days require a system tray. GNOME and KDE have system tray applets enabled in their panels by default. WindowMaker doesn’t have a panel. It supports DockApps, which are, of course, much cooler. 😛

wmsystray

wmsystray 0.2.0 with 2 icons wmsystray 0.2.0 with 3 icons

wmsystray (homepage) is a DockApp that supplies a notification area for Window Maker. The version that is in Portage (0.1.1) was maintained by Matthew Reppert. Was; I installed it almost a year ago and it crashed as soon as I started the first app which used the system tray. I went looking for a newer version than the one in Portage. I found it in a comment on its dockapps.org page by Vlad Dinulescu. He had fixed a few bugs and released a new version (0.2.0).

Unfortunately, version 0.2.0 suffers some problems of its own: it crashes when I quit Skype and it sometimes “loses” the uTorrent icon (usually when I have to restart the DockApp after quiting Skype).

Why isn’t this built into Window Maker?

I would much prefer it if Window Maker natively supported a notification area, preferably with the icons appearing within or replacing the App Icons. I’m not the first to have this wish. There exists a patch already, but the WM devs don’t like the idea.

An alternative to wmsystray

Something that I completely overlooked until I started writing this post is this, which looks like a decent alternative to wmsystray. I’ll have to try if that one works better than wmsystray. Some time…

Increasing (encrypted) disk image size with dd

When you have a raw disk image file, you may need to increase its size at some point. With dd, you can do this:

dd conv=notrunc oflag=append if=/dev/zero of=backups bs=1M count=1024

This will add 1GB of zero data to the image file ‘backups’. You can then use resize2fs on it to increase the file system size (that is, if you use ext2/3/4):

e2fsck (-f) backups
resize2fs backups

However, if the disk image is a volume encrypted with cryptsetup + luks, first open it:

losetup /dev/loop/0 backups
cryptsetup luksOpen /dev/loop/0 encrypted-backups

Then resize the encrypted volume:

cryptsetup resize encrypted-backups
e2fsck (-f) /dev/mapper/encrypted-backups
resize2fs /dev/mapper/encrypted-backups

And I know, I still have to add LVMs to my set of skills…

© 2026 BigSmoke

Theme by Anders NorenUp ↑