Jazoon 2013 – 33 things you want to do better

25. October, 2013

Jazoon 2013 badgeTom Bujok listed a lot of methods, technologies and frameworks that you should be aware about in his talk “33 things you want to do better” (slides on speakerdeck)

At the beginning he reminded us how quickly a well designed system goes bad due to hurried changes. We need to be aware of our technical debt and we need to allocate time to spend on reducing it (slides 3-12).

As an example, car batteries are easy to find. They are a replacement part, designers and engineers make it easy to find. Compare this to the configuration of your project. If you need to change it, how easy is it to find the file that needs to be changed and then the place in the file?

Another important point is skills. In most other professions, you have some mastery of a skill before you use it. You train hundreds of hours before you play your first football game. In Software, we show you a computer, we show you the programming language of the year (not necessarily¬†this year’s). There is no time to master the tools you have to use from day one (slides 13-15).

“We are what we repeatedly do; excellence then, is not an act but a habit.” – Aristotle

Or as Wikipedia defines it:

“Habits […] are routines of behavior that are repeated regularly and tend to occur subconsciously.”

Stop wondering why you always make the same mistakes – they’re habits. Eliminate them ASAP (slide 19):

Bad Habits – Katherine Murdock “The Psychology of Habit”:

  • Recognize bad habits and eliminate them ASAP
  • The older you get the more difficult it is to remove a bad habit
  • Each repetition leaves its mark!

Turning bad habits into good ones – Dr. Michael Roussell, PhD.:

  • You can’t erase a habit, you can only overwrite one.
  • Insert the new habits into the current habit loops

Bad Habits

Configure your IDE properly and remove bad defaults. Replace “ex.printStackTrace();” with “throw new RuntimeException(ex.getMessage(), ex);” (slides 43-45).

One bad habit is empty catch blocks with “can never happen” comments. If you see one during a code review, replace it with “System.exit(-1);”. It can never happen, right? Right? (slides 46-47).

Note: I have create a “ShouldNotHappenException” for this case ūüôā

Another one is to make every method in a static helper class public. Maybe some of them can be package private? (slide 48)

Learn about other good habits. Read books like “Effective Java” (Joshua Bloch) and “Clean Code” (Robert C. Martin) (slide 49)

Use code reviews to notice bad habits and to spread knowledge in your team but prevent blame games. (slide 73)

Learn the keyboard shortcuts of your IDE (slide 78)

Remember (slide 79):

“Any jackass can kick down a barn, but it takes a good carpenter to build one.” – Sam Ryburn

Projects You Should Know

Project lombok and lombok-pg РIn a nutshell, these hook into the Java compiler and generate additional bytecode when certain annotations are present. Bored with getters, setters, hashCode() and equals() plus a nice toString()? Use @Data (slides 21-28).

Guava (slides 29-33)) is a great library with many tools that you have been missing in Java for years. You might also want to look at commons-lang.

Want to use lambda expressions but can’t upgrade to Java 8? Then lambdaj¬†is for you (slides 34-39).

Logging? slf4j (40-42). Especially nice when combined with the @Slf4j annotation from lombok.

Bored to write all that boiler plate code to create all those services and managers that form your app? Look at Guice or Spring.

Use Spock to make tests more compact and easier to understand. (slides 50-52)

Unitils contains all the helper functions that we always missed in JUnit and Hamcrest (53-56).

JUnitParams will help you run tests with different parameters (57-59).

Need to wait for something during a test? Awaitility will help. (60-61)

When mocking isn’t enough and you need to inject code during a test, Byteman is the tool you want to look at (62-63)

Getting bored writing boiler plate code in Java to make a compiler happy? Have a look at Groovy. (64-67)

How about adding dependencies to your scripts? Try Grape. (68-69)

Is your build a mess? Do you feel Maven is too verbose or too limiting? Gradle might be for you. (70-72)

Version control is slowing you down? Have a look at Mercurial or Git (75)

Use bash or Python to automate man-/menial work. If you’re on Windows, look at Babun or Cygwin. (76-77).


MercurialEclipse 1.8 With Mercurial 1.9 On Ubunutu

10. August, 2011

The MercurialEclipse plugin doesn’t play well with the latest 1.9 release of Mercurial.

If you’re on Ubuntu, you can replace the “mercurial” package with “mercurial-1.8” to get the old version back (see Launchpad packages). Thanks go to Max Bowsher for a quick solution:

sudo aptitude install mercurial-1.8

Getting MercurialEclipse 1.7.0

27. November, 2010

Wondering why Eclipse suddenly asks for a password for cbes.javaforge.com? Someone decided that it was a good idea to request users of MercurialEclipse to create accounts on JavaForge.

Not impressed? Go here instead.


hg convert and “abort: Interrupted system call”

20. May, 2010

If you get “abort: Interrupted system call” when running “hg convert”, then see this issue for a workaround.


Using Mercurial with Dropbox

17. April, 2010

If you want to take a Mercurial repository with you, you have several options:

  1. Create a server somewhere. Don’t forget to install all the security patches.
  2. Use an USB stick. Don’t forget it somewhere (like at home) and don’t forget to always push your changes onto it.
  3. Use Dropbox

Dropbox is a file server in the cloud. While they swear your data is save (“All files stored on Dropbox servers are encrypted (AES-256) and are inaccessible without your account password.” – see the features), it’s better to be safe than sorry. Also, Dropbox can’t really cope with the fast changes to the virtual filesystem done by Mercurial (this will lead to corrupt repositories and missing changesets).

The solution is to create a TrueCrypt container in your Dropbox. Dropbox won’t be able to see any changes as long as the container is mounted. When you dismount the container, Dropbox will check the file for changes (if you write to the container, TrueCrypt just modifies a few sectors). So even if you create a 100MB container, only the initial sync will be slow.

There are few obstacles, though:

  1. You must remember to mount the container, and push your changes into it.
  2. If you forget to dismount and push changes into the container on a different computer, you’ll see two containers. In this case, mount the second container somewhere, merge the changes using Mercurial and then commit to the original container.
  3. You must install TrueCrypt and Dropbox on all computers where you want to use this.
  4. The cycle “mount-push-dismount” becomes tedious over time.
  5. If you use HgEclipse, the plug-in will forget the local paths if you forget to mount the container before you start Eclipse.

Confused by DVCS? Joel can help

22. March, 2010

In his last article, Joel talks how DVCS confused him and how he solved the problem. One sentence in particular should be noted:

these systems think in terms of changes, not in terms of versions.

Still confused? Read his HgInit tutorial to get you up to speed with Mercurial (or any other DVCS because they are all pretty similar at that level).

PS: I prefer Mercurial to Git for twothree reasons:

1. I need a working DCVS, not a toolbox to build one. I prefer it when a smart guy has given all the hidden issues some thought, so I don’t have to.

2. There is a simple, working Windows installer.

3. It’s written in Python.