Some hacky things to know about the Kindle Paperwhite

Hi everyone!

Here’s one more note for myself and for everyone. I can’t forget anything of these not-that-easy things about the Paperwhite e-reader.

If you want to disable the screensaver, tap the search box and type in ~ds, the acronym for don’t sleep. I guess. Or disable screensaver? Who knows… but hey, they’re good hints, aren’t they?

To change the timezone of the device, in case you need the Javascript of the Experimental Browser to successfully convert timestamps to Date, you have to setup the timezone in your Wi-Fi router. That’s mad!

This is how the timezone selection looks in my router
This is how the timezone selection looks like in my router

If you are wondering why I needed that, it’s just to convert the Kindle reader in a weather station. Feel free to check my mad repo on GitHub to know more. And happy hacking!

Install Tomcat 8.5 on Debian 9 with Java 8

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.

apt-get update &&
apt-get -y upgrade &&
apt-get -y install ntp cron htop tomcat8 tomcat8-admin

Then, just change the content of the Tomcat users file:

vim /etc/tomcat8/tomcat-users.xml

And append this content:

<role rolename="admin-gui"/>
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<user username="YOURUSER" password="YOURPASSWORD" roles="admin-gui,manager-gui,manager-script"/>

Restart Tomcat… et voilá!

/etc/init.d/tomcat8 restart

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.

vim /etc/cron.daily/fewlaps-disk-cleaner

rm -rf /var/log/tomcat8/*

Note that the last * mark is important. If we delete the whole directory instead of the contained files, Tomcat will not start anymore. That’s not exactly production-ready. Finally, give execution permissions to that script.

chmod +x /etc/cron.daily/fewlaps-disk-cleaner

Nice! Now, in case you want to monitor this brand new Tomcat via JMX, you’ll need to enable JMX. Internet is full of answers, but this one will be specific for Tomcat 8.5 on Debian 9. Everyone will have Tomcat installed in the same place, so let’s make something copypasteable. The thing is to create a new file with a new line that sets CATALINA_OPTS, and two files to authenticate a user to monitor the instance and another one to control it.

vim /usr/share/tomcat8/bin/


vim /usr/share/tomcat8/jmxremote.access

readonlyusername   readonly
controlusername    readwrite \
              create*,* \

vim /usr/share/tomcat8/jmxremote.password

readonlyusername  READONLYPASSWORD
controlusername   WRITEPASSWORD

chown tomcat8:tomcat8 /usr/share/tomcat8/jmxremote.*
chmod 400 /usr/share/tomcat8/jmxremote.*

And that’s all! I will update this post if I detect something to improve. Guys behind Debian 9: THANKS! You made my life easier.

Introducing EDD

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:

What I feel when opening a Presenter class for first time

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.

Ideas about Android engineering

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…

… and that’s all! Just a small post launched to the world!

Let’s talk about commit messages

… or look at this great Chris Beams post:

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.

Thanks Chris :·)

Why I don’t like rebasing

Hi @channel!

Last weeks I worked with 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 a very committed team that loves living at risk, 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.