doctrine_mongodb:
  document_managers:
    default:
      logging: false

I’m liking Henri Sivonen’s Validator.nu service. I’ve got it running locally, and it works well. I can use it as a web service and validate HTML from within Vim, using quickfix to rapidly resolve errors. My Jenkins CI server uses the same validator via phpunit tests.

Warning: it took me a very long time to get it running locally. Technically easy (just run a build script), but it downloads tons of libraries and files before it can do its job.

Even better is to have these web tests run automatically every time I commit code. I use Jenkins for this. Jenkins even fires up a headless desktop so Selenium can run Firefox.

When a web test breaks (especially in some way I can’t reproduce on my local desktop), sometimes it helps to actually see what Jenkins sees as it runs the test. Here’s a quick guide for doing so on an Ubuntu GNU/Linux server.

1. Connect to the remote server using SSH. Install VNC server:
   

   sudo apt-get install vnc4-server

2. On the remote server, become the user tests run as. For example:
   

   sudo su - ci

3. Set a password for the VNC server using the vncpasswd command.
4. Start headless X server by running vncserver. Note the given display. If example.com:1 is included in the output of vncserver, the display is :1.

5. Figure out which port the VNC server is using. I usually do something like

   sudo netstat -nape | grep '^tcp.*LISTEN.*vnc.*'

   Here’s some example output:

   tcp        0      0 0.0.0.0:6001            0.0.0.0:*               LISTEN      107        3099855     13233/Xvnc4     
   tcp6       0      0 :::5901                 :::*                    LISTEN      107        3099858     13233/Xvnc4

   By trial and error, I figured out that 5901 was the port I should use.

6. Port-forward VNC to your local machine.

   1. Disconnect from the server.
   2. Reconnect, including -L10000:localhost:5901 on your SSH command line.
   3. Leave this connection open.

7. On your local machine, connect a VNC client to localhost:10000. An X terminal should be displayed.

8. In the X terminal, run your web tests.

9. When finished debugging, kill the X server using the display noted earlier.

   vncserver -kill :1

I think it’s important to measure the impact of our improvements. I want to know: are we moving faster? Is product quality flourishing? Can we say so quantitatively? The last bit has been the most elusive. It’s like measuring how useful a painting is!

Still, here are some measures which we hope will eventually show how much the improvements are or are not helping. Right now we’re just establishing baseline data.

The red line in the graph represents legacy front-end code that will eventually disappear. The green line is new code, but it really doesn’t matter.

From the chart data, we can say the following by measuring deltas between points: the most dramatic change in Struts/jsp LOC was 4380, for the time period ending Aug 2010.  The most dramatic change in SpringMVC/ftl LOC was 3665, for the time period ending Sep 2010.

Assumptions:

• these data are not useful for estimating speed of future refactoring work
• all acceptance tests pass in refactored areas
• look & feel of refactored areas is acceptable

The 2nd & third bullets are a bit vague. To address this shortfall, we’ll measure the following aspects of quality:

1. Time spent modifying CreateSavingsAccountTest.
2. Number of issues (regressions) caught during CSS walk through.
3. Number of layout or functional bugs logged during testing phase (missed during walk through).
4. Time spent by QA manually testing the feature, including logging issues and retesting bugs fixes.

Finally, developers should know if things are better. This is the most qualitative and possibly the most important “measure”! Certainly, for the migration of our codebase from svn to git, it was the only measure we used, and it was enough.

Thoughts/comments/feedback are appreciated. I’d rather have some kind of simpler measure, like “x increased by 250%”. Do you know of any more effective (and hopefully simpler) means of measuring development speed?

I used gnuplot to generate the graph. Here’s the source.

Here are some example tasks for the i18n champion:

• Make sure messages in Mifos are translatable.
• Document messages and resolve issues mentioned on our Translator Helpdesk.
• Hang out in #mediawiki-i18n (an IRC channel on Freenode), answer Mifos questions when they come up, or add them to the Translator Helpdesk.
• Work on specific i18n issues: MIFOS-3859, MIFOS-3821, MIFOS-2018 and others.
• Improve and refine the Mifos i18n/L10n guide.

See also: #Mifos, #microfinancing and #Wikimedia

Update

A day after I sent out this call for help we got two volunteers! Thank you, Stanley Kwok and Jasmine Sandhu!

Since we used FLOSS Manuals to write our manual, it’s easy to generate an ebook using Objavi. Here’s the Mifos Manual as an ebook. Looks pretty good on the iPhone (lately I’ve been using “Stanza”). Probably looks even better on a Nook, Kindle, or iPad.

Our corner of the Grameen Foundation focusing on Technology for Microfinance has a lot to learn from OpenNMS! They’re also FLOSS, and they’re profitable.

