Last weekend (26-28 Feb 2010) DrupalCamp Spain happened in Barcelona at the great CitiLab (pic), which is where DrupalCon Barcelona happened a few years ago. I don't have the exact numbers in front of me, but there was just about the same number of attendees for the DrupalCon a few years ago as there were for the DrupalCamp just a week ago (before and after)! Drupal is getting huge!

The camp was wonderful. The organizers did a great, professional job. Though my Spanish is not very good at all, all the presenters did a great job and had a nice variety of topics. I met lots of wonderful people, both seasoned Drupal professionals and Drupal first-timers. Unfortunately my trip was short, but I did get to experience some of the beauty of Barcelona. And, of course, there was the poll-dancing Drupal gorilla (pretty standard). Thanks for having me and for all the hard work!

Understanding OpenLayers Presentation

I did a presentation on Understanding OpenLayers and Drupal. I think it went pretty well. I am still getting my sea legs (and by sea legs I mean ability to speak in front of people); but the room was packed, and I got to do my first Prezi presentation. I am pretty pleased with Prezi, though it took some time to put it all together and stop thinking about things so linearly.

Below is an embedded version of the presentation; it actually starts on the second point. This is a presentation based on OpenLayers 2.x which is still in development but doing good thanks to the hard work of the developers. They took video at the camp, so I am assuming one day there will be a video which might help with understanding the presentation some.

Spread the word; Chach Sikes and Erika Stenrick who work with Gorton Studios, have just announced a DrupaChix Sticker Design Contest for DrupalCon San Francisco (sponsored by Gorton Studios). This is a great opportunity for anyone to show off their design skills, and, more importantly, help support women in our Drupal community.

In case you aren't in the know, DrupalChix is an awesome group dedicated to supporting existing women in the Drupal community as well as working towards getting more women involved in Drupal. Drupal has such a great community, but we could be so much better by getting more women (and other under-represented people) involved into Drupal.

The stickers will be made in mass quantity and distributed at DrupalCon San Francisco. Designs are due in by 15 March 2009, so act quick! Post your entries to this thread. And for the non-designers, voting begins on 17 March 2010.

Update via Garrett Albright (see comments)

Just a quick tip for managing variables in a Drupal module. Please prefix your variables with your module name. For example:

This ensures that another module won't override your variable, or your module won't do the same thing. Pretty simple. But what is also nice, is that you can clean up after your module a lot easier in the uninstall hook:

Please note that the above convention could cause problems if your module name is something like content_permissions and then the content module (CCK) defines a variable with a conflicting name. All the more reason to make your module names more unique and without underscores.

My Valentines Day consisted of coding the beginnings of the upgrade path from 1.x to 2.x of the OpenLayers module; that's some true love for the OpenLayers 1.x users.

The OpenLayers has a fairly unique situation where we have 3 major versions for Drupal 6, but they are not sequential, and going form OpenLayers 1.x to 2.x is a fairly large change. We have just released 1.0-RC1 and 2.0-alpha1, so it was about time to create an upgrade path for those folks on 1.x. Though it still needs some serious work, it's getting there. But, the point is, I ran into this problem: testing a Drupal update function with major schema changes without help can be tedious.

The Problem

Basically, a Drupal update is a specific function that gets called from update.php (or equivalent Drush command) given that the state of the module's schema is less than the newest available one. This means I have to do the following to test:

1. Set up site with test data.
2. Code update.
3. Run update.php.
4. Make sure everything went as planned.
5. Repeat as needed (even if you have a syntax error).

Imagine doing this over and over again for a very involved upgrade process! I knew right away that this was not for me.

The Solution

(Note, there may be some much better way to do this with the Drupal SimpleTest module but I am unaware of it)

It was pretty obvious that a database dumb was going to be the best way to go; I could set up the site and then restore when I needed to test. But exporting, importing, managing changes, and just laziness kept me trying to think of something better. Then the Demo module popped into mind! The Demo module basically takes a snapshot of your database and allows you to restore to it, either through the interface or on cron runs. This seemed like a good candidate to getting around installing a new site and setting it up or using database dumps.

So, first step is to setup your Drupal site as you want it before the upgrade process. Then use the Demo module to make a snapshot. Also, it is important to install the Demo Reset module (part of Demo package) and set a default snapshot to use as we will refer to this when resetting. And! if your process changes, Demo makes it really easy to make changes to your site and save another snapshot.

Next, we just need to write a simple little script to do the restore and update (keep in mind we are going for lazy and automated). Luckily Drush is wonderful and allows us an easy way to run some simple PHP after Drupal has bootstrapped itself, and then perform the update. Here is my basic script, which is really just two commands.

Sorry if French is bad. I have been kind of quiet for the past few months. This is because I have just moved from Minneapolis, US to Geneva, Switzerland to start work at Shelter Centre. It's a very exciting move for me for many reasons; but that isn't really the intention of this post.

Anyway, what is really amazing, is that after being here for only two weeks, (with a little bit of help) I was able to get almost 25 local people together for drinks and Drupal! How? About a month or so ago, I couldn't find any information on a Geneva Drupal meetup; so I started a thread to "announce" my migration and to see if anyone was interested in a meetup, and voila! We had a couple dozen wonderful people talking about Drupal tonight. Also, we had very good feedback, and should be able to make this a monthly thing. My sincerest apologies for not knowing French yet, but I am on my way.

I think it's really great to see how, even in this virtual Drupal community, there is still so much value and desire to get together with local people face to face. We had all types of Drupal people there, from people who have only heard of Drupal, people who just made their first node, to project managers, to developers, and to business owners and freelancers. There is a great community in Minneapolis and I hope I can bring that energy here to Geneva and make this a regular thing. There was even a joking mention of DrupalCon Lausanne (maybe in 2012).

If you are in the Geneva area, or in the greater Romandy (French-speaking Switzerland) region, please join up to the Switzerland group. I believe patchak asked for a new group for Switzerland-Romandy (hint, hint, nudge, nudge groups.drupal.org moderators); so look for that. Also, I will be posting a follow-up on the Switzerland group tomorrow to see how we want to proceed.

Thanks again!

As I prepare for my move to Switzerland to start my new job as Web Manager at Shelter Centre (many thanks to Eric at Development Seed), I am excited to be back in a position where I get to concentrate on one (or just a handful) of sites. Don't get me wrong, my time at Chicago Tech and Trellon over the past year and a half have been wonderful, and I have learned many things. But I am excited for the focus of a single project job.

My original intention with this post was to compare the difference between working at a Drupal shop, and working for a single Drupal project. But what it really comes down to is personal preference. Instead, I started to think about just the general idea of the quality of our Drupal jobs and how we, as community members, represent that quality. There are plenty of Drupal folks that don't make Drupal their means of making a living, but there is a large amount (majority even) that call Drupal our day (and night) job and are really happy about that. I sure am.

But I don't see this conversation out in the open. Maybe it is a cultural thing, or a contractual agreement, or maybe people just don't care, but there is no open discussion about what it's like being a Drupal employee. We talk about a lot of things, from code, to architecture, project management, drinking, community, minorities, respect, products, finances, and right back to code. And I think, indirectly, we all kind of put our woes and excitements about our jobs into the community in some form. But we still seem to be quiet about our jobs as Drupalers.

This post may be entitled "The Drupal Union", but I am not endorsing or condoning a Drupal Union. I simply feel that it would be nice to be able to openly discuss the things we love and hate about our Drupal jobs. Maybe, just given Drupal's success, it's safe to say that a Drupal job is heaven, but I think there is more to it and that its important to start these discussions out in the open.

After reading Morten.dk's article on Typekit and looking a little further into Typekit, I got pretty excited. I put my email in for an invite, and either by some act of randomness or someone seeing my tweet, I got accepted today.

Typekit Drupal Module

Yes, I jumped on the Typekit Drupal module right away. It's real simple. It basically fills that need for site builders who don't want to edit their themes. It also allows you set the visibility of it, much like the block system (borrowed code directly). It's not going to win any awards, but it makes things a tad bit easier.

Semi-Revolutionary?

Just as a qualifier, I am not a designer and don't care that much about fonts and know little about the school of Typography. But! Typography has always been this chained up monster in the basement. I mean, back when the Internet started, all web pages were just text. And it's still true, most of what we put up on these crazy Internets is words. So, why has it been so difficult to get some nice looking words on our web pages, even after so many years?! Why do we have to keep Aladdin down in the basement, or just use his photo?

This is not anything I have a complete answer for, but one of the main reasons is licensing for fonts. There are a lot of fonts out there, but many of them have some sort of copyright or limiting license on them that keeps them from being fully embedded in websites. There may be some direct correlation with how the two main commercial operating systems have their own sets of licensed fonts, so browsers just got stuck in the middle. Either way, owner of fonts just don't want their fonts flailing in the cyber-wind, which is what some people see embedding fonts into websites might be.

This is where I think Typekit begins to bridge this gap of having no fun fonts on the web and having all fonts free and open-source (or some other solution). Typekit, like Cufon (which is awesome and has its own benefits), allows for easy embedding of fonts via Javascript and selectors, but the problem that Typekit solves is that it has already put together a number of fonts that are available for you to use by already adddressing the licensing issues with the fonts. These fonts are not "free", mind you, and Typekit's payment schemes have a little to be desired in my opinion. But you can have anywhere from what looks like 50 - 200 fonts that are provided from many different sources (I am assuming they will be adding more too). Typekit also has this fairly unobtrusive note in the corner of your site that links to information about the specifics fonts you are using (example), which is really awesome and fair for free use of cool fonts.

