Devoxx France 2016 : L’Odyssée du Continuous Delivery

Les 20, 21 et 22 avril a eu lieu à Paris la 5ème édition de la conférence Devoxx France. Issue de la communauté Java, Devoxx France s’est ouverte au fil des ans et accueille les développeurs en général.

Lors de cette édition, j’ai eu l’occasion de co-présenter un retour d’expérience sur la mise en place du Continuous Delivery à la Société Générale CIB (SGCIB), à laquelle j’ai participé en tant que coach technique. Depuis quelque temps, la SGCIB investit massivement sur le Continuous Delivery pour répondre à ses enjeux métiers.

Dans notre retour d’expérience sur un an de transformation vers le Continuous Delivery, nous parlons de notre passage en Feature Team, de l’adoption du Trunk-Based Development, de la mise en place des Release Train et du Toggle Feature, de Deployment Pipeline, de BDD, TDD, Clean Code, dette technique, entre autres.

Voulez-vous en savoir plus ? Clément Rochas a fait un retour sur notre présentation sur le blog de Xebia. Sinon, ci-dessous vous pouvez regarder notre présentation en vidéo. Les slides sont sur SlideShare.

Posted in Uncategorized | Tagged , , , , , , , , | Leave a comment

Soirée Software Craftsmanship au Paris JUG le 9 février 2016

Le 9 février 2016, j’ai eu l’occasion de co-animer avec Bruno Bouccard et Thomas Pierrain la soirée Software Craftsmanship au Paris Java User Group.

Cette soirée dédiée au refactoring du code legacy s’est déroulée en mode coding dojo. Le kata Trip Service a été utilisé pour l’occasion.

Durant l’exercice, Bruno a fait du live coding en C#. En face, les participants, majoritairement en Java, l’ont suivi en répétant les mouvements de refactoring.

Je tiens à remercier Bruno et Thomas pour l’invitation, à l’équipe du Paris JUG pour l’accueil et l’organisation et aux participants pour les échanges, questions, etc.

Pour en savoir plus sur les techniques utilisées pour remettre le code d’aplomb, une vidéo a été mise en ligne par l’équipe du Paris JUG.

Posted in Uncategorized | Tagged , , , , , | Leave a comment

Ruby: from ZERO to HERO

Gentle introduction to Ruby programming language. This presentation brings an overview of basic concepts and useful information to start coding.

Posted in Uncategorized | Tagged , | Leave a comment

Extreme Carpaccio

At the end of 2014, I started working for a well known French investment bank as Software Craftsmanship evangelist. About 2 or 3 years before, an ambitious program started being deployed across the organisation in a huge movement towards Continuous Delivery. I joined the agile and technical coaches’ team in charge of the program as Craftsman Coach (as they use to call the role themselves). My job was to help development teams to improve software quality, stability and the delivery process, by introducing concepts like TDD, clean code, continuous refactoring, BDD, continuous integration, simple design, and so on.

On my day-to-day work, I strongly used coding exercises, better know as code katas, in order to help developers to improve their skills. Most of the exercises I used can be easily found on the internet. Nevertheless, sometimes I was led to create some exercises by my own to better address specific team needs. On that context, while trying to figure out how to better explain feature slicing and iterative development, Radwane Hassen (a colleague also working as a tech coach) and I have created Extreme Carpaccio, which is the merge of two great existing exercises: Extreme Startup and Elephant Carpaccio.

Extreme Startup

Extreme Startup is a coding exercise created by Robert Chatley and Matt Wynne. The first time I played Extreme Startup was during a Xebia Knowledge Exchange (XKE) in a session organised by Sébastian Le Merdy, Nicolas Demengel and Jean-Laurent de Morlhon.

During an Extreme Startup session the facilitator uses his own computer to send HTTP requests with puzzles to participants’ computers. Participants should figure out how to solve each puzzle and code to respond server’s requests. For every good answer, the participant earn points and for wrong answers, he loses.

Extreme Carpaccio uses the same principle: a server simulates a market and sends requests to participants who need to code the response. It turns out this approach is very funny, since it creates a competitive atmosphere and people try their best to win. However, counter to Extreme Startup, in a Extreme Carpaccio session most of the problem is unveiled at the beginning and teams should decide what to implement first.

Elephant Carpaccio

Elephant Carpaccio is a slicing exercise created by Alistair Cockburn. Many colleagues use this exercise to work with teams and help them to improve their slicing skills.

In an Elephant Carpaccio session, the facilitator exposes the problem and asks participants to slice it into small pieces, prioritize and implement iteratively. At the end of each iteration, teams demonstrate how they devised the problem and what they achieved. The goal is to slice the whole problem into a bunch of small ones, in such a way that each sub-problem could bring feedback and value (either knowledge value, customer value, or both). The opposite approach (waterfall) would spend a huge amount of time during the development phase and only release in production once everything is done. This approach has many drawbacks and one of them is that it postpones feedback.

Unlike Elephant Carpaccio, Extreme Carpaccio doesn’t guide participants through slicing, iterations and demonstrations. However, the exercise was designed to promote teams that slice the whole problem through a value perspective. The more you slice, the earlier you go to production, and the earlier you earn points. If you only go live when the whole problem is implemented, people that took an approach based on iterations will start earning points before you.

Problem to be solved

Based on Elephant Carpaccio, the problem consists in a company which sends to each team’s computer (sellers) a purchase order. The order contains prices and quantities of each product being sold, the buyer’s country and the reduction (discount) to be applied. Using this information, teams need to figure out how to calculate the order’s total amount and send back to the server a bill containing the amount. If the answer is correct, the team earns points equivalent to the order’s amount. Otherwise, they lose half of the order’s amount. For each wrong answer, the server sends a feedback to the client with the right amount value.

Following an example of request the server sends to participants:

{
    "prices": [65.6,27.26,32.68],
    "quantities": [6,8,10],
    "country": "FR",
    "reduction":"STANDARD"
}

The number of purchase orders each country sends varies depending on the country who sent it. This number follows the population density of each country. Germany, UK and France, for instance, will send more requests than Luxembourg, Cyprus or Malta. That information is not mentioned explicitly to encourage people to exchange with the facilitator. It is also possible to figure that out only by looking at the messages sent by the server. Nevertheless, as in real life, asking questions to the right person can save you time.

Session Plan

Extreme Carpaccio was designed to be played with developers and product owners (or business analysts) together. Nevertheless, it is possible to run the exercice only with developers too.

During an Extreme Carpaccio session:

  1. participants get organised into teams of 2 or 3, with 1 product owner and at least 1 developer each (2 is better) – this should take around 5 minutes
  2. the facilitator exposes the problem and announces the next steps – takes generally between 5 and 10 minutes
  3. the facilitator asks teams to start slicing and prioritizing user stories – between 10 and 20 minutes
  4. the facilitator starts the server and asks teams to register themselves via the server’s dashboard – can take from 5 to 15 minutes, depending on the number of participants, network problems, etc.
  5. once everyone is registered, the facilitator allows people to start coding – takes between half and one hour
  6. retrospectives – around 15 minutes

Book 1h30 to 2h for the exercise. During the session, the facilitator should circulate among teams in order to make sure everyone is on the run. Most of the problem is exposed at the beginning, but not all of it (see reductions’ section). Teams should try to decouple the problem based on their own strategy with the information they have.

At the end, take some minutes to do a retrospective and ask participants what they’ve learnt and if they have something to share. I generally ask people who finished at the top which slicing strategy they chose. You can also ask about technical difficulties, success, etc. Retrospectives are frequently very rich and I’m frequently surprised to discover new ways to deal with the problem.

Extreme Startup session at Software Craftsmanship Paris:

This slideshow requires JavaScript.

Reduction Variation

In the middle of a session, things start to stabilize and we will probably have some teams at the top and the others in the middle and down in the ranking. At this moment, in order to challenge teams on top and shake the score, the facilitator can change the order’s reduction type without saying anything. Since the reduction rules used to calculate the new amount aren’t described anywhere, people need to stop doing what they are doing and try to figure out how the new reduction works (this can be easily achieved by looking at the new purchasing orders). By doing this, we allow people which were in the mid-raking to challenge people on the top. This breaks with the “predictable” aspect of the exercise, that happens when some teams perform much better than the others from the beginning.

Interesting things I’ve faced running Extreme Carpaccio

Something interesting I’ve noticed running Extreme Carpaccio sessions is how teams slice when someone is playing the role of product owner and when there are only developers in the audience. Generally, developers tend to release once the whole implementation is ready. Product Owners usually gather developers around a slicing strategy and prioritize user stories in order to earn money (points) as soon as possible.

