Author: rocboronat

Hey folks! Do you remember the hard ages when you have to install Java and Tomcat by hand when setting up a new Debian server?

Now, I tried setting up a Tomcat 8.5 server just using apt-get commands, and it works! So, here’s the list of commands that you (and me in the future) have to run when setting up a new Debian 9 + Java 8 + Tomcat 8.5 server.

Nice! Our environment is ready for production. But… just until the disk becomes full of logs. So, let’s clean the Tomcat logs daily. As we installed cron previously, we can create a script under /etc/cron.daily to remove those huge log files.

Do you know EDD? EDD means Error Driven Development, aka “Write a test to reproduce the bug before fixing it”. That sentence leads the InfoJobs’ app to the zero bugs dream. And here are some slides to help me spread the idea to Schibsted’ teams:

In this list of public methods, which ones are just handling the View’s events?

When you open a new Presenter that has several methods, it’s a pity to see a lot of methods. You feel overwhelmed of don’t know the flow of the screen. What methods are handling a View’s event? What methods are really doing Presenter business?

Please please please, when writing a Presenter, just call the methods that receive events onSomething(). Instead of login(), onLoginButtonClicked(). That way leads to easy knowing what are the View events that this Presenter has to manage. And, the best of it, when following this rule, it’s easier to write tests. In your tests, you should just call onSomething() events and verify that some View methods are called with the expected values.

And remember: the View has to be dumb. Just forwarding View events to the Presenter, and just offering methods to the Presenter to do View things. The Presenter is the responsible of actually doing the business of that screen, so the View has to be responsible of doing what the Presenter expects from it.

I need a place to put some ideas about developing Android apps in a clean way.

As we want to test our domain in a quick and simple way, we need to write code testable with just the JUnit framework. We need to avoid using Roboelectric, PowerMock and that kind of frameworks, as they are not simpler than just avoiding them :·)

How to do that? Just try to avoid depending on Android things, like the Context, SharedPreferences, SQLite classes…

Everything started ’cause I requested a colleage about stop ending the messages with a period. And then, I realised that my messages starting with “adding”, “fixing” and other continous pasts doesn’t has any sense. So, I started writing in imperative.

Last weeks I worked with the Vibbo‘s Android team. Changing from one team to another one is great to learn new things. You know everything about moving outside of the comfort zone so I will not talk about it… :·)

This article tries to list all the times that git rebase broke my heart. I know that there’s a hot conversation about merging from develop to your branch or rebasing on develop. I always merged to fix conflicts, and some members of the Vibbo crew asked me to rebase over merge, so I went forward with rebasing. In addition, I tried to spread the word to another team… and well, I regret it.

The broken heart facts:

– When you rebase on another branch, you are requested to resolve every conflict it happened, commit by commit. So, if the branches are not too small, you will be asked several times. If you resolve conflicts on ten different files, it’s ok. But, if you have to resolve conflicts ten times in the same file… madness.

– If you missed a conflict and you screwed the whole code (’cause you are not perfect, my friend), you don’t have a “merge commit” where you can find your mistake. You have rebased. No merge commit. Good luck!

– Push force will be your new friend but HEY. git push origin –force pushes your branch to origin, right? Well, yes, but only partially. In Windows (at least, the version I had) it pushes ALL your branches. So, if you had an old version of develop, you will push it and screw all your friends. There’s a –force-with-lease version in the latest versions of git but hey, it’s not the standard –force.

– The Pull Request conversation gets disordered. A common Pull Request seems a Twitter timeline. Two commits, one comment, one commit, three comments. Then, you push force your just rebased branch, and all the messages are moved to the start of the conversation and all the comments after them. Goodbye, timeline!

Conclusion: if you are alone in a project, or you work with very committed colleagues that love to life at risk and you look at the commits history every night to see its shape and colour, rebase could be a good option for you. But if you are in a real world, you are an average git user or you work with average git users… don’t rebase.

You heard about Jenkins and you want to try it. Good news: it’s so simple to do it in a production environment. So, skip trying it at your localhost and then installing it again in your production environment. The steps are these:

1. Get a production server. We use to get it at gandi.net. To build Android apps you’ll need 2GB of memory. About the number of cores: it will work with only one core, but if you can afford a machine with more cores, gradle will use them. Fewlaps’ Jenkins has two cores and it performs great.

2. Install Java 8. You can also use Java 7 but… well. At some time, someone, will write a lambda, and you will need to update to Java 8 :·)

4. http://yourserver:8080 it works! (note that it’s not too fast starting the daemon)

5. Install git, mercurial… All the things that Jenkins will need to pull your projects from your repos. You know:

apt-get install git
apt-get install mercurial

… and so on

Important: before creating any Job, check your security configuration. Create an user for you, another one for every colleague, and grant them the needed permissions. Also check that “anonymous” doesn’t have any permission, and that the “users can register to the environment” box is not checked.