Typekit is not a good solution to our problem, but it is a good place to be for interim until we can actually address the real problems with licensing of fonts and typography on the web.

I have always been a big supporter and advocate of making sure code is done correctly. I did a presentation at Drupal Camp Wisconsin this past summer about module building best practice which did not show any lines of code, but instead focused on testing, security, documentation, and community. I also put in a session for Paris, which did not get accepted, about similar things.

I recently went to the very informative Continuous Integration presentation in Paris. At that presentation there were a number of people that asked how long it took to setup the environment and the presenters had a number for it; but when I asked how much time it saved, there was no answer, not even the ability to estimate. And with some recent discussions I am having with some very respected people, I am unable to quantify the value of process.

I feel like its really hard to get metrics on how processes and methods really do make for better software. I feel like my heart is in the right place, but it seems so tough to be able to convince people that certain processes hold so much benefit over just having something work. So, how do we put specific value on these sort of things:

• Documentation
• Security
• Automated Testing
• Methodology (like Agile)
• Open Source
• Peer Review
• Drupal Core Issue Queue
• Coding Standards

It seems to be if people don't value these things, they don't do them. How can I convince people that these things are just as important as elegant code or the fact that it works (for now)?

I am currently working on a project and we are having a bit of a dilemma about how to move the project forward. So, I thought I would write an article about it, post it out to this wonderful community, and maybe get some unbiased insight from some outsiders. I feel like myself and the others involved are all a little too invested to necessarily make the best decision; maybe I am being petty, irrational, or even short-sighted (hopefully you can let me know). You can read the original thread here, and I suggest you do so to get an accurate vision of this issue.

To me, the question is about the value of process over code and here is my story. And in reality it should not be a decision of one or the other.

The Situation

I am greatly going to simplify this situation in hopes to give a more accurate and unbiased view but there are plenty of details that are relevant to our actual discussion.

• There is a module at version 1.0.
• There is a group with a forked version with good code in it; we'll call it Cool-Code-X
• We have decided to bring these together to create a version 2.0

The Decision

The question is how to bring things together.

1. Option M: Start with version 1.0 and bring in Cool-Code-X changes to create version 2.0. This requires porting the changes in Cool-Code-2 to be ported into the 1.x.
2. Option N: Start with Cool-Code-X and bring in 1.x changes to create version 2.0.

We have just released the first beta of the Drupal OpenLayers module. It's been a pretty crazy adventure as to how we got here, and there are still high hopes for the future. This post is going to be a long one, and should give you the complete introduction to this new mapping module for Drupal, and will also build on and borrow from my previous post on building this module.

• Jump to Project Page
• Check out the Demo
• Read Documentation

What is OpenLayers?

OpenLayers is a free, open-source Javascript library that provides an easy interface to bring together any sort of map tiles, markers, features, and other GIS goodness. OpenLayers was initially developed by MetaCarta; it is now a project of the Open Source Geospatial Foundation. Think Google Maps but open-source. The OpenLayers has many examples and a gallery of sites.

Where Drupal Fits In

Drupal is a great content management system and development framework. OpenLayers fits well into this because it basically is a really great visualization tool for content (the most obvious visualization being maps). Drupal can provide the ability to create and management data/content and OpenLayers can be a fun vehicle to displaying that content and provide a rich interface for your users.

Main Features and Modules

The Drupal OpenLayers module is actually a full suite of modules that provide many integration points with other contributed modules.

• At is core, the OpenLayers API module provides just enough to take a map array in PHP and render it through hooks, pass it to javascript where it can interact with events, and display a working map to the page. The main API module also manages the basics of map presets.
• The OpenLayers Preset User Interface module provides a web based interface to manage presets. Presets are basically just named map arrays that are either stored in code or in the database. With presets it becomes easy to provide interfaces to pick maps.
• OpenLayers Layers modules provides a wide range of layers to use outside the simple default, like Yahoo, Google, OpenStreetMap tiles, and more. Layers can be manually put into map arrays, but with hooks, other modules can provided named layers that get put together when the map is rendered.
• Much like the layers module, the OpenLayers Behaviors module provides a set of behavior add-ons that can easily be added to map arrays. These include things like feature controls, fullscreen controls, popups, and tooltips.
• On the input side, there is the OpenLayers CCK module which provides integration with OpenLayers and CCK. This module provides a field and widget for basic WKT input, as well as a widget for the Geo module; both of which allow the user to use a map to enter features like points, lines, and polygons. On the formatter side, you can display any preset map for the field.
• A simple way to display a map is to use the OpenLayers Filter module, which provides an input format filter where a user can input [openlayers preset_name] into the body content of a node and it will be rendered as that map.
• Finally, there is a Views plugin provided by the OpenLayers Views module that allows the user to aggregate all kinds of Drupal data and put it into a map.