Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Ruby on Rails training in London

Posted by Fri, 21 Apr 2006 19:07:00 GMT

As mentioned on the Ruby on Rails weblog earlier today, EastMedia is hosting a 3-Day Ruby and Ruby on Rails Training course in London. PLANET ARGON was invited to send one of our developers to London as one of the three instructors. We’re excited to announce that Jeremy Voorhis, Lead Architect at PLANET ARGON, will be joining David Black and Matt Pelletier in London as an instructor.

University of East London – Docklands Campus — May 5 – 7 — £1200.00 GBP

A three-day training course which offers a thorough introduction to Ruby and the Ruby on Rails web application framework. Organized by Smartlab/Volks Lab and EastMedia, this course will provide web developers, product managers and entrepeneurs with a solid foundation for understanding the concepts, tools, and real-world tips needed to build robust, scalable, full-featured web applications using Ruby on Rails.

For more information, see here.

Stay tuned for more fun announcements… :-)

Agile development begins within...

Posted by Fri, 21 Apr 2006 14:45:00 GMT

4 comments Latest by Aaron Schaap Sun, 23 Apr 2006 02:37:46 GMT

When I got back from Canada on Rails, I found myself looking at a review copy of Practices of an Agile Developer [1] sitting in our library. I haven’t had a chance to really dive into the book, but did take a few minutes to skim through a few sections that I found interesting.

Some bullets that I found useful.

  • Don’t fall for the quick hack. Invest the energy to keep code clean and out in the open.

There have been times where I have found myself taking the quicker-well, it seemed quicker at the time-approach to solving an immediate problem.

  • Keep your project releasable at all times. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice.

This is extremely important when there are several people working on one project. Developers have their own schedules and when we make a commitment to push new changes to a production environment, it’s important to be confident that all developers and designers involved in the project are following the same rule… test-before-you-commit. When this rule is followed, you aren’t concerned that if developer A needs to leave work early that the work that she checked in is tested. This allows us to push new changes to the production server at the end of each day if all tests are passing.

  • Develop in increments. Release your product with minimal, yet usable chunks of functionality. Within the development of each iteration, use an iterative cycle of one to four weeks or so.

This is something that PLANET ARGON has been practicing more and more. Our iteration cycle is limited to 2-3 weeks, no more (unless there is a good reason to). When we are able to look at a distinct set of deliverables, which take 2-3 weeks to plan, design, develop, test, demo, and deliver, we can build our cost estimates around the number of resources that we be necessary to achieve those well-defined deliverables. It might only take 2 developers and a designer part time for those 2-3 weeks and we can adjust our cost estimates accordingly.

  • Write code to be clear, not clever. Express your intentions clearly to the reader of the code. Unreadable code isn’t clever.

When Jeremy and I began working with each other last Fall… within a day of working around each others code… we decided to build a style guide for all of our code. This style guide has evolved over time… but the core principals remain. Keep your code… readable.

_“Remember your code is for a human first and a computer second.” _

- Martin Fowler, Refactoring

As I continue to review the book… I’ll post more thoughts. :-)

1 Practices of an Agile Developer, Venkat Subramaniam and Andy Hunt, The Pragmatic Programmers, 2006.