However, an interesting fact that sometimes happens when there are mainly developers in the audience is that they try to hack the server as well as other teams. Personally, I find this great because it pushes people to think out of the box. Generally, participants try to hack their own friends and someone they don’t know only when we’ve established together from the beginning that “everything is possible”. Some hacks I’ve faced were DDoS against the server or someone sending fake requests trying to usurp server’s identity.

Extreme Carpaccio sources are available on Github. If you run an Extreme Carpaccio session share your feedback on a blog post or on Twitter.

Posted in Agile | Tagged , , , | Leave a comment

Java Performance: what developers must know

Developers (me included) generally focus more on make it work and make it right and less on make fast. Consequence: our applications slow down, and frequently we realize that too late.

In this presentation, I list some tips that helped me to find, fix and prevent from performance issues.

Posted in Java, Speech | Tagged , | 1 Comment

Java: Inner Classes

Since Java 1.1, when inner classes were first introduced, they have started a lot of discussion. Some people like them and find them useful. Others hate them. Viewpoints apart, the fact is that inner classes can be efficient in many situations and it is possible to write clean code using them.

Basically, inner classes give us the possibility to define one class within another. In general, we divide classes in four groups:

  • Inner classes
  • Anonymous inner classes
  • Method-local inner classes
  • Static inner classes

Examples showed on this post were built using a JDK 6.

Inner Classes

Inner classes are mostly used when some pieces of the code are intimately tied. A chat application is a good example. When someone is chatting, the application needs to handle a couple of things in background, like, listening and writing into sockets, reading messages from text fields, sending messages when the “Send” button is pressed, and so on. The handlers (the Java components that help us to send and receive messages) are strongly tied to specific instances of the chat client’s components. These handlers need to access members of a specific component instance, like buttons, text fields, etc. Thus, we tend to implement these handlers as inner classes such  way they share a special relationship with its outer class instance. As the inner class is part of the outer class, it can access the private members of its outer class.

Following an example of an inner class.

public class OuterClass {
    private int index = 0;

    class InnerClass {
        public void printIndex() {
            // Because the inner class is a member of the
            // outer class, it can access its private members
            System.out.println("Index: " + index);
        }
    }
}

Compiling the above example will produce two class files:

OuterClass.class
OuterClass$InnerClass.class

The inner class has its own class file. Nevertheless, it is not possible to execute the inner class file in the usual way by doing java OuterClass$InnerClass.  Because a simple inner class cannot have static declarations, it is not possible to put a main method on it.

The only way to access inner classes members is through an instance of the outer class. This is only possible at runtime when there is an instance of the inner class tied to its outer class. In other words, an inner class instance cannot stand alone without an outer class instance.

Following an example of an outer class using an inner class.

public class MyOuterClass {
    private int index = 0;

    public void usingInnerClass() {
        // The only way to access MyInnerClass instance is
        // through MyOuterClass instance.
        MyInnerClass innerClass = new MyInnerClass();
        innerClass.printIndex();
    }

    class MyInnerClass {
        public void printIndex() {
            // Because the inner class is a member of the
            // outer class, it can access its private members.
            System.out.println("Index: " + index);
        }
    }
}

But, it is also possible to call methods of inner classes directly from a static context. As every inner class instance is tied to its outer class instance, we need an outer class instance for this. Let’s see an example:

public class InnerClassAcessor {
    public static void main(String... args) {
        MyOuterClass.MyInnerClass myInnerClass = new MyOuterClass().new MyInnerClass();
        myInnerClass.printIndex(); // will print Index: 0
    }
}

Is this magic? No, it’s only the keyword new called from a class instance. Instantiating an inner class is the only case in which we can call new on an instance, rather than invoking new to construct an instance. This is a special way to instantiate inner class from outside the class it lives in.

Finally, since the keyword this always refers to the current object instance, the same keyword used within an inner class refers to the instance of the inner class itself. So, when an inner class needs to refer to a member of the outer class, it needs to use the NameOfTheOuterClass followed by .this.

public class SecondOuterClass {
    private String classAlias = "outer alias";

    class InnerClass {
        String classAlias = "inner alias";

        public void printAlias() {
            System.out.println("Outer: " + SecondOuterClass.this.classAlias);
            System.out.println("Inner: " + this.classAlias);
        }
    }

    public static void main(String... args) {
        InnerClass innerClass = new SecondOuterClass().new InnerClass();
        innerClass.printAlias();    // will print   Outer: outer alias
                                    //              Inner: inner alias
    }
}

Anonymous inner classes

Anonymous inner classes are called “anonymous” because they don’t have a class name. Anonymous inner classes can be used in many situations: inside a method, as a class member or even as a method argument.

Following an example of anonymous inner class defined inside a method.

abstract class Bird {
    abstract void fly();
}

public class AnonymousInnerClass {
    public static void main(String... args) {
        Bird bird = new Bird() {
            @Override
            void fly() {
                System.out.println("Flying...");
            }
        };  // Semicolon required!

        bird.fly(); // Will print Flying...
    }
}

It is important to remark that when using anonymous inner classes as a class member or a local variable inside a method, the semicolon is required at the end of the class instantiation. If the semicolon is omitted the code does not compile.

Anonymous inner classes are available in two flavors. The first one is called anonymous subclass. Anonymous subclasses are created extending a class. The second flavor is called anonymous implementer and is created when implementing anonymously an interface.

Another point to be mentioned is that methods defined inside anonymous inner classes other those overridden from the super class or the interface cannot be called from the outside. Since Java is a strongly typed language, only methods defined by the type can be called. 

Method-local inner classes

Simple inner classes are defined inside a class, more specifically inside the curly braces of a class. Method-local inner classes are inner classes defined inside methods and can be used only with the method they are defined in. There is no other piece of code (inside another method or class) that can instantiate a method-local inner class.

public class MethodLocalInnerClass {
    private int x = 10;

    void printFromInner() {
        class InnerClass {
            public void printX() {
                System.out.println("x=" + x);
            }
        }

        InnerClass innerClass = new InnerClass(); // must come after the class
        innerClass.printX();
    }
}

On the other hand, there is an interesting point here: method-local inner classes cannot access the local variables of the method the inner class was defined in (trying this will produce a compiler error). The reason is simple: as the local variables of the method live in the stack, they exist only during the method execution lifetime. So, if an instance of a method-local inner class is passed to another class and it is being used there, when the method ends, its local variables don’t exist anymore. The only way to use method-local variables inside method-local inner classes is declaring them final. Once it has been assigned, the value of the final variable cannot change. This allows the Java compiler to “capture” the value of the variable at runtime and store a copy as a field in the inner class.

class MethodLocalInnerClass2 {
    private int x = 10;

    public static void main(String... args) {
        MethodLocalInnerClass2 clazz = new MethodLocalInnerClass2();
        clazz.printFromInner(); // will print x=101
    }

    void printFromInner() {
        final int y = 1;
        class InnerClass {
            public void printX() {
                System.out.println("x=" + x + y);
            }
        }

        InnerClass innerClass = new InnerClass(); // must come after the class
        innerClass.printX();
    }
}

And only to remember, local variables rules are also applied to method-local inner classes and they cannot be declared public, private, static, protected, transient, etc. Only abstract and final are allowed.

This question on stackoverflow brings some good examples about the use of method-local inner classes.

Static inner classes

Static inner classes or static nested classes are members of the outer class that can be accessed from a static context. In this case, static inner classes can be accessed like any other static member, without having an instance of the outer class.

On the other hand, there is also another point with static inner classes. Unlike the other inner classes, static inner classes don’t have any kind of special relationship with the outer class, except the namespace. In other words, they cannot access non-static members of the outer class.

class HelperClass {
    static class InnerHelper {
        void print() {
            doPrint();
        }
    }

    static void doPrint() {
        System.out.println("Printing from HelperClass");
    }
}

public class StaticInnerClassExample {
    static class AnotherHelper {
        void print() {
            System.out.println("Printing from AnotherHelper");
        }
    }

    public static void main(String... args) {
        /* Remark the way we create an instance of a static inner class
         is not the same as for inner classes */
        HelperClass.InnerHelper h1 = new HelperClass.InnerHelper();
        h1.print(); // will print: Printing from HelperClass
        AnotherHelper h2 = new AnotherHelper();
        h2.print(); // will print: Printing from AnotherHelper
    }
}

Note: A non-static nested class (or “inner class”) has full access to the members of the class within which it is nested. A static nested class does not have a reference to a nesting instance, so a static nested class cannot invoke non-static methods or access non-static fields of an instance of the class within which it is nested.

Posted in Java | Tagged , | 1 Comment

Carreira e TI

Esta foi uma palestra que eu dei na ComputerTec em Araguari-MG (Brasil) no dia 17 de fevereiro de 2012.

Junto com o pessoal da empresa, conversamos sobre a carreira do profissional de TI e as tendências do ramo. Foi um dia bem legal!

Posted in Speech | Tagged , , , | 2 Comments