Michael J. Ross contributed a review of our Drupal 7 Module Development book. Slashdot typically writes very fair reviews, and Michael's is no exception. He does a good job of digging into each chapter and examining both the strengths and weaknesses of the book.

Slashdot review of D7 Module Development
Up front I would like to make a request. We would like to encourage readers to use the GitHub book code instead of the downloadable code bundle from Packt. The bundle packaged by Packt was outside of our direct control, and seems to contain earlier versions of some of the code. In addition, the GitHub project contains code updated to the latest errata that we know about. And we respond to bugs filed through GitHub. In other words, the code there is a living document.

I found it interesting that Michael could tell that different authors had written different chapters. This is very much the case. Each of us took a turn or three as a "primary author" for a chapter, while others just provided input about what should be covered or how well a topic was covered. This gave each of us a chance to play to our own strengths. It also (I hope) held at bay the old "too many cooks in the kitchen" problem. We assumed that readers would be able to move effortlessly from chapter to chapter without being tripped up by the unavoidably different voices of the authors. We could have added a byline to each chapter, giving a clear indication about who wrote what, but we just didn't feel like that added anything.

Perhaps the biggest difficulty writing the book was in continually trying to hit a moving target. When I began chapter 2 well over a year ago, Drupal was still under very heavy development. APIs were changing. Strategies were still in flux. Documentation (and in some cases, design) was not complete. This led to an interesting writing process: Write the chapter, go back three months later and try to find out if anything changed, go back three more months later and try to find out if anything had changed, etc. Thankfully, the tech reviewers caught many of these issues along the way. Needless to say, it is far easier to write a book against a finished code base, but it was more important to us that we get the book in developers' hands right around the time D7 was released. It was sort of our D7CX commitment.

For the second year I was given the opportunity to represent Drupal at the Google Summer of Code Mentor Summit. The primary purpose of the Mentor Summit is to bring together the projects that participated in GSOC, and provide a forum for discussions.

While there, I learned about what other CMS systems are up to and how other Open Source projects were working with Git and DVCS systems. Here are some of the highlights.

For whatever reason, I have not seen Varnish documentation on concatenating strings. It's not on the official operators list. Even more bothersome, I occasionally see people using regular expression substitutions (regsuball) to do string concatenation in Varnish's VCL.

In fact, string concatenation in Varnish is simply a matter of setting a variable with two strings. For example, here's how to prefix a URL in vcl_recv:

set req.url = "/my_prefix" req.url

That's actually all there is to it. No explicit operator is needed.

I have led or contributed to dozens of Open Source projects. And with one exception, all of my code has been Object Oriented. (That one exception is Drupal.) Java, Python, PHP, and even OO Perl... I'm a dyed-in-the-wool OO developer. So this may come as a shock to anyone who knows me, but I am about to make the argument that OO is bad for Drupal.

Trust me, this is not a high point in my development life. I feel like I'm telling my child that she should skip college; that such a level of sophistication is just not necessary in her life. And I guess in a way that is precisely what I am saying.

I spend most of my days doing software development and system administration. And I am always busy, so streamlining any part of my workday can have a big impact on how much I get done and how good I feel about my productivity. Taking a look back over the last six months, I see that I have added a handful of new tools that have had a positive impact on my daily work.

1. NirvanaHQ

I've never been all that successful managing a todo list. But Nirvana has changed that. Nirvana does one thing very well: It helps manage todo lists. The user interface is great. It keeps everything front and center. It's easy to create new tasks and projects. It's easy to see what needs to get done today. And it's easy to organize all of your tasks into meaningful groups. The mobile web app runs remarkably well on my iPhone.

2. Homebrew

These days my routine work is done on a Mac. While there are many things to love about it, one thing I have long missed is the ease of installing new Open Source packages. Mac Ports was never my thing. But Homebrew is. It functions like a blend of Debian's apt-get and the BSD ports system. And it is not only easy to use, but easy to add new packages.

Now I'm running wget on my Mac.

3. Ttytter

