A look to the past to see where you are going

I read a great article just now by Bruce Eckel ‘The Positive Legacy of C++ and Java’.  Bruce talks about Java as a language gettings stuck (complicated Generics, etc) but paving the way via the efficient JVM to develop and host new higher languages very quickly (Groovy, Scala).

It finishes with this great line

All future languages should learn from this: either create a culture where you can be refactored (as Python and Ruby have done) or allow competitive species to thrive.

Chuffed

I just deployed my first Grails app running with PostgreSQL on MorphExchange.

Following their Java Dev Cookbook was quite easy though I found I had to do the following:

  • Under log4j configuration add a property logs.home = ”./logs” (here)
  • Don’t need to change the Grails DEFAULT_DEPS in War.Groovy to exclude jdbc2_0-stdext.jar per their doc.  Perhaps the exception they warn about will be a problem if trying to use JNDI?

The real wide internets beta lookout, I now have a place to host some unsuspecting Java onto the world, <cold evil laugh>

Of Cisco, Tcl and Java

Whilst busily reading up on Scala and Groovy and other languages that ran on the JVM, I had a thought with regard to the scripting language that the network architect at work now advises is included in the Cisco ISG/ASR’s.  Cisco now have the Tcl scripting language installed on the IOS.  One application is used to control phone IVR and voicemail systems which is a pretty neat feat. 

Tcl itself doesn’t seem to be much of a mystery language either and should be easy for anyone coming from another scripting language background.

There is a Jacl for the JVM as well and also a means to bring Java code to a Tcl interpreter via Tcl Blend.

You can use Tcl to script EXEC level commands on a router such show version and int fa0/0 type stuff as shown here.

There is also a Cisco article about getting started with Tcl on the routers.

JavaPuzzlers Talk

This is a great talk with Josh Bloch and Neal Gafter with a whole lot of cooky Java-ness.  Programs that look like they should behave but don’t…. or even worse, work as expected, but not because they are following the line of execution you intended to.

http://www.javapolis.com/JP04DVDContent/talks/Puzzlers/index.html

Edit: If you look on Parleys.com and also Javapolis.com (now called Devox) you’ll be able to find the 07 talk (parleys) and the 05 (however wasnt able to find a direct link for that one on Devvox)

Bertrand Meyer, ETM, Java Byte Code, Eiffel

Bertrand Meyer is the author of a classic software development book Object-Oriented Software Construction.  He is also the father of the Eiffel language.  I have a lot of respect for his work, it was quite heavily plugged when I was at Monash.

In looking for a Bertrand Meyer home page, I came across Betrand Meyer’s ETM homepage.  ETM is where he was working during mid 2007 when the page was written.  He plays a part in co-teaching many of the subjects there (lucky students!).

There are many pieces of gold linked to his site, though these two subjects seemed of most interest to me.

+ “Languages in Depth” series: Java programming, with Manuel Oriol (bachelor’s/master’s) Java

The lectures about the class loading and bytecode were very informative.

+ “Languages in Depth” series: C# programming, with Lisa (Ling) Liu (bachelor’s/master’s) C#

You can also find a link the ECMA Eiffel language specification.

In addition, there are a few interesting tools linked to from this page, as well as a few from the Dept of Computer Sciences download page.

Autotest is a tool that generates tests automatically by looking at the source code, in particular, the way that Design by Contract is used, gives a lot away about what a human tester would be writing, but also tries to make up for the shortfalls that would not normally be apparent in the source code and the fact that developers aren’t perfect to begin with.

The text for the next lot appears directly from the school’s download page.

Contract Wizard 3.0
Description: Regrettably Design by Contract is still a specificity of the Eiffel programming language. Contract Wizard 3.0 is a GUI application that enables adding contracts (preconditions, postconditions, and class invariants) to any .NET assembly, whatever .NET language it was initially written in.

The Pattern Library contains patterns that are usable as components. For the patterns that could not be turned into components the download contains the Pattern Wizard, that let’s you generate the patterns according to your input.

Eiffel library to generate Java bytecodes

Description: This Eiffel library is able to generate Java class files that can be executed by a Java Virtual Machine. A simple language with a corresponding compiler that uses the library as backend was created to test this library and also to give examples of how to use the framework. This language is similar to the Java language, but much simpler.

Funnily enough, the java references I mention in this blog all make reference to the following sites:

The universe is telling to learn about the bytecode behind the JVM…  javap My.class

UML and CRC and Agile References

CRC Cards (Class Responsibility Collaborator cards)

