| def choose_last_radio_in_selector(selector) | |
| within(selector) do | |
| choose field_by_xpath('.//input[@type="radio"][last()]') | |
| end | |
| end |
| Scenario: Filter by controller | |
| Given I am on the initial page | |
| When I filter results for the "users" controller | |
| Then all entries in the summary list should be for the "users" controller |
| $(function() { | |
| $('#summaries tr').live('click', clearDetail).live('click', selectRow); | |
| $('form#search').submit(clearSummaries); | |
| function clearDetail(e) { | |
| $('#detail').empty(); | |
| } | |
| function clearSummaries(e) { |
A few weeks ago I decided I wanted to hire a personal trainer. The interaction did not go quite how I expected.
Me: So, I'm looking to get buff. I mean big changes. I want to turn heads when I take my shirt off. I've got a trip coming up in three months, so I need to start training as soon as possible.
Trainer: I can definitely help you with that!
You've heard this mantra before, right? Don't bog programmers down in process, just let them get stuff done. Back when I lived in the corporate IT world, we would joke that any problem could be solved with more process. Indeed, at the time it seemed that was management's solution to everything.
But what does this statement even mean? It's started to grate on me because it
I think I'm ready for a new kind of project planning tool. Tracker has served me well for a couple years, but what I'm finding lately is that it falls short on the most critical component of project planning: the discussion.
Every feature is a discussion. Every bug is a discussion. Every architectural decision is a discussion. Discussions are everything. To paraphrase Joe O'Brien from one of his recent talks, I've never seen a project fail due to technical reasons, it's always communication. But looking at a Tracker project doesn't
A lot can be said about talking face-to-face with someone versus writing back and forth. Voice inflexion, facial expressions, and hand gestures are just a few of the non-verbal cues that can never come across in writing. Actually, let me amend that: they can never have as much precision in writing. Given some lightweight markup, smilies, and pacing, some of this actually can come across in writing, but it's certainly a far cry from what we can communicate in person.
| --type-add=ruby=.haml,.rake,.rsel,.builder | |
| --type-add=html=.html.erb,.html.haml | |
| --type-add=js=.js.erb | |
| --type-add=css=.sass,.less,.scss | |
| --type-set=cucumber=.feature | |
| --type-set=coffeescript=.coffee | |
| --ignore-dir=coverage | |
| --ignore-dir=doc | |
| --ignore-dir=log |
I clearly remember my first day at EdgeCase, over four years ago. I was new to Ruby, Rails, Vim, Agile, and -- more than anything -- pair programming. It was one of the most painful working days of my career. I was convinced I'd made a terrible decision. I was completely overwhelmed, my confidence was shot, and I dreaded coming in on day two. Of course it got much better. Over time I gained experience and confidence with Ruby, Rails, and Vim. I got comfortable with the continually evolving agile project flow at EdgeCase. Obviously, I fell in love with EdgeCase and the team I was a part of. But I never got used to