You know Agile is becoming prevalent when the keynote of a conference about testing in the more traditional sense of testing major applications used by airlines, banks, and other financial institutions.

Fran O’Hara from Insight Test Services is speaking about Agile Test Strategies and Experiences. He asked at the beginning of his presentation how many companies have embraced Agile, about a quarter of the ~250 people at the conference raised their hands (including me!). He asked how many are evaluating/thinking about it, and about 50% of the folks raised their hands. And then how many are not looking at Agile, and an oustounding 25% raised their hands! I’d have thought that Agile had been the “next new thing” for long enough that everybody would have at least looked at it, and either decided to adopt it, or discard it as not strict enough.

He highlighted some of the types of tests that don’t really fall into the purview of normal unit or iteration testing including:

• Performance testing
• Combination/feature interaction testing
• Business cycle testing such as End of Month processing

We’ve seen these types of tests not be written while heavy development of the system is happening. Developers and testers are all focused on just churning out the next feature/solving the requirements and verifying they work properly. However, once you’ve had a couple of interations under your belt, then you start thinking more about those complex scenarios. We worked with a client that had a device that processed large amounts of data. The first 5 or 6 iterations were all focused on making the device work. But iterations 7 through 11 were all about writing analyses tools and complex tests that exercised the device and flushed out issues in the algorithems or verified complex interactions worked as expected. In these later sprints the developers and testers worked hand in hand to understand where the problems are and what the expected behavior should be. Writing those tests earlier would have been very difficult if not impossible, because often what the expected behavior should be can’t be defined until the device was up and working!

Fran emphaized that by having the testers integrated directly into an Agile development team they can have a lot more input into the project. They can ensure that the customers needs are met, not just that the software is technically correct. And when you have a sepearate QA team, then that imples that Quality isn’t something the developers need to be concerned with. Which is a recipe for disaster. By pushing the need for Quality down to every level, you end up with a better system. Think Honda and Toyota versus General Motors.

He also pointed out that one of the key reasons to have Testers invovled directly is becasue often Agile is introduced by the developers, which can lead to making mistakes such as using unit tests for accepetance tests. Or thinking that automated tests are sufficient!

Ruby DCamp is the first conference, of any type related to ruby or my recent work with Ruby on Rails, I have attended since graduating from UVa. I have been awaiting this opportunity for a while now because my colleagues at OSC have been raving about the kind of people that will be present. People like Rich Kilmer, Brian Marick, Jeremy McAnally, Lucas Cioffi, David James and many more. Being new to the Ruby community, it is very important to meet the people who are responsible for the development of the Ruby ecosystem.

It was very convenient that the first topic that we discussed on the first day of the conference was the Ruby ecosystem. One of the key points that I got from that discussion was how people got introduced to Ruby through different ways and different circumstances but the majority got in through Rails. But a consensus between the “expert Rubyists” was summed up by one of them in the sentence “Came in for Rails, stayed for Ruby” which indicates that although Rails is the reason why people start learning Ruby, it is in itself not as appealing as Ruby is. This is why during one of the discussions we had, people were interested to find out more about the different technologies out there that leverage Ruby and give the developer the same functionality as Rails such as Merb. It was really cool to get the input of the people at the conference on their experiences with the language and the community itself.

There were two interesting things I want to mention specifically from the first day. The first one is that I found out that I am not as much a beginner as I thought myself to be.  I came to this conclusion from the Beginner Talk discussion I listened in on. During that talk, a few people who have been working with Ruby for a long time and one of them even teaching it were giving an outline of the language and mentioning things to look out for. Surprisingly enough, I already had experience with all that stuff unlike a few others who have a lot of experience with other programming languages but are new to Ruby. This was interesting to me because I came in thinking that I was the least knowledgeable person attending RubyDCamp in terms of Ruby and Ruby on Rails, but that was not true (much to my relief). The other thing would have to be the fact of how smart some of the Rubyest at the conference are. I heard all about it from my coworkers but I had to see it for myself to believe it and it was very apparent the moment I observed those people planning to patch ruby gems to add a functionality they figured to be important. This was not just it, as people were mentioning ideas of what needs to be done, one person in particular was already done implementing some things and the best part was how he had it all done before everyone even reached a consensus about it.

