Ola Bini, core committer on the JRuby project and Zheng Ye, core committer on the XRuby project are in Bangalore for 2 week attending ThoughtWorks Immersion. I happen to be one of the TW Immersion trainers. It’s fun to coach celebrities.

JRuby allows us to run Ruby code - including Rails - on the Java JVM.
XRuby is the first Ruby to Java compiler which compiles Ruby source code (.rb) to Java bytecode (.class)

Date: Friday, 31st August
Time: 6:00pm
Venue: ThoughtWorks Bangalore.

Here are the directions

Abstract of the talk: (as given by Ola)

Ruby and Ruby on Rails is making large waves in the Web Development world. Many Java developers have converted to Ruby, and more and more find the language a breath of fresh air compared to Java. JRuby is quickly becoming the Ruby implementation of choice for large enterprises and Java organizations where the Java platform still have much to offer. In this presentation Ola Bini will first introduce the Ruby language, highlighting the features that makes it different from Java, including some examples of metaprogramming and language mutability. After that, he will introduce JRuby, walking through most of it’s features and finally showing some examples of the exciting things that can be accomplished by combining Java and Ruby.

ThoughtWorks have for a long time been one of the largest companies delivering services using Ruby, and was also the first to release a product based on JRuby on Rails (Mingle).

You will learn what Ruby, Rails and JRuby is. You will learn how JRuby on Rails can be used to create web applications. You will learn how it’s possible to use first class Ruby test frameworks to make testing your Java code a breeze. You will also get some hints and tidbits about other things that are possible with JRuby.

If you’re interested in meeting Ola and Zheng Ye, please sign up on the GeekNight wiki.

This is a great article on how FOSS (Free and Open Source Software) can help organizations. If you are having trouble convincing your management about FOSS, ask them to read http://www.cio.com/article/print/111950

During the Agile 2007 conference, Shyam and I were preparing for our experience report presentation. While we wanted to focus on preparing our presentation, we could not get our hands and minds off the burning topic : “Is Enterprise application the right approach or should we focus on really small, focused applications, which do one thing well?”

Both, Shyam and I have had some really bad experience with the whole enterprise solution/architecture crap. Trying to integrate all the small little focused apps into one gigantic piece of application just seems so nice and beautiful on paper. You can also easily convince the CIOs and CFOs that this is the silver bullet and it will save the company millions of dollars. I’m sure the enterprise product vendor companies can come up with tens of millions of reasons to reassure them that this is the best solution (just that there is a little learning curve).

With my experience of building really large scale enterprise applications, I have concluded that “Enterprise Applications are Dead”! What we really need is small, well focused, single responsibility applications which does one thing well and that’s all they do. It just feels so easy to maintain them and migrate them to new technologies as time passes by.

Look at all those large enterprise applications. First of all, they contain tons of features which no single user will ever use. Some of them even collapse and die under their own weight. Secondly, the fact of life is, they get old and have to be migrated to new technologies. Guess what? When you have to migrate them, you end up with a 5 year migration project which takes millions of dollars. Also consider the amount of hardware, software and experts you need to maintain this monster. Now really think about the benefits. Aahhhh….well….don’t take your anger out on the monitor or the keyboard.

Look at companies like Google or Yahoo. They don’t have large enterprise projects. They have a lot of small little apps, that do the job. Some of them don’t even have the same look and feel. But guess what, functionality is more important than all the make up. One could argue that these apps are not data centric, which most enterprise apps are. I agree. But, really how much of a difference will it make? Also do they really have to be on one database box or they can have their own instance of database. Again, we at least need to think about these rather than just having the herd mentality.

Patterns:

