Seeking a volunteer for 3000 Acres (Melbourne, Australia)

As you might know, I’ve been working on 3000 Acres over the last few months. My time there is almost up and they’re looking for volunteers to continue developing the site. If anyone in the Melbourne area is interested in working with me on this, and then taking it over, please get in touch! It would be a great way to get involved in a tech project for sustainability/social good, and the 3000 Acres team are lovely people with a great vision. Feel free to drop me an email or ping me via whatever other means is convenient, and please help us get the word out.


3000 Acres connects people with vacant land to help them start community gardens. In 2013 3000 Acres was the winner of the VicHealth Seed Challenge, and is supported by VicHealth and The Australian Centre for Social Innnovation (TACSI) along with a range of partners from the sustainability, horticulture, and urban planning fields. We are in the process of incorporating as a non-profit.

Our website, which is the main way people interact with us, launched in February 2014. The site helps people map vacant lots, connect with other community members, and find community garden resources. Since our launch we have continued to improve and add features to our site.

So far, our web development has been done by one part-time developer. We are looking for another (or multiple) volunteer developers to help us continue to improve the site, and to help make our code ready to roll out to other cities.

We’re looking for someone with the following skills and experience:

  • Intermediate level Rails experience (or less Rails experience but strong backend web experience in general). You should be comfortable using an MVC framework, designing data structures, coding complex features, etc.
  • Comfort with CSS and Javascript (we mostly use Bootstrap 3.0 and Leaflet.js) and with light design work (eg. layout, icons)
  • Familiarity with agile software development, including iteration planning, test driven development, continuous integration, etc.
  • Strong communication skills: you’ll particularly use them for writing web copy, advising on information architecture, and project management.
  • You should be in Melbourne or able to travel regularly to Melbourne to meet with us. Phone, Skype, and screen sharing may also be used — our current developer is based in Ballarat.

We welcome applications from people of diverse backgrounds, and are flexible in our requirements; if you think you have skills that would work, even if they don’t match the above description exactly, please get in touch.

We envision this role being around 8 hours a week ongoing (somewhat flexible, and mostly from your own location). Initially you will work closely with our current developer, who can provide in-depth training/mentoring and documentation on our existing infrastructure and processes. Over the next 3 months you will become increasingly independent, after which time you will be expected to be able to create and maintain high-quality code without close technical supervision.

For more information you can check out:

If you’re interested in working with us, please drop Alex an email at skud@growstuff.org. No resume required — just let us know a bit about yourself, your experience, and why you want to work with us. If you can show us an example of some relevant work you’ve done in the past, that would be fantastic.

Testing PayPal Express with ActiveMerchant’s BogusGateway (and how to make it work)

If you’re writing a Rails app with PayPal Express checkout, and having trouble testing because ActiveMerchant’s BogusGateway doesn’t support PayPal-specific methods like setup_purchase, here’s a fix. I spent a while figuring this out the other day so I thought I’d note it here in case someone else is googling.

The problem

Presumably you are writing a Rails app, and are following the instructions in the RailsCast #146 Paypal Express Checkout, or something along those lines.

In your config/environments/test.rb you have:

config.after_initialize do
  ActiveMerchant::Billing::Base.mode = :test
  ::STANDARD_GATEWAY = ActiveMerchant::Billing::BogusGateway.new
  ::EXPRESS_GATEWAY = ActiveMerchant::Billing::BogusGateway.new
end

The BogusGateway just mocks the behaviour of a real payment gateway, so that you can run your tests without connecting to a real one — even in test mode. This means you can run your tests offline, for example.

So far so good. Then in your controller you have something like:

response = EXPRESS_GATEWAY.setup_purchase(order.total,
    :ip                => request.remote_ip,
    :return_url        => new_order_url,
    :cancel_return_url => products_url
  )

When you try to test the checkout method in your controller, however, you see an error message like:

