Tarin Gamberini

A software engineer and a passionate java programmer

The Scrum Guide 2017 in Italian

On August I passed the Certified ScrumMaster exam at SCRUM Alliance. To get ready for the exam I had studied the Scrum Guide and I had noticed that it was available in Italian too.

Reading the Italian translation I realized that I could have contributed to improve it further. Therefore on July I got in touch with Francesco Lomonaco, the maintainer of the Italian Scrum Guide, who very kindly gave me his willingness to cooperate for an update of the translation.

ThoughtWorks Technology Radar vol. 17 in Italian

I have always been enthusiastic about the ThoughtWorks Technology Radar both because of the idea in itself and because of its implementation in the form of radar.

The Technology Radar is a document which gathers substantial changes in IT technologies of interest to various ThoughtWorks teams. The Radar is written by the ThoughtWorks Technology Advisory Board (TAB), made up of senior technologists at ThoughtWorks, which regularly meet themselves to talk about technology trends that significantly impact our industry.

The implementation in the form of radar is characterized by four quadrants: techniques, platforms, tools, languages & framework; and four concentric levels (from outside to inside): hold, assess, trial, adopt. The various moving technologies appear on the Radar as blips: the closer the blip is to the center, the more it is qualified to be of worth by ThoughtWorks.

The ThoughtWorks Radar contents summarise the essence of the TAB meetings, and its format effectively communicate contents to a wide range of stakeholders, from CIOs to developers.

As I did last year, this year too I contributed to the Italian translation of the ThoughtWorks Radar.

A more communicative Builder

The Builder pattern [1] is a good choice when designing classes whose constructors have more than a handful of parameters, not only because is less error prone in case of identically typed parameter, but also because it is more readable from the client [2]. For example, instead of instantiating an Application object with its constructor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class Client {
    ...
        Person legalRepresentative = getLegalRepresentative();
        Company beneficiary = getBeneficiary();
        Person notary = getNotary();
        Person localOfficial = getOfficial();
        Company centralOffice = getOffice();

        Application application = new Application(
                legalRepresentative,
                beneficiary,
                notary,
                localOfficial,
                centralOffice);
    ...
}

we could use an ApplicationBuilder or, if the builder is an Application inner class, an Application.Builder as:

My Comments about «The Rise of Test Impact Analysis»

I have red the article The Rise of Test Impact Analysis by Paul Hammant finding it very interesting.

I agree on the fact that developers might feel slowed down when tests execution on the development machine takes too long. Comprehensibly they might tend to not executing tests before commit, relying on tests running later on a continuous integration server. That fact might slowly drift developers off good Agile practices.

The article reports some «conventional strategies to shorten test automation» before describing «Test Impact Analysis». Test Impact Analysis (TIA) is a technique that helps determine which subset of tests execute for a given set of source code changes. The way by which the tests subset is determined starts with a code coverage or instrumentation phase, and finishes building a map which associate, for each entry, a test with the source code methods it will cover during its execution. TIA avoids executing all tests because it enables only the execution of the relevant ones.

I have just attended a Scrum Master course

I have just came back from a three days Scrum Master course taught by Craig Larman.

The teacher told us so many things, and some of his experiences and insights, that is quite impossible reporting all of them in a blog post. However I share with pleasure one of his clarification about the meaning of the Scrum value: commitment.

Testing with the appropriate injection

Times ago I added some new functionalities to a Spring-based web application.

After some changes a unit test failed. The cause was a missing bean which stopped the auto-wiring process while Spring was loading the application context.

The test declared its own application contest, by using the annotation @Configuration on a static inner class; there were some mocked beans, so I added the missing bean:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class MyClassTest {

    ...

    @Configuration
    static class ContextConfiguration {

        @Bean
        public MissingBean missingBean() {
            return new MockMissingBean();
        }

        @Bean
        public ThatBean thatBean() {
            return new MockThatBean();
        }

        @Bean
        public ThisBean thisBean() {
            return new MockThisBean();
        }

        ...
    }

}

Then I changed other classes adding other auto-wired beans, new methods, and the like, till when the same test that had failed before failed again!

ThoughtWorks Technology Radar in Italian

I have always been enthusiastic about the ThoughtWorks Technology Radar both because of the idea in itself and because of its implementation in the form of radar.

The Technology Radar is a document which gathers substantial changes in IT technologies of interest to various ThoughtWorks teams. The Radar is written by the ThoughtWorks Technology Advisory Board (TAB), made up of senior technologists at ThoughtWorks, which regularly meet themselves to talk about technology trends that significantly impact our industry.

The implementation in the form of radar is characterized by four quadrants: techniques, platforms, tools, languages & framework; and four concentric levels (from outside to inside): hold, assess, trial, adopt. The various moving technologies appear on the Radar as blips: the closer the blip is to the center, the more it is qualified to be of worth by ThoughtWorks.

The ThoughtWorks Radar contents summarise the essence of the TAB meetings, and its format effectively communicate contents to a wide range of stakeholders, from CIOs to developers.

Over the years the Thoughtworks Radar has evolved in the contents, in the graphic layout, and in the distribution in various languages; but it hasn’t been available in Italian yet. Last year, when I discovered that ThoughtWorks has an office in Bologna, the city where I work in, I wrote an email asking if I might have contributed to the Italian translation of the ThoughtWorks Radar. I received a reply from Matteo Vaccari: