Open Source for Microfinance

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

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.

Code Review for Fun & Profit

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

Upgrading to 6?

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?

Generating OmniGraffle Diagrams from MySQL Schemas

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:

Upgraded to Drupal 6.2

I just did a total seat of my pants upgrade to Drupal 6.2 here. The only special thing I had to do was go in and create a .info file for my theme. Plenty of other things aren't optimized for 6.2, but it is working.

Google is S-M-R-T

An interesting piece on how Google uses A/B tests to refine user interfaces. Google's interfaces all seem so nondescript, but there is plenty of thought that goes into them.

Panels 2 and Views 2

Panels 2: will be released for 6 in a couple of months
Views 2: only for Drupal 6.

Panels 2

Lets you create nodes that contain regions (panel-nodes). Considerably more flexible than the original panels.

Can disable Drupal blocks regions with Panels 2. This would be very nice for landing pages where you want to eliminate the side navigation.

Views 2

Very stable even though it is still labeled beta.

Views 2 can work with nodes or other content types like users.

Ok, this is pretty cool.

CCK and OO Drupal Programming

CCK.

If you need something really weird, do it in your module. Otherwise, do it with CCK.

CCK 6 is going to behave more like Form API, so much easier to create custom elements.

Image field and image cache are very worth checking out. Imagecache will auto generate different sized thumbnails.

CCK Mistake: still need to plan. Think ahead, plot out your content-types.

Consider using CCK and creating select list instead of using taxonomy. This can keep the category or whatever actually on the node. Using CCK is often more programmer friendly, though taxonomy is still often most friendly for content administrators.

Uses taxonomy instead of node_reference to do groupings. This way it is a two way reference.

OO Drupal:
Class == Content Type
Object == Node
Attribute == CCK Field
Function == hook_nodeapi