Comments
CBQ
One of the best features of Ruby on Rails development is the “Rapid Feedback Loop” that allows developers to quickly make a change and see right away how that new feature, enhancement, (or bug fix) behaves and looks in real-time.
This Rapid Feedback Loop actually becomes even cooler when you loop in the client—the product owner requesting a new feature or enhancement. At Highgroove, we do outsourced development and feature additions for many different projects. We’re always looking for ways to enhance that feedback loop with our clients. Here are few tools for quickly enabling an even more rapid feedback loop, that we can’t live without….
Read more... 
Posted in Business Comments
CBQ
On the rails-business list, someone asked recently about Iteration Based Contracts.
“Iterations” in the software development world are a simple, yet powerful concept for developers and businesses. An Iteration is a pre-defined timeframe, usually 1 or 2 weeks, a pre-defined cost, and a general overview of the functionality and goals of an iteration (see also: Iterative and Incremental Development).
Some examples of Iterative development might have one goal:
- Develop a simple back-end server for an iPhone application that allows user registration, signup, and stores user profile information.
Or may include a package of goals, usually building on a previous iteration:
- Add a simple Software-as-a-Service payment processing system to user registration.
Most businesses looking for development really don’t care about the hourly rates when it really boils down to work (i.e., $20/hr for 5 hours of development for one developer or team == $100/hr for 1 hour of development for another developer or team). They really just want their product or service to work, and they would really like to know how much it will cost and how long it will take.
There is an old adage (backed up by some empirical evidence and real-world proof) that says:
“you can build software 1) on time, 2) on budget, and 3) on scope, but you can only pick two….”
This is not to say that no developer team could never do all three, but it’s actually a lot more manageable (and fun) for businesses and developers to fix “time” and “budget”, and alter the scope in Iteration based development.
You might be thinking that we’re still back in Square 1—i.e. aren’t those pesky developers just packaging up a set of hours and time—how will I know what will get developed in that time and for that cost? But, something very cool happens when you really embrace those constraints.
With an iteration, both parties are agreeing to a fixed amount of money and time, and the developers (and product owners) will develop as much functionality and business value within the Iteration. If development on an Iteration begins, and then the business owners suddenly have a fantastic new idea (which usually happens right after the first demo, once they have working software in their hands), they can simply ask the developers to make it happen. Similarly, if the developers think of a great way to simplify a process, leverage an existing plugin or library, or add (or remove) an additional feature, they can propose it without recourse. Both parties know how it affects the Iteration, and thus, the bottom line. There is no concept of the “change-order” and the rapid-feedback-loop created from iterating makes sure that what is being developed by the developers is exactly what the business owners want.
At Highgroove, we have a Master Services Agreement for Iteration Based Contracts, and without posting all the nitty gritty details, the meat of it revolves around the compensation and deliverables:
Compensation. Highgroove shall be compensated for Services at the rate of:
Development per Iteration (Ruby/Rails/JavaScript/HTML/CSS): $xxx
Deliverables are always outlined as attachments to the agreement, and are usually story-based (see BDD).
Iteration Based Contracts require quite a few more mechanisms to ensure that developers are not just packaging up X number of hours—there has to be agreed upon functionality and time-frames surrounding those deliverables within the Iteration(s).
We’ve found that our best clients are really seeking a proven process, and a team that can execute on that process: being transparent and delivering real business value at every step. Iteration Based Contracts are a great way to structure this relationship.
Posted in Open Source Comments
Matt Todd
Most database-backed applications, especially Ruby applications written in Rails do fine with a SQL Database, like MySQL. Adam Wiggins of Heroku does a great job explaining how SQL Databases are an Overapplied Solution. There are definitely a few cases we’ve seen where a NoSQL solution like Redis can really shine.
At Highgroove, we’ve got several projects utilizing the Redis key-value store. Here are a few reasons you might want to look into Redis:
1) ”Data is frequently written, infrequently read” – if you are making tons of writes and MySQL can’t keep up, Redis has been clocked at 110000 SETs (the INSERT equivalent) per second!
2) ”Data can be expired” – if you have data that can be expired on a regular basis, over time, or explicitly, like stats, logs, and session data, Redis can explicitly expire whole keys or quickly trim large lists of data in no time.
3) ”Data is a collection of COUNTs, or SUMs of other data.” – if you have ever written an UPDATE statement that adds +1 to a record, you probably know that it is quite expensive, and could possibly be wrong. Redis has built in support for incrementing and decrementing values, quickly.
We love SQL Databases, so you won’t see us abandoning them any time soon, but we enjoy adding tools like Redis to our toolbelt.
More Information on Redis:
Redis Project Page – http://code.google.com/p/redis/
Redis (wikipedia entry) – http://en.wikipedia.org/wiki/Redis_)
A Collection of Redis Use Cases – http://www.paperplanes.de/2010/2/16/a_collection_of_redis_use_cases.html
Posted in Scout, Ruby on Rails Comments
CBQ
Deploying Rails applications has definitely become easier with the use of tools like Capistrano and Phusion Passenger (a.k.a. mod_rails/mod_rack), but really keeping them serviceable, maintainable, and always humming along can require a bit of work.
Andre over at Scout has written a fantastic guide—a checklist, really for putting a Rails or Sinatra application in production and keeping it up in tip-top shape.
Read the Production Server Sysadmin Essentials or, as Andre likes to call it: “Sysadmin Eye for the Dev Guy”.