undefined method `setup_purchase' for #

The problem is that ActiveMerchant::Billing::PayPalExpressGateway provides a number of methods that BogusGateway doesn’t duplicate. Why not? Well, apparently PayPal Express is a bit of an odd duck in the ActiveMerchant world, and mumble mumble no real reason.

The solution

There’s a pull request by sideshowcoder submitted to ActiveMerchant which creates a PayPalBogusGateway that does all the necessary PayPal-Express-specific things, but it got turned down as “not a common enough use case”. Personally I think that ActiveMerchant shouldn’t have shipped the Paypal Express functionality in an untestable form, but whatevs. You can use sideshowcoder’s fix in your own app, as follows.

First of all, in order to monkeypatch in this way, you’re going to have to take a copy of the gem and put it in your vendor/ directory. I did so following the instructions in this blog post, specifically:

  • Download the activemerchant gem from rubygems.org
  • gem unpack ~/activemerchant-1.33.0.gem --target vendor/gems
  • Repeat for the active_utils gem, which is also required.

Then in my Gemfile, I have:

gem 'activemerchant', '1.33.0',
  :path => 'vendor/gems/activemerchant-1.33.0',
  :require => 'active_merchant'
gem 'active_utils', '1.0.5',
  :path => 'vendor/gems/active_utils-1.0.5'

Finally, after running “bundle install” to make sure that all worked, I dropped paypal_bogus.rb into the appropriate place in my vendors/ directory.

Congratulations, you can now test your Rails app’s interaction with PayPal Express. Hopefully the googles will take note, and the next person searching for this won’t have to pound their head against it quite as hard as I did.

(Thanks also to Ben Bleything for some help on Twitter with the vendored gem part of this.)

Growing stuff (vegies, open source projects, communities…)

The other week I posted from GUADEC, saying I’d been inspired to start an open source project to build a gardening website.

If I posted, “I planted tomatoes in my garden in Melbourne on the 1st of November” and everyone else did likewise, we’d wind up with an extensive database of food plants, including things like heirloom varieties and where to source them from. We could also build a histogram of the distributions of planting times for every location. Eventually, we could build in tools for sharing your harvest with your local community, saying eg. “I have a tree full of lemons, does anyone want them?” or facilitating seed-sharing and other community gardening activities.

I couldn’t stop thinking about this over the next day or so, and I realised it’s something I really want. Really really want. I want a resource that’s like Ravelry, but with a focus on food gardening, especially the sustainable/organic/heirloom end of that scene. My perfect site would have a strong community committed to sustainability both in the green sense and in the sense of a successful online community. I’m also thinking of Dreamwidth as inspiration, especially with regard to its ethics and the way its developer community works. I’d definitely want this whole thing to be open source and community-built.

This project is now up and running, and has been active for about a month, so I thought it was about time to post an update.

What we have so far:

  • Github — this is where our source code lives, along with most of our project management. Take a look at our dev branch for active development, also our wiki (note: moving to self-hosted soon) and issue tracker, especially this iteration’s stories (see notes below on development process).
  • Mailing list — most of our interaction happens here, strongly recommended to join if you want to take part in the development of the site. We need technical and non-technical people, coders and gardeners. If you’re interested in having input into what Growstuff will be, you should probably be on this.
  • Dreamwidth community/project blog — Dreamwidth and its inclusive development community are inspirations for Growstuff, and many of our contributors already have accounts there. The Dreamwidth community operates, to some extent, as the project’s blog, and has an RSS feed you can follow if you don’t already use Dreamwidth. It’s low-traffic and often gets highlights and important points crossposted from the mailing list. Note that if you don’t have a DW account you can still comment anonymously or using OpenID.
  • IRC channel – realtime chat room for anyone interested in the project. If you are already familiar with IRC, it’s #growstuff on irc.freenode.net, otherwise see the linked page for more information on connecting.
  • Twitter — if you want to follow us for occasional updates on that platform.
  • Server hosting with a provider that uses 100% renewable energy — geothermal, actually, as they’re based in Iceland. This is part of our commitment to sustainability.
  • Placeholder website on growstuff.org — there’s nothing much there, but I link this so that if you want to tell people about it, it’s somewhere to send them.
  • License (AGPL3+) — Growstuff is free, open source software. Our license choice allows anyone to use or build on our work, but they must use the same license for what they do. Our data about crops, once we have the site up and running, will be under the roughly equivalent CC-BY-SA.
  • Community guidelines — we wanted to get this in place from the start so everyone would know the groundrules. These apply to all project-related forums.

Most importantly, we already have a team of people who are working on building this thing. I wanted to talk briefly about our development process, because I think it’s unusual. We’re using an agile development methodology called Extreme Programming. XP consists of a collection of practices including:

  • sustainable pace
  • constant involvement of the customer (in our case, gardeners)
  • simple design focused on present needs
  • pair programming
  • test-driven development
  • continuous integration
  • short release cycles

XP isn’t often used by remote teams or by open source projects, but we’re taking a shot at it because it’s such a good fit with our community’s goals. It’s been a bit rocky trying to get things going at first, but we are currently in our second iteration, and as I am travelling around Europe (currently in London) I’ve had the opportunity to meet and pair-program with a few of our developers on different tasks. It’s amazing how much more productive, and more fun, it’s been to work on stuff with other people, especially as we’re learning the development stack. This is my first “real” Rails project, though I’ve played with it before. If it weren’t for pair programming, I would have been spending a lot of time pounding my head on my keyboard in frustration as I tried to figure out how everything fits together. For other contributors, it’s their first open source project, or first time sysadmining, or first time writing unit tests, but since we have people who know all these things, we can use pair programming to help spread that knowledge around. For those who can’t pair face to face, we make sure that the two people assigned to each story can work together online, co-ordinating via email and/or using tools like tmux and voice chat to share their work.

Right now, we’d love to more people to join us. If you have Rails experience (and experience with all the related technologies, like RSpec and Capistrano and so on) that would be great, but we’ll also welcome inexperienced developers who are keen and want to learn, or non-developers who’d like to be involved by sharing their gardening knowledge and helping us understand what you’d want from a site like this.

If you’d like to help us build Growstuff.org, please join our mailing list.