Just to clarify:
Although the integration build may include running integration tests, they’re are clearly two separate problems.
Sometimes in a project:
Having self managed teams is a good way to change this reality but to make people capable of managing their own work is a tricky task. With that in mind, the principles I consider most important to achieve it are:
1) Shared vision
The first step to build a self managed team is sharing the project goals. A good start is to define SMART (Specific, Measurable, Achiveable, Realistic, Timed) goals and to make sure that the goals make sense for the whole team.
2) Commitment
Once the vision is clear, the next step is to build the commitment. When the members of the team agree to work to achieve the defined goals, the perception of the their actions changes and they start thinking about the best solutions to get closer to the goals.
3) Trust
If people trust each other, a bond is created and there’s no reason to control other people’s work. On the contrary, people start helping each other.
4) Support
Every self managed team needs an “interface” with the rest of the organization. That’s why one or more people should be able to help when the solution to a problem depends on external factors. These people should be considered part of the team since they share the vision, are committed and trust the other members of the team.
Conclusion
Although these principles look very simple, they’re forgotten all the time. And they’re usually replaced by micromanagement, which on top of wasting people’s time frequently becomes the biggest cause of stress to the team.
Then it’s time to try the Way of Testivus:
If you haven’t tried Ruby on Rails because was too busy developing your J2EE applications, now you have no more excuses! It’s possible (and surprisingly simple) to deploy a RoR application in your favorite J2EE server just by following these few steps:
Get JRuby and install the Ruby on Rails gem:
gem install rails --include-dependencies --no-rdoc --no-ri2) Create a simple test application
Run the following commands to set up your new application:
rails test_app
cd test_appYou’ll have to edit the first line of the created scripts (’script‘ directory) to use JRuby:
#!/usr/bin/env jruby
And at this point you’re ready to test your application:
script/server
Open http://localhost:3000 and check if your application is running as it should.
Now let’s create some functionality. First, edit your config/database.yml file, defining your development and production database as it follows. Note that we don’t need the test database and we can use the same database for both development and production for the scope of this example:
adapter: mysql database: test_app user: root password: xxx host: localhost
Create a scaffold:
script/generate scaffold Dog name:string rake db:drop:all rake db:create:all rake db:migrate
At this point you’re already able to point your browser to http://localhost:3000/dogs and start playing with with your database.
3) Install the JDBC adapter and change your application
In order to deploy as a Java web application, you’ll have to replace the database adapter by a JDBC one. To achieve this, first you need a new gem:
gem install activerecord-jdbc-adapter --no-rdoc --no-riYou also need to copy your mysql driver (JAR file) to your JRUBY_HOME/lib directory and edit your database.yml once more:
adapter: jdbc driver: com.mysql.jdbc.Driver url: jdbc:mysql://localhost/test_app username: root password: xxx host: localhost
Restart your server and, since we just changed its configuration, everything should be still working exactly as before.
4) Install Goldspike and create your WAR file
In your application directory, install the plugin:
script/plugin install http://jruby-extras.rubyforge.org/svn/trunk/rails-integration/plugins/goldspikeTo include your database driver in the generated archive, you have a few options (Maven is one of them), but for now let’s just copy it to the ‘WEB-INF/lib’ directory of the application:
mkdir WEB-INF/lib cp $JRUBY_HOME/lib/mysql-connector-java-5.0.5-bin.jar WEB-INF/lib
You also need to edit the app/controllers/application.rb file and include the line:
protect_from_forgery :secret => '6dc47d156f8f3724e4634c37bc0f9f94'
Finally, to create your WAR file, run:
rake war:standalone:create
Deploy the generated file in your favorite J2EE server like Tomcat or WebLogic.
Conclusion
The integration between Ruby on Rails and Java is easier than most people would expect, and it may become a new option to develop your next web application. That may be also a great motivation to learn JRuby and start taking advantage of its integration with existing Java code.
After taking the Asshole Test, now is time to know about the Asshole Driven Development and other “alternative” methodologies 
PS: see all the comments about the Scott Berkun’s post. There’s a lot of new acronyms there too.
Reading about several things they don’t teach you in school, one that sounded me very important is how to deal with failure:
In school, kid’s learn that “failure” is a negative term.
However, it is nothing of the sort. There has never been a
single successful person who hasn’t failed numerous times on
their journey to success.In fact, the most successful people in life are those who
have failed the most.Edison ‘failed’ more than ten thousand times before he
succeeded in creating the light bulb. As said by Thomas
Edison: “I have not failed 10,000 times. I have
successfully found 10,000 ways that will not work.”
In software development, failure is mostly seem as a negative term too. Obviously we don’t want to deliver software with bugs to the end users, but I believe that most of the bugs could be avoided if the developers change their view about failure.
When you start doing Test-Driven Development, one of the first lessons you learn is how failures are useful during the development process. Every test that fails is an allied to understand a little more about the problem you’re trying to solve. Why don’t they tell this in Software Engineering class? I really don’t know.
For the last year I’ve been involved with the organization of Coding Dojo meetings in Florianopolis/Brazil. This kind of “coding meetings” started in France and spread to Finland, United States (Pittsburgh and Houston), United Kingdom, Canada, Brazil and Sweden.
The sessions are basically about solving a programming challenges using Pair Programming and Test-Driven Development. Everyone is welcome since there’s no skill prerequisites for attendees. The main goal is simple: improve coding skills through practice.
Apparently today when it comes to Agile, there’s a huge gap between the software Industry and Academia. I thought it was just in Brazil, but it seems that there’s too much students out there finishing their degrees without even heard about it. Well, the Coding Dojo doesn’t fill this gap, but it seems to be right at the middle: it’s a simple way to learn about some agile concepts and it can benefit both Industry and Academia.
Today I’m not living in Florianopolis anymore but I’m helping my friends there to keep the sessions running. New people are asking me about the next meetings and in the last weeks I heard about at least more 2 possible Dojos (one more in France and other in Sweden). I think it’s just the beginning for the Coding Dojo Global.
My result was:
Your programmer personality type is:
DHTC
You’re a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.You work best in a Team.
A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.You are a Conservative programmer.
The less code you write, the less chance there is of it containing a bug. You write short and to the point code that gets the job done efficiently.
Now you can take the test too or simply check the other possible results.
The first agile principle is about “individuals and interactions over processes and tools”. How can it be managed when people are not all in the same place?
Dave Churchville wrote about it and classified distributed team as:
1. Type A: All developers are together, all customers are remote
2. Type B: Multiple development teams in different locations (but each team is together)
3. Type C: “Virtual” team where nearly everyone works remotely (e.g. from home, in various offices, etc.)
I’ve been working in the last years mostly with Type A and Type C teams, and I believe the main goal in these cases should be improving the communication channels between people to be as effective as if everyone was in the same room. Long story short, this isn’t possible, but we can still make it work.
For remote costumers, the first challenge is having they available to talk with the development team. It can be painful at the beginning because “build software” normally is not their priority, but as long as they realize how their contribution is important to get the best results, they will probably change. And in this case, cellphone, skype, IM or even e-mail will become very important for their collaboration, and both costumer and team should not underrate these communication tools.
Here’s some tips to work with remote costumer:
The “virtual” team is an extension of the previous scenario, and beside there’s less people together, it can be surpassed easier if the team already realize how communication is important in an agile project. That’s because in this case the communication channels are already open. They can use Skype/IM/e-mail to talk to each other, and even VNC to share their desktops during coding sessions.
This means that if there’s lack of communication among team members, the challenges will be similar to the faced with the costumer. And probably the approaches to fix it will be similar.
After read the 10 Eclipse Navigation Shortcuts Every Java Programmer Should Know, I tried to figure out my favorites shortcuts. I think I would go for:
You can see more shortcuts (or even print them) in the eclipse-tools site.