October 2011

29 Oct

Is Size Code's Worst Enemy?

in drupal, php, programming

The Drupal codebase upon which I work is now over a million lines of code (excluding whitespace and comments). It sounds impressive. But the reality of the matter is that the combination of lots of code and the Drupal way of doing things makes it not impressive, but a maintenance nightmare. Nobody on the current team knows what all of this code does or what it is for. Even limiting things to the custom modules, there still is no longer any member of the team who knows the code well. This, of course, isn't a criticism of the team or even of the platform, but a reflection on what happens when a codebase balloons over the years.

Reading Steve Yegge's post entitled Code's Worst Enemy hit home the concern I have with our code -- and with Drupal in general. (Update 10/29/2011: Steve Yegge's the guy who accidentally posted the Amazon/Services rant on Google+, and who unintentionally "quit his job" in the middle of his presentation at OSCON.)

I suggest reading the entire blog post on its own, but here are several salient details that need explicit mention, and that have a Drupal context:

  • While some languages (Java) may exacerbate the problem, clearly ballooning code can happen in any language. And with a semi-opaque execution sequence (as we have in Drupal), the problem can be compounded by the fact that one cannot determine at a glance what code might be executed on a given execution. To know what code will be executed on a given request, you must know not just core and your own modules, but all of the installed modules.
  • Design Patterns might deserve a measure of skepticism. Steve's point is that relying upon them can introduce needless complexity. He uses Dependency Injection as an example. Too often, design patterns are introduced for their own sake or because they look similar to what we want to accomplish. But then the need to (re-)architect in terms of the pattern sometimes overshadows the original goal of accomplishing a task.
  • Copy-and-Paste (CAP) code is bad. Obviously. But because all of Drupal is a public API, I often see developers choosing to CAP code from function body to function body because they think that is more elegant than providing highly-contextual stand-alone functions that might be mistaken by other developers as "generally useful". (No, prefixing functions with underscores is NOT a good alternative. Lately, I've been encouraging developers to underscore all functions that aren't hooks or constructed callbacks because it's too easy to get hook/namespace collisions otherwise.)
  • Unfortunately, Steve doesn't talk about YAGNI ("You Ain't Gonna Need It") as a good design principle, but the converse of YAGNI -- that tendency to attempt to solve all possible cases before there are any actual cases -- is a dangerous tendency in software developerment that must be countered in the name of simplicity and maintainability.
29 Oct

Good PHP: Coding Standards and Why You Should Follow Them

in drupal, php, programming

In hindsight, I'm surprised how long it took me to develop a strong appreciation of code formatting standards. It's not that I haven't followed them all along (most IDEs and editors do the lion's share of that for you). What surprises me is that I never really appreciated the value of following them. But managing a codebase of over a million lines makes it readily apparent that coding standards are a big boon -- and that lapses in those standards adversely impact the entire team.

The primary reason for coding standards is this: humans are worse at syntax parsing than machines are. Coding standards exist to make the code easier for humans to work with, and they do this by making the code more amenable to visual scanning.

There are four benefits to be gained from following coding standards: reduction of bugs, preventing new bugs, lowering the learning curve, and easing long term maintenance. I discuss them below.

29 Oct

JavaScript, Node.js, and the Flying Wedge Anti-Pattern

in javascript, node.js, programming

The "Flying Wedge" is the name of a military formation in which troops would march into battle in a V-shaped formation. That same V-shaped "formation" unfortunately has a tendency to show itself in JavaScript and CoffeScript. And in the vast majority of cases, it is bad practice.

Code that's easy to read, modify, re-use, and debug is better code. A convention that hampers those goals without offering an overriding benefit is an anti-pattern. That, in a nutshell, is why the flying wedge ought to be avoided.

Here's an explanation of the anti-pattern, along with some suggestions for avoiding it.

Node debugger

Node debugger
28 Oct

Node.js Debugging with the Built-in Debugger

in debugging, javascript, node.js, programming

Node debuggerNode debuggerThe HTTP version of the app worked, but the commandline version did not. What went wrong? It was hard to say. The application simply hung, unresponsive. Try/catch and event handlers didn't find anything wrong, and my typical console.log() approach wasn't cutting it, either. I need to fire up Node.js's command line debugger.

This is a short tutorial explaining how to use the debugger that comes built-in to Node.js. It explains how to use the command line debugger to set breakpoints , step through the code, and analyze the debugging output. By the time you're done reading, you should be able to quickly debug your own code.

The Basics

  • Node has a built-in debugger
  • It can be executed using node debug your_scriptfile.js
  • In your app, you can set breakpoints using debugger;

Now let's look at each step of debugging....

26 Oct

Node.js: Five Things Every PHP Developer Should Know

in javascript, node.js, php, programming

I recently started working on a few Node.js applications. Coming most recently from PHP (and Drupal in particular), I found the transition to Node.js to be surprisingly easy. Pleasurable, in fact. But I had to learn to think differently about a few things.

Below I list the five things I think every PHP developer should know about Node.js.

26 Oct

Five Reasons for Doing Drupal Development on a VM

in drupal, pear, php, programming, system administration

In years past, I used to do my development on a local machine, and then push my work to a remote server for testing. About two years ago, though, I switched my environment. I began using virtual machines instead of physical servers. Configuring them for Drupal, I could do my Drupal development locally, and then do advanced testing on my virtual machine.

In this article, I give five reasons why I believe Drupal development can be enhanced through using VMs.

26 Oct

Node.js: Connection Pools and MongoDB

in javascript, mongodb, node.js

Node.js can interact well with MongoDB using the MongoDB native driver. The driver comes with plenty of documentation. However, one feature that isn't explained clearly is the pooling system.

The MongoDB Node library can create a pool of connections to the database that can then be shared throughout your Node application. That means that you can open a series of connections once (at startup) and then use those connections as needed.

Here are the mechanics:

mongodb = require('mongodb');
 
// Define options. Note poolSize.
var serverOptions = {
  'auto_reconnect': true,
  'poolSize': 5
};
 
// Now create the server, passing our options.
var serv = new mongodb.Server('localhost', 27017, serverOptions);
 
// At this point, there is no connection made to the server.
 
// Create a handle to the Mongo database called 'myDB'.
var dbManager = new mongodb.Db('myDB', serv);
 
// NOW we initialize ALL 5 connections:
dbManager.open(function (error, db) {
  // Do something with the connection.
 
  // Make sure to call db.close() when ALL connections need
  // to be shut down.
  db.close();
});

The salient detail of the above code is that the database connections are not opened until Db.open() is called. At that point, all five (our poolSize is 5) will be opened at once. These will be left open until the database is closed.

Internally, the MongoDB library will manage which requests go to which connections.

Note that the variables dbManager and db above both point to the same object. To really make use of pooling, your application will have to do something more sophisticated than the above. After all, there's no sense in opening five connections, executing a single operation, and then closing all five connections.

21 Oct

Node.js Automated Testing: A Quick Intro to Writing and Running Tests

in node.js javascript testing

make testmake testNode.js does not come with a formal testing suite (though there are several available). However, it comes with the necessary tools for writing simple and effective automated tests. This is a quick explanation of how to write simple tests for Node.js code. We cover the directory structure for testing, the assert class of Node.js, and automating the process with make and a Makefile.

By the end of this short blog, you should be able to quickly and easily write automated tests for your Node.js packages.

make test

make test