Many of the ideas in this post actually come from my friend Unny Nambudiripad, but Unny doesn’t blog, so I’ll have to write this up for him.

The other day I was talking with Unny and Lisa Kimball about a nonprofit Lisa had looked at. She was disturbed because they’d spent their entire budget on salary. Unny and I didn’t think that was a problem, and Unny had a very good take on how to evaluate a nonprofit organization’s donation worthiness.

Spending on salary or office space or printing or pretty much anything else is irrelevant. The common advice you’ll hear is that a nonprofit should not spend more than X% on admin, where X may be 10% or 15% or some other essentially random number. I googled and found a good blog post that goes into more detail on this.

Of course, if an organization is spending 80% of its income on admin, something is wrong, but is 20% okay? How about 25% or 30%? The answer is “it depends”.

This obsession with admin and fundraising costs is particularly hard on smaller nonprofits that are trying to grow. Let’s look at my favorite nonprofit, Compassionate Action for Animals (yes, I’m biased, since I co-founded this organization). About 18 months ago, we started renting an office in Minneapolis. Previously, our only office space was the space allotted to us as a student group at the University of Minnesota.

Having an office has been a huge help. Going to the U is really annoying for anyone who’s not a student. It’s hard to navigate, parking isn’t free, and the space we have at the U is very small (maybe 120 square feet) and sometimes insanely loud. In contrast, our current office has lots of space, is very quiet, and is relatively easy to find. We can easily host small events (potlucks, training sessions), have meetings, store lots of equipment, and get work done.

For our current fiscal year, this office space will cost about 10% of our income. On one hand, that seems like a lot. On the other, we’re spending $700 per month for at least 700 square feet of space, which is a very good price. The office enables us to be more effective, which is exactly what you want from a nonprofit.

If we spent half the money, we’d up with a tiny office, big enough for just a few people at a time. This wouldn’t meet our needs, since what we really need is a space for collaboration (meetings, events, training), not a place to stick one employee. If we had “saved” money by getting a much smaller office, we’d actually be wasting money. This is a perfect example of how focusing on admin percentage can lead a nonprofit down the wrong path.

So how can you evaluate a nonprofit? Unfortunately, there’s no simple way. It’d be nice to look at a few numbers and declare “this nonprofit is effective”. That would make donation decisions so much easier! Too bad that doesn’t work.

Now we come to Unny’s idea. Pick ten (or five, or twenty) nonprofits in fields you care about. Now comes the hard part. Look at what they say their goals are, both in terms of mission, and in terms of year-to-year plans. Are their goals reasonable? Are they ambitious? Do their goals further their mission? Do they have a strategy?

Next, attend their events, read their newsletters, and volunteer with them. Get involved in ways that go beyond writing a check.

Now compare their reported outcome with their goals. Did they fail to meet their goals or exceed them? Did they change course when needed? Did they spend more than they said they would? If they did overspend, did they get more done for that money? How was your experience attending an event or volunteering? Was it a good experience? Would you recommend it to your friends?

You can also talk to the nonprofits. Call them up or write them email and ask some questions. A good nonprofit will be happy to talk to you.

Based on this, you can eliminate some of the nonprofits you’re following. Keep doing this for a few years, and you should have a good idea of which nonprofits are doing good work. Donate to them.

Yes, this is a lot of work, but if you care where your money goes, it’s worthwhile.

Since I’m looking for work these days, I’ve been doing a lot of interviewing. An interview is a potential employer’s chance to learn more about me, but it’s just as important that I learn about them. I think in an ideal interview, I spend at least as much time asking questions as answering.

Over the years, I’ve created a standard list of questions that I want answered.

  • What do you like best about working there?
  • What do you like least?
  • What would you change if you could?

These are all pretty obvious questions. If the person you’re talking to doesn’t have anything that they dislike, then I know they’re lying to me. No employer is perfect, and honesty is important.

  • What’s your remote work setup look like?

Telecommuting can be very isolating, and the burden is really on the employer to make it work.

If the employer isn’t already set up on some sort of chat system, that’s a warning sign. If the primary form of communication between their existing devs is shouting over the cubicle wall, then it’s probably not a good place for a telecommuter.

  • What’s your dev env like?

If they say “we don’t really have one” or “one shared machine with one shared database”, that’s bad. What I want to hear is “you can check out the source, run 1 (maybe 2 or 3) commands, and start hacking”. That said, I’m willing to work on getting them to that point if they’re willing to pay me to do so.

  • How are conflicts resolved? technical, social?

This comes from a past position where management effectively did nothing in the face of conflicts, both technical and social. Conflicts need to be resolved. This can be as simple as “Jane is the tech lead” for the tech side, and “the manager gets the conflicting parties in a room to talk” for the social side.

  • Do you have any sort of technical principles or vision?

