One simple example of proving closures’ power is in the concept of PHPUnit’s dataProviders. A data provider provides data to a test, in which a test consumes the data and asserts that the code is ok. As data can also be closures, you can also alter the execution of the tests appropriate to the data you want to test, without actually altering the test. I’ll show you an example ¹.

Consider the following class:

class FooBuilder {
    function add($property, $value) {
        $this->properties[$property][] = $value;
        return $this;
    }
 
 
    function remove() {
        if (!empty($this->properties[$property])) {
            array_pop($this->properties[$property]);
            if (count($this->properties[$property]) == 0) {
                unset($this->properties[$property]);
            }
        }
        return $this;
    }
 
 
    function build() {
        return $this->properties;
    }
}

Though there is no obvious use case for this class, the pattern is simple: we have some builder with methods to create something, and the builder provides a fluent interface to do so. This is also very common for query builders, including jQuery. With such a pattern, there is a meriad of possibilities to use this code, with at least as much edge conditions. The order in which the methods are executed might influence the way it is implemented, what would happen if properties are added, removed and then removed again, etc etc.

These edge cases won’t be displayed by simple use of code coverage, and introducing separate tests for each of these conditions would be cumbersome, having to introduce separate test names for each of the cases.

So, here’s where closures come in handy. We’ll simply call the test testBuildingWithFluentInterfaceWillResultInExpectedArray:

class FooBuilderTest extends \PHPUnit_Framework_TestCase {
    /**
     * @dataProvider builderCases
     */
    function testBuildingWithFluentInterfaceWillResultInExpectedArray($expected, $builderImpl, $description) {
        $builder = new FooBuilder();
        $this->assertEquals($expectedArray, $builderImpl($builder)->build(), "$description failed");
    }
 
 
    function builderCases() {
        return array(
            array(
                array(),
                function (FooBuilder $builder) {
                    return $builder;
                },
                "Initial construction"
            ),
            /* .... */
            array(
                array('a' => array('b', 'c'), 'x' => array('y', 'z')),
                function (FooBuilder $builder) {
                    return $builder
                        ->add('a', 'b')
                        ->add('x', 'y')
                        ->add('x', 'z')
                        ->add('a', 'c')
                    ;
                },
                "Adding different properties multiple times in a different order"
            ),
            /* .... */
            array(
                array(),
                function (FooBuilder $builder) {
                    return $builder
                        ->add('x', 'y')
                        ->add('x', 'z')
                        ->remove('x')
                        ->remove('x')
                    ;
                },
                "Adding different properties multiple times in a different order"
            ),
        );
 
}

This way, you´ll have a clear view of all the test cases and expected output, without having to only provide data through your data provider, but logic too. Clear separation of use case and consumer logic makes the test very clear and easily extendable.

Hope this offers more food for creativity in your tests

The “old” paradigm: Procedural

Procedural programming is a form of imperative programming in which you define “procedures” or “subroutines”¹ that encapsulate a certain set of operations, and accept parameters or “arguments” to that set of operations. A very simple example of this, is a procedure that will return the sum of two arguments. In C:

int sum(int a, int b) {
    return a + b;
}

We declare a procedure that accepts two integer arguments a and b and return an integer sum of the arguments. Simple, efficient, clear. If we want the sum to be present in a third variable, we simply execute the procedure:

#include <stdio.h>
 
int sum(int a, int b) {
    return a + b;
}
 
int main(int argc, char *argv[]) {
    int c;
    c = sum(10, 20);
    printf("c now contains %d\n", c); /* Will output: "c now contains 30" */
    return 0;
}

Procedural is imperative

The procedural style of programming is imperative. Imperative means that you program the execution flow. You decide what pieces of code gets executed by using control structures, loops, procedures, etcetera, and the state of the variables (the “context” or “environment”) ultimately define the execution flow. This is very intuitive, since you can read most imperative languages as “if something happens, you do this and that”. More or less like an instruction video for driving. If someone comes from the right, yield.

The “newer” paradigm: Object Oriented

Another, still imperative, paradigm is Object Oriented programming. Though it is not strictly different from procedural programming, it introduces a new concept: binding data and methods to a single object, that represent one single previously initialized state of the object. This is called instantiation and means that multiple objects of one type can exist in memory simultaneously. Each of these objects have their own methods that act only on the state of that particular object.

There are two concepts that are new in OO style programming, first of which is encapsulation, where the outside world does not need to know what is going on within some object’s internals. Second is polymorphism, which means that an object can explicitly express that it is capable of some sort of functionality and may implement it in a very different way than another object which exposes the same behaviour. Huh? Bear with me. Here’s an example.

class AreaCalculator {
    public float total = 0;
 
