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

Continuous Integration == Communication

Posted by Tue, 02 May 2006 15:24:00 GMT

1 comment Latest by Me Tue, 02 May 2006 23:19:16 GMT

Martin Fowler has updated his Continuous Integration article.

One of the points that I appreciated reading about in this article was that when you’re working in a team, the ability to keep consistent communication. This is vital to the success of the project, just like all forms of quality communication is important during the lifespan of a project.

“Continuous Integration is all about communication, so you want to ensure that everyone can easily see the state of the system and the changes that have been made to it.”

Another point reminded me of something I recently posted about1, which was that you should always keep your project releasable… at all times.

“To help make this work, anyone involved with a software project should be able to get the latest executable and be able to run it: for demonstrations, exploratory testing, or just to see what changed this week.

Test. Before. You. Commit.

Fowler also mentions Ruby on Rails in regards to automating deployment practices yourself. :-)

In any event, read the article.

1 Agile development begins within…

Agile development begins within... continued

Posted by Wed, 26 Apr 2006 23:15:00 GMT

1 comment Latest by RyanA Thu, 27 Apr 2006 02:03:16 GMT

“It is not the strongest of the species that will survive, or most intelligent. It is the one most adaptable to change.”

- Charles Darwin

Last week I posted, Agile development begins within…, which referenced some bullets from the book, Practices of an Agile Developer. Since then, I have taken a little more time to read a bit further in the book. With books like this, I tend to jump forward and backward, so ten leaps further might put me on page two. In any event, I found a few more things that I wanted to point out… and by all means, you should go buy the book.

In Chapter 3, the authors, Venkat Subramaniam and Andy Hunt, discuss some ways to feed your Agile developer brain.

side note: while typing this… a huge bee just snuck in through my office window… where was I…

  • Learn iteratively and incrementally. Set aside some time every day for catching up. It doesn’t have to be long, but it should be regular. Keep track of concepts you want to learn more about—just jot down a note when you hear some unfamiliar term or phrase. Then use your regularly scheduled time to investigate it further.

This is a very important aspect of being a developer in any environment. Otherwise, you’ll end up like that disgruntled guy who has been programming in the same language for 25 years and refuse to use tabs in a web browser. Trust me on this one. There are people like that… and it could be you!

The point that I liked within this is that you shouldn’t just wander off and figure out what it is that you’re not sure about. I believe many people have a tendency to immediately look up at their google search box in their browser and…well… google it.

Don’t! Schedule time to do it… otherwise you’ll end up learning about the Canadian farming industry. GTD it! ;-)

  • _Attend local user groups. _

This is a no-brainer. Find a local Ruby user group… and start going each month. Perhaps your local Ruby user group meets more than once a month. :-)

Disclaimer: I’ve missed the last few meetings at PDX.rb. Bad Robby. :-/

I wanted to post more… but have since decided that it’s probably time for you to just go and purchase the book for yourself. :-)

Agile development begins within...

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

4 comments Latest by Aaron Schaap Sun, 23 Apr 2006 03: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.

Keeping Prototypes is a Bad Idea

Posted by Sat, 11 Mar 2006 14:30:00 GMT

11 comments Latest by Perry Tue, 21 Mar 2006 01:30:46 GMT

In a recent article titled, Just Build It: HTML Prototyping and Agile Development on Digital Magazine, Garrett Dimon writes,

“You need to temporarily suspend any notions that prototyping is always throwaway work. If you approach it as throwaway work, it will be. However, if you approach it with the intention of keeping it, you can create modular code that can be reused.”

I disagree. :-)

I’m not a HTML web designer, but when building applications, a prototype should be looked at as a process in which you agree that what is built will and should be thrown away.


When you are in prototyping mode… you should be very aware of the fact that it is a prototype. This is your chance to take shortcuts, break the rules, get creative, and express your ideas on a piece of paper, in plain HTML, or perhaps you may even run ./script/generate scaffold to spit out some code that you know will not be used in a production application later on. The goal here is to figure out what direction you want to take the project and get the client to sign off on these ideas… not to build reusable and modular code. If you’re building a prototype with the goal of reusing it than it’s likely that you’re spending too much time doing it.

Just Toss It

While you might not physically toss your application into a nearby trash can, you should aknowledge and remove any attachments that you may have that suggest that the prototype was a waste of time because no reusable artifacts came out of it. It’s the ideas that are expressed here that make this time valuable. Perhaps you don’t need a prototype phase… this would mean that you know exactly what you are about to develop. If you go the route of prototyping and find it to return nothing useful… than imagine how you’d feel if you just started developing and determined that you really missed an important requirement a few weeks later.

“The physicist’s greatest tool is his wastebasket.”

- Albert Einstein

The shortcuts that you should have taken earlier have likely created too much technical debt in your code. A fresh start should be the next step. Prototyping is part of the development process but the moment you allow yourself to think that you should reuse some of the prototype in your application is when you begin to become too attached to the notion that your prototyping phase was a waste of time end energy. Go into the prototype phase knowing that reusable artifacts are not the goal of this phase. Throw it away. ;-)

“Every act of creation is first of all an act of destruction”

- Pablo Picasso

Keep The Lessons and Ideas

You don’t need to rm -rf the_prototype but you should be very honest with both yourself and your client that the prototype phase is a way to quickly express an idea or process in a both a technical (and often) visual manner.

Prototyping Generates Confidence

Clients have (many) ideas. I hate to be the one to break it to you, but it’s almost certain that they are not as confident in you as you would like to believe. Confidence evolves over time and should be nourished on a regular basis. Their ideas are important to them and they are paying you to be part of the execution of those ideas. If you even remotely sense that you are not confident in their ideas… tell them this. Prototype their ideas. It could save both you and your client a lot of time, money, and resources in the long run… especially if an idea proves to be too complicated to execute.

Ideally, this is when you both agree that this idea is a good idea and that you both understand how it will be executed. This is both a good and healthy process. :-)

Document your learnings, the changes presented by both your client and yourself, and then revisit your Use Cases.

What you are about to build is that much clearer now. This feeling of clarity is exactly why you created a prototype. Remind yourself of this.

Always Start Fresh

Now that the client and you have come to an agreement about what is to be developed… the next phase should begin.

rails the_real_app

...and remember… don’t be afraid to revisit prototyping again. If an idea is not clearly defined yet, whip up a new prototype and see what comes of it. Just keep it out of your code base…. and if it’s already happened… please Refactor. ;-)

Like I said… I am not a HTML person… reusing the colors, graphics, and html artificats that you worked on might be useful… but modular code shouldn’t fall out of a prototype.

However, prototyping is a good idea and I highly encourage it.

Prototyping can also be extremely fun!

Similar Post(s): Keeping the Code Organic, The bitter-sweet taste of agnostic database schemas

Rails development in 2006, part 2

Posted by Tue, 17 Jan 2006 15:15:00 GMT

Before I get too excited and make another cool announcement, I just want to say that I am really looking forward to 2006. This is going to be an amazing year.

Many people believe that there is going to be a significant spike in web development in the coming year and much of that is going to surround AJAX/Web2.0… and I can honestly say that this has been the case for the past several months here at PLANET ARGON. To prepare ourselves for the coming year, we have been working with some amazing developers… one of which is named, Jason Watkins, which we’ve just recently hired as our Lead Product Developer. He’s already proving to be a wonderful addition to our Core Team and I would expect that you’ll be hearing a lot more from him on his fairly new blog in the coming months. :-)

Welcome to the team Jason!

Jeremy comes to Portland

Posted by Mon, 14 Nov 2005 07:05:00 GMT

I announced almost two weeks ago that Jeremy Voorhis was taking the position as Lead Architect at PLANET ARGON.

He’s been here for a week and a day now… and it feels like we’ve worked together for quite a long time already. When he hasn’t been coding in Emacs and working with the awesome Ruby on Rails framework, we’ve been wandering the city…. and yes, he’s been Powells! He claims to like Portland. :-)

I took a picture of him yesterday when he was discussing a clients project that we’re currently refactoring. The project comes to us with an existing schema, codebase, and opinions.

We’ve been working on several of these types of projects together in the past few months… which prompted us to deciding to start our project, Refactoring Rails.

It’s been great working with him in person. He, like some of the other developers that we call upon for some projects, had been assisting us through IRC, IM, and BaseCamp... and being able to be in the same office together… has been very beneficial.

In any event… I thought it would be fun to post a picture of Jeremy. :-)

Stay tuned…

P.S. You can see a drawing that Allison created of Jeremy on the PLANET ARGON about page.

There is a rumor that his mother photoshoped the drawing and put his head on the body of SuperMan. I beg you all to convince him to post ig on his blog. ;-) to get some sleep.

Older posts: 1 ... 11 12 13