Or is your code base a mish mash of whatever anyone felt like doing at the time. See above about resolving technical conflicts.

  • What end-users do you deal with? How do they feel about the app?

I (strangely) like to talking to customers and understanding how they use a product. If the tech side never interacts with customers, that’s a problem. If the customers hate the app but have to use it anyway, that’s demoralizing. I’ll pass.

  • How do you balance technical/business goals?
  • Are there reasonable goals & expectations? How are missed deadlines handled?

Does the business side realize that developing software requires more than just building new features? You need to keep the code base manageable, fix bugs, and work on infrastructure. If it’s just features, features, features then it’s not the right fit for me.

  • What is your level of tech debt?
  • Testing? release with failing tests? source control? code reviews? continuous integration? docs? QA group?

This is my truncated version of The Joel Test.

If you don’t do any of this stuff, then you can hire me to introduce good dev practices. But I’m too cranky to just maintain your giant ball of mud spaghetti indefinitely.

  • How would I fit in?
  • What might a typical day look like?

I like to know that the employer has some idea of how they would integrate me into the team and what work I’d be doing.

  • What’s the policy on releasing open source?

I’m more concerned with being able to release bug fixes for my existing projects than entirely new ones. If I fix a bug in Moose or DateTime at work, I must be able to release it, no questions asked.

I’d love to also package up work code for release when appropriate, but that’s more of a nice-to-have.

  • Hours?
  • Vacation?

I won’t be working 50 hours a week. I have a life and other things to do. The occasional crisis happens, but some places are in permanent crisis mode.

I also plan to do things like go to conferences and visit my in-laws in Taiwan. The American standard of 2 weeks is terrible.

  • On-call?

I don’t really like the idea of being on-call, but if there’s a reasonable rotation and compensation for being on-call, I’m willing to do it occasionally.

What else should I be asking? Tell me in the comments.

(I’m still looking for a new position. Please check out my resume and contact me if you’re looking for a great Perl developer.)

I was talking this weekend with Matt Mackall about Python 3 and Perl 6. Matt is the creator of Mercurial, so he is deeply invested in Python.

He was asking about the relationship between Perl 5 and Perl 6, and we were comparing it with the relationship of Python 2 and 3. His main problem with Python 3, as I understand it, is the backwards-incompatible change in string handling from 2 to 3. In Python 3, all strings are Unicode by default. Byte arrays are now their own thing, no longer interchangeable with strings.

Meanwhile, Mercurial is still supporting distributions that are running Python 2.4, which is over 6 years old at this point. To make matters worse, Mercurial really doesn’t benefit from the Unicode-is-everywhere changes in Python 3, so there’s little incentive to migrate.

I suspect that eventually Mercurial will be stuck with some sort of compatibility layer that checks what Python it is running on, and loads the appropriate versions of libraries (or monkey patches them, or whatever Python people do ;).

This discussion helped me realize that regardless of any problems Perl 6 has, we’ve done one thing really right in the overall Perl community. There’s no intention to have Perl 6 replace Perl 5. Perl 6 has been designed to co-exist with Perl 5. The Perl 6 binary will presumably be called perl6 (or maybe rakudo), not just perl.

Meanwhile, Perl 5 has maintained it’s strong commitment to backwards compatibility while still pulling in cool bits from Perl 6. This commitment can be frustrating in many ways, but its also has benefits. The Perl 5 commitment to prototyping new features on CPAN has made for a much cleaner upgrade path. Finally, the fact that syntax breakage is almost always opt-in (with use feature or use 5.x), means that we can safely upgrade one module at a time to new syntax.

Of course, Python has from __future__ import, but Python 3 doesn’t use that to enable Unicode everywhere. Even worse, there doesn’t seem to be a from __past__ import "old string semantics", so upgrading to Python 3 requires an entire application (and its dependencies) to upgrade all at once.

Whatever you think of Perl 6, I think the Perl community can be thankful that Larry had the foresight to realize that Perl 6 cannot replace Perl 5. Decoupling Perl 6 from Perl 5 has let the two projects grow at their own pace. If Perl 6 had been officially anointed as the coming replacement for Perl 5, I doubt we would ever have seen the Modern Perl “movement” emerge, nor would we have seen the revitalized Perl 5 core development of the past few years.

When Perl 6.0 is released, in whatever form that takes, our Perl 5 programs will continue working for as long as we want. That’s a very good thing.

(I’m still looking for a new position. Please check out my resume and contact me if you’re looking for a great Perl developer.)

There was a lot of interest in Chloro, my new form library, when I blogged about it last week.

I just released 0.01. I’ve started integrating Chloro into a web app that I’m developing, and I really like using it so far.

That said, this release should be considered an alpha, and I reserve the right to completely rewrite it for the next release. Don’t start using it unless you’re okay with that.

