For the last few months I’ve become involved with Youth Tree – a local not-for-profit I’ve been slowly helping to develop sites for. One of my most recent tasks has to been generalise our development tasks to make it easier to introduce people to the codebase and our current direction.

The following I’m posting here partly for public feedback and partly because it’s the easiest way to host it. We encourage all to contribute to our YouthTree projects but if you’re interested, I suggest contacting me first (darcy.laycock@youthtree.org.au).

YouthTree Developer Overview

Organization Strategy

Currently, tools are documented typically in a relatively unorganized manner – Tim and I (Darcy) typically communicate over Skype to discuss featueres and we have google docs with lists of items. We use a very ghetto method of marking progress (red means awaiting work, green is done) and to be honest it makes it hard to keep track of what is going on.

The current (to be implemented in the very near future) plan is to move towards Pivotal Tracker. Each project (YouthTree, BigHelpMob and TEDxPerth) will have a pivotal project, we’ll have a project manager responsible for each one (their tasks primarily being checking / validating tasks, assigning items and following up progress).

Iterations will be typically two weeks long (given the fact it is primarily free time work) with points being based on the complexity of the task.

Code wise, everything will be open source (licensed under the MIT license) with an emphasis on write modular / plugin code. For example of this, see later sections.

Along with fortnightly iterations, I’d like some sort of stand up (via Skype / in person somehow) on a reasonably regular basis. This is something we’d need to talk about more in person, based on how much time each person has.

Standard Tools

For the sake of consistency, I like the notion of having the tools used across every project being the same / with a standard app base. At the moment / as of BigHelpMob, this stack is:

• Ruby on Rails 3.0 for app stack
• HAML for template
• SASS (w/ Compass) for stylesheets – v3 formatted.
• Coffeescript for Javascript
• MySQL (although I’m willing to change for relational databases)
• MongoDB for not relational databases (currently considering TEDxPerth)
• jQuery as standard
• Asset Packaging via Jammit

Also, applications should built on the following libraries for consistency sake:

• Shuriken for Javascript Namespaces
• bhm-admin for admin areas
• bhm-google-maps for Google Maps
• youthtree-js for standardised Javascript components.
• Barista for Coffeescript Compilation

I personally like the approach of using:

• Gems for ruby code
• Compass Plugins (via gems) for general CSS / SASS
• Barista Plugins for javascript (with namespace support in Shuriken)

The idea being we can basically build extendable, well designed software in a consistent manner. Anything non-app-specific in terms of JS for example would be placed in the youthtree-js package (e.g. a Flickr-based gallery) and would be namespaced – e.g. YouthTree.Gallery.Flickr with standard entry methods. This means it’s easy to write higher quality code.

I’m still undecided on test frameworks etc so I’d like to see what you guys like / would prefer.

General Guidelines

Ruby

This should be documented better, but typically:

• Controllers should be lightweight
• Gems whereever possible
• Seperate items (e.g. PasswordReset model in BigHelpMob) where possible using tools.
• Consistent code skills
• Testing is important (I don’t do enough)
• Namespaces are good (but harder in Rails Apps) – Libraries should be namespaced.
• Structured (e.g. in Rails, app/observers and app/mailers should be added and the like).

We may need to create something like beard for us in order to make this process simpler. Or, possibly, just a rails template?

For simplicity sake, bundler is to be used.

Coffeescript / Javascript

Files should either go in app/coffeescripts if app specific or in a barista plugin otherwise.

Namespaces are to be used with the naming convention: <Root>.<Group>.<CurrentIfNeeded>. See existing code for more details on this structure. To be honest, as long as it is consistent I’m happy. You should always be unobtrustive.

File name wise, we use underscored names. thus, there should be:

• <namespace>.js – e.g. bhm.js OR <ns>/<ns>.js – bhm/bhm.js
• <namespace>/<item>.js – e.g. youthtree/gallery.flickr.js.
• Libraries / non-app specific js should be compiled into vendor/<library> – with jquery plugins etc being grouped there.
• All items should be packaged accordingly with jammit.

CSS / SASS

The idea is that we should use sass (v3 syntax) with compass where possible. CSS3 is encouraged especially in situations where it degrades peacefully.

Stylesheets should be placed in app/stylesheets, using the general convention of:

• <project>.sass – compiles down to a single file for the whole site
• <project>-admin.sass – compiles down to a single file for the admin area
• <project>/_util.sass and the like – utilities, general shared stuff.
• <project>/public/<item>.sass – stuff for the front end of the site, partials.
• <project>/admin/<item>.sass – stuff for the admin area.

The notion being we create small, reusable parts. YouthTree general stuff will be included in a youthtree-sass or youthtree-base gem in the near future, to keep with the notion of compartmentalizing everything.

HAML

I usually write helpers for anything non-trivial; these should be extracted into a youthtree-base gem (possibly merging youthtree-js).

I plan to have a nicely formatted page available for each referencing the tools we have available for developers. This is a top priority.

Deployment

Currently everything (bare youthtree.org.au) is hosted on my server – I plan to rearrange this soon. The idea will be all developers have access to staging but only a few can deploy to production. I like the notion of possibly deploying stuff on heroku but we’d need to talk about that a bit more in the near future.

It’s also possibly worth approaching a few companies to see whether they’d be interested in sponsoring with products / hosting. Other than that, we may be able to get a vps.

Currently I deploy using a minimalist rake task + set of tools, but I’m tempted to move back to capistrano or to extract it to a yt-deploy gem which we can just drop in to any application.

Future Plans

So, there are a couple of things – both, how YouthTree as a whole would like to advance in regards to the web and stuff I think would be beneficial to us in the long run.

Facebook App

One of the things in the pipeline (with the aim being a launch very, very early next year – I’m talking NY’s day / early jan early).

I’m not 100% sure what this entails yet – but it is something to keep in mind. I’ll add detail as I have it.

YouthTree ID

Since we have a large, overlapping group of users one of the things I’d love to see added developed is a centralised account / sso service for people (youthtree id being a general name). In general, this would be the most basic social things:

• Authentication
• Basic roles
• Badges etc
• Profiles / Default information

The idea is we’d built it with Mongo (so we can add data as needed / freeform information about uses) and a nice, simple restful interface. We’d use oauth2 to interface with it and implement sso. all in all, we’d make it something super simple people could use. Along the same lines, we could basically replace rpx now with it (or use rpx now as an authentication method for it), meaning we could then manage persisted identities.

It’s a bit more complex than we may need but in my opinion it’s a good idea for something to have in the long run and makes our lives as developers a little bit easier once it is running.

For users, it also gives them a bit more of a general idea as to what is going on / makes it easier for us to implement badges on a more general scale.

Ideally this would be in the next 6 months to a year and more importantly it would be something anyone building modular apps could use.

Generalising Tools / Platforms

One of the things we’ve discussed and aim to work on is making the tools more general (e.g. instead of BHM being Perth specific, make it a platform for recruiting people to work on little help mobs). This is something that needs some thought and is a long term goal.