Webdurance - Getting Charities Online in 24 Hours

I recently took part in an event called webdurance. The aim was to get six charities online within 24 hours. The following is my write up of the experience…
Getting There and Setting Up
Thursday the 15th of July 9am, buzz goes the alarm, quick shower, large breaky, bag packed and on the bus into town by 10. A snippet of tourist like GPS navigating and 10 minutes later I strolled into the webdurance room in the INEX building at Newcastle University. After walking into the room it was great to finally put a picture to the set-up, somehow it’s always completely different to how you imagine it. Everyone was setting up shop with cables, laptops, and other crazy stuff like huge touch screen tables being thrown around like balloons at a kids party. It was a cracking atmosphere and you could just feel the excitement in the air.
The Pre-work Necessities
Once settled in we spent an hour or so on introductions and getting to know our team members. We had a quick photo and listened up to the schedule, making particular note about when the pizza, sandwiches and possibly most importantly (especially for Kat) the red bull deliveries were due. Next up was probably the funniest health and safety talk I’ve witnessed and a scary tweet from onion2k about the interesting materials nearby. I particularly enjoyed the radioactive sign on the way past the loos! There were also reports of the odd guy or two running around in hazmat suits. Anyway none of that could phase us as we had an important job to get on with.

Meeting The Charities
Each team met with their charity and spent some time talking through the requirements. At this point Danny and Kat in particular started to shine getting in instant grip of how Azure is structured, the details of the work they perform and where they do it. From then onwards we were talking with Ken Addison and Julie Embleton from Azure about the objectives, the audiences and some ideas for what would benefit them. Ryan and Kat were busy working on the design brief, Ash was talking through copy, Lee and I were noting functional requirements and Danny was kicking butt on the flip chart (Watch the video to see him in action) making notes on the entire lot. With the guys leaving behind a few nice chocolate treats and the promise of bacon rolls in 21 hours they left us to it with a clear idea of what we were building.
Go Team Five
Danny, Kat, Ashleigh, Ryan, Lee and I made up team 5. Due to the intensity after just 24 hours I’m sure we all felt like we’d know each other for years. The range of skills was quite incredible. Unfortunately Ash wasn’t feeling too good as the night draw in and was still recovering from illness through the week, but Paul King and Wayne Smith stepped in to help us out. That was the awesome thing about webdurance people were just pitching in wherever needed, I wouldn’t be surprised if all teams owe an extra thanks or two to someone outside their initial six members.
Throughout the hours our productivity went up and down like a yo-yo as expected, but we all managed to get our heads down and battle through when it really mattered. “Headphones On” soon became a signal to leave people alone as they’re in that special place “The Zone”. Time seemed to shift occasionally, one minute we had loads of it left, next we’re asking was that really yesterday with only 3 hours remaining!? The funny hourly updates and the giant count down timer aided in bringing us back into real time. Finally I have to mention the genius of “the list”, anything and everything got chucked on it and although it was forever growing and never written down it definitely helped us focus on getting things finished.
The End Product
After looking at something for 24 hours I’m convinced that you start to believe whatever you working on isn’t good enough. The feedback from the team, the charity and others, plus the reflection after a lengthy sleep or two has completely changed my mind. All six websites produced at webdurance are top class. It’s likely some sites like ours are a little rough around the edges, but that’s okay, they are built and usable. Like the other teams we’ve committed to pitch in and help the charities out in the future. I know our site will be undergoing a small review from the charity’s chief exec and once approved we’ll be putting it live. I’ll add the link once that’s done.
Wrapping Up
Once finished each team gave a five minute demo of their site, with the charity representatives present this was a great time to reflect on all the hard work everyone put in. It was great to see what the other teams had been busy working on up on the big screen. Once complete, some cleverly thought up awards were handed out to the well-earned winners, our team won a couple of prizes including twitterholic (Kat) and loudest person (Ryan). So we’ll be shooting it out at paint-ball and avoiding Ryan at all costs after his James Bond training session. The last part of the story was naturally a quick visit to the pub for the few that could conjure up enough energy. After a couple of pints and a few more giggles it was time to hit to road home.
I’m proud to have taken part in the first ever webdurance. The King Brothers and friends, the event’s sponsors, all the volunteers and everybody else involved helped make it one incredible experience. I will most definitely be signing up next year!
Single form / Multiple records / One model / Rails
It’s fairly easy now days to put together complex nested forms with that user friendly “add another” button, but acting on a single resource is something I haven’t had to tackle before.
In fact, without the parent resource around to accept the nested child attributes I was actually a little lost for a while. I was tempted to create a parent to sit the records under but that just feels wrong to me. I found a few code snippets around in some old forums but no end to end examples on how to do it. The excellent github project from Ryan Bates http://github.com/ryanb/complex-form-examples already contains more than enough code to get going so I’ve used that with some modifications to solve the problem.
I’m using formtastic (I like the error messaging) and jQuery (as it rocks) here. Because I don’t need to deal with editing multiple records I haven’t, although that shouldn’t be hard if you need to.
Place a new user object into an array so the view can act on @users as a collection
1 2 3 4 5 |
# users_controller.rb def new @users = [User.new] end |
Note I’m just using form_tag, it simply needs to post to the correct location. This will render one set of empty fields for that first new user. Outside the scope of the form I render the hidden div containing the template fields for any more users. This way I don’t need to worry about ignoring those empty fields later as they wont be posted. I wanted to offer a delete link but not on the first record. I thought it was wise to make sure they add at least one user if they’re clicking the “Create user(s)” button.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<!-- new.html.erb -->
<h1>Creating new users</h1>
<% form_tag users_path do %>
<% @users.each_with_index do |user, index| %>
<% semantic_fields_for "users[#{index}]", user do |f| %>
<%= render :partial => "new_user_fields", :locals => {:f => f, :offer_remove => index > 0} %>
<% end %>
<% end %>
<p><%= add_record_link "+ add another user", "User" %></p>
<%= submit_tag "Create User(s)" %> or <%= link_to "cancel", :back %>
<% end %>
<%= new_fields_template("User", :partial => "new_user_fields") %>
|
This is the partial that first gets rendered in the form, then via a helper to create the template div.
1 2 3 4 5 6 7 8 9 10 11 |
<!-- _new_user_fields.html.erb -->
<% offer_remove ||= false %>
<div class="new_fields">
<% f.inputs "New User#{' - ' + remove_record_link('Remove this user') if offer_remove}" do %>
<%= f.input :email %>
<%= f.input :first_name %>
<%= f.input :surname, :required => false %>
<%= f.input :telephone, :required => false %>
<% end %>
</div>
|
I changed the helper methods slightly so they know they are dealing with a single model not an association on a parent model. This basically renders a hidden div that is picked up and used via the jQuery when the users clicks ‘Add another user’
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# application_helper.rb def remove_record_link(link_text) link_to(link_text, "javascript:void(0)", :class => "remove_record") end def add_record_link(link_text, model) link_to(link_text, "javascript:void(0)", :class => "add_record", :"data-model" => model.downcase) end def new_fields_template(model, options = {}) options[:object] ||= Object.const_get(model).new lowercase_model_name = model.downcase options[:partial] ||= lowercase_model_name content_tag(:div, :id => "#{lowercase_model_name}_fields_template", :style => "display: none") do semantic_fields_for("#{lowercase_model_name.pluralize}[new-id-here]", options[:object]) do |f| render(:partial => options[:partial], :locals => {:f => f, :offer_remove => true}) end end end |
Finally once the user submits the form the create action will do its magic. Although this doesn’t sit 100% with me I’m happy enough it does the job intended, I wanted error messages to appear on all entries not just the first user object so I loop through all the users asking them if they’re valid. Can someone help improve this?
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# users_controller.rb def create @users = params[:users].values.collect { |user| current_organisation.users.new(user) } if @users.all?(&:valid?) @users.each(&:save!) redirect_to :action => 'index' else @users.each(&:valid?) # Call valid? on all objects to gain errors on all objects render :action => 'new' end end |
The last piece to the puzzle is the jQuery. Nothing new here except we can just do away with a lot of the code that we don’t need. In essence we grab the template div, replace the new-id-here with a unique id and inject it into the page as a new set of fields for a new user. The delete link simple removes the div out of the page, will need to change if you add an edit.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# application.js
$('form a.add_record').live('click', function() {
var assoc = $(this).attr('data-model'); // Name of model
var content = $('#' + assoc + '_fields_template').html(); // Fields template
// Make a unique ID for the new record
var regexp = new RegExp('new-id-here', 'g');
var new_id = new Date().getTime();
content = content.replace(regexp, new_id)
// inject the content into the page
$(this).parent().before(content);
return false;
});
$('form a.remove_record').live('click', function() {
$(this).closest('.new_fields').remove();
return false;
});
|
I hope this is helpful to someone else. Maybe if there is enough interest I’ll add the edit/update anyway.
Refinery CMS: Consider it if you are searching for a Ruby on Rails CMS
Refinery CMS is something we’ve recently stumbled across at work. I’m going to explain why we have taken to it like a duck to water.
In the main we build web applications, not websites. The problem is occasionally the former requires the latter. Using Ruby on Rails I have been able to work on a vast array of different, interesting, simple, complex you name it web applications; but there has always been this niggle that the CMS part is missing. There are lots of Rails CMS alternatives out there but we’ve never really been hooked by one for some reason or another. Rails being Rails means with a little time, custom CMS functionality has been chucked built into some projects, everyone knows you can write a blog in 15 minutes with rails, right!?
The problem with that approach is the re-invention of the wheel, plus that blog or pages engine written in 15 minutes doesn’t touch that stable, fully tested feature rich one a team of programmers have been working on for years.
What I love about Refinery CMS is that it’s really geared towards the end user, i.e. to add content like pages, news articles, images etc the client doesn’t need to be a programmer and certainly doesn’t need to learn any template language. For them the WYSIWYG editor is simple and offers plenty of power. Don’t get me wrong, you will need a developer to get everything up and running, unless your client is very technical minded. Once setup though it’s extremely easy for the user to take over. Depending on the client’s ability, understanding and your trust you can offer a fair bit of control over to what they can do, such as deleting that core page contact us or messing around with other settings.
As much as I love the end user I’ll be honest, how difficult my life becomes is pretty important too, after all time is money. This is where Refinery CMS wins hands down for me. In principle it’s just rails app. In fact it’s just a rails app with many engines as its core. The beauty of this is that you can do whatever you like to it with ease. The architecture allows you to add your own functionality in the root of the application or through additional plugins. There is even a simple plugin generator to make adding new ones a breeze.
Since working in Rails I’ve always wanted to get involved with an open source project but have honestly been a little worried I wouldn’t have much to offer. Refinery has helped me get over that fear, quite quickly in fact. The core team are very helpful but do rightfully ensure the project upholds their vision.
It’s not yet at its first release so things are changing and improving all the time, but it’s not hard to follow and upgrade. Tests are being added all the time which will improve the stability in the long run. The plugin list is growing, we’ve added our own, a simple way for handling testimonials, we’re also working on one for vacancies. Looking at the github network you can see others are helping with i18n and bringing it all up to rails 3.
Refinery continues to help us tackle some of our projects, it’s also improved my knowledge and finally got me contributing back to open source. If you’re looking for a Ruby on Rails based CMS, I would highly recommend you check it out!
Links
Refinery CMS Home Page
Refinery CMS GitHub repoistory
Transcendit Testimonials Plugin
The smartest, ideal, efficient programming can still look awful!
I always try my best to write extremely neat code; even if I fail. I’m a complete stickler for it. I think it’s because as a programmer one of things that frustrates me most is looking at messy code. Before I can even begin to start solving or understanding the logic involved I often spend time sorting out the indention. Whilst doing that I’m usually thinking “this should already be done, not many clients are particularly willing to pay for time spent on this”. The idea of re-factoring bad code is a difficult sell; we’ve found explaining the long time benefits and future time saving can help.
I think my C programming tutor back at uni grilled it into me, that the code just has to be neat and well organised, even if it doesn’t work initially. Thinking back it was probably just to make her life easier, seeing as she had to review it all. But hey the result it’s had on me is hopefully a good thing, helpful to me and others who look at my code.
Building Rails applications daily does tend to help with many conventions; most of the code I pick up has that going for it, although staying DRY, useful comments, good documentation, sensible variable names and consistent indentation especially are often slightly lacking.
Everybody is probably guilty of thinking I’ll just get this working first, then I’ll organise it afterwards. The problem I’ve found with that approach is it very rarely gets sorted, leaving your perfect solution looking a little wilted, confusing and quite simply messy. If like me you feel you could improve and would like to perfect the readability of your own code, I suggest you checkout the Top 15+ Best Practices for Writing Super Readable Code article posted this morning. It’s a great tutorial; just imagine the hours we could save ourselves in the long run…
Up, up, up into the clouds...
Finally it’s here, my blog has arrived! It’s been a busy few days getting things up and running. I’ve been transferring my domain to 123-reg, configuring DNS, finding an email provider, finalising the design, deploying to heroku and scrapping this first post together.
To get things up and running I’ve chosen to push everything up into the cloud. I’ve spent countless hours setting up servers in the past but to be honest, it’s really not where my passion lies. Heroku’s free plan suits my needs just fine for now and I must say I have been blown away at how easy those guys have made it to deploy rails apps, incredible!
I’ve opted for Google Apps to provide my email; the personal plan is free and easily provides me with what I need. Sending out emails will be a big requirement for the next project so I thought I’d get testing.
Anyways, here are a few ideas that spring to mind in terms of what I’m hoping to achieve with the site:
• Help other rails developers using examples from our development team’s experience.
• Hopefully improve my writing style. Simply by writing more.
• Keep the few people that care up to date with what’s going on in my life
Finally I’d like to thank the following, Lee Irving (informing about the management in 123-reg), David Wong (helping out with Google apps), David Elliott and Dave Kennedy for their expert DNS advice, Tom Tinsley for inspiring me to re-think my initial design (a backgroundlabs theme came to the rescue at the very last minute) and Leo Babauta with his book The Power of Less which inspired me to actually do something about my shockingly bad website that’s been hanging around.
I guess all that’s left to say is watch this space!