(I’m still looking for a new position. Please check out my resume and contact me if you’re looking for a great Perl developer.)

Perhaps I should title this entry “Building a Slightly Less Horrible Form Library.” When I mentioned form processing in the Moose IRC channel recently, mst said “form modules are … satan”. That sounds about right.

I’ve looked at a number of form libraries over the years. Recently I started using HTML::FormHandler (HFH) in an application I’m working on, but eventually I realized it just didn’t work for me.

I think there are a few fundamental problems with all the form libraries I’ve looked at. First, they’re not really sure what a form is. It’s a set of user input widgets, it’s a set of validations and data types associated with names, it’s a thing that can introspect your database, it’s a thing that can update your database. That’s a lot of things to be!

This is actually two separate problems. First, the form library is trying to solve every form-related problem possible, from rendering to validation to acting on the form input. But the real problem is that it tries to do this all in one class!

There’s nothing wrong with trying to solve a lot of problems, but this is best done by building a set of cooperating classes. I think the DateTime ecosystem, for all of its faults (faults I’m mostly responsible for) really gets this right. The core DateTime library is all about representing and manipulating a single date/time. If you want parsing, special formats, sets, incomplete date/times, holidays, and more, then you can have it, but all of those features come from additional packages.

This “ecosystem” approach forces us to create real APIs and think about how different libraries can play nice together. It also helps us provided consistency across similar libraries. For example, all of the DateTime parsing libraries have basically the same core API, as do event libraries, alternate calendars, etc.

Building an ecosystem reduces the stuff you need to learn for any particular library. The DateTime docs are already pretty huge, but imagine if they also had to cover parsing, alternate calendars, holidays, and so on. It would be a true nightmare.

I think that nightmare is the state of form libraries today.

Enter my own form library, Chloro. This is actually my second attempt at writing Chloro. I scrapped the first because it was becoming exactly the kind of does-everything-in-one Frankenstein’s monster that I’m complaining about!

This time around, I was able to focus on the pieces I really cared about. Specifically I want a tool for taking user input, applying some validation, and getting the results in an easy to consume data structure. “Getting the results” glosses over a pretty big task. The result needs to indicate whether the submission was valid, and if it wasn’t valid I need all the validation errors that were found. If the result is valid, I want the data submitted by the user. Oh, and I want to do some munging of that data along the way.

I don’t care about rendering, mapping fields to a database, building forms from a database, or updating a database. (Actually, Chloro is designed so you can plug those sorts of things into it, but it won’t be part of the core.)

With Chloro, forms are defined as classes, and you won’t be surprised to see that it looks like a Moose class:

package MyApp::Form::Login;

use Moose;
use Chloro;

field username => (
    isa      => 'Str',
    required => 1,
);

field password => (
    isa      => 'Str',
    required => 1,
);

field remember => (
    isa     => 'Bool',
    default => 0,
);

You’ll also notice that the field’s type is defined as a Moose type. Remember, I don’t care about rendering, so I want to express field definitions in terms of the

back end. The back end doesn’t care if the input came from a select, a text box, or a file upload. It just wants a string (or positive integer, or an image file, or …). Fields can also define custom extractors (a birth_date field that builds itself from a year, month, and day input) and custom validators (end_date must be greater than start_date). With Chloro, form objects are essentially immutable. When you process user input, you get back a Chloro::ResultSet object. The form object itself is unaffected. Separating the form from the results is just a cleaner design, and avoids the “form object as god object” problem of many existing form libraries.

my $resultset = $form->process( params => $submitted_params );

if ( $resultset->is_valid() ) {
    # Log the user in
}
else {
    # Do something with errors
}
 Results can be associated with a field, and can also include overall form errors that span multiple fields (like "the two passwords must be the same"). 

# Errors that are not specific to just one field
my @form_errors = $resultset->form_errors();

# Errors keyed by specific field names
my %field_errors = $resultset->field_errors();

The Chloro::ResultSet object can give you back a simple hash reference of data, which you can use to insert or update some data in your database.

my $login = $resultset->results_as_hash();

Chloro also supports the idea of “repeatable groups”. For example, a contact might have multiple phone numbers. Each phone number consists of a type (cell, home, work), a number, and an optional note. We want to let the user submit 0-N phone numbers, each of which has the same fields. The client side piece is up to you, and you can use some sort Javascript to make this nice and pretty. On the server side, I want to say “give me all the phone numbers that were submitted”. I’m also working on allowing custom ResultSet roles which can add more structure to the returned data, beyond “give me a hash reference of all the submitted data”. This will allow a form to say that its resultset uses certain roles. These resultset roles can be defined on a per-app and per-form basis. I’ve started converting an existing application over to Chloro, and I’m pretty happy with it. It’s definitely not Satan. Maybe Chloro is Satan’s little sister Satana, but that’s an improvement in my eyes!