Review: Talking Carl

Talking Carl is a simple application you can get from AppStore. Its idea is very simple. You’ll get Carl on your screen and if you touch him, tickle him, pinch him, he will react funnily. If you speak to him, it will repeat your sentence with funnier voice. It’s hilarious and both of my kids love it, even the one who is not yet 1 year.

It will be better if they add more interactions in the future though, like the background adjusted to the time of the day and something to see when we shake the device.

Anyway… it’s highly recommended.

multitail: colorize your log files

Love watching those log file flying on your screen? How about having that WITH color?

MultiTail is small program that exactly does that. This application is available in *nix system and mac users can even use it from Macports.

According to the website, the program is released with many color schemes for different log formats including: Postfix, Apache, RSStail, Acctail, WTMPtail, Squid, Asterisk, Sendmail, Mailscanner, Samba, Exim, HTTPing, TCPdump, ISC-DHCPD, Bind, Smartmontools, Kerberos, NTPd, nagtail, WebSphere (SystemErr), NNTPcache, Veritas Netbackup procmail, Checkpoint Firewall-1, Netscape directory server (LDAP), log4j, ClamAV, p0f, sysstat, portsentry, pppd, strace, Linux firewall (netfilter) logging, Argus, Snort, Motion, IBM AIX errpt, MySQL error log, BOINC, acpitail, netstat.

Java Tips: Using generic correctly

Generic is very powerful tools, it allows us to get errors that usually only happen in runtime to compile time like the usual type error.

Generic is also very tempting and in normal case, is very easy to use in daily programming. But without a good thinking, we normally will lose the actual power of generic. Let’s we start with this bad news.

The last article I referred on article Java Tips: Iterate and cast is one example where we wrote a Java code using generic but not optimally. The code is as follow:

@SuppressWarnings("unchecked") public static <X> X cast(Object o) {
    return (X) o;
}

What’s wrong with that? PPOW show the wrong cases to us.

Number telephoneNumber = cast("1234567");

session.setAttribute("digits", setOfDigits);
List<Character> characters = cast(session.getAttribute("digits"));

String authorName = cast(session.getAttribute("authorId"));

The errors that we usually get in compile time are missed and can only be get in runtime.

How to make it correct? It is actually pretty simple if we think it through. The essence of casting is to specify that certain superclass that we have is actually a subclass. This relationship is important. Knowing that we know that the argument of the method should be superclass of the result, and not an arbitrary object. So we can fix our method cast like following.

@SuppressWarnings("unchecked") public static <T, X extends T> X cast(T o) {
	return (X) o;
}

And now try all the cases PPOW suggested and we will get an error in compile time. That’s good!

The last case PPOW suggested in the article is not really valid because even using a not tricky techniques, the error will only be happen in runtime. These codes compile correctly but all have problem in runtime.

Using original code:

// Because of an error we cast it to a map of String to String
Map<String, String> badMap = cast(session.getAttribute("map"));

// we pass the map between many objects and doing many operations on it
String s1 = badMap.get(1);
badMap.put("2", "2");
String s2 = badMap.get("2");
String s3 = badMap.get(2);
String s4 = badMap.get(123);

Using modified code:

// Because of an error we cast it to a map of String to String
Map<String, String> badMap2 = cast2(session.getAttribute("map"));

// we pass the map between many objects and doing many operations on it
String s1a = badMap.get(1);
badMap.put("2", "2");
String s2a = badMap.get("2");
String s3a = badMap.get(2);
String s4a = badMap.get(123);

Using normal cast:

// Because of an error we cast it to a map of String to String
Map<String, String> badMap3 = (Map<String, String>)(session.getAttribute("map"));

// we pass the map between many objects and doing many operations on it
String s1b = badMap.get(1);
badMap.put("2", "2");
String s2b = badMap.get("2");
String s3b = badMap.get(2);
String s4b = badMap.get(123);

As you can see, generic is easy to implement, but to implement it correctly is not that easy. I really suggest to read the white print of generic which honestly, I still don’t understand the whole of it. The latest edition of Effective Java also has some tips to work with generic.

Learn generic, it is worth it!

Kindle DX goes international

As correctly predicted by BlogKindle, the Kindle DX is not shipped internationally. It’s pretty obvious that the reason behind this is to keep the momentum as high as possible.

Beside the size and price (of course), the only difference that I can see is only that the DX supports auto rotate. The price is $489, with shipping and custom it is $606.88 to Germany. Compared to the smaller version’s price of $343.33, it seems so expensive.

And no, Indonesia is still not in the list of shipping destinations.

My Eclipse Code Formatter

A consistent code format across the project is one sign of a maintainable project. Almost all of Java IDEs provide a way to format your code, but in my opinion, Eclipse does deliver the most customizable Java formatter. Many aspects from the code can be configured using the tools.

Lately the format used by Kevin Bourrillion caught my eyes. Among other things, he chose to use method annotation without any line break. So instead of:

    @Deprecated
    @Override
    public void bar(@SuppressWarnings("unused") int i) {
        @SuppressWarnings("unused")
        int k;
    }

he used:

    @Deprecated @Override public void bar(@SuppressWarnings("unused") int i) {
        @SuppressWarnings("unused")
        int k;
    }

And for an empty constructor or an empty method, instead of the standard:

private Casts() {
}

he used:

private Casts() {}

At first, I don’t really like it, but after working with Google Collections, this format seems make sense. It reduce the number of lines and make the code a lot easier to read. Yes, the line will be longer, but today’s programmers seem to use a big monitor anyway, right?

Now I know that he uses IDEA for his IDE and he doesn’t publish his code style in the Google Collections or Google Guava, but I also don’t want to copy his style 100%, so I made my own custom style and publish it in GitHub: http://github.com/enefem/eclipse-config

You can download the style there and import it to your Eclipse. And by the way… Git rocks!

I almost forgot. Unfortunately Eclipse has a bug in the code formatter. If you use my style and you have a method or constructor that contain only comment(s), the formatter will give a result:

public Thread() {
// TODO Auto-generated constructor stub
}

Which should be:

public Thread() {
    // TODO Auto-generated constructor stub
}

I’ve reported this and you can also use the patch I provided there.

Please let me know if you have special style that I might be interested in!