Last August (2013) I ran into an issue where I wanted to get the latest 10 created entities from a database table but I was getting the first 10 instead. The relevant components of the stack involved were PostgreSQL 9.3, with Hibernate 4.2 used as the EntityManager provider for Spring Data JPA 1.4. Turns out that the cause is an old, obscure (but known) issue in Hibernate: HHH-5574. Continue Reading
I try to program by interface. It gives the code more flexibility. More details.
I have an issue however with the Java collections classes, which are always used. Checkstyle by default sets all implementing classes of the collections as illegal types. However, I don’t agree with it.
For instance: Set.remove(Object) makes no promises, it says it could simply throw a UnsupportedOperationException if the method isn’t supported. This isn’t usually a problem as most of the time the implementation is HashSet or possibly LinkedHashSet. Sometimes, however, I use ImmutableSet, which throws a UOE on remove. What I would like to do is return something which is a Set but which can be modified with remove.
Scala collections I think have a much nicer API.
For instance, Scala’s Set defines that the – method “Creates a new set with a given element removed from this set”, which is also the functionality of the mutable version (scala.collection.mutable.Set). The mutable version, however, also adds a -= method to modify the set in-place, something that only makes sense for mutable collections. But mutable.Set doesn’t define the implementation used, so it can be used as the type of any parameter or field that you declare to be a Set (no duplicate elements) and modifiable (-=, +=, etc).
If only, if only. If only Java’s collections had interfaces for mutable collections without implementation, that way I could return a MutableSet, leaving the user able to remove object (without having to create a new Set with the contents of the original Set), without having to specify the implementation..
I develop Java web applications, but I would like to change.
In the last few weeks and months, I’ve looked at various alternatives and I’ve basically come down to 2 choices, a situation I very often find myself in.
Ruby on Rails or Scala & Lift?
I like them both, and I’m leaning very heavily on Rails, for various reason, but one reason keeps me with an eye and a hand still looking and reaching for Scala and Lift – refactoring.
In the amazing world of Java and especially Java tooling, great IDEs such as Eclipse allow me to greatly refactor code with the security of knowing that it works simply because the IDE tells me it compiles successfully. This, however, is also a double-edged sword. It might compile, but that doesn’t cover all cases. You need tests for that, and those tests to be respected and maintained.
So, Scala and Lift allow me to build, maintain and extend a web application due to the fact that the code is statically typed, compile-checked and there are powerful tools (Intellij Idea X is what I prefer for Scala) that allow me to make big changes quickly and securely.
With Ruby and Rails I would (and have already) use RubyMine. And it does let you refactor, as well as jump to and from method usages/declarations, and from controller to view and back (which is really really cool). However you don’t get a code-wide check that a automatic compile does, so you have to fall back on to your tests.
This gives tests a much bigger importance than in Java. In Java the compiler can easily become your only test (and until a year and a half ago, I didn’t write tests, but that’s another story). Nowadays, I really think tests are important, they help me and they make me confident of the code I write. So I like the idea that tests gain importance, that way the development team will have to maintain and expand on tests during development, otherwise there won’t be any guarantee.
On the otherhand, some tests aren’t necessary, or at least they aren’t in general. Until your system breaks. Such as changing, what would be called in Java, a ‘getter’ (or attribute writer in Ruby, right?). “Damn, let’s pass it a Map (Hash in Ruby) instead of a List (Array)!” In Java or Scala, everything turns red in the IDE; in Ruby? Well I guess you have to work through all the code that called that method and change it accordingly. System-wide functional or integration tests would help- traversing the entire project to test common or edge-case functionalities and integrations would make these tests jump out.
So the type system and the compiler does help, because it simply tests that statically everything makes sense. And this can be used. I don’t have to check everything that comes in and comes out of a method, because the compiler assures me what it is. This makes the code less full of mid-execution gate-keeper checks, and leave more space for the application logic to shine (hopefully :D).
I’m a little afraid of stepping down from statically-typed languages. I’ve heard horror stories of applications (Twitter I think) that basically coded up a type-system in Ruby whilst making their application. I don’t wanna have to do that.
See my dilemma? 🙂
One last thing, pro Ruby, because refactoring takes a little longer, and is more error prone, you tend to make smaller commits, which is good pratice and a good practice. As in, it’s a good thing to commit often, and you can practice, for instance, writing good commit messages as well. I’ve been known (and know even worst cases) for massively refactoring code in single commits.. gets the job done, but it’s not the best.
Comments are welcome 🙂