The first homebew package I created was for ttytter. Ttytter is a command-line twitter application. I love it's low key CLI interface, the ease of use, and the fact that it supports pretty much all of the twitter goodies that I want. Oh, and it can use Growl for notifications. Yes, I miss some of the pretty profile images. But otherwise, it's a Twitter dream come true.

4. Sequel Pro

I'm not a huge fan of GUI database management apps, but I have to admit that I am really enjoying Sequel Pro, an Open Source OS X tool for working with MySQL. With SSH tunneling (which it supports out of the box), I can use it to connect to everything from my local virtual machine to production servers.

5. Google Chrome

I sorta hate to add "just another browser" to the list, but Chrome's crash proof tabs make it a big deal for me when I use large web apps (and work on unstable code). Plus, it's fast and seems to take less of a toll on my workstation that Safari.

Learning Drupal 7 DevelopmentThe Learning Drupal 7 Module Development book is now in Packt's RAW (Read As we Write) program. This has been an exciting few months, as Larry (Crell) Garfield, Ken Rickard, Greg Dunlap, John Albin Wilkins, Sam Boyer, Matt Farina and I have all worked together to bring this book to fruition. As you no doubt know, Drupal 7 is still in the polishing stages. So is our book. But Packt has once again decided to release the book in RAW format, which means you can basically read the book as we write it -- and before we've added that final layer of glossiness ourselves.

The book is far more than an update of my solo effort, Learning Drupal 6 Module Development. Instead, it's an entire rewrite, with each of the members of this phenomenal team contributing chapters that best suit their own expertise. For that reason, I don't think I've ever been more excited about a book release.

While we have very conscientiously written this book to be approachable for the new Drupal developer, we have also made a concerted effort to cover the changes between Drupal 6 and Drupal 7. The experienced developer just looking to get up to speed should find this book a quick and valuable read.

Some of the things we cover:

• Theming for developers
• The block system
• The new Entities API
• Building admin interfaces
• The new Files API
• Nodes and permissions
• JavaScript
• Creating installation profiles

And as usual, the book is full of practical projects that will really get you started.

When I tried to run pyrus.phar on Mac OSX recently, I had a strange experience. Executing php pyrus.phar generated the output ??? and then exited. With a little more testing, I discovered that all of my Phar packages, when from from the command line, generate "garbage" output (a series of question marks, usually) and then exit.

Quite a bit of digging later, I discovered an old bug report (recently re-opened) that documents the problem and suggests a solution. In a nutshell, the problem is that the Zend engine Unicode checker is enabled by default in at least some versions of PHP 5.3. My Apple-built PHP package (included in the Snow Leopard releases) has this problem, and I suspect that other builds do too.

While there is no solution yet, the workaround is as simple as setting the following ini directive:

detect_unicode = Off


While I'm not a huge fan of this workaround, it definitely works. I simply added it to my /etc/php.ini file, and now I can run pyrus and other Phar files.

Did you know that you can reload varnish VCL configuration files without restarting varnish? While I could find any clear mention of this in the manual, it turns out to be a simple two-step task accomplished using varnishadm.

Prerequisites: Having Varnish Listen for Admin Connections

In order to reload using varnishadm, we need to have the varnishd instance listening for incoming admin connections. Here's an example showing how to start varnishd with an admin listener on localhost:81

Note the -T localhost:81 option. That's what tells Varnish what address and port to listen on.

Reloading a VCL File

Now we can reload the file using varnishadm.

At the console, we connect to our varnishd instance with varnishadm:

$ varnishadm -T localhost:81

From the Varnish admin console, we issue a pair of commands:

vcl.load reload01 /usr/local/etc/varnish/default.vcl
vcl.use reload01

The first line tells varnishd to load and compile the VCL file (/usr/local/etc/varnish/default.vcl), and assign it the name reload01. If we wanted to see a list of all of the named configurations that varnishd currently has, we could use vcl.list.

If the new file loads and compiles okay, we will get a message on the console telling us that that is the case. Now that the file is loaded, we just need to tell Varnish to use that new file. That's what vcl.use is for. It takes as an argument the name of the configuration. In our case, this is reload01.

That's it. Within moments, varnishd should be using the new configuration.