Class Name
Responsibilities Collaborators

A very good UML diagram reference (I may have referenced this one before).

http://www.agilemodeling.com/essays/umlDiagrams.htm

And a page of useful agile resources, from a process standpoint.

http://www.agilelogic.com/sp_resources.html

I particularly like the ones about Missing the Point of the Daily Stand-Up? and eXtreme Adoption eXperiences of a B2B Start Up

The Self-Shunt unit testing pattern in short is a way to think about your tests so that you are not testing more than one thing in a test. It talks about passing the object you are testing to itself. Here is a quote (paraphrased) from the document about when to use it "Methods such as testScanAndDisplay scream testing two things."

More on Enums

Something that bothers me about Java Enums, is that they don’t represent ints out of the box.  Like no easy way to use them to represent particular indexes in an array, with the auto-incrementing thing happening, as per C/C++.

If you look a little deeper, there is the YOUR_ENUM.ordinal() method which will give you an int based on the position in your code that the ENUM_USED appears in the enum class, but the javadoc for ordinal makes you wary about using it

Returns the ordinal of this enumeration constant (its position in its enum declaration, where the initial constant is assigned an ordinal of zero). Most programmers will have no use for this method. It is designed for use by sophisticated enum-based data structures, such as java.util.EnumSet and java.util.EnumMap.

Returns:
the ordinal of this enumeration constant

"Most programmers have no use for this method"…. This method emulates the old C way of doing enums and not specifying a default.  Surely many programmers would be at home with such a thing?

…. is there a better way to represent static constants of indexes that don’t use an enum?

Well, there are some articles on this question, and what exactly the java enum implementation can and can’t do.

Making the Most of Java 5.0: Enum Tricks

This article contains some really clever things you can do with Java enums, like having a static block in the enum to initialise a static Map or even cooler, using Enums to implement Template methods.

AssumeThat(flexibleJunitTesting.withMatchers(), isGreat());

I’ve seen Matchers used in EasyMock but I kinda stumbled across the assertThat method in JUnit today and realised how powerful this stuff can be.

Usage:
assertThat(“You Failed”, testValue, allOff(greaterThan(3), lessThan(6))

They seem a lot simpler in this context even though they are the same thing.

The Matchers are taken from a project called Hamcrest which both JUnit, various xMock and other testing frameworks have all jumped on board to.

Hamcrest comes with a library of useful matchers. Here are some of the most important ones.

  • Core
    • anything – always matches, useful if you don’t care what the object under test is
    • describedAs – decorator to adding custom failure description
    • is – decorator to improve readability – see “Sugar”, below
  • Logical
    • allOf – matches if all matchers match, short circuits (like Java &&)
    • anyOf – matches if any matchers match, short circuits (like Java ||)
    • not – matches if the wrapped matcher doesn’t match and vice versa
  • Object
    • equalTo – test object equality using Object.equals
    • hasToString – test Object.toString
    • instanceOf, isCompatibleType – test type
    • notNullValue, nullValue – test for null
    • sameInstance – test object identity
  • Beans
    • hasProperty – test JavaBeans properties
  • Collections
    • array – test an array’s elements against an array of matchers
    • hasEntry, hasKey, hasValue – test a map contains an entry, key or value
    • hasItem, hasItems – test a collection contains elements
    • hasItemInArray – test an array contains an element
  • Number
    • closeTo – test floating point values are close to a given value
    • greaterThan, greaterThanOrEqualTo, lessThan, lessThanOrEqualTo – test ordering
  • Text
    • equalToIgnoringCase – test string equality ignoring case
    • equalToIgnoringWhiteSpace – test string equality ignoring differences in runs of whitespace
    • containsString, endsWith, startsWith – test string matching

Here is a summary of Matchers from the Hamcrest tutorial page.  They may not all be in JUnit.  JUnit ships with org.hamcrest.CoreMatchers and org.junit.matchers.JUnitMatchers.

Assumptions

Assumptions are like @Ignore-ing tests programmatically.  They are a test, intended to determine that the environment a test is running in, will successfully run the test.  The example from the JUnit 4.4 release notes best illustrates this:

import static org.junit.Assume.*  
@Test public void filenameIncludesUsername() {
assumeThat(File.separatorChar, is('/'));
assertThat(new User("optimus").configFileName(),
is("configfiles/optimus.cfg"));
}

If the expression in the assume statement fails, then the test will be marked as passed.  Apparently in future, the failed assumption may lead to the test being marked as ignored which would be excellent.

Edit: Another useful resource is the Junit API on Matchers