Eden Development Staff Notes

Rails alphabetical pagination

by: aimee

A common problem we often run into at eden is paginating a list of things alphabetically. I thought it was possible with will_paginate but apparently not, so yesterday we created our own simple solution, and today we rolled it into a plugin.

Here’s a little tutorial of how to use it.

So i have a nice simple view of Gowalla pins ordered by name. Please forgive the scaffolding! ;)

This page is quite long. Of course, we could use standard pagination to make it 10 per page or something, but it wouldn’t be very helpful if you were looking for a pin with a particular name. You’d have to click through the pages to find it. Wouldn’t it be neat to list a page for each letter?

Enter paginate_alphabetically!

Simply install it as a plugin:

rails plugin install http://github.com/edendevelopment/paginate_alphabetically.git

Enable pagination in the model:

class Pin < ActiveRecord::Base
  paginate_alphabetically :by => :name
end

Make the controller fetch the right pins:

 
class PinsController < ApplicationController
  def index
    @pins = Pin.alphabetical_group(params[:letter])
  end
end

Add pagination links in the view:

<ul class='pagination'>
  <strong>Jump to:</strong>
  <%- Pin.pagination_letters.each do |letter| -%>
    <li><%= link_to(letter, pins_path(:letter => letter)) %></li>
  <%- end -%>
</ul>

Perhaps a touch of CSS:

ul.pagination {
  list-style: none;
  color: lightgray;
  padding: 1em 0.5em;
}
 
ul.pagination strong {
  color: black;
}
 
ul.pagination li {
  display: inline;
  font-size: 1.1em;
}
 
ul.pagination li:before {
  content: '| ';
}

And here it is:

The cool thing is you can add this to any of your models, and paginate by any attribute you wish.

Tested with Rails 2.3.5 and Rails 3 release candidate.

Get it from github: http://github.com/edendevelopment/paginate_alphabetically
or RubyGems: http://rubygems.org/gems/paginate_alphabetically

Thanks to Tom, Enrique and tooky for their help making this.

Posted on: August 25th, 2010 by: aimee In Categories: gem, i use tags, not categories, pagination, rails | Comments Off

David Good in the Wandering Book

by: Enrique Comba Riepenhausen

It has been a while since David Good wrote his entry in The Wandering Book and I am the sole culprit of not sharing my ideas here on it. I have been caught up with many different things lately that prevented me from writing my thoughts about his entry down.

David Good's entry

David’s entry starts by giving us a glimpse of craftsmanship outside our craft, talking about Sauder, Maloof, O’Sullivan and Stickley, four remarkable furniture craftsmen. He uses these four woodworkers to explain that Software Craftsmanship is not about the companies that adhere to it, but about the individuals who craft.

I think that in a way he is right. Our customers remember our names, the people who crafted their products and the relationship we have build with them over time. Our company is just the frame in which excellent people come to work together as a team to reach this goal.

Further into his entry David asserts that craftsmen are passionate about what they do and try to find ways to improve their techniques and toolset. Many people do so (maybe not as many as they should), but, as he explains further a craftsman makes sure he passes his knowledge on to his apprentices, enabling therefore the evolution of our craft.

I do agree with this statement. A craftsman is not only trying to improve himself and his craft, he also shares his knowledge and passes it on to other aspiring craftsmen willing to learn and move the craft forward.

Are you sharing what you learn? Are you seeking the advice from people who know more than you?

Posted on: August 22nd, 2010 by: Enrique Comba Riepenhausen In Categories: NexWerk, Software Craftsmanship, apprenticeship, community, craftsmanship, manifesto, the wandering book | Comments Off

What’s a pomodoro?

by: aimee

At eden, we often use the Pomodoro Technique™ to manage our time effectively. What exactly is a pomodoro? You could find out on the Dizionario di Italiano but i’ll give you a clue: it’s a tomato.

A tomato?! How does a tomato help us manage time and increase our productivity? Well when we talk about pomodoros, we’re actually talking about a 25-minute block of time followed by a 5-minute break to reflect and assess how we’re doing and what we will do in the next 25 minutes. After four of these we take a longer break. If we’re really serious about the technique, we aim to do 12 pomodoros in a day.

