QCon Sao Paulo - 2015: A short overview

So, this week I attended to QCon-SP.

The conference was great (congratulations everyone :beers:), but, I thought it would be nice to do an overview.

So, the top subjects were Microservices and Docker. A lot of Big Data too, but I like the Microservices thing more, so I didn't follow the Big Data track.

We saw a lot of company culture too, and, believe it or not, it was strongly related to Microservices.

Let me explain.

Basically, they defend small teams (5-8 people), each team owning one or more Microservices. The team is responsible for both develop and deploy those services, basically, the teams are multidisciplinary. The teams, not the people.

Also, a real Microservice should be independent. Microservices sharing the same database are not Microservices.

The philosophy behind Microservices is based on Unix Philosophy:

Of course you probably won't do that from day-1 in your new startup. You don't even know if it will work, and, Microservices add a little of complexity you might not want to pay now.

About this, two quotes by @randyshoup:

And, as expected, Docker seems to be now the pop thing to use to deploy Microservices. Even Microsoft is working on it.

There is a lot of cool things that you can do with it right now, and there will probably be more soon, like running desktop softwares inside a Docker container and freezing user space to turn on a Docker container in a "warm" state - which seems nice if you think about JVM JIT, for example.

I wish I had attended to the Docker tutorial by Jerome, but, unfortunately, that was not possible. There were very little practical stuff about Docker in talks and keynotes, but they were nice anyway.

See you next year!

Comment this post here.

Using Mockito's @InjectMocks

FYI: Like the previous post, this is a really quick tip.

Let's imagine we have two classes, and one depends on another:

Another.java:

@Log
public class Another {
    public final void doSomething() {
        log.info("another service is working...");
    }
}

One.java:

@Log
@RequiredArgsConstructor
public class One {
    private final transient Another another;

    public final void work() {
        log.info("Some service is working");
        another.doSomething();
        log.info("Worked!");
    }
}

Now, if we want to test One, we need an instance of Another. While we are testing One, we don't really care about Another, so, we use a Mock instead.

In Java world, it's pretty common to use Mockito for such cases. A common approach would be something like this:

OneTest.java:

public final class OneTest {
    @Mock
    private transient Another another;
    private transient One one;

    @Before
    public void setup() {
        MockitoAnnotations.initMocks(this);
        this.one = new One(another);
    }

    @Test
    public void oneCanWork() throws Exception {
        one.work();
        Mockito.verify(another).doSomething();
    }
}

It works, but it's unnecessary to call the One constructor by hand, we can just use @InjectMocks instead:

OneTest.java (2):

public final class OneTest {
    @Mock
    private transient Another another;
    @InjectMocks
    private transient One one;

    @Before
    public void setup() {
        MockitoAnnotations.initMocks(this);
    }

    @Test
    public void oneCanWork() throws Exception {
        one.work();
        Mockito.verify(another).doSomething();
    }
}

It does have some limitations, but for most cases it will work gracefully.

If feel like more info, read the Javadoc for it.

Comment this post here.

One more process might not be the right answer

Don't get me wrong, I do believe that some set of basic rules must exist. What I don't believe is that they are the only way of fixing things.

Warning: this article will contain some philosophical and economics boring stuff.

Introduction

I would like to start my rationale with a quote about politics I recently found which I think applies perfectly to this scenario:

The more corrupt the state, the more numerous the laws. - Tacitus

I think we can interpret this as something like "Laws are only needed when values are not present".

Given some thought, that might sound a little harsh, huh? Let's explore the subject.

Values and Economics

A well known example of absence of values is the Brazilian "culture". Here, we have a law for almost every stupid possible corner case of almost any stupid thing any stupid human being might want to do. The result is a book of laws that no one really knows nor fully understand, full of "design flaws" "hacked" to innocent bad people - or worse.

Those laws exist mostly because it's common here to take shortcuts to do stuff (like cheating other people). Looking for the bright side, people can be really creative. The other side is that a lot of people use that creativity to do bad things.

Giving this lack of good citizen values in Brazilian culture in general - which is extended to the government, we end up having a lot of laws.

This issue is also addressed in a economics book from 1944, written by Friedrich Hayek, called "The Road of Serfdom":

Friedrich Hayek

(...) De Tocqueville's prediction of the "new kind of servitude" when after having thus successively taken each member of the community in its powerful grasp, and fashioned him at will, the supreme power then extends its arm over the whole community. It covers the surface of society with a network of small complicated rules, minute and uniform, through which the most original minds and the most energetic characters cannot penetrate to rise above the crowd. The will of man is not shattered but softened, bent and guided; men are seldom forced by it to act, but they are constantly restrained from acting. Such a power does not destroy, but it prevents existence; it does not tyrannize, but it compresses, enervates, extinguishes, and stupefies a people, till each nation is reduced to be nothing better than a flock of timid and industrial animals, of which government is the shepherd.

If you ignore the government part, this can be applied to almost anything - including industries. An almost endless amount of processes and rules that "enslave" the employees in a way that might not look as enslavement at all. This is necessary, mostly, because, well... people suck.

The People

It seems obvious to me that we, as an industry, must focus in improve the people, not the process or the tools.

After all, programming is still considered by many people as a creative process, like an art or a craft. How can an artist or a craftsman do "their thing" if they cannot clear their minds because of a "network of small complicated rules" above them clouding their judgment?

David West also wrote about this in his book, "Object Thinking". He defends that the solution is, in fact, better people. His writing is way better than mine, so, I will just quote him:

"Better people" has been recognized as the most promising silver bullet for addressing the software crisis, and yet almost all of our energy has been spent on creating better tools, methods, and processes instead of better people?

And, well, there is XP.

Values, again

But, what does "better people" even mean? For me, values. Let's go back to the citizen example. One might say that to have good values as a citizen is to be honest, to follow and respect the laws, to respect other citizens and the authorities and to contribute to the country in some way.

I like to think that, to have good values as a developer is to take responsibility for your own mistakes, to want someone to review your code because you know you are not perfect and might as well commit mistakes like anyone else, to know that, like a musician, you are not paid to practice, but to create value to their customers, and, maybe more that anything else, to always want to improve as a human being and as a professional.

Rules... and Scrum

I do think that some rules are needed. Even open source projects usually have some set of basic rules to maintain the order, like, tabs or spaces, 80c, naming patterns and so on. They usually don't, thought, have a set of complicated rules that predict how to port yourself in front of all possible situations.

I like to think that good rules can be automated and almost everything else is secondary. That's why I don't like Scrum that much. For me, it's a good tool to improve one or more aspects of a given team.

For example, if the team don't talk to each other as much as they should, by adding "rules" - or ceremonies, if you like, like daily meetings, Scrum can induce the team to create the culture of talking, until they are mature enough to realize that the ceremony itself is now useless - even if it was necessary one time.

This is nothing more than a "hotfix" to the real problem: the team doesn't talk to each other as they should. Remember the very first item of the Agile Manifesto: "Individuals and interactions over processes and tools". Scrum is a tool.

The People, again

Remember that CASE tools which were promised to allow anyone to create a software by dragging some arrows and boxes? Just a few millions of dollars spent in the wrong problem.

That's why there were that flaming posts like "Agile Is Dead (Long Live Agility)". That's also why - I believe, Uncle Bob, after publishing the "Clean Code", published the "Clean Coder", which focus in improving people behavior as professionals rather than the code they write. I also like to think that that's why Agile was created, and, ironically, was corrupted into a set of certifications and tools.

That's why, after the Agile Manifesto and its "Individuals and interactions" thing, the "Manifesto for Software Craftsmanship" was created, stating, among other things, "Not only individuals and interactions, but also a community of professionals". I believe that the main focus of a community of professionals is - or at least should be, to share knowledge and experiences between their members, so everyone can improve as a professional.

Finishing

Creating a new process is usually easier than fixing the real problem. It also gives you a sense of accomplishment quickly than fixing the real problem - if ever - would. That's probably why there are more work related to fixing tools and processes than focusing in improving people who uses them.

That said, I would like to recommend you something: as a team member, doesn't matter in which role, think twice before adding that new "simple process" to your already existing set of processes. Do a root cause analysis of the problem, find the real issue and act on that. Maybe you can also do that in the already created processes and find if there is something that can be removed. Do a "clean code" in your processes. Sometimes the root cause will be just the lack of knowledge. Other times lack of communication. It might even be a one-time thing that - by definition - will never happen again. Let me know what you discover.

Literature cited

Books

Blog posts, manifestos

Comment this post here.

Introducing JVM - The Java Version Manager

Last years it becomes more and more common to work in different projects running on different versions of Java. There still some running on Java 6, and there are tons already running on Java 8.

That's nice!

What isn't nice is to change JAVA_PATH and PATH every time you work on other project.

JVM aims to help you with that.

It's basically a shell script that you load on your bashrc or zshrc. It will then listen on folder change events. If you cd to a project running on Java 7, and you have Java 8 on your PATH, JVM will do the ~magic~ for you. :sparkles:

But how it works?

Basically, JVM will search for pom.xml files. If any is found, search for a java.version property in it. If it's found, search for matching installed Java, otherwise, JVM will look for .java-version file, and, if found, try to set a matching Java version to your PATH, otherwise do nothing.

Currently, it works Mac OS X and Ubuntu only, but, of course, pull requests are welcome.

For further info, take a look at the project's README.

Comment this post here.

Dump a PostgreSQL table as insert statements

FYI: Like the previous post, this is a really quick tip.

This week I'm working closely to the "front-end guy". Not that I don't know how to front end, but he is helping me.

We are developing an internal tool, that, for this first version, will use only a few tables of one of our databases.

Doing the "back end" part of it, I created tons of rows in my local database, and, in order to properly test the front end part, the "front end guy" needed some data. He could just create a lot of rows in that table. That would be easy. And boring. And inaccurate.

Dump an entire database is also boring, and usually takes a lot of time. Besides, he only needs one table.

So, I dumped that one table in the form of inserts. pg_dump, with some parameters, can easily do that:

pg_dump \
  -h localhost \
  -p 5432 \
  -U user -W \
  --table="table-name" \
  --data-only \
  --column-inserts \
  database-name > table.sql

So, I just had to send him this table.sql file somehow, and he had to execute that SQL file in his database, which can be easily done with the pg command:

psql \
  -h localhost \
  -p 5432 \
  -U user \
  database-name \
  -f table.sql

That's it. A quick and useful tip that I have used many times and will probably use many more.

Comment this post here.