Code Monkeyism

Who wins the Olympics?

Considering the fact that the swoosh is the most shown icon of the Olympics, guess who has won?

My MacBookPro is kaputt

… since several days :-(

Hg gets rebase

Hg gets rebase. Though from the comments it’s not yet up to git, add “Killer features for Git are git rebase [...] ;s/Git/Mercurial/g” to the Mercurial part of my comparison post and remove “[...] no rebase [...].”.

Response to the critique for my last post and OneElementIterator

I’ve wrote an update to the post where someone suggested in a trackback to use the JDK for an one element iterator.

I got interested in aa OneElementIterator, which optimized - not sure how fast try is - could look like this:

public class OneElementIterator[T] implements Iterator[T] {
  private T element;

  public OneElementIterator(T element) {
    this.element = element;
  }

  public boolean hasNext() {
    return element != null;
  }

  public T next() {
    try {
      return element;
    } finally {
      element = null;
    }
  }

Faster and shorter ideas?

Update: Remove got lost during cut & paste:

  public void remove() {
    // not supported, throw exception
    throw new UnsupportedOperationException("Remove not supported in OneElementIterator");
  }

And as Eugene noted next() should throw NoSuchElementException .

“For” hack with Option monad in Java

There has been some discussion going on in the blogosphere about monads, and especially about the Haskell Maybe monad or the Scala option class. Those are ways to prevent problems with NULL and NPEs that Java lacks. Java returns NULL form many methods to indicate failure or no result. Suppose we have a method which returns a name:

String name = getName("hello");
int length = name.length();

The problem with this method is that we don’t know if it returns null. So the developers needs to deal with length == null, though the compiler doesn’t force the developer to deal with the returned NULL. A lazy developer then leads to null pointer exceptions. Other languages deal in different ways with this problem. Groovy has safe operators and Nice has option types.

Some posts like the one from James show how to use options in Java. All have the problem that you need to unwrap the value inside the option / maybe. Scala ans Haskell do that automatically for you, with the case classes in Scala for example.

But there is a construct with syntactic sugar in Java which unwraps the value from inside another class: the for loop from Java 1.5.

Option[String] option = getName("hello");

for (String name: option) {
	// do something with name
}

To make this work we need our option class to implement Iterable.

public abstract class Option[T] implements Iterable[T] {
}

And the None and Some sub classes to return an empty iterator

public abstract class None[T] extends Option[T] {
  public Itertator[T] iterator() { return EMPTY_ITERATOR; }
}

or an iterator with one item.

public abstract class Some[T] extends Option[T] {
  public Itertator[T] iterator() {
    // or better use google-collections
    List[T] list = new ArrayList[T]();
    list.add(this.value);
    return list.iterator();
}

Then voila Java does the unwrapping for us and instead of

Option[String] option = getName("hello");
if (option instance of Some) {
    String name = ((Some) option).value();
} else { ... }

we can write (sacrificing the else):

for (String name: getName("hello")) {
	// do something with name
}

Thanks for listening.

Update: Completely ignoring the point of this post, Euxx posted a correction for the single element list creation I did.

  return Collections.singletonList(this.value).iterator();

Happens all the time in IT, people missing the point but nitpicking on something irrelevant. Other than that, if we start arguing performance, “The java.util.Collections class also have number of other utility methods that allow to shorten code like this and help to improve performance of your application.” I’d write (or reuse) a OneElementIterator something like this (could probably be optimized with some further thinking)

public class OneElementIterator[T] implements Iterator[T] {

	private boolean done = false;
	private T element;

	public OneElementIterator(T element) {
		this.element = element;
	}
	public boolean hasNext() {
		return ! done;
	}
	public T next() {
		done = true;
		return element;
	}
	public void remove() {
		// not supported, throw exception;
	}
}

(Or again using google collections)

“I can’t not notice the ugly use of ArrayList to create collection with a single element, but what made matter worse, is that author suggested to use 3rd party library to replace those 3 lines of code.”

As far as I know, the JDK does not help you very much with Iterators or Iterables as third party libraries do. So, yes, I’d suggest using a third party library to implement an Iterator/Iterable for Option.

Hg versus Git - and why I did chose Hg

After my unpleasant experience with setting up Git, I’ve had some time to play around with Git and use it in a project. Git is really nice for a DVCS. What I like was the git status view, especially with colors turned on. Grouping added and modified files is much nicer than the Subversion style “A”, “D” (…) list. What I also like is that Git is fast. And not very difficult to use for day-to-day jobs, with tutorials like the Svn-Git Crashcourse. Killer features for Git are git rebase and especially branching. Git is different to other VCS that it uses revisions and branches as views to a directory. Other VCS - like HG and SVN - use different directories for different branches. This makes it much harder to jump between those branches. Git seems to have the biggest community, mindshare and momentum to become the next SVN/CVS.

What made it unusable for me was the Windows port. It just does not work reliable. Cygwin is a problem in it’s own. Msysgit isn’t up to par neither. I use a MacBookPro so Git works for me, but others who needed to access the repo from Windows were out of luck. Windows support isn’t very high on the list of Git priorities - perhaps because it’s linked to Linux kernel development.

Now to Mercurial. It seems to have the second biggest mindshare (more than bzr) after Git. Some big Java projects use it and there are some good blog posts about Mercurial. So I gave it a try. The setup was easy for a central server over http, it just worked after following the instructions. It’s command style is more like SVN than Git so the learning curve is even shallower than with Git. It works with Windows, the main reason for me the switch to Hg from Git. The downsides: SVN style hg status, no rebase and SVN style branches. Nice that hgignore is just a file in the repo and accessible by all developers (Maven target and generated files).

Should Git become usable under Windows, I’ll probably move again.

(My personal take is, SVN will become a DVCS by adding local repos, moving to hash revisions and eat the DVCS market)

Thanks for listening.

Update: I forgot about that post:

For Subversion 2.0, a few of us are imagining a centralized system, but with certain decentralized features. We’d like to allow working copies to store “offline commits” and manage “local branches”, which can then be pushed to the central repository when you’re online again.

I want to meet Cameron Purdy ;-) Who do you want to meet?

Partially because of the good discussions on TSS about Coherence and the knowledge he has, but mostly because of this recent presentation. It’s about “The Top 10 Ways to Botch Enterprise Java Application Scalability and Reliability”. I’ve enjoyed the video very much and laughed several times so loud my colleague looked up. Cameron made a joke every 30 secs - noone laughed in the audience though I found them all funny.

Meeting Cameron - well no chance - I know - and I wouldn’t know what to say.

Others I’d like to meet are above all Crazy Bob for Dynaop (and Guice), Cedric for his stand on dynamic languages and Rickard of course.

Whom do you want to meet and why?

“Yahoo will go down in flames”

Funny, I wrote that more than a year ago.

Update 10/24/08: Looks more and more likely

Using Google Guice Providers to Solve Law of Demeter Problems

A post on the Google testing blog made me think. Their post presents an example of a class

class Mechanic {
 Engine engine;
 Mechanic(Context context) {
   this.engine = context.getEngine();
 }
}

which depends on an object Context in the constructor, when indeed it only depends on Engine, a violation the law of demeter. This often happens with Context objects which play the role of a central object repository to give access to objects in different parts of an application. The resulting code is hard to test and hard to reuse and the Google testing team suggest refactoring the code.

Sometimes that’s not possible. With IoC this can be solved without (much) refactoring.

For example with Google Guice one can write a Provider that provides an object of a given class, in this case Engine.

public class EngineProvider extends Provider<Engine> {
    private Context context;

    @Inject
    public EngineProvider(Context context) {
       this.context = context;
    }

    public Engine get() {
       return context.getEngine();
    }
}

Binding the Provider to Engine,

  bind(Engine.class).toProvider(EngineProvider.class);

the application will use the provider (probably from the @Request scope) to extract the engine from the context. The Mechanic can be rewritten to use Engine directly, but no other code in the potentially large application needs to change.

class Mechanic {
  Engine engine;  

   @Inject
  Mechanic(Engine engine) {
    this.engine = engine;
  }
 }

Thanks for listening.

Update: Are more clever Provider could support the NullObject Pattern.

 public class EngineProvider extends Provider {
     private Context context;  

     @Inject
     public EngineProvider(Context context) {
        this.context = context;
     }  

     public Engine get() {
        if (null == context ||context.getEngine() == null) {
           return new NullEngine(); // better Engine.NULLOBJECT
        }
        return context.getEngine();
     }
 }

Unscientific Jetty versus Glassfish for REST

This post was too unscientific and was updated. Jetty is an excellent container and the container of choice whenever I do something with servlets. Ever since we’ve developed SnipSnap some years ago I love Jetty. Glassfish has some very promising features like the admin console and I´m eager to try Glassfish in a project sometimes in the future.

Reading about another story of Rails performance, I grabbed JMeter to benchmark one of my current projects. Not so much as a comparison for Ruby - which managed 320 requests per second - but more as a comparison of Jetty and Glassfish.

The application is a small REST server which reads data from a JDBM storage, transforms it with my own framework to Json and delivers the result with Jersey.

Both servers were started with their default configuration through their maven plugins (wonderful easy to use mvn glassfish:run). Unscientific as it may be, the numbers are:

• around 1000 requests/sec for both containers

Both with 200 threads and 50 requests per thread. Both numbers are great for my MacBookPro and good enough for me. They also are so close to each other so they are not a deciding factor for either Glassfish or Jetty. At the risk of comparing apples to oranges I have no fear of deploying this to a production system and scaling cheap (and even better with E-Tag caching), keeping in mind the requests per second with 25 servers in the Rails example.

Thanks for listening.

Update:: Another Rails application which thinks it did scale - at least with Merb, to 650k page views per day, well that’s “650K hits per day is ‘only’ around 8 per second (assumed a 20 hour day to spike it a little). This doesnt actual seem all that much?”.

The JMeter speed and 1000req/sec (for an admittantly simple REST GET) results in … 86.4M requests per day. Uh. On my MacBookPro.

Current code coverage tools (for maven)?

What to use for code coverage? Clover seems the only option but costs (which I will probably buy when my project makes some money). Emma and Cobertura seem to be dead, IDEA code coverage doesn’t work - obviously - with maven. Any ideas?

Unpleasent Git experience

I’m too stupid for git. I’ve run several SVN servers over the years but a Sunday afternoon isn’t enough for me to get git working.

• Debian stable has git 1.4, for git init one needs 1.5. Some major reconfigurations later (think Debian backports) and updates and updates I had 1.5 working
• Lots of “fatal” errors during git configuration on the server, with no helpful explanations
• The client - MacOS X isn’t any better:git add . is followed by fatal: pathspec '' did not match any files. Perhaps git is only for Linux?

And more problems and more problems and more problems. My first SVN repo took 10min to setup and 10min for configuring the client. Voila. Perhaps git is only for the geniuses out there and I’m stuck in the 90s of SCMs.

Update: No this won’t stop me - yet. Though the thought comes to mind if mercurial would have been a better choice ;-)

Update 2: The server works and is accessible. Now I only need to fix the fatal: pathspec '' did not match any files for my local add and then push the contents to the server. Look here for help with the git backports on Debian.

Update 3: More fun: Updating remote server info PUT error: curl result=22, HTTP code=403

Update 4: I’m getting very very old, see: “I experienced these phenomena first-hand. Git was the first version control system I used, and I grew accustomed to it, taking many features for granted.”. I’ve started with RCS, or the version file system on VMS, 18 years ago.

Update 5: fatal: no matching remote head when cloning a new repository.

Update 6: Everything seems to work now!

My interview

Carl did a short interview with some software engineering guys and me in February, the results are up now:

“Java Experts: Server Side is Where Java Shines”.

Compared to the others my answers are rather short. That’s what people sometimes complain, my answers and mails are too short ;-)

The Erlang hype is grotesque

Take for example this recent post on hacker news with the title “Amazon and Google Discover Erlang (IMDB is switching from Perl to Erlang)”. There in the comments someone gives a source for the IMDB claim: “IMDb on Java/Erlang (a job posting)”. Going to the job listing results in

We are currently working in Perl but have plans to use Java, Erlang and any other language that we think will suit our purposes.

Constructing an “IMDB is switching from Perl to Erlang” (though everything is better than Perl) out of this job listing is grotesque.

As a side node, I’ve been looking into Erlang for some time but I’m still undecided. With some functional style in Java, Kilim, Terracotta and a Supervisor modul (see Scala), I guess most of the Erlang failover/distribution stuff can be done in Java too. I’m interested in CouchDB, but I have no reliability numbers and performance is said to be very low (for now?). The feature set of CouchDB is compelling though.

Ah in the end I only wish for some more functions in Java, better separation of concerns, constructors which can return any type instance, syntactic sugar like in Groovy, structural interfaces, enforced nice-style non-null references, catch(E1,E2,E3) … well well well. I’ll better stop before this turns into another How-to-improve-Java rant.

Not intellectually simulated in my school

I tried to explain them how important it was to me, since I am not intellectually simulated in my school, and how meeting other smart colege students was imporant to me.

:-)

http://prez.wordpress.com/2006/10/16/facebook-has-a-post-limit/

Erlang vs. Java benchmarking update

As an update to my last post, I didn’t find an image which goes to 100.000 tasks for performance, but the Kilim guys have a graph for creating 200.000 tasks.

Perhaps they implement an supervisor architecture too. And perhaps this makes it into a future JDK.

Update: There is also a Google talks video about Kilim on YouTube.

Interesting picture: Benchmarking Erlang versus Java concurrency

I stumbled upon a nice Java framework called Kilim. It implements message passing in Java and it’s interesting to compare to Erlang:

As I’ve said before, usually comparing Java to Erlang is stupid, because it compares threads to actors, not Java to Erlang. Comparing actors in Java to actors in Erlang is the right thing to do. Also see Scala (Which I don’t use because it won’t make it into the enterprise and I don’t like a type-inferencing language).

SMC WGBR14-N 802.11n doesn’t work with my MacBook Pro

I’ve bought a SMC WGBR14-N router as a replacement for my current Fritzbox. The FB is too slow for wireless with only a small - non replaceable - antenna. I thought I could attach my Qnap 409 to the SMC draft-n router to speed up time machine backups and copying to the NAS.

Reality: The SMC drops connections and doesn’t work with either my MacBook Pro nor the MacBook of my girl friend. Most of the time there is a time out when connecting to the SMC. Both with G and N wireless modes. WPA with 802.11g on the Fritzbox works, but not on the SMC router. Connecting by wire gets me into the internet. Next week it’s going back to the dealer and I’ll try a D-Link or Apple Extreme 802.11n router. I hope for better luck.

(Is there a way to see with which mode a mac is connected to a wireless router?)

Another Rails and dynamic language fallacy concerning missing methods

Russell writes in the post The Dynamic Language Advantage: A Concrete Example:

“All you have to do is make the call to the non-existent method that contains your column names and Rails will dynamically generate the method for you.”

Though he got quite some flak for his opinion.

@cards = Card.find_all_by_cardType_and_expirationData(cardTypeId, expirationDate)

Which looks magic to most people and most impressive. But in the end it’s not more safe or magic than

Card.find("all_by_cardType_and_expirationData", cardTypeId, expirationDate);

This code can easily be written in any static language, becasuse the method missing property is no more safe or expressive than a String. The idea that parsing a method name from method missing is different than parsing a String in this case is a fallacy. I wonder why not more people use Strings like this to create finders? Perhaps because it’s not a good idea, as some comments in the mentioned post claim?

Thanks for listening.

The only thing that really matters in software development.

Catchy title? I mean it. After 25 years of programming, the only thing that really matters in software development is if a company understands the project triangle. That from the three variables scope, time and resources you can only define two. There are two kinds of companies. Those that understand this and those that don’t. Everything they do flows from there. This is what really matters about software development.

Update: There are a lot of other factors, probably people being one of the most important (think “Peopleware”). Without understanding the Scope-Time-Resources triangle your development won’t work. It just can’t. You can screw up by chosing the wrong architecture, or methodology, or screw up during requirement engineering or with the wrong language for the problem.

But from my point of view this triangle is like gravity. If you ignore gravity, all else will fail.