This is the Pomodoro Technique created by Francesco Cirillo in 1992. It is called Pomodoro because Francesco used one of those kitchen timers shaped like a tomato.

These are the five simple steps of the Pomodoro Technique:

Choose a task to be accomplished
Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
Work on the task until the Pomodoro rings, then put a check on your sheet of paper
Take a short break (5 minutes is OK)
Every 4 Pomodoros take a longer break

We don’t actually use a kitchen timer (though i think it would be cool to have some!) but we use software tools instead. We use Apple’s Pomodoro timer which has Growl integration and keeps track of tasks and interruptions. When pairing remotely we use http://tomatoi.st/ which enables both people to see the time as it counts down.

At eden, pomodoro time is highly respected in terms of not interrupting unless it is really urgent. It’s very easy to say, “We’re on a pomodoro” and people know that you’ll talk to them in your next break.

We find that the Pomodoro Technique increases our focus, keeps us on track with what we’re doing, and keeps us in control of our time, rather than time controlling us. For ideas and resources, visit PomodoroTechnique.com.

Posted on: August 20th, 2010 by: aimee In Categories: i use tags, not categories, pair programming, pomodoro, time management | Comments Off

Reactive Data Integrity

by: Xavier Shay

This is a guest post by Xavier Shay, who is running a course about using your database to write rock solid applications at Eden Development on the 22nd September.

The common tools used to ensure data integrity, such as not null constraints and foreign keys, are not always available to us. They may be too expensive to retrofit on to an existing application (for example, foreign keys tend to break test suites with lots of fixtures and mocking), or the data store may not provide them, such as is the case with most NoSQL databases. In these cases, another technique is required to give confidence in the integrity of the data.

Database constraints are proactive. They prevent invalid data from ever reaching the database and are the strongest method to ensure integrity, but as noted they are not always available. In this case, reactive techniques can be used. You may not be able to prevent invalid data from entering the data store, but at least you can detect when it happens promptly, rather than three months down the track when it starts causing errors.

One of the simplest ways to implement reactive checks in Rails is by creating a test suite that runs against your production data. Aside from a bit of setup to give the environment access to the data — either load up a production dump or point it at a read-only slave — it is quite a basic concept.

# For whatever reason this relationship doesn't have a foreign key constraint
test 'all tractors should have an owner' do
  sql = <<-EOS
    SELECT tractors.id
    FROM tractors
    LEFT JOIN owners ON owner_id = owners.id
    WHERE owners.id IS NULL
  EOS
  orphans = ActiveRecord::Base.connection.execute(sql).map {|x| x['id'] }
  assert orphans.empty?, "Tractors do not have owners: #{orphans.join(', ')}"
end

That’s really it! Told you it was basic. Some things to keep in mind:

Keep these tests separate from your main suite in a new folder.
Use SQL (or a native data store query) where possible rather than iterating using ActiveRecord. It is far more efficient especially when there are a large number of records.
Ensure the error message helps you fix the error. “Orphans was not empty” is not helpful, “Tractor orphans: 3, 6″ is.

Reactive integrity checks are another tool that can be used to increase confidence in your production data. You should use proactive checks where possible, since they are much stronger and more efficient, but reactive checks can reach areas proactive ones cannot cover and can be far cheaper to implement, especially on existing projects.

Register for “Your Database Is Your Friend” training at Eden Development on 22nd September. It covers this sort of thing and much more, including design and concurrency issues. See www.dbisyourfriend.com for more detail.

Posted on: August 19th, 2010 by: Xavier Shay In Categories: Uncategorized, data integrity, database, database constraints, dbisyourfriend, rails, ruby, xaviershay | Comments Off

Using Cucumber to test concurrency issues

by: aimee

Recently i encountered a concurrency problem of the type where there is a queue of things to do, and users press a button to be automatically assigned the next item in the queue. The bug report was that two users could get assigned the same item.