    public void add(HasArea obj) {
        total += obj.getArea();
    }
 
    public void subtract(HasArea obj) {
        total -= obj.getArea();
    }
}
 
 
interface HasArea {
    public double getArea();
}
 
class Rectangle implements HasArea {
    private double _side1;
    private double _side2;
 
    public Rectangle(double side1, double side2) {
        _side1 = side1;
        _side2 = side2;
    }
 
 
    public double getArea() {
        return _side1 * _side2;
    }
}
 
class Circle implements HasArea {
    private double _radius;
 
    public Circle(double radius) {
        _radius = radius;
    }
 
    public double getArea() {
        return Math.PI * Math.PI * _radius;
    }
}
 
class Example {
    public static void main(String[] args) {
        AreaCalculator calc = new AreaCalculator();
        // our yard is 10 by 4.2 meters
        calc.add(new Rectangle(10.0, 4.2));
 
        // But it has a pool, 3 meter in diameter
        calc.subtract(new Circle(1.5));
 
        System.out.println("The square metrage we need to buy grass seed for is " + calc.total);
    } 
}

The result:

The square metrage we need to buy grass seed for is 27.195593

The example shows that two different objects have some common characteristic. In this case, they both know how they should produce their own area. The implementation is bound to the meaning of the class itself, since the area of a circle is calculated differently from the area of a rectangle. So, they both provide their own implementation to do so. Since the two different implementations are tightly related, it does make sense that we defined a common interface for it, so the actual consumer of the objects (the calculator) does not need to know they are totally different kinds of objects. All it needs to know is that the object is capable of producing it’s own area. That’s it. Well, if you know OO you know this already, but you might not have known that this phenomenon is called polymorphism. The fact that we hide the properties _side1, _side2 and _radius from the outside world is encapsulation. Especially polymorphism is something that is hard to achieve with a purely procedural language.

It strikes to see that OO versus procedural, however still imperative, is much more descriptive. It describes natural things in a natural way. A pear is a fruit, an apple is a fruit, they both have some specific characteristics, but they share a lot of common properties and probably operations, such as feed() or ferment(). The programming style still is imperative as it follows the execution flow, but much of the organisation of the code revolves around typing and classifying, so it is more descriptive even though not yet strictly declarative.

It would also appear that OO moves focus from processing and decision-making to behaviour. Describing behaviour is typically part of the object model, because behaviour defines how objects interact and how they depend on each other. This is curious: the data no longer plays the main role in the design of the program, the behaviour does. Let’s stash that thought.

Declarative programming

The main difference between declarative and imperative programming, is that declarative means that you express what something is, rather than what something should do. A common example of declarative programming is build scripts. I’ll use a Makefile for this example.

As we define a task within a Makefile, we can specify what tasks it is dependent on. As this simply declares what the task does, without actually doing any decision-making within the program this is typically a declarative approach. The tasks get declared as what set of executions the represent. The decisions that are needed to make for execution of the tasks is made by the platform:

# building the app depends on mysum.c (the example above)
# if mysum alters, the app should alter too
mysum: mysum.c
    gcc mysum.c -o mysum

The approach is declarative. We do no checks, we just tell what needs to be done to generate the app. See the entire Makefile for the above examples on the github repo

Another relatively simple example is Haskell. Without explaining too much about functional programming, the main idea of Haskell is that you declare anything you need. Declaring things does not mean executing them. For example:

l = repeat 5

What happens here is that we declare a list that is made up of an infinite list of 5s. So, how come nothing happens? If the list is infinite, how can it exist? It exists because it is declared. It only gets meaning as soon as it is used in context, which means that the meaning is defined by evaluating the list in it’s context. When (or even if) this happens. The problem is, imperative programming leads to the assumption that everything that is actually declared, will be evaluated as soon as execution flow enters. This is different in declarative languages, simply because they do not have execution flow. Or, at least, the execution flow is irrelevant. Evaluation is delayed until the point it is required. That is called lazy evaluation. And we like lazy, because lazy means CPU cycles and memory is only consumed as needed.

The best of both worlds

Languages now tend to shift to a mixture of (imperative) Object Oriented and (declarative) functional. We see that in Python, Ruby, Erlang and maybe even the best example of them all: Scala. What’s even more surprising is that in PHP world, which isn’t the fastest cat of the bunch, the seed is actually planted. Symfony2 introduces declarative paradigms with an inversion of control service container. That is declarative. You simply declare what service depends on another. PHP code is generated to have these dependencies resolve gracefully and lazily and we no longer need to think about execution flow for this. The services and their dependencies are only declared, and the (imperative) code for initializing the services is generated under water. Consequentally, requesting the services from the container will have the services be initialized lazily.

Another fine example is NodeJS. Since the entire model is built around one simple event loop, all behaviour is essentially defined declaratively.

So, what’s next?

Learning imperative languages will become obsolete, just as learning assembly has. You will need to learn how to define behaviour and dependencies, but no longer what needs to be done to get the entire thing rolling. As languages get more and more declarative capabilities and functional programming paradigm features, the imperative idea will only be a resort where the awesomest go.

Or…. will it? Compiling code introduces overhead. There is no compiler that is able to optimize all and every situation as well as an advanced programmer could. This holds true for, say, a C to Assembly compiler, and would most certainly be the case for compiling declarative approaches. Because ultimately, the little pieces of hardware that get the work done, are not that professed in languages. They only do ones and zeros, and have no concept of meaning. This means that bringing the code from the keyboard to the processor’s registry will become further and further apart. And if that’s the case, there’s only two ways to go. Either software will become even less efficient, or the hardware needs to get smarter. Pick one.

NB: The code in this post is on github

I do not intend to convince you to use a content repository. I think the matters speak for themselves. If you know all the limitations classical setups using relational databases have, you’ll probably see a future in NoSQL databases, as they are affectionately called. MongoDB and CouchDB never convinced me the way the JCR specification did. Google the specs and read them yourself and know what I mean.

1. Get a CR backend running

I chose Apache Jackrabbit, a Java Content Repository (JCR), to do this. As pointed out on the Jackalope website, you’ll need a patched version of Jackrabbit to get things compatible with PHPCR. Actually, it is just version 2.2 with a backport patch of the 2.3 branch applied to it ¹, so don’t fear using it. I’m told it is pretty stable.

1. Get the patched Jackrabbit here.

2. Run the the server

   java -jar jackrabbit-standalone-*.jar

This will run jackrabbit at port 8080. Visit your jackrabbit front end at http://localhost:8080/. You’ll be asked a username and password, but you can leave them blank. By default, there is no access control. If you see a page about jackrabbit, it works.

2. Install Symfony

I’m assuming you know how to do this. If you don’t, follow the instructions at symfony.com. The short version is:

1. Download Symfony 2.0 latest version
2. Extract the archive in your document root, say /var/www/
3. Visit /Symfony/web/config.php and follow the instructions
4. Visit /Symfony/web/app_dev.php to determine if the installation worked

3. Install PHPCR, Jackalope, DoctrinePHPCR ODM and the DoctrinePHPCRBundle

Go to your vendor dir and clone the PHPCR libraries from github:

cd /var/www/Symfony/vendor
git clone git://github.com/phpcr/phpcr.git
git clone git://github.com/jackalope/jackalope.git
git clone git://github.com/doctrine/phpcd-odm.git
cd bundles/Symfony/Bundle
git clone git://github.com/symfony-cmf/DoctrinePHPCRBundle.git

4. Configure the autoloader

Open app/autoload.php and configure the namespaces for the downloaded libraries:

<?php
/* ... */
$loader->registerNamespaces(array(
    /* ... */
    'Jackalope'             => __DIR__.'/../vendor/jackalope/src',
    'PHPCR'                 => __DIR__.'/../vendor/phpcr/src',
    'Doctrine\\ODM\\PHPCR'  => __DIR__.'/../vendor/phpcr-odm/lib/',
    /* ... */
));

5. Add the DoctrinePHPCRBundle to your AppKernel

Open app/AppKernel.php and add the bundle to the registerBundles() call:

<?php
/* ... */
public function registerBundles()
{
    $bundles = array(
        /* ... */
        new Symfony\Bundle\DoctrinePHPCRBundle\DoctrinePHPCRBundle()
    );
    /* ... */
}

6. Configure the ODM default service

Add the following section to your app/config/config.yml file:

doctrine_phpcr:
    session:
        backend:
            url: http://localhost:8080/server/
        workspace: default
        username: ''
        password: ''
    odm:
        auto_mapping: true

7. Set up the Doctrine system types

To have Jackrabbit understand some type internals Doctrine uses for document mapping, we’ll need to make the content repository aware of these types. There is a console command for that, to make things easy:

app/console doctrine:phpcr:register-system-node-types

If you skip this step, persisting documents with a Doctrine DocumentManager will fail with a Jackrabbit error message complaining about phpcr being an unknown namespace.

8. Set up a PagesBundle

You should, of course, change the class and namespace names to whatever you wish. Here’s what I used:

In src/Melp, I created a PagesBundle. This bundle will hold my routes for editing, creating, deleting and showing pages from the content repository. It will also hold the Document model classes I will be using for mapping documents to objects:

cd /var/www/Symfony/src
mkdir -p Melp/PagesBundle/{Controller,Document,Resources{,/views}}

This creates the bundle’s directory structure. There is also a console command for it, which can scaffold the directory structure and some classes for you:

cd /var/www/Symfony
app/console generate:bundle

The MelpPagesBundle class will be in /var/www/Symfony/src/Melp/PagesBundle/MelpPagesBundle.php, and contains the following code:

<?php
namespace Melp\PagesBundle;
 
use Symfony\Component\HttpKernel\Bundle\Bundle;
 
class MelpPagesBundle extends Bundle {}

Add the bundle instance to the AppKernel class’s bundle initialization routine:

<?php
/* ... */
public function registerBundles()
{
    $bundles = array(
        /* ... */
        new Melp\Bundle\PagesBundle\MelpPagesBundle()
    );
    /* ... */
}

9. Set up the controller, routes and view scripts

I’ll use Annotations for the controller set up. I was a bit reluctant at first to use annotations for such configuration, but I find it much easier and clear to use annotations than the other configuration options. The only thing we’ll need is to let the router configuration know the controller exists. We’ll do that in app/config/routing.yml:

_pages:
    resource:  "@MelpPagesBundle/Controller/PageController.php"
    type: annotation

I will also use Twig view scripts. You can of course use PHP view scripts or whatever you prefer, but Twig has had my heart for some time already. The @Template annotation will tell Symfony to render the view resources using the twig template engine as is configured in the default Symfony2 distribution you downloaded. ²

The controller class will then look like this:

<?php
namespace Melp\PagesBundle\Controller;
 
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Routing\Annotation\Route;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Template;
 
class PageController extends Controller
{
    /**
     * @Route("/")
     */
    function indexAction()
    {
        return $this->redirect($this->generateUrl('view', array('path' => 'home')));
    }
 
 
    /**
     * @Route("/{path}", requirements={"path" = "(?!(edit|delete|create)).+"}, name="view")
     * @Template
     */
    function viewAction($path)
    {
    }
 
 
    /**
     * @Route("/edit/{path}", requirements={"path" = ".*"}, name="edit")
     * @Template
     */
    function editAction($path)
    {
    }
 
    /**
     * @Route("/create/{path}", requirements={"path" = ".*"}, name="create")
     */
    function createAction($path)
    {
    }
 
 
    /**
     * @Route("/delete/{path}", requirements={"path" = ".*"}, name="delete")
     */
    function deleteAction($path)
    {
    }
}

Since I want to have the routes reflect the path in the content repository, I use a wildcard pattern for the paths, so they may contain slashes. You can use PCRE in your routes, which I used to exclude the /edit, /create and /delete routes from the default viewAction() to avoid conflicts.

These actions will implement CRUD actions for nodes inside the content repository.

10. Create the document model class

To have Doctrine manage my model class, I will need to attach Doctrine annotations to it, so Doctrine will know how to read and write model data from and to the content repository backend. I will use a simple Page class, with title and content properties, wich we will later implement the CRUD for, as layed out in the Controller above.

In src/Melp/PagesBundle/Document, create the model reflecting the ‘Page’ data structure we’ll be using to edit and show pages ³.

<?php
namespace Melp\PagesBundle\Document;
 
use Doctrine\ODM\PHPCR\Mapping\Annotations as PHPCRODM;
 
/**
 * @PHPCRODM\Document(alias="page")
 */
class Page
{
    /** @PHPCRODM\Id */
    public $path;
 
    /** @PHPCRODM\String */
    public $title;
 
    /** @PHPCRODM\String */
    public $content;
}

11. Create a Pages facade and register it as a service

I created a facade for controlling how pages are persisted and added some logic to that for placing pages in a configured root:

services:
    pages:
        class: Melp\PagesBundle\Service\PagesFacade
        arguments:
            - @doctrine_phpcr.odm.default_document_manager
            - 'Melp\PagesBundle\Document\Page'
            - "/pages/"
            - "home"

The facade exposes the following methods:

public function __construct(\Doctrine\ODM\PHPCR\DocumentManager $dm, $documentClass, $root, $default)
{
}


function createDefault($title = "Homepage")
{
}


function removePath($path)
{
}


function findPath($path)
{
}


function remove($node)
{
}


function persist($node)
{
}

This saves some clutter in the controller code. The Facade dispatches to the document manager and the document repository for finding and persisting pages.

12. Create a PageType form class

Following a best practice not to initialize your forms inside your controller, I created a PageType class in src/Melp/PagesBundle/Form/Type/PageType.php:

<?php
 
namespace Melp\PagesBundle\Form\Type;
 
use \Symfony\Component\Form\AbstractType;
use \Symfony\Component\Form\FormBuilder;
 
class PageType extends AbstractType
{
    function buildForm(FormBuilder $builder, array $options)
    {
        $builder
                ->add('title', 'text', array('required' => true))
                ->add('content', 'textarea')
        ;
    }
}

This class will be used inside the controller to build the forms for creating new pages and editing existing ones.

13. Implement the CRUD Controller

I chose to implement a very, very basic CRUD for the document class. The code speaks for itself. I used twig templates to render the output of the edit, create and view actions, and rely heavy on flash messages and redirects for feedback to the user.

Summarizing

Much, much easier than an RDBMS based hierarchical system of pages, much more convenient and easier to control, and crazily scalable. I think there is much future in this kind of set up. So get comfortable with it while I’ll do the same, and I hope to get even deeper into the subject some next blog.

I hope this post helped you some further if you got stuck, and is of some inspiration if you want to get started. All tips and comments are appreciated.

set -e

Quoting the man page:

-e errexit

Exit immediately if a simple command exits with a non-zero, unless the command that fails is part of an until or loop, part of an if statement, part of a && or || list, if the command’s return is being inverted using !.

If you want to reset to normal behaviour, reverse it using:

set +e

Very useful, it’ll save you lot of tedious if’s and error checking.

I already knew of the nice program, with which you can alter the CPU scheduling prioritization of processes. nice usually prefixes a command to start it up with altered ‘niceness’:

$ nice -n 19 rsync -a ~ /net/share/backup

renice is used to alter an already running process’s niceness:

$ renice -n 19 -p $PID # where, of course $PID is de pid of the process you're altering

Pretty useful, and also pretty common knowledge, as far as I know. But then it dawned on me that CPU priority isn’t at all what’s useful here. You want I/O priority. So, a little googling lead me to ionice – how inventive a name – with which you can alter process I/O prioritization. Awesome!

$ ionice -c 2 -n 4 -p 1234 # Give process 1234 "best effort" priority 4

You should read the man pages of nice and ionice to find out what the parameters mean (just because it’s a good habit to read man pages, and not blogs ), but the basic usage is as follows:

# start a process 'some command with arguments' with a niceness of 19. 
# 19 means lowest priority, -19 means highest
nice -n 19 some command with arguments 
 
# The process with pid 1234 gets a new niceness of 10, provided you are either root,
# or you are the owner of the process
renice -n 10 -p 1234
 
# The process with pid 1234 gets "Idle" class priority, which means it only gets I/O access
# when no other process needs it.
ionice -p 1234 -c 3

Use top and iotop to monitor the usage of CPU and I/O usage respectively. From now on, I’ll be nice to the kernel and not let him figure out all the prioritization. Wow that’s cheesy

I do. And it sucks. Big time. And if bash wasn’t so awesome in helping you tune your shell into what you want for yourself, I probably would’ve found some configuration in nano to warn me properly. But, bash is awesome, and after all I like tuning my stuff into my stuff. So here’s my solution:

Edit ~/.bashrc and add the following lines

function nano() { 
    nano=`which nano`; 
    if ([ -e "$1" ] && ! [ -w "$1" ]) || ( ! [ -e "$1" ] && ! [ -w "`dirname $1`" ]); then 
        read -n 1 -p "$1 is not editable by you. sudo [y/N]? " y
        [ "$y" == "y" ] || [ "$y" == "Y" ] && echo -e "\n" && sudo $nano $@
    else 
        $nano $@
    fi
}

source your file, or log out and log back in again.

$ . ~/.bashrc

And you’re done! You’ll get a nice prompt asking you if you want to sudo to change the file if you do not have privileges to edit the file. Check, done, and done. Gotta love that unix environment.

$ nano /etc/apt/sources.list
/etc/apt/sources.list is not editable by you. sudo [y/N]?

This is how to do it. First, check if you have an rsa key pair in your homedir:

$ ls ~/.ssh/id_rsa*

You should have an id_rsa and an id_rsa.pub file there. If not, you need to generate them, using the following command

$ ssh-keygen -t rsa

If you wish, you can add a passphrase for accessing the keys. This is an extra security, which you don’t really need if you don’t hand out your private key to anyone. However, if you feel quirky about entering systems without passwords, you can enter the passphrase anyway. In that case, you will need to enter that password in stead of the password on the remote machine when you want to connect.

Use the ssh-copy-id script to copy your public key to the remote machine’s “~/.ssh/authorized_keys” file. You can do this by hand also, but the script makes it a little bit easier for you:

$ ssh-copy-id remoteuser@remotehost

After you entered the remote password as prompted, the machine’s door will be open to you. In terms of security, a good rule of thumb is not to use password-less authentication unless the firewall restricts ssh access to your ssh client’s machine, or to your office network. Be sensible, but don’t learn every password you’ll get handed over by heart, it’s a waste of time and brainpower.

Check out this not-particularly-useful example

for i in 3 2 1; do 
    echo $i
done | sort -n

Result:

1
2
3

What I’ve proven here is that the output of the for loop goes through the sort pipe, before ending up on your screen. Pretty useful if you’re doing some processing inside a for loop, but still want to make use of sorting without having to end up using temporary files.

A more useful example (something I tried today) was listing a bunch of SVN repositories and the times they were last changed (in days):

#!/bin/bash
now=$(date +"%s")
 
for i in */; do
    mtime=$(date --date "$(svnlook date $i)" +"%s")
    age=$(( ($now - $mtime) / (24 * 3600) ))
    echo $i $age | awk '{printf "%-40s%d\n", $1, $2}' 
done | sort -k 2 -n

The -k option directs sort to use the second column in the for-loop’s output. Very useful, imho

$ xev

xev is the X Event monitor, which shows you all events that X receives and dispatches. You should be aware that it will output any event that occurs, so the trick is to know what you’re looking for. We’re looking for Key events, so it’s probably easiest grepping the key events from the result:

$ xev | egrep '^KeyPress' -A5

Now press the keys you wish to know the keycode of. Openbox’s rc.xml will need the name part of the keysym. For example pressing your Escape button would yield something like:

KeyPress event, serial 39, synthetic NO, window 0x1800001,
root 0x15a, subw 0x0, time 3512708, (-289,-351), root:(1862,445),
state 0x0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,
XLookupString gives 1 bytes: (1b)
XmbLookupString gives 1 bytes: (1b)
XFilterEvent returns: False

The part you’re looking for is:

state 0×0, keycode 9 (keysym 0xff1b, Escape), same_screen YES,

Now, do the same for the +, – and Mute buttons on your keyboard. Press them and find out what code X dispatches. You’ll find XF86AudioRaiseVolume, XF86AudioLowerVolume and XF86AudioMute are the codes you’re looking for.

Now, we need a program to influence mixer control. The easiest is to use amixer, which is the alsa command line tool to control the entire mixer. To change the volume, you can pass the mixer control name and some commands to the amixer set command. Here’s my config:

<keybind key="XF86AudioRaiseVolume">
    <action name="Execute">
        <command>amixer -q set Master 2+ unmute</command>
    </action>
</keybind>
<keybind key="XF86AudioLowerVolume">
    <action name="Execute">
        <command>amixer -q set Master 2- unmute</command>
    </action>
</keybind>
<keybind key="XF86AudioMute">
    <action name="Execute">
        <command>amixer -q set Master toggle</command>
    </action>
</keybind>

Of course, this isn’t really rocket science, but since now you know how to find out what key code you are pressing, you can think of all kinds of exciting things to do with all those special buttons at the top of your keyboard. Go crazy

#!/bin/bash
id=$(wmctrl -lx | grep $1 | awk '{print $1}'); 
[ "$id" == "" ] && shift && $@ || wmctrl -ia $id;

With this nifty script, you can raise an existing window or spawn the program newly with the following syntax:

reraise gedit --whatever-argument-you-wish-to-pass

If you put this in your openbox rc.xml as a shortcut, you can easily assign shortcuts behaving as “only open this program anew if the window isn’t there yet.” Pretty useful for terminals, editors and browsers.

Simple usage example would by a local MySQL terminal:

reraise.sh MySQL 'xfce4-terminal --title=MySQL -x mysql'

Very useful, if you, like me, hate to search for windows and prefer manhandling your array of shortcuts. Of course, you will need to install wmctrl.