Pyxis

In September 2009, I decided that for the next year, I would concentrate on three goals:

• Reading (12 books)
• Blogging (40 posts)
• Coding (4 projects)

What did I learn about setting objectives? What do I need to improve? These questions will be answered in a few moments… and if you care you might even hear how I fared.

The results (drum roll)

Overall I’m happy with what I accomplished. I read more books than what I planned (16 books that I remember plus tons of blogs), and I blogged as planned (*exactly* as planned if I include this post and another I posted only on the Pyxis blog). However I wanted to code a lot more than I did. I’m still pleased with the small projects that I worked on but I envisioned something bigger. I mostly did prototypes, katas and experimentation with Rails. No big projects, nothing on github (yet).

I did learn a lot about setting objectives for the future:

Lesson #1 : Never write about goals other people set for you

My wife convinced me to put something about losing a bit of weight. Fail. It wasn’t my goal, it should never have made the list

Lesson # 2 : Keep your objectives focused

For me, three goals was one too much. Very early on I could see that it was easier for me to write blogs or read books than it was to code – books were feeding me for blogs, blogs were giving me questions to read about. Coding felt lonely. Next time I’m going to go with two goals max to start with – and coding is going to be one of them.

Lesson # 3 : Do it gradually

Setting goals is definitely something that allowed me to improve. When I did it in the past, I usually started with a big goal in mind. I suggest you try it with small objectives at first and grow more ambitious as you go. Get started, have habits in place. Then think big.

Lesson #4 : Think about your next goals in advance

Especially if you plan on blogging about it on time. Shame on me.

I have a few ideas but I’m not fixed yet, so I’ll set a few very short term goals for now.

Scrum n’imposant rien sur le plan technique, une dérive couramment constatée est un manque de rigueur par rapport aux pratiques d’ingénieries utilisées par les équipes de développement.  Par exemple, l’omission de tests automatisés lors de l’évolution de projets informatiques rend généralement de plus en plus difficile l’atteinte de l’objectif de livraison de qualité “production” au fil des itérations. Martin Fowler a nommé ce phénomène le Scrum Flasque.

Le cours “Professional Scrum Developer” offert à Pyxis vise à contrer ce problème en replaçant l’emphase sur les bonnes pratiques de développement essentielles à l’atteinte des objectifs de Scrum.

Le développement piloté par les tests (TDD)

Nous avons pu mettre en pratique le TDD dans toutes les facettes de l’application, aussi bien pour le développement en tests unitaires qu’en tests clients (bout en bout).  Ceci nous a permis de nous rendre compte qu’il est possible de couvrir la quasi totalité du code par des tests automatisés.  En conséquence, le code obtenu est robuste, explicite et diminue le stress du développeur qui sait que ses changements seront plus faciles à implémenter dans le futur.

Choix technologiques

Certains choix technologiques peuvent rendre difficile, voir impossible l’application des bonnes pratiques et donc l’objectif de Scrum Robuste: la livraison itérative de logiciel de qualité.  Il est par conséquent essentiel de choisir un ensemble d’outils (langages, cadres d’applications, environnements de développement) qui supporte convenablement ces pratiques.  Un exemple parmi tant d’autres, le cas d’utilisation étudié durant la formation utilisait une librairie de rendu visuel légère et testable.  Ceci nous a permis de facilement tester les vues de manières unitaires, ce qui est malheureusement rarement possible…

Elimination des mauvaises odeurs de code

Les mauvaises odeurs de code (aka Code Smells), comme par exemple les duplications ou les classes géantes, sont des causes fréquentes de difficulté à maintenir une base de code et d’une réduction de la vélocité des équipes.  Le cours nous a permis dans le cadre de la pratique du TDD, de veiller à enrayer en continu, par le “refactoring”, ces mauvaises odeurs.

En conclusion, il faut garder à l’esprit que Scrum ne suffit pas en soit à livrer du logiciel de qualité.  Scrum doit nécessairement être entouré de bonnes pratiques de développement, telles que celles enseignées durant la formation pour éviter de sombrer dans la flaccidité.

Allez-y, soyez robustes du Scrum!

Marc-André Thibodeau et Gaël Luisier

Written in collaboration with Carl Létourneau

What’s the problem?

Creating software without bugs is hard. Many developers are used to unit test their models. Controllers are also relatively simple to test in many frameworks. Tests often hurt when it comes to Views – many frameworks make it hard, or developers might think it is. Sometimes we just don’t take the time to explore what options are available, because we think the time investment might be too heavy.

After a week following a Professional Scrum Developer class, we changed our mind!

But why?

Views are the front of your application. The first thing the user sees and interacts with. Why should they be less important than the rest of the code? What if you had the same confidence modifying your views than you have refactoring your code? An important information displayed to the user is as important as a business rule on the backend. A shopping cart is useless if the total is not displayed. What if someone removes this information by mistake and this problem goes in production?

Testing Velocity templates is pretty easy once you know how.

But how?

Here is an example of a unit test that tests if a cart displays the grand total.

@Test
public void displaysCartGrandTotal() {
  Element cartView = renderCartView().using(
    aModel().with(
      aCart().containing(anItem().priced("20.00"),
                         anItem().priced("12.99"),
                         anItem().priced("43.97")))).asDom();
  String grandTotal = "76.96";
  assertThat("view", cartView, hasUniqueSelector("#cart-grand-total",
                                            withText(grandTotal)));
}

The method renderCartView() method renders a velocity template as a string. asDom() then converts it to a DOM Element. The element is finally tested against the css-selectors library wrapped into our own hasUniqueSelector() Matcher.

Wow, it’s that easy?

You bet it is! Although writing tests for your views might not be available for the technology you are currently using (though we encourage you to do some research). Next time you are faced with a technology choice, you might want to consider the testability of the framework as an important criteria.

This week, the first dry-run of the Professional Scrum Developer for Java course was given at Pyxis. For this occasion, 6 Pyxissians were on-site for 5 training days. Here is a sample of the many things we have learned.

One of the fundamental aspects that was covered was producing a proper “definition of done”(D.O.D).

For most of us, even with our extensive Scrum background, this was actually harder than we had originally expected. The training course consisted of 4 sprints spread over a 4 day period. At the end of each sprint, we had to demonstrate our accomplishments to the Product Owner.

At the end of the fourth sprint, we had to put our software into production.

Like most teams, we started out with a D.O.D that was too ambitious and wasn’t clear enough. For example :

• We had planned for 100% test coverage for all of our tests, yet it was impossible to demonstrate since we were unable to calculate code coverage for view tests. Even worse, there was simply no available tools to calculate our test coverage for these.
• We also had ambiguous elements, like following the code standard, without stating which one.

After achieving first sprint, we did what we thought were the proper modicifications to our done definition. As you can guess, we failed our second sprint. Our done definition was being seriously violated. We committed to too many tasks and did not take the time to truly understand all the work involved in achieving our done definition. We adjusted for the following sprints. Inspect and adapt as always.

However, when came the time to release the product, we realized that our done definition was seriously lacking. We had no confidence in being able to ship our product to the customer. The Product Owner was disappointed in learning this. We then had to modify our done definition to finally be able to deliver. Unfortunately, we had skipped some important steps in the previous sprints which accumulated up until the last day.

Here are few key points that were missing :

• Exploratory testing
• User Experience testing
• Proper production deployment procedure

This really helped us see how important it is to have a true definition of done and to follow it through sprint after aprint. After all, we had accumulated debts after only 4 days of sprinting. Imagine if we had been sprinting for weeks !

-Nicolas Henin and Nicholas Lemay

Since I discovered Haml for my HTML templates in Rails, I stopped using ERB. Haml is more intuitive and readable to me.

I am rediscovering ERB though for something else completely – Java code generation.

There is a lot of boilerplate code in most Java projects. A good IDE can help you alleviate some of it but most (if not all) applications will have additional boilerplate very specific to your application. Using ERB, you can easily create cut down on mindless typing.

For example, let’s suppose you are writing many Java listeners. Just create a script that will do it for you. I’ll make an exemple with a ContactListener class that is notified when a user is added, removed or blacklisted from your contact list.

require 'rubygems'
require 'erb'
 
# setup - could be initialized from script arguments
classname = "Contact"
listener_methods = ["added", "removed", "blackListed"]
 