My pair programmer and i tried to reproduce the problem using two computers, but we couldn’t. We were only running one Rails instance, but we know that in the production environment there are multiple load-balanced servers pointing to one database, so we had an inkling that we’d be able to produce it using multi-threading.

To give it a test, we wrote a Rake task which we ran in two terminal windows to mimic the simultaneous access. The Rake task looked something like this:

require File.join(File.dirname(__FILE__), '..', '..', 'config', 'environment.rb')
namespace :test do
  task :take_next_for, :login do |t, args|
    user = User.find_by_login(args[:login])
    user.take_next_item
    puts user.item.inspect
  end
end

This is easily called by running:

rake test:take_next_for['ann']

We ran it for two users simultaneously and inspected the output. Sure enough they were being assigned the same item.

Since there is only one database, we knew that we could fix it with a carefully placed transaction and lock on the database. But we wanted to add a Cucumber feature so that we could be sure it was working, and to give us confidence that the bug would not come back again in the future.

  Scenario: Two users take next item simultaneously
    Given a user with login "ann"
    And a user with login "bob"
    And an available item called "Item 1"
    And an available item called "Item 2"
    When two users attempt to take the next item at the same time
    Then they should each have taken different items

Notice we can’t actually say who gets which item – it’s a race condition. We can only check that both of them have an item and that they are not the same item. We could alternatively check that both of the items have successfully been taken.

Testing this concurrency issue in Cucumber turned out to be somewhat tricky. We tried using simple Ruby threads in Cucumber, but it wasn’t properly simultaneously. I guess the single Cucumber environment still only does one thing at a time. So it was back to the Rake task.

When /^two users attempt to take the next item at the same time$/ do
  t1 = Thread.new { `RAILS_ENV=cucumber rake test:take_next_for['ann']` }
  t2 = Thread.new { `RAILS_ENV=cucumber rake test:take_next_for['bob']` }
  t1.join
  t2.join
end

We ‘join’ the two threads to make sure they’ve both finished before carrying on.

It’s slow because it loads up a whole new Rails environment for each of the Rake tasks, but that is exactly what we want to do, to mimic the concurrency of the production system.

The next problem we encountered was that Cucumber scenarios are run inside a transaction which means that a Rake task running outside of it cannot see the users and items we just created. So we had to tag the scenario as @no-txn so that they would be available externally and @clean-up-afterwards so that we could remove them from the database.

After "@clean-up-afterwards" do
  User.destroy_all
  Item.destroy_all
end

With this in place the Cucumber scenario failed as we hoped it would! Then it was simply a matter of creating a transaction from the moment we find the next item (with a database lock) until we have successfully assigned the item. This is a simplified version of what we ended up with:

class User < ActiveRecord::Base
  has_one :item
 
  def take_next_item
    transaction do
      item = Item.available.by_priority.find(:first, :lock => true)
      self.item = item
    end
  end
 
end

The Cucumber scenario passed and the problem was solved. In the live system, if two users now try to take an item at the same time, one of them has to wait a moment until the database has finished assigning to the first user so that it can assign a different item to the second user.

How would you have tested a concurrency issue like this? Are there better ways of imitating a multi-server production environment than the solution we came up with?

Posted on: August 12th, 2010 by: aimee In Categories: concurrency, cucumber, i use tags, not categories, pair programming, tdd | Comments Off

My Polyphasic Sleep Experiment

by: Chris Parsons

I've always been one to try new things, and screwing with my sleep patterns to attempt to cram more into my day seemed like a fun thing to try :) I had a go at it a few weeks back, and wanted to share my experience.

Polyphasic sleep is something that caught my eye a year ago, when I heard about the idea from Nathaniel Talbott at Bizconf last year. The idea is that you take a much shorter night’s sleep (perhaps 3-5 hours) and make up for it with 20 minute naps spaced out during the day. There are some fixed schedules that have been shown to work, but the basic rule is that the shorter your nightly (or “core”) sleep, the more naps you need and the more fixed your nap schedule has to be during the day.

The idea of getting loads more time in my day really appealed, so I finally decided to give it a go after I saw Micah Martin was trying it too.

My experience

I went for a 3 hour core sleep from 10:30pm to 1:00am, with 3 naps spaced out during the day: one at 6 - 6:20am, one at 12:10pm - 12:30pm, and one at 5:10pm - 5:30pm. The idea was that I could get my first nap in before my kids awoke at 7am, and then nap once at lunchtime, and once just before I came home.

Full of anticipation of hours of extra time, I went to bed on Sunday night at 10:30pm, setting my alarm for 1am.

Sure enough, the alarm went off and I dragged myself out of bed. I felt euphoric at the thought of having all this time, and my 750 words for the day proudly exclaimed the virtues of this sort of living. (I’m afraid I’m a serial kool-aid drinker. I took my naps at normal times, and it all worked wonderfully. My naps weren’t wonderful: we have a very open office and I couldn’t easily find a good place to sleep for 20 minutes. I felt a little tired, but not too bad to be honest. That is, until 10:30pm where I promptly crashed. The fact that my baby daughter was asleep by then was great (later I found that this was a happy coincidence :). I slept very deeply until 1am the following day.

Tuesday to Friday I felt much more tired, and found that I really needed my naps at the appointed time. It was like my body began to shut down at around midday and I knew I needed to go and sleep. The nights were much worse though. It was a real struggle to keep my eyes open between 1:00am and 6:00am after only three hours core sleep. I managed it though, and only had one short oversleep.

Why I stopped

The real problem, the one that ultimately caused me to abort after a week, was not the tiredness. I think that I could have gone on and persevered throught that. The problem was scheduling the naps, the life adjustment and the flexibility.

Whilst you’re adapting, it’s really important not to deviate from your set nap schedule, yet I have three kids and a busy work schedule. Often this causes me to be out on trips at the weekend, and in London meeting clients midweek. I was looking at my diary a week ahead and thinking: “How on earth am I going to survive Wednesday? And Saturday? Oh, and Sunday?”

If I skipped a nap whilst adjusting, it would effectively had set me back several days in the adaptation process, and with my schedule I couldn’t guarantee that I’d ever finish adapting. Some sleep deprivation is acceptable during adaptation, but go on for too long and it begins to affect your health.

Another difficulty: it was great to be awake in the middle of the night, the same time as my three-week old girl, and my wife got a good deal more sleep than she would have done normally. However it was difficult at 10:30pm: I simply had to be asleep at that time for it to work, and often the baby still needed settling around them. My wife was pretty good about this, but she was tired too, and it felt like I wasn’t doing her any favours. I was basically getting more time for me, at the expense of being flexible for the family during the day/evening. As long as it didn’t affect them much it was fine, but after a certain point I’m just being selfish.

So, for multiple different reasons, I decided to call time on the experiment after about five days.

It’s important to stress that people who successfully implement a polyphasic sleep schedule persevere longer than I did, and have more success scheduling their naps. If I worked from home, with less commitments and meetings during the day, I can see how I might have been able to make it work. Ultimately, my life just isn’t fundamentally set up for this sleep pattern, and to a certain extent that’s reflected in society. It would have been difficult to find a place to crash for 20 minutes in central London, and it’s not something I could easily have explained to people.

What did I learn?

I got much better at napping. I’m able to fall asleep more easily now, for short periods, when I need to.

I learnt that our society isn’t set up for daytime naps. This might improve in the future if it catches on, who knows?

Your cognitive performance is super impaired when your brain thinks you should be sleeping. This sounds obvious :) but I didn’t think of it before starting: I was expecting to have lots of tasks done, but looking through my list at 3am when I was super tired only elicted perhaps one or two things I could manage. A lot of my work requires a fair amount of concentration, and I just couldn’t manage it.

This would hopefully have ceased to be a problem after a couple of weeks when I’d have stopped feeling so tired, but it also threw up another problem, and the biggest lesson I learnt: many of the old tasks on your list aren’t incomplete through lack of time, but through lack of motivation. If you remove lack of time from the equation, you start to see what you’ve been procrastinating about because you really just don’t want to do it. That was a challenge, and led me to think deeper about some of the things on my list that I’ve been putting on.

Would I try it again?

Perhaps. I think the life circumstances would need to be right, and the need for that extra time would need to be extreme. I don’t regret the experience though, and I’m grateful for the lessons learnt.

That was my story: what’s yours? Have you tried and succeeded, or failed? Any tips to share?

Posted on: July 29th, 2010 by: Chris Parsons In Categories: life, productivity, sleep | Comments Off

Card Of The Day: Actually Do Retrospective Actions

by: Chris Parsons

Current cards of the day at eden

Our current Card Of The Day board at Eden

Retrospectives are something we’ve been doing regularly for quite a while at Eden, but we’ve hit a problem. It’s very easy to come up with a great list of actionable items, and then very easy never to look at them again. Don’t tell me you’ve never done this :)

We’ve started doing something slightly different at Eden to try and stop this happening: we’re using a method we’ve called Card Of The Day.

When the retrospective is finished, we take all of the cards with SMART action goals and put them on our company kanban board to ensure they’re done. Then we take all the cards that are a little more hazy (the sort of cards that say: “Be better at X”), we pin them up on the wall, and every morning after standup we read one out at random to the team.

Normally this has a “ahh, yes” effect on the team. Sometimes it generates a conversation, sometimes an action we hadn’t thought of yet and something else to go on the Backlog. There’s always something that comes out of it.

It’s not a perfect method, but it’s working better than the alternative: feeling guilty at the beginning of the next retrospective about all the terribly important things we haven’t done.

Have you tried something similar? Or do you have an alternative way to remember to do retrospective actions?

Posted on: July 22nd, 2010 by: Chris Parsons In Categories: agile, index cards, process, retrospectives | Comments Off

Agile UX and Design – What’s in it for me?

by: Spencer Turner

A friend nudged me on twitter to write a blog post about this, which was great for two reasons, firstly I was having a bad case of writers block (or at least procrastination), lots of things had made me nearly write a blog post, but not quite catalysed. (UX of Riverford’s new store, Should you try and make your copy SMART? etc.) Secondly, we are going to a UX retreat this weekend, and I think this might be a topic I want to discuss there, so thank you James for the timely inspiration.

Creatives and agile – The smell of fear…

When I first started at Eden; in the designer part of my role, faced with an agile developer asking me to commit to short iterations, my gut instinct was panic. Not because I felt incapable, but because creativity isn’t something you always have, or can turn on, on demand. This was of course not the right reaction, or even justified. It was however, I suspect what most ‘creatives’ feel when faced for the first time with seemingly short iterations.

Reality Check

It’s true, creativity waxes and wanes, but we cope with this all the time.

What are the tricks we use to do this?

Limiting the fidelity that we work at (In the traditional design world, Marker visuals, Lorem ispum, Photoshop comps, low-res thumbnails of photos)
Trying our ideas out as quickly as possibly and discarding LOTS of bad ones. You still scribble stuff, right?
Slowly refining and enhancing ideas and designs (thumbnails, to mockups, to proofs etc.)
Working with a team to get things done quicker
Only presenting part of the solution (e.g. We need the Brochure first, lets start there)
Getting feedback from the client and refining at each stage.
Building some extra time into the deadline to make sure there is ‘wriggle room’

Hmmm - Maybe it’s not so bad… Breathe.

You are already doing it!

Limiting fidelity, Agile Story Cards are a lo-fi method of capturing the idea of a piece of functionality.
Slow refinement - well that’s iterative development
Working with a team - You are part of the team (and maybe have your own team as well - double win!)
Only present part of the solution - Work on a small chunk of functionality at a time
Getting feedback early - Weekly (or even daily or less) releases mean constant feedback.
Wriggle room - You should be in the planning meeting and state if you can do it in time.

But What’s in it for me?

Shorter time-frames add focus. Given longer, I won’t actually get more done, I’ll procrastinate until I have a looming deadline, then find focus.
You’ll have happy customers At the end of the day, we all want to deliver things customers are happy with. The problem is that at the beginning of most projects, the customers think they know what that is (and don’t) and you think you undertsnd what they want (and don’t). If you do Agile design right, you can combat this by really establishing what the needs are and then delivering a solution to the real problem.
Built in Fail. Sounds odd, I know, but it is liberating to acknowledge that you don’t have a crystal ball, and it’s not reasonable to expect to entirely acurately understand every problem and therfore, it’s impossible to provide a correct solution first time, every time.
When you do get to see the whole, you have something real to design If you’ve iterated on your project, and kept the design (skinning) to a minimum, you can at the last responsible moment, start doing PSDs with the benefit of a working prototype which removes the ‘we’ll probably need a twitter widget here’ page filling that creating PSDs often induces.

What techniques can I use.

This is a blog-post (or series) in itself. However, we’ve been trying out Story Mapping, and Sketchboarding, both of which we’ve found pretty helpful.

My main tips are:

Pens and paper Scribble your ideas, perfect drawing is not required (anyone can draw a box!) and use it as a tool to facilitate conversation about your ideas.
Conversation You need to talk. To your client, to thier stakeholders, to your team, to your developers and ideally along the line, you should talk to users (a lot).
Avoid Photoshop early on We’ve found that photoshop gives a false impression of a finished solution. Unless your stakeholders need Photoshop visuals to get buy in, we say avoid them. Try and steer them towards wireframing. If they need them for buy-in (which many do) be very clear that they are an indication of what could be. Nothing more.

Caveat lector

No amount of Agile allows you to not have to think. You still need an overview of the whole project in the back of your mind, when you are working on a small piece.

You’ll have to have an understanding not just of the problem, but of the solution, the technologies, the implications of decisions on the team and budget.

You will have to push back against developers and customers from time to time. That’s OK. Defend the things you genuinely feel are required.

You are part of the team

Agile is all about collaboration. You need to be one of the team. Seriously, the siloing of creative vs. technical is just rubbish. Developers are unlikely to have your skills and vice versa. You will learn and teach a lot (as will they). Share your skills liberally, and everyone will benefit.

I think there is a whole post in how you get ‘on the team’ and as it’s late and this is already a long post, I’ll come back to that another time.

Posted on: July 20th, 2010 by: Spencer Turner In Categories: design, eden, ui, ux | Comments Off

Learn to Type – Day 4

by: aimee

I had a day off work today, so i’ve only just come to do my 5-minute test just now. 88wpm, hands covered, not so good as yesterday, but i am really tired at the end of a lovely exciting day.

I think i’ll go do a few powertyping exercises, followed by a few rounds of typeracer. In the meantime, enjoy this video that Enrique made: it’s me and Tom playing typeracer yesterday lunchtime!

Type Racers from Enrique Comba Riepenhausen

I scored 102 words per minute, at 100% accuracy!!

Posted on: July 15th, 2010 by: aimee In Categories: i use tags, not categories, learn to type week, practice | Comments Off

Sixth Day at Eden

by: Tom Crayford

(This post is part of a series documenting my apprenticeship at Eden. For more, visit the archives)

Yesterday was very fun. I worked with aimee on a client project, getting Jasmine working so we could test some javascript that we wanted to refactor. To test that we had to break up the code quite a bit, and then mock out things that touch the DOM. This is mostly because we couldn’t work out getting fixtures generated for jasmine, so maybe we’ll work on that today.

On another note, my typing (seeing as I’m participating in #learn2typewk) seems to be getting worse. However, I’m somewhat aware of my problem areas now (pretty much anything not on the home row), so I know what to work on. I’ve also started a Trickle ListODO: Link here) for keeping track of my typing practice.

Posted on: July 15th, 2010 by: Tom Crayford In Categories: Uncategorized | Comments Off

Eden Development Blogs

This is an aggregated feed of the blogs of people working at Eden Development.

If you are looking for the main company blog, click here.
Search for:
Contributors
Categories