Saturday was great in the sense where I got to meet a bunch of new people and get an idea of what kind of projects everyone is working on. Sunday on the other hand was great to get into more detail. The first session I attended was titled “CouchDB hack session” and as the title indicates, it was a session focused on CouchDB. I think it was the most popular session of the morning because there were a lot of talks about it during the first day but most of the people had no idea what it was. It was a good session with a lot of discussion about CouchDB and its uses.

The next session I sat through was a session about SproutCore. I already had an idea of what SproutCore is because I had considered using it to develop one my apps, but ended up not using it. So it was interesting for me to get the perspective of someone who had already used it and also contributed to it. What distinguishes SproutCore is how it is modeled on Rails and allows the developer to use Ruby in development but then generate JavaScript and Json to be deployed once the application is done. This allows developers to keep using Ruby even in environments that limit them such as developing an application for OpenSocial. The main thing I got from this session was some sort of validation that SproutCore is a technology that can be trusted and used, which is a fear that I had because I did not want to develop an application using a new technology that will not be supported in the future, but I learned from the conference that Apple used SproutCore for their MobileMe application and also contributed to the project. This gives me some sort of relief that it will be around in the next few years.

At lunch we started sharing our “ruby experiences” and our “favorite tools” and here’s some of those tools: git-bisect, limelight, hpricot, mechanize, jruby… So if you haven’t heard of these tools before, make sure you do your research!

Oh… and one more thing that I should mention: We at OSC need to do a bit more pair programing!

All in all, it was a great conference and special thanks to Evan Light for organizing the event. Hopefully we will be able to build on this to grow and improve the Ruby community.

For an agile web developer two frameworks are available for quick and easy deployment of a new website: Ruby on Rails for the Ruby fans and Django for the Python fans. These two tools should provide the same functionality and as someone who’s been working on two projects for the last month, each using one the frameworks, I have had the experience of starting from scratch on both of them and trying to learn both in parallel (or at least one right after the other without acquiring more experience in one and becoming biased for one over the other). So what has this experience taught me?

Deployment
It is very easy to start an application using both Rails or Django:
rails myapp vs. django-admin.py startproject mysite
even though one is wordier than the other it is pretty simple to start the project with all the directories and files needed automatically generated.

Starting the Server
This task is as simple as the previous one:
ruby script/server vs. python manage.py runserver
in both cases there is a call to the language in use, then passing a command. In Rails’ case the command is an executable found in the “script” directory whereas in Django’s case the command is an argument passed to the Python manager.

Configuration
Both frameworks provide a place to configure the application. Rails provide an entire directory to configure the database setup and the Rails environment whereas Django provides a settings.py file where all the configurations can be present but also provides the option of having a config directory for multiple personalized configurations.

Updating the Database
Yet another simple task:
rake db:migrate vs. python manage.py syncdb
In this case we notice that with Rails the call is actually to “rake” whereas for Django it is still consistent with the previous format. But we’ll see that Rails is also consistent where “rake” is called for everything relating to the database.

Creating Models
Where some of the differences begin:
With Rails you create one application that can have multiple controllers, models and models and link to each other using ruby script/generate * (where the * differs depending on what needs to be generated).
Whereas in Django you create multiple applications which each has its own models and views using python manage.py startapp myapp

Documentation
It seems that Rails is more widely used which results in more available resources online for documentation and help. None the less, the Django documentation site is very extended and provides sufficient help.

The Dirt
In the case of Rails I started the project from scratch by first following with the example in the book Agile Web Development with Rails, Third Edition and then applying what I learned to the project I was working on. Whereas in the case of the Django project, I was put on it late in the development process and tried to learn the language and at the same time understand what was already done on the project. My experience with both has been limited and what I have found is that the Rails magic seems to be the difference maker for most people. The majority are not comfortable with that “unknown” but I have seen some magic done with other languages like Java, although it is not the same type but in either case there is something in the background that is doing some sort of work for the programmer. And I have become comfortable with such a setting and because I have seen a bit of how programming languages interpreters work I understand and appreciate the Rails magic.

Even though I was more productive using Rails than I was using Django, which may have influenced my opinion about them, I am still willing to give Django a chance. Both are great tools for developing web applications in an agile manner. My recommendation though, if I have to make one, will go for Ruby on Rails, just because I was more comfortable with it.