YouthTree Developer Introduction
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 (email@example.com).
YouthTree Developer Overview
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.
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.
- 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:
- bhm-admin for admin areas
- bhm-google-maps for Google Maps
- Barista for Coffeescript Compilation
I personally like the approach of using:
- Gems for ruby code
- Compass Plugins (via gems) for general CSS / SASS
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.
This should be documented better, but typically:
- Controllers should be lightweight
- Gems whereever possible
- Seperate items (e.g.
PasswordResetmodel 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.
Files should either go in
app/coffeescripts if app specific or in a barista
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:
- 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
<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.sassand 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-base gem in the near future, to
keep with the notion of compartmentalizing everything.
I usually write helpers for anything non-trivial; these should be extracted into
youthtree-base gem (possibly merging
I plan to have a nicely formatted page available for each referencing the tools we have available for developers. This is a top priority.
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.
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.
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.
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:
- 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.