I talked with Tarus the other day. Turns out he’s a really cool guy. I’ve been following his blog closely for quite a while now, so I was thrilled with the chance to pick his brain. The point of the call was to find out why and how they run their developer summits: in-person meetings where coding, alignment, teambuilding and planning are plentiful. OpenNMS hosts these yearly, and we’d like to do them for Mifos.

We talked for a while, so I’ll summarize. I’ll cover the dev summit stuff first, then more about FLOSS business.

Adam: what instigated the first summit?

Tarus: I live on a farm in the middle of NC, wanted to get in touch with other devs. I invited them to hang out at my place and code for a week. The result was camaraderie and commonality of purpose. In other words: the hard stuff. We also got a lot of useful coding done. There were only 5 people, yet it was an awesome time.

A: How do you think things will be different if you didn’t have these summits

T: we had to cancel last year’s, and we felt the pain. We missed each other. We usually have dev tasks that are especially suited to summits that we didn’t do.

A: can anyone come?

T: yes. We sponsor active contributors. Full-time paid employees are pretty much required to go. Others must pay $1400 (includes room + board). This is modeled after debconf ( http://debconf.org ).

A: who comes?

T: 1/3 full-timers, 1/3 sponsored volunteers, 1/3 folks who pay their own way. Even with the folks who pay, dev summits are expensive and can run $20-$30k.

A: what’s the format?

T: loose/barcamp/vague. This works much better for us than a dictated organized agenda

A: What are your definitions of “success” for a summit? How do you know when you’ve had a successful summit?

T: we don’t really have a measure, but the value is apparent from the team cohesiveness, fun had, code produced, and productivity following the summits.

A: can I come?

T: yep

A: what do I need to do to run a successful summit?

T: plan it well. Make it fun. Buy food. Have someone go onsite and set up logistics: rooms, wifi, whiteboards, projectors, etc. Do stuff together. Discourage newbies (they need to pay to attend): don’t make it a training session: make it a *developer* summit. Publish prereqs: compile the code, run tests, study the schema, have your laptop ready, etc.

Other stuff:

A: where are your devs?

T: global.

A: how do you reward volunteers and retain contributors?

T: LOTS of ways! “order of the X polo”: exclusive group of contributors are in the “order of the green polo”, these folks are the steering committee. OpenNMS is business driven, but the OGP drives the tech. They stick around because they are invested and we value what they say. They’re the experts. OpenNMS Group sells services, not software: training, consulting, installation, custom dev. Volunteers and contributors are invited to (and do!) do the cool stuff, the fun stuff, the most important stuff. We guarantee the code will not suck, and it will always be Free (as in freedom). also see “order of the blue polo”: that’s the one you should sign up for, Adam!

A: will do. Can you say more about what custom development you’ll have to do?

T: yes, but not just anything. Ex: someone wanted RT integration. Instead, we built a generic event-based framework and allowed them to hook into it. I don’t sell “custom dev” to a customer, I make them *sponsors* of features that make it into OpenNMS. Salespeople must have technical knowledge to make this work. The custom features aren’t what make them competitive anyway, it’s their business strategy, their processes, their people. We also sell commercial licenses for OEM arrangements. They pay for (us to do) custom dev, and we get the code, too.

I’ll be there, too!

Thanks to Adam Feuer for encouraging me to approach Tarus/OpenNMS.

We’ll have a video feed going. I’ll be wearing my track suit.

Check out our coordination wiki page and stop by our IRC channel if you’d like to join in! If you’ve ever edited text on a wiki, are brave enough to learn how, or just want to see me in a track suit, come on by.

I suppose I should explain the title of this post. If we can establish a framework for software development on Mifos like we’re running this sprint, we can break Brooks’s law. Why not? The Ksplice folks did it, so we can too!

Apparently Ehcache includes an automatic update check that is also effectively a phone home. Terracotta software conveniently collects some extra information (such as your IP address) when Ehcache phones home. The information they collect is benign. But, seriously? A library phoning home, by default?

Who decided it would be a good idea to add this feature to a popular Java library? It’s a transparent attempt at gathering usage statistics.  As a participant in a professional FLOSS project, I can fully identify with the need for knowing who is using your software. But automatically, secretly phoning home is not the way to do it!

Terracotta, will you turn this feature off by default in the next Ehcache release?

I see this issue has come up in forums:

• Ehcache update check
• Can Ehcache check user local info?!
• ehcache 1.7.0 calling home to check for updates?!?!?
• Possible justification by a Terracotta employee

Other tidbits:

• We use Ehcache 1.4.1 in Mifos, but that (pre-Terracotta) version does not phone home
• Quartz, another recent Terracotta acquisition, also phones home
• Here’s an open issue about the update checker creating unnecessary threads