• Organizing Tests - Allowing customers to add new tests without breaking the build. This is possible by using the concept of symbolic links in FitNesse. Ideally, I would have a story tree [stories are not linear structures, they have relationships and hierarchy] under the FitNesse. The leaf of the tree is the smallest story that the developers work on. For each leaf, we define one or more acceptance tests (AT). This is one view of this info. Another view of the info would be to look at the stories from each iteration/sprint point of view. You might want to know which all stories are being played/worked upon in iteration/sprint 2, for example. The we create an Iteration/Sprint page at the same level at the root of the story tree. Under this page, we create separate  pages for each iteration/sprint and once the acceptance test is ready and working [after developers have written just enough code to make it work], we symbolically link the test to the iteration/sprint page. Each iteration/sprint page is defined as a Test Suite which runs as part of the Continuous Integration build. So the customers can work on the ATs for their stories and check them in, without breaking the build.
• Version Control -  Checking in the acceptance test under the same version control with the code makes it very easy to reproduce the build at any point in time. Tests always go hand-in-hand with the code. Unfortunately FitNesse does not have built in support for version control. I’m working on a framework for adding version control support which will be a part of the FitNesse project soon.
• Cross-Functional -  The vision of FitNesse was to be a collaboration tool rather than just a testing tool. Using FitNesse based acceptance tests for collaboration between cross-functional team members is a great way to help communication within the team. It also encourages every one on the team to talk about the domain entities and hence domain language at the very beginning of the story.
• ATDD (Acceptance Test Driven Development) - In my opinion the real value of ATs is when we use to express business intent and use that to drive development. The way we have done this on our teams is, we have the customer/product owner/BA write the acceptance criteria (AC). Usually they do this before the beginning of the iteration/sprint. Developers use this to estimate. Once the story is added to the current iteration/sprint backlog, a develop pair picks up the story. They pair with the customer/product owner/BA/QA to write the acceptance tests in FitNesse. This helps the developers and QAs really understand the story. Then they part their ways. Developers write just enough code [including the fixture code] to make the AT pass. In the mean time, the QAs write other scenarios around the story. Once the developers and QAs are done. They have a touch point to make sure all the ATs are working. When this is done, the story is Dev complete and ready for BA and QA sign-offs.
• Cleanup, Setup, Test, Teardown - We started with Setup, Test and TearDown + Cleanup. We could clean up any external state of the system at the end of the test. External state includes, data in database, files on file system, messages on Ques, etc. But soon we realized that if a test failed, we did not have a way to know what the state was, when the test failed, coz the AT would clean up the state after its execution. Hence we changed to a pattern where we did not clean up the state at the end, instead we cleaned it up at the beginning and setup whatever state the test needed.
• Independent Tests - Its very easy to end up with tests that depend on each other. Usually people do this to avoid duplication. But this leads to a state where one test fails and it has a ripple effect across all the tests and it becomes very difficult to find out which test is the root cause. We really try had to create test that don’t depend on each other.
• Dynamic Stubbing - Its very easy to fall into the trap of testing the system completely integrated with all external 3rd party systems. While it would be great to had tests that are integrated and as close to reality. There is a cost you need to pay for it. The cost can come in-terms of time to execute, the cost can come in terms of added complications of set-up, test execution and teardown. A lot of times it better to avoid this extra cost by dynamically simulating the expected response from external systems. At the beginning of the AT, you can set expectations on the external system and then run the AT to make sure your system behaves in the expected way. [similar to the mock object analogy]
• Non-Production code for Setup/Teardown - A lot of times its tempting to use production code to setup and teardown data. For Ex. if you are using a OR mapping tool, it seems easy to use the OR mapping production code to setup and teardown data. This is quite problematic if this code changes. For all you know, this code itself has nothing to do with what you are testing. So what I prefer instead is to use non-production light weigh code for setup and teardown. This helps test only what I want to test. For Ex. in the case of DB data setup, I would use simple JDBC or ODBC code. You can also use the DBFit project for the same.
• Suite Levels - Creating different levels of suites depending on the depth/level of feedback desired is very important to get quick feedback. Again use the Symbolic link concept of create different suite pages and include more tests or other suites. Ex: Smoke, Current Iteration/Sprint, Regression suite pages are really useful.
• DRY (Don’t Repeat Yourself) - Use !include to avoid duplication and encourage once-and-only-once. If you have duplicate tables in your AT pages, refactor the tests, by pulling out the common tables and moving them to a separate page. Then use the !include to include the common page in the respective test page.
• Make it Real - In an ideal world, you would be running your ATs against a production box. But that’s too costly to afford. So we try to strike a balance between cost + complexity and real + concrete feedback. So the idea is to write ATs as close as possible to the real environment without incurring too much cost. Ex: Execute ATs inside the app container if that’s how your app is going to run
• Fixture Evolution - Allow Fixture implementation to evolve over time and treat them as first class citizens. I have some teams which write a wrapper framework with all possible fixtures before they actually write their first AT. Unfortunately this does not fly. JIT fixture creation works very well. Having said that, its also important to treat your fixture code as first class citizens. Follow the general good OO principles. Don’t over use statics, don’t create hierarchy of fixtures to share instance variables, use meaningful names, etc
• At Least One Test/Story - Every story should have at least one acceptance test. Avoid long/multipurpose tests

Anti-Patterns:

• Developer AT democracy - On a lot of teams, developers writing acceptance tests for themselves and by themselves. That defeats the purpose of ATs. They are used for communication and collaboration. They also happen to be good for testing. But if you only think of that aspect, you might miss the forest for the tree.
• Unit Testing - Don’t write ATs at the unit testing level. Unit tests are implementation specific, while ATs are NOT implementation specific. ATs express business intent, while unit tests express technical implementation intent.
• QA Testing Tool - FitNesse is not a QA testing tool. They can use it to write acceptance tests. But not other types of tests. Keep the tool simple and let it do one job well. With lack of support for test maintenance, it really becomes a big issue for QAs to use this tool effectively. Plus it is very difficult to write UI level ATs in FitNesse. You need a different tool. Its not a Silver Bullet -Don’t try to use FitNesse for all types of Acceptance Tests. Like UI, XML testin, etc
• Test After - Writing tests after the code is already written does not give you enough value when compared to writing them before and using them to drive development
• Hiding Test Data in Fixture Code- Hiding test data that affects the behavior in the fixtures is a bad idea. A lot of teams write FitNesse tests such that the test data is completely obscure from the user. Again, its about communication. Make sure your tests communicate intent. [Test data is a part of it]
• Implementation Dependant ATs - Making test pages (tables) dependent on implementation details and data structures is really troublesome.IMHO, AT should be platform, technology and implementation independent. I would say if you build a system today with good AT, a few years down the lane if you decide to port the application to a new technology or architecture, with some changes in the fixture code, you should be able to run the ATs against the new system.
• Logging in Fixture Code - Putting log statements or print statements in the fixture code is a real smell. This implies that your fixture code is probably too complicated. Having said that, it is very difficult to debug FitNesse AT the way it works. Have a look at the Patang project on how we have solved this issue.

ASCI have 3 events planned so far and 1 in planning.

1. One day Introductory Agile Workshop in Coimbatore on Sep 8th
2. One day Introductory Agile Workshop in Indore on Sep 22nd
3. Two day Introductory Agile Conference/Seminar in Chennai on Oct 4th and 5th.

1. Agile conference in New Delhi NCR in November/December under the NAUG umbrella.

If you are interested in attending/presenting at any of these events, please visit the links for more details.

If you are interested in hosting/organizing a similar event, please email us at helpdesk@agileindia.org

If you want to groom/mentor a college grad (fresher) to be a software developer in any language what are the very initial thoughts you will put in her/his mind?

Short ans: Business [biz] value
Long ans: Biz value is very important and good quality software which helps solve the real biz problem is a great start. Educating them that technology and process are means to achieve this and not an end in themselves. IMHO, making someone realize this is a huge step forward.

At the Agile 2007 conference, Jeff Patton and I were awarded the Gordon Pask award for the year 2007 by the Agile Alliance.

The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice demonstrate, in the opinion of the Award Committee, their potential to become leaders of the field. The award comes with a “travel to two conferences in two other continents” and all expenses paid by Agile Alliance. This will help the award recipients to spread their ideas. Last year, the award used to comes with a check for 5000 USD from Agile Alliance. The objective of the award is to help potential leaders be heard in different communities. Presenting 5000 USD does not directly help towards this objective. So this year they changed it to sponsor the award recipient to 2 conferences in 2 different continents. The winners were announced at beginning of the Agile2007 conference banquet.

While receiving the award, I was asked to give a small speech. The gist of the speech is: “A few months back, a colleague at ThoughtWorks asked me, what brings me to the software industry and why am I working in this industry? I thought about this for a while and there was this particular image of a man with long hair walking down the streets of Boston that kept coming to my mind. He was wearing a black T-Shirt and in big bold letters it said Free (as in Freedom). Any guesses? Well, its none other than the great Richard Mark Stallman, also known as RMS. The founder of Free Software Foundation (FSF). RMS have always motivated me to build communities which cherish free and open exchange of ideas. Its my belief that its only these communities which can foster innovation and make a real difference to civilization. The reason why I’m talking about this is, I think Free Software movement and Agile have one common goal. Its Freedom. Freedom from systems/processes which kills innovation and fosters horrible & painful software experience [both while building and using it]. Again, Agile is not a silver bullet, its a ray of hope for me!”

While I’m very excited/honored to receive this award, I also feel the pressure to exceed the expectations as the recipient of the award. I really believe that India has a potential to become the next powerhouse. Over the past few years, India has become the focus of IT. I think that clubbed with Agile or light weight software development process can made a huge difference to make IT a real value add industry. There are lots of companies out there [not just in India, but across the globe], who think throwing more bodies at a problem will solve the problem. I my experience, it only complicates things further. With Agile and other light weight process, I think we can bring the emphasis back to small highly collaborative teams of quality people. Helping companies in India understand this and implement it will really be focus for the next few months. Having the recognition and the ability to established bonds with leaders in this space across the world, I think I can bring some of that expertize to India to fast track our vision of Freedom through the adoption of people centric software development process.

What else will I do with the award? Well, I love traveling and with the help of the award, I’m looking forward attend conferences and meet folks who have different views of software development. I looking forward to attend some conferences not just in the software field, but other fields which can help us push the state of software development to the next level. The award will really help me with my passion for connecting different networks of Agile Practitioners across the world and build a global community. I call this as the “connecting the dots” vision.

Thank you for your support and help.