Drupal 6.7 and Drupal 6.8 are out today. Security vulnerability.

These notes were lying around on my laptop, left over from a good presentation at OSCON.

LEAN
- Eliminate waste ruthlessly and measurably.
- Amplify learning - knowledge is power.
- Most productive people are not the specialists, they are the generalists who understand the whole system and can see the bottlenecks.
- Decide late, deliver early. Just in time decision making.
- Smaller chunks of work moving through the system faster.
- See the whole, cultivate a shared result. Avoid hand offs where someone can say "I'm done, it is their problem now".
- Likes the cycle from agile, doesn't like the explicit identifying of what is going to happen in the cycle.
- "Cadence is Key": go from "release early and often" to "in this cycle we added X."
- Know where you stand. Track bugs, feature requests, ideas.
- Branching and merging. Keep trunk pristine, keep features flowing, release on demand.
- Code reviews. Accelerates learning, maintains quality, verifies test coverage.
- Automate testing. Unit, integration, utilization.
- Pre-commit testing.
- Sprints. Nothing brings people together like bringing people together.

Today I needed to add a new candidate page.tpl file based on node-type. I found this code snippet and modified it slightly.

function phptemplate_preprocess(&$vars, $hook) {
	switch ($hook){
		case 'page':
		  // Add a content-type page template in second to last.	
			if ('node' == arg(0)) {
				$node_template = array_pop($vars['template_files']);
				$vars['template_files'][]  = 'page-' . $vars['node']->type;
				$vars['template_files'][]  = $node_template;
			}
			break;
	}
	return $vars;
}

My tweak puts the new template in the middle of the candidate templates array so that I can still have specific page.tpl files for specific nodes. The devel module tells me my candidate files are now:

page-node-4.tpl.php < page-story.tpl.php < page-node.tpl.php < page.tpl.php

This works on Drupal 6.

A MySQL Search and Replace.


update node_revisions set body = replace (body, 'photo=old_id', 'photo=new_id');


No more select, fetch, regex, update just to change a little bit of content.

George Conrad, Executive Director - Mifos.org

Says microfinance isn't scaling in part because of inadequate technology. Mifos is trying to build an open and scalable platform for microfinance providers.

One of the big challenges is that they need to build local support systems. Saas is great, but banks are going to want local resources to help them. Mifos needs to build a local support ecosystem.

Been in development for 3-4 years. So far learned:

- Can't just be a project, needs to be a business
- Betting on Saas to reduce technical barrier
- Channel is required to scale
- The are no examples that fit their model

Runs on Tomcat, Windows 2K3, MySQL 5.

Creating Skimmable Code.

Narrow your focus. You want to have to remember as little as possible.

How? Lexical encapsulation. Put things in functions.

Refactoring to do this?
1. Refactor
2. Test
3. Commit
4. Repeat

Two important refactoring techniques for creating skimmable code:

1. Renaming - Give things names that are expressive.
Bad: a name like $arg or $tmp. That is like having a box that has a label on it that says "box". It says what it is, not what is in it.

2. Extract - Pulling out a chunk of functionality that should be in a function or a method. If you can explain a chunk of code in one sentence, you probably should give it its own function that does that.

"Narrow Scope Forgives Many Sins" - A chunk of code can be ugly as hell, but if it is isolated so that no one has to look at it typically that is OK.

Some people don't like putting anything in a method until it is necessary. He (we) disagree. "Discoverable reuse": if something is already in a method, people are likely to start using it (programmers are lazy).

Doesn't like comments to end blocks. Violates the DRY principle (Don't Repeat Yourself) as well as the idea that comments should not be the same as the code. Makes sense in a server side code, but I like the way Paul does this with DIVs, which inevitably are deeply nested.

Add whitespace between logical paragraphs.

"Similar things should look similar."

Add horizontal whitespace to line up arguments, operators, etc.

Name things and name them well.

If you have to have globals, use Caps to make them obvious. Just as similar things should look similar, different things should look different.

RED FLAGS

No documentation

No tests

Things are deeply nested. Makes it difficult to remember.

Complex names. function make_pancakes_and_waffles

Bad names like $tmp, $array, $data, $x, $r

Long names. If you need to say $total_amount_spent_on_corn, you probably should have a method buy_corn that has a $total.

Global variables are bad because they aren't skimmable, can be accessed anywhere.

Recommends doing code review by email so you get a change log, even if people are in town (unless you are doing a sprint).

Recommends ~200 lines of code, 400 max. White space doesn't count, comments do.

All code for major projects at Google is reviewed prior to check in.

Tools:
http://codereview.appspot.com/
http://code.google.com/p/rietveld
http://review-board.org/

Slides

Drupal 6.3 is here.

Drupal.org just went tits up in a very similar way that this site did when I upgrade to Drupal 6 while it was live. Perhaps they are doing the same?

I experimented with a number of tools to try to get my mysql schema into OmniGraffle. The best script I found was this one.

A couple of notes:

• You need to install the AppleScript XML Tools first.
• You need to have Omnigraffle running with a blank canvas open.

Once I figured that out it worked like a snap for me. A sample of the raw output: