Open minds leads to freedom

There is an interesting discussion between using TestNG or JUnit on Java projects at Javalobby. It’s very worth reading.

Some weeks ago I started doing pair programming with some co-workers basically for two things:

1. code some tasks of an user story
2. get familiar with a new software code base

I haven’t had an opportunity to put this technique in practice a lot before, but I can say it was extremely important and benefit for the project. Sometimes I was the driver and sometimes I was the observer. The driver is the person who starts coding and the observer is who starts doing the code review. That point is important: code review.

Pair programming encourages the review of the code. Perhaps you won’t have an opportunity to refactor some code as you have when you are pairing with someone. I think code reviews are important because:

• Reviews increase code quality, because there are 2 people thinking at the same task at the same time.
• Refactoring areas arise in the design where improvements are needed
• When you have the strong support of an IDE (as Eclipse), some refactorings (extract method, extract class, introduce parameter) are highly automated
• Code is more read than written, two people reading the code can understand a lot more about the code base
• New ideas arise because of different point of views
• Questions can be solved by the sum of knowledge of the code base

And you? What’s your experience with pair programming?

I’m proud to announce that JFileContentManager, a software of mine, has been added to Softpedia’s database of software programs for Mac OS. It is featured with a description text, screenshots, download links and technical details on this page.

JFileContentManager has been tested in the Softpedia labs using several industry-leading security solutions and found to be completely clean of adware/spyware components. We are impressed with the quality of your product and encourage you to keep these high standards in the future.

You can see the announce by clicking on the image above. Thanks Softpedia for the award!

Interesting article showing some changes on the Java platform to address its verbosity, but keeping code readability safe.
I liked the new Collection’s literals syntax to create lists, sets and maps:

List powersOf2 = {1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024};
Map ages = {"John" : 35, "Mary" : 28, "Steve" : 42};

Although it can be possible to use the DoubleBraceInitialization idiom to initialize collections in a more elegant way, this syntax is very terse and concise.

BTW, as I said before, Scala already has a syntactic sugar to create a literal Map:

val ages = Map("John" -> 35, "Mary" -> 28, "Steve" -> 42)

Maybe this change was taken into account considering the Scala collection literals implementation?

From Javalobby, an interesting and short video showing the evolution of the Java platform since 1991.

I just came across an interesting post by Stephan Schmidt about constructors in Scala.

It shows how to create constructors with immutable and mutable fields, how to have multiple constructors how to invoke super class constructors. I found it very handy and concise to create a constructor with a private immutable field:

class Foo(private val bar: Bar)

Some days ago I started to use the Scala programming language to update my Livejournal tags using its XML-RPC protocol reference. First I had to check if some tags of mine were entered wrong, so I’ve done this Scala program to list all of them:

   1:import org.apache.xmlrpc.client.XmlRpcClient;
   2:import org.apache.xmlrpc.client.XmlRpcClientConfigImpl;
   3:import org.apache.xmlrpc.client.XmlRpcCommonsTransportFactory;
   4:import java.net.URL;
   5:import java.util.Map
   6:import java.util.HashMap
   7:import scala.collection.immutable.TreeSet
   8:
   9:object LJListTag {
  10:     def main(args: Array[String]) {
  11:         val config = new XmlRpcClientConfigImpl()
  12:         config.setEnabledForExtensions(true);
  13:         config.setServerURL(new URL("http://www.livejournal.com/interface/xmlrpc"))
  14:         val client = new XmlRpcClient()
  15:         client.setConfig(config)
  16:         val params = new HashMap[String, String]
  17:         params.put("username", "user")
  18:         params.put("password", "password")
  19:         var paramsToServer = new Array[Object](1)
  20:         paramsToServer(0) = params
  21:         val results = client.execute("LJ.XMLRPC.getusertags", paramsToServer).asInstanceOf[Map[String, String]];
  22:         printEachTag(results)
  23:     }
  24:
  25:     def printEachTag(results: Map[String, String]) {
  26:        var allTags = new TreeSet[String]
  27:        val iterator = results.values().iterator()
  28:           while(iterator.hasNext()) {
  29:             val resultFromRPCData = iterator.next().asInstanceOf[Array[Any]]
  30:             resultFromRPCData.foreach(singleResult => allTags += extractTag(singleResult))
  31:           }
  32:        allTags.foreach(tag => println(tag))
  33:     }
  34:
  35:    def extractTag(singleResult: Any): String = {
  36:        val tag = singleResult.asInstanceOf[HashMap[String, String]]
  37:        return tag.get("name")
  38:    }
  39:}

Just fill your user and password to have all of your LiveJournal tags printed on the standard output. The experience was so amazing, since you can use all the Java libraries (Scala is fully interoperable with Java and runs on top of the JVM). I used a TreeSet because I wanted print my tags sorted according its alphabetical order. I’m continuously studying Scala and its API, so the code above doesn’t use any advanced Scala constructs. If you have any suggestion about the code or how to use better the Scala constructs, post your comments here. It will be all appreciated.

Some times ago I had to parse a XML messages’ file to produce some i18n properties files.

I decided to try it with Ruby, mainly because of two reasons:

1. I’m continuosly exploring some dynamically-typed languages, like Python and Ruby
2. I wanted to try the conciseness of programming with closures

So, I used the REXML API to process the XML file. The result code looks like the one below:

   1:require 'rexml/document'
   2:include REXML
   3:englishFile = File.new('englishFileName', 'w+')
   4:spanishFile = File.new('spanishFileName', 'w+')
   5:portugueseFile = File.new('portugueseFileName', 'w+')
   6:errorMessagesFile = File.new("errorMessages.xml")
   7:document = Document.new(file)
   8:root = document.root
   9:root.each_element("Property") do |propertyTag|
  10:  id = propertyTag.attributes['id']
  11:  propertyTag.each_element("element") do |elementTag|
  12:      elementAttr = elementTag.attributes['otherTag']
  13:      error = elementTag.text == nil ? "" : "#{id} = #{elementTag.text}\n"
  14:      if elementAttr = "pt"
  15:          portugueseFile << error
  16:      elsif elementAttr == "es"
  17:          spanishFile << error
  18:      else
  19:          portugueseFile << error
  20:      end
  21:  end
  22:end
  23:errorMessagesFile.close()
  24:englishFile.close()
  25:spanishFile.close()
  26:portugueseFile.close()
  27:

I like to solve this kind of tasks with programming languages (mainly the dynamically-typed ones..) I don’t know very much because it’s an opportunity to put my hands on them! This way I could experience Ruby’s closures syntax, it was really nice and I’m gonna try something new with it often!

*Updated: line 13

JavaLobby released an interesting interview with Emmanuel Bernard, the spec lead of of JSR-303: Bean Validation..

One of the important goals of the Bean Validation spec is, as Emmanuel Bernard says, is

to provide a default runtime engine that is used to validate the constraints around the domain model, in Java.

The development team decided to use annotations to express the constraints applied at the domain model. They argued that with annotations the constraints are put directly at the properties in the code, expressing the constraints associated with the property.

I highlighted some interesting parts of the interview:

Bean Validation lets you standardize the way you declare the constraints. So an application developer will just know one way to declare constraints, and just forget about all the different models. There’s no duplication around the validation on the layers.

If you think about a constraint, a constraint is really some kind of an extension of the type system.

Bean Validation lets you validate an object graph using the @Valid annotation. Basically saying, ‘Well, when you validate this object, make sure the associated object is validated as well.’ By the way, even if Bean Validation is primarily annotation focused, there is the equivalent in XML.

Any framework that is having a need to use validation, to apply validation, can either use the runtime engine of Bean Validation or go extract the metadata and play with that. So the user declares it once, in one place, and every framework in the Java space can actually go and either apply the validation routine …

You can listen the podcast of the interview also. It’s very noteworthy to read or listen the interview and see what’s next on validation in Java. Before the Bean Validation API become public to all of us, which framework do you use to validate constraints on the Java platform?

In this talk (recorded at Javapolis), Joshua Block presents guidelines about how to design good APIs. I highlighted what i think are the most important parts of the talk:

• Functionality should be easy to explain: If it’s hard to name, that’s generally a bad sign
• Good names drive development
• Be amenable to splitting and merging modules (If names are nasty, take a step back and make things easy to describe)
• When in doubt, leave it out
• You can always add, but tou cannot take it out
• Implementation Should Not Impact API
• Always omit implementation details
• Inhibit freedom to change implementation
• Don’t let implementation details “leak” into API (For example: Serializable, hash functions)
• Minimize Accessibility of Everything (This maximizes information hiding)
• Public classes should’nt have public fields
• API should be easy to learn, read and use: It should be consistent, it’s a little language
• Documentation matters (Example: Method contract between it and it’s clients)
• Think of preconditions, postconditions, side-effects
• Don’t Transliterate API’s
  • What’s the problem it solves?
  • What shoud abstractions did it use?
• Don’t Make the Client Do Anything The Module Could do
• Throw Exceptions to Indicate Exceptional Conditions

When you see the talk, post your comments here.