# create file based on 'listener.java.erb'
content = File.read('listener.java.erb')
template = ERB.new(content)
File.open("#{classname}Listener.java", 'w') { |f| f.puts(template.result) }

If I run this using listener.java.erb:

public interface <%= classname %>Listener {
  <% listener_methods.each do |method|  %>
  void <%= method %>(<%= classname %>Event event);
  <% end %>
}

Then I generate this file:

public interface ContactListener {
  void added(ContactEvent event);
  void removed(ContactEvent event);
  void blackListed(ContactEvent event);
}

That was easy – and it’s not that useful I admit. I’m sure you can create your own listeners just as fast in your own IDE. Probably even faster.

However here comes the fun part – the same script can be used to create lots of other classes:

• The ContactAdapter class
• The ContactEvent class
• The ContactController
• The Contact model
• The ContactRepository (maybe even with a few methods to add/remove/retrieve a contact by id)
• The ContactView through which users will be able to trigger ContactEvents (maybe with a simple UI – even buttons to trigger each events on the ContactHandler)
• Registration of the ContactHandler and the ContactView by your favorite IOC framework
• Registration of the ContactView so it is accessible from your application’s menu
• Test classes for all of the above (including failing test cases that you’re going to have to write)

And probably other bits here and there to glue everything together.

Your mileage may vary, but code generation might be a great way to make your path shorter.

Can your IDE do that?

Incubators are looking for ways to differentiate themselves. The newly launched AngelPad (an incubator created by 7 ex-googlers), for instance, bets on recreating a google-like atmosphere to foster innovation.

A recent post from Mark Shuttleworth seems to show that some foundations also have interesting ideas when it comes to financing projects :

“The model of the Foundation is unusual: we identify interesting change agents, like Mark, who are articulating powerful ideas that seem like the offer a hint of the future, and we fund them to work on those for a year. We also offer them an investment multiplier: if they put their personal money into a project, we multiply that by 10x or more, up to a maximum amount. In short, find good people, back them when they put skin in the game.”

Now, I am wondering about something : could incubators be a model for managing companies ?

• What would happen if you created a company that was merely a kind of aggregate of smaller companies sharing a common vision but running mostly independantly ?
• Could the Politics of Switzerland be an inspiration  for creating such an ecosystem ?
• How much federal government do you need to have inside a company to have the perfect balance between “feeling like a single company” and “feeling empowered enough to do things without any bureaucracy” ? (do-ers hate bureaucracy, so if you want doers in your company, you’d better find a way to systematically fight it if you want to keep these people)
• Is is possible for people to feel part of their community without neglecting the rest of the ecosystem, the same way Texas inhabitants feel both texan and american ?  (Have you noticed that people have both the texan flag and the american one in their garden over there ?)

There will be an interesting conference on Lean Startup by Eric Ries at SXSW. Eric asks 5 questions everyone involved in building new products (or any market offerings) should ask frequently. Answering these questions is not as easy or obvious as it sounds. It’s even more important for mobile development as product lifecycles are very short and spending too much effort on a bad or average product might have high impacts (opportunity loss). I’ll reuse these questions in coming blogs and apply them specifically to the mobile market. To read these questions and vote for Eric panel, visits http://panelpicker.sxsw.com/ideas/view/8270

I had to read the content of a file for a ruby project. This is how I did it:

def read_file_content(filename)
  File.read(filename)
end

Simple enough, right?

Then for some reason I thought about how I would have to the same in Java:

public String readFileContent(String filename) {
  try {
    BufferedReader reader = new BufferedReader(new FileReader(filename));
    StringBuilder buffer = new StringBuilder();
    String line = null;
    while ((line = reader.readLine()) != null) {
      buffer.append(line);
    }
    return buffer.toString();
  } catch (IOException e) {
    return "";
  }
}

Need I really explain why I prefer Ruby these days? Even if you remove the try/catch clause and rethrow the exception, that’s still a lot of code compared to a single line of ruby. I am also aware that it is possible to write the same Java code in a single line using Apache’s commons-io (IOUtils.toString(InputStream) – but still, why are the base Java libraries so verbose for file manipulation?

I still like Java, but I’m impress by the compactness of Ruby. It just works as it should. Sometimes working in Java it seems I’m just smashing the keyboard instead of getting actual work done.