These are just simple instructions, one way I found of doing things. There are other ways, which may be slightly easier. First step is RVM:
Next is Bundler. I'm doing this from the head of the master branch, is it contains recent bugfixes.
You should now have Bundler installed in the RVM environment. Finally, Rails. I'm doing this a slightly unusual way to bootstrap the Rails installation. I first create the rails appdir, and load it with a Gemfile. Then I use Bundler to install the gems. Finally, I back out of the app and use the rails command to generate over the app (telling it to use PostgreSQL as the database).
Watch out for the use of $GEM_HOME with the bundle command - the reason is explained on this GitHub issue
Finally, here is the Gemfile I used. It's an interim state between the one I have in my Merb app, and an ammendment of the one you get from the Rails app generator.
I have yet to get Cucumber, RSpec and Capybara working. The Cucumber & RSpec generators need updating and merging back into the main projects. I haven't looked at Capybara yet.
Sunday, 7 February 2010
Monday, 4 January 2010
GeekUp Sheffield 2 (June 2008): Encouraging Agile Discipline
These are the slides for the GeekUp Sheffield presentation on encouraging discipline in software teams, from October 2008. This is the first presentation I made, since the start of PatchSpace / my agile coaching career. Despite being so old, I still agree with what I said over 18 months ago.
The nature of the session was a huddle, so the slides are brief, and most of the value was in the discussion after.
This is a repost, as I will shortly be dropping the aviewfromafar.net blog, but this one is worth preserving.
The nature of the session was a huddle, so the slides are brief, and most of the value was in the discussion after.
This is a repost, as I will shortly be dropping the aviewfromafar.net blog, but this one is worth preserving.
NWRUG (Oct 2009) - Uses & Abuses of Mocks & Stubs
These are the slides for the NWRUG presentation on mocks, from July 2009.
Note that most of the slides were written in the middle of the night, and I didn't have much time to trim them down. And I didn't get to beta test them on a real live human being. So the presentation goes on a bit long, and some things look a bit strange without me there explaining them. I've corrected the slide that I noticed was spectacularly wrong (ie, the spec didn't even pass), but otherwise it's as presented.
Note that most of the slides were written in the middle of the night, and I didn't have much time to trim them down. And I didn't get to beta test them on a real live human being. So the presentation goes on a bit long, and some things look a bit strange without me there explaining them. I've corrected the slide that I noticed was spectacularly wrong (ie, the spec didn't even pass), but otherwise it's as presented.
Also my opinions on some things may have changed since, so consider this an archive...
This is a repost, as I will shortly be dropping the aviewfromafar.net blog, but this one is worth preserving.
GeekUp Sheffield 6 (October 2008): From Specification to Success
These are the slides for the GeekUp Sheffield presentation on developing software with user stories, from October 2008.
The structure of the huddle was like this:
The structure of the huddle was like this:
- Intro - 10 mins
- Audience writing stories - 10 mins
- Audience prioritising - 15 mins (after it overran)
- Break for coding - 45 mins (there was another talk here which gave me just enough time to code up the top-voted feature)
- Demo of Cucumber, Celerity, RSpec using the code from the break - 15 mins (for full details and links, grab the slides).
NWRUG (July 2009) darcs presentation
These are the slides for the NWRUG presentation on darcs, from July 2009.
This is a repost, as I will shortly be dropping the aviewfromafar.net blog, but this is worth preserving.
This is a repost, as I will shortly be dropping the aviewfromafar.net blog, but this is worth preserving.
NWRUG July 2009 - Darcs
View more presentations from PatchSpace Ltd.
Wednesday, 16 December 2009
The Mars Lander (without integration tests) in Ruby
At the Agile 2009 Conference in August, J B Rainsberger gave a talk called Integration Tests are a Scam, which you can see in video. The session is well worth watching. While it's long, and takes a while to get to the core issues, it's a very thorough analysis of the costs of slow test runs and (failed) attempts to enumerate all application behaviour from too high a level.
J.B. wrote an example of how focused tests can be used to detect integration issues in the blog post Surely we need integration tests for the Mars rover!. The example is worked through in pseudo-code. I find it hard to read extensive pieces of code, so I turned it into a coding exercise. Here is the pseudo-code translated into Ruby, with comments about the order of how it was built up (more interesting than replaying the SCM patches).
J.B.'s methodical approach to collaboration/contract tests is simple and powerful. The Mars Lander example makes a good concrete example. I highly recommend working through it in your language of choice; I learned a lot.
J.B.'s methodical approach to collaboration/contract tests is simple and powerful. The Mars Lander example makes a good concrete example. I highly recommend working through it in your language of choice; I learned a lot.
Tuesday, 15 December 2009
Customer Input and the Russian Doll of Software Development
While replying to a mailing list post, I realised I was doing a terrible job of articulating where I thought the value of communication from customers is in the software development cycle(s).
The start of the thread was "is it normal for customers to have no contact with developers?". I said this is a terrible thing, and customers should always be able to talk to developers. This is simplistic - so I refined it to saying that having a primary point of contact before the developers is not a bad thing. This is unclear - so I tried to refine it, and in the process decided it was time to dust off OmniGraffle.
As an initial attempt, ths model is that software development is a set of nested cycles, each of which involves specifying the problem in such a way you can test the solution, developing something to meet that specification, and refactoring to improve design and understanding.
I once worked with a guy who constantly sat down by and badgered developers when they were trying to work. Little of his input was useful, and much of it caused delay and multi-tasking. A good deal of it was blue sky daydreaming that probably had no benefit in the next 6 months, at least. It doesn't have to be this bad, but incoming communication that interrupts developer and is not part of a feedback loop is waste, in my experience.
The line is thicker between the inner-most development and the customer because my experience is that when developers have questions during the coding phase, it's often about unexpected costs stemming from technical limitations. These tradeoff conversations enable economic decisions about what is feasible, rather than a build-at-all-cost mentality (yet another issue of fixed-price contracts).
I'm making no claims that this is generally applicable, and counter-examples are welcome.
What is a Market Test?
Watch out - the following is more conjucture than fact. I am only now going through the first iteration of customer development, so my opinion in relation to Lean Startup matters should not be given much (if any) weight.
I coined the term Market Test because I couldn't think of anything better to represent the idea that what you fundamentally need is to specify something that will sell (or be used, if it's free/internal etc). An example of what I have in mind is an analytics system that monitors signup rate. It's analogous to the Customer Development Engineering on slide 23 of The Lean Startup slides (Eric Ries and Steve Blank). I nested it because I'm naturally uneasy about any segmentation or conflict (read "discordant" rather than "antagonistic") introduced into a development cycle. The idea that Customer Development Engineering is segmented from or in conflict with development may be a misinterpretation; it may be presented that way for visual impact.
But: A team that can't invalidate its own assumptions is lacking a core self-improvement skill.
How many cycles are there?
It has been pointed out to me that the cycles in this diagram are all fundamentally the same, and that each one falls out of the next. Exactly what needs to be done at each layer is a technicality. That means the diagram simplifies to this:
Comments welcome. Especially any that explain how I ended up at this conclusion simply by asking "where should customers provide input?".
The start of the thread was "is it normal for customers to have no contact with developers?". I said this is a terrible thing, and customers should always be able to talk to developers. This is simplistic - so I refined it to saying that having a primary point of contact before the developers is not a bad thing. This is unclear - so I tried to refine it, and in the process decided it was time to dust off OmniGraffle.
As an initial attempt, ths model is that software development is a set of nested cycles, each of which involves specifying the problem in such a way you can test the solution, developing something to meet that specification, and refactoring to improve design and understanding.
Now, a few unintended things spring out of this, but let's tackle the initial problem - where should customers provide input? My current position is that maximum value of customer input is during test case preparation, as identifying what problem to solve is almost always the hardest part of software. At the other stages, the focus is technical, and, with possible exceptions, customer input is of little value.
However, developer contact with the customer is of immense value, as the ability to clarify and mine for insight enables simplification of code and reduces rework.
The line is thicker between the inner-most development and the customer because my experience is that when developers have questions during the coding phase, it's often about unexpected costs stemming from technical limitations. These tradeoff conversations enable economic decisions about what is feasible, rather than a build-at-all-cost mentality (yet another issue of fixed-price contracts).
I'm making no claims that this is generally applicable, and counter-examples are welcome.
What is a Market Test?
Watch out - the following is more conjucture than fact. I am only now going through the first iteration of customer development, so my opinion in relation to Lean Startup matters should not be given much (if any) weight.
I coined the term Market Test because I couldn't think of anything better to represent the idea that what you fundamentally need is to specify something that will sell (or be used, if it's free/internal etc). An example of what I have in mind is an analytics system that monitors signup rate. It's analogous to the Customer Development Engineering on slide 23 of The Lean Startup slides (Eric Ries and Steve Blank). I nested it because I'm naturally uneasy about any segmentation or conflict (read "discordant" rather than "antagonistic") introduced into a development cycle. The idea that Customer Development Engineering is segmented from or in conflict with development may be a misinterpretation; it may be presented that way for visual impact.
But: A team that can't invalidate its own assumptions is lacking a core self-improvement skill.
How many cycles are there?
It has been pointed out to me that the cycles in this diagram are all fundamentally the same, and that each one falls out of the next. Exactly what needs to be done at each layer is a technicality. That means the diagram simplifies to this:
And let's put the customer inside the process FTW. This implies that all you need to develop valuable software is:
- someone capable of identifying/proposing a problem and proposing a solution
- an iterative development process that incorporates self-improvement
- a development team capable of apply this recursively to solve problems at all levels
Comments welcome. Especially any that explain how I ended up at this conclusion simply by asking "where should customers provide input?".
Subscribe to:
Posts (Atom)
