Talk on Services at Drupalcamp Stockholm 2009

I just held a presentation about services and my plans for services 3.x at Drupalcamp in Stockholm. Everything went well except that I was so nervous about running out of time that I teared through the presentation in 20 minutes. But here are the slides if you missed something.

Check out the english version over at slideshare too

Check out my previous blog post A future for Services - 3.x? for more in-depth information about my views on the future of services.

Attached files: 

Slides in swedish

Slides in english

Co-Maintainers Wanted!

The list of modules that I maintain has become quite long, and in the beginning of next year I'll have a little daughter (if the nurse guessed right on the gender). So the time that I have for being a good maintainer will be very limited.

If you feel that you'd like to help maintain any of the following modules, I would be very grateful!

• Cobalt
• Node form columns
• OAuth Common
• Services OAuth
• Simple Geo
• JSONRPC Server
• Query builder

Modules not on DO

• Services OOP
• CSS DRY

Experience of using git, or the willingness to learn, is kind of a requirement, as all my development is done with git. The alternative is a patch-based workflow.

Copying Ubuntu VM:s and eth0

Note to self: when copying virtual Ubuntu servers between machines the MAC address will be changed and a eth1 device will be added with the new MAC address. But it won’t be properly configured. Edit `/etc/udev/rules.d/70-persistent-net.rules` and remove the old `eth0` device and rename the `eth1` device to `eth0`. Then reboot and everything should be fine.

If you’re running a local bind9 server, remember to update the zone file so that the A-records match your new IP-address (For me that was `/etc/bind/db.vmdev`) and restart bind: `sudo /etc/init.d/bind9 restart`.

Dynamic vhost configuration

I've recently tried out a new way define my virtual hosts on my development machine. I've always had a configuration file in my home dir (that gets included from httpd.conf) that looks something like this:

Ensuring that values are in an array

I've run across situations where I want to ensure that some values exist in a non-associative array (without getting duplicates). The way I've usually solved it is:

if (!in_array('nid', $fields)) {
  $fields[] = 'nid';
}
if (!in_array('title', $fields)) {
  $fields[] = 'title';
}

This is kind of ugly, and the more values you want to add the uglier it becomes, so it evolved to:

$ensure = array('nid','title');
foreach ($ensure as $f) {
  if (!in_array($f, $fields)) {
    $fields[] = $f;
  }
}

This is great if you have a known array of values that always should exists. But if you have third party code that could have requirements for certain fields to be there, or logic that's more spread out that determines the fields that needs to be ensured, this is the way I've settled for:

$fields = array_fill_keys($fields, TRUE);

// Add a required field
$fields['nid'] = TRUE;

// Add a set of required fields
$fields += array_fill_keys(array('title', 'created'), TRUE);

// Add another set of required fields
$fields += array('modified' => TRUE, 'teaser' => TRUE);

$fields = array_keys($fields, $ensure);

This way we get away with not using loops or conditions by first turning the values into keys in a associative array, modifying them, and then turning the keys into an array again. I guess this is a matter of personal preferences, and this last approach might have the drawback that it's not immediately obvious what's going on for the uninitiated. The other two approaches are more readable.

Convenience scripts for Solr

This is a set of convenience scripts for daily drupal use of solr in a dev environment. When you use the apachesolr module in many projects it becomes somewhat boring to set up solr again and again. And when you have a whole team doing the same thing, this script becomes a time-saver.

This little project lives at github (as usual): http://github.com/hugowetterberg/solr_nightly. Clone or download and execute get-nightly from the terminal (when inside the solr_nightly directory) to download the latest nightly and set it up with the drupal-specific configuration files.

$ ./get-nightly

Then execute start to get solr up and running.

$ ./start

Now your drupal install should be able to use solr through the apachesolr module. Press ctrl+c to quit solr. If you want to clear out all files that's been created for the search index and other runtime files (to use it with another drupal install, or just to start over), run:

$ ./reset

Remember to delete the index from the drupal admin when you have a site that expects that there is a index. Otherwise your nodes won't be re-added.

Re-run the get-nightly script if you want to download the nightly again.

Code lost

If you're anything like me you probably misplace some code every once in a while. I have a drupal module that I work on in both spare and work time, and I use it in many projects. I sat down just now and started coding on a feature when I realized that I've already done it somewhere else - but where? Somehow I had to find it, and being a programmer, doing it manually isn't an option. So here follows a quick, osx only, tip on how to sift through folders by combining spotlight searches with your own logic.

Caching the results of your functions

Sometimes when you use info-hooks to collect information from a arbitrary number of modules, or perform some other expensive or "unknown cost" operation, you'll start to feel the need to cache your results. If your function will be called several times during one request caching in a static variable will take off some of the load, combining this with the Drupal cache could help even more.

Caveats: you probably know this already, but as with all caching it's only effective/sensible to cache stuff if the cost to calculate the results from scratch exceeds the cost of retrieving the results. This is especially important if the database backend is used for caching. If APC or another fast, memory based caching backend is in place, the list of stuff that could benefit from caching grows a bit longer. The other consideration is hit-rate - will your function really be called often enough for it to be necessary for it to be cached? If your cache is invalidated regularly because of writes this becomes even more of an issue, if the cached never is used, or at least not used enough to justify the cost of the actual caching, you will just have written unnecessary code, or in the worst case unnecessary code that just makes your website slower.

Now, the reason for this post: sample code & potential best practice here at Good Old. The following snippet collects information through module_invoke_all() and then lets other modules alter the very same info in a subsequent drupal_alter(). The results is cached in both statically and in the Drupal cache:

Terminal tips and tricks

This is a collection of terminal (not as in life-be-gone) tips and tricks - good things to do with your terminal and bash. It originates from our old google code wiki and contains things picked up from http://blog.macromates.com/2008/working-with-history-in-bash and other places. There are some good tips over here too: http://programmingishard.com/code/tags/bash

PHP cli script for inverting hex colors

Here's a gist of the script I used for creating the inverted NeoPro theme in my last post. This way I could do most of the conversion automatically and just tweak some stuff for contrast.