Agile Methods

Design Patterns - A Singleton in Ruby

Rusty Divine recently posted a look at the Singleton design pattern, with some Java and C# based examples.

I wanted to show that same pattern using Ruby:

Interview: Mike Ho of QCodo

This is the second in a series of interviews we're making available to the CodeSnipers community. We have been working to track down people who we thought had something valuable to say about the software development community, tools, practices, or direction. Some of the names you will recognize immediately, others you've probably never heard of, but all of them have made an impact in one way or another. Without further delay... we have Mike Ho the lead developer of Qcodo.

Qcodo had its debut at the Zend/PHP Conference in October and few in our community were there. Can you tell us about how Qcodo came about and what it does?

Well at the risk of sounding like “yet another PHP framework”, Qcodo is in fact a PHP development framework.

It is focused on allowing development teams create good, solid prototypes in a ridiculously short amount of time, and for giving developers a toolset to mature these prototypes into full-fledge enterprise-level applications.

At its core, Qcodo is broken down into two main parts: the Code Generator and Qforms. The Code Generator focuses on analyzing your database to create basic Create, Restore, Update and Delete (CRUD) functionality. Qforms is an object-oriented stateful, event-driven architecture to handle web page and HTML forms processing, similar to .NET or Java Struts. Both obviously work with each other seamlessly. But you could definitely choose to just use one or just the other.

The entire framework originally started out over 4 years ago as just a simple but robust Microsoft SQL Server and ASP code generator while I was working as an independent contractor. Since then, it has been rearchitected and greatly improved upon throughout the years, first being ported to ASP.NET. Over a year ago it was redesigned specifically for PHP 5 and has been made into a full-fledged development framework for use with the many projects I have been fortunate enough to work on. Throughout Qcodo’s life it has been used on a wide variety of projects on all these platforms, from small startups to Fortune 500 companies like Covad and Lockheed Martin and large government agencies like Chicago Public Schools and NASA.

Earlier this year, I was fortunate enough to be invited to speak at the MySQL User’s Conference, where I talked about the code generator, specifically, and how code generation techniques could be used to greatly accelerate enterprise application development. The feedback was so overwhelming, not only for the technique, but for the code generator itself, that I realized that the market has a huge need for not just the code generator, but an entire framework like Qcodo to be open sourced. So I spent the next couple of months cleaning up the code and ensuring that it was clear of any proprietary or IP constraints, and released it as an open source framework in time for the Zend/PHP Conference.

Beta max

Part five of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

"Can we add a link for Trip Reports under the Correspondence section?" Brett, our client on a small web application project, asked during the alpha demonstration.

"Of course," was my gut reaction, "Do you want it below the link for Meeting Minutes?" And with that, the scope crept incrementally.

Overall, the alpha demonstration went very smoothly. We used Live Meeting to share our desktop with the client, which worked great, even through the firewalls. Brett was happy with the progress we had made in short order, and besides the few new features they asked for during the demo, we were right on schedule.

Down to business

Part four of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.

It was Monday, and I was finally starting to feel at peace with my job and personal life. Friday's confrontation with Robert ended amiable enough with an agreement that we were basically on the same page; the problem was that we didn't know each other well enough yet for trust and understanding to develop. Even the confrontation started building our understanding of each other and brining us closer together as a team instead of driving a wedge between us.

Alpha blues soup

Part three of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest.


To: Rusty/SEA
From: Robert/SEA
Sent: Fri Oct 21 08:35:20 2005
Subject: RE: Just when you thought it was safe to go out...

I will be in late this morning (about 9:30), and will drop by. Can Angela get started with training docs?

R

Team Friction

Part two of a series of storied experiences on a small project at a large consulting company in the Pacific Northwest. (Part One).

Robert held his key card to the electronic light of the entry door to the third floor office space. The light greened, and he opened the door while gentlemanly holding it for the team to pass through.

We were working on a project to develop a web application that managed documentation related to contracts and communications for a regional power utility district. The team consisted of Robert, Project Manager; Ryan, Developer; Angela, Graphics/Usability; and myself, Lead Developer. The client had requested a six-week final delivery schedule to coincide with opening their next big project using the web application. A break-neck project to be sure; six weeks to gather requirements, develop an interface, code, and document; forget about time for testing. Registering my complaint about the over-ambitious schedule at our internal kick-off meeting fell on deaf ears, but at least it was on record.

Our Team Palace

"You're not going to believe it," the project manager quipped in his cagey style as he lead my development team from our cubicles to our first meeting in the team room reserved for our latest project.

After a brief pause where I attempted to evaluate whether I should expect to be pleasantly surprised or morosely let down, I guessed the former, "I bet it's like the Taj Mahal." After which Robert's only reply was a chuckle, preferring to keep his game going instead of acquiescing to my correct assertion.

The four of us boarded the elevator on the fifth floor and went down to the third floor. Our company occupies all of the fourth, fifth, and sixth floors (the top floor of the building), which are all well connected by stairs. The third floor, of which we occupy only half, can only be reached by the elevator. People on the third floor complain they feel cut off from the rest of the company; I don't think they even have a fridge or a microwave down there. Not a great sign to start off this project.

Agile Web Development with Rails

Many people (like me) want to start using Rails, but are a little intimidated by picking up a new language and framework. We don’t want to spend countless hours reading through online documentation and puzzling out how things work. We just want to get stuff done. Agile Web Development with Rails is written with this group in mind and it certainly delivers.

The book is targeted at people who are familiar with coding and object oriented design. While prior knowledge of Ruby is certainly helpful, the book works well for those who are new to the language as well as the framework of Rails (like me). For Ruby newcomers there is an appendix that covers some of the basics of the language. Let’s get on to the meat of the book.

We're 90% Done!

We're 90% complete with X and we'll be done in no time!

We all know it never happens that way, yet we hear it regularly, most of us have said it, and some of us have said it more than once.

Why does this sort of thing prevade software development?

Agile Methods need a different mindset

I came across a great article today from Agile Project Planning called: "Do agile software teams make more mistakes?" and he points to the obvious answer of "Yes!" But then he goes into a detailed explanation describing that success comes about quite often because of failure, not in spite of it. True points all and I completely agree, but I'm a bit more pragmatic about it.

As a advocate of Agile Methods, I agree wholeheartedly agree with the idea of fast, tight loops to get customer feedback, design reviews, code reviews, error correction, etc, etc. But in most development, the customer already has a rough idea of their goal and it's your job to figure this out. If you have an excellent requirements gathering/digging team, you probably already have a list of these, but it's nowhere near complete regardless of what the percentage next to the task says. There will always be more that you have to do because of incomplete requirements, unclear requirements, misunderstandings, new customers, etc.

It's an iterative process, so your development should be too.

For example, I live just outside Washington, DC and grew up outside of Chicago. When I drive back, I essentially get on I-70 Westbound, turn northeast at Indianapolis, and turn West again at the appointed place. Little thought is involved because the path is clear, I've driven it quite a few times, and it's major Interstates almost the entire way.

On the other hand, if I go to visit the highly esteemed Duane (a fellow CodeSniper), it takes a bit more effort. I've only made the drive to the area a few times, there are more turns involved, there are state highways involved, and it's to an area that I'm less familiar with. Therefore a completely different mindset is involved:
* I plan the route by looking at the map in advance.
* I keep an eye out for landmarks to mark my progress.
* I watch the odometer and clock to compare actual driving time against my plan.
* And as I get closer, I give him a call to get any last minute changes, detours, etc that might affect my decisions.

When you know exactly where you're going, how to get there, approximately how long it should take, and you've done it numerous times, a waterfall method might work.

If you're unfamiliar with the destination, the route, the effort, and you've done it less than ten times, you need ways of evaluating your progress, establishing baselines and adjusting your route as you go.

This is why I use Agile Methods... because even when I "know" the route, there are a million things that can happen along the way.