A GPS diary in four weeks with Play!

During the last four weeks I did another small project for one of my university courses this semester. The course was about ORM modelling and abstractions for databases. We did some exercies with Hibernate and discussed diefferent aspects about ORM modelling. At the end of the course, every student made a small web-project using a framework and ORM tool of his choice.

Most of us used Play! and ebeans to make their application – me too. I didn’t have any experience with Play! but it was very pleasent to work with. Togehter with Foundation CSS prototyping was extremly fast. And ebeans also did a great job. During the whole project I didn’t write any line of SQL – nice!

Online demo

You can see a demo on http://tad.mi.hdm-stuttgart.de/. Just log-in as tad@tad.de with 123456 as your password to see a demo-account with some data.


My presentation about TAD: http://tuhrig.de/wp-content/uploads/tad/presentation.html


The code is available on my university’s own Git repository, but it is public:

git clone https://version.mi.hdm-stuttgart.de/git/TAD

Best regards,
Thomas Uhrig

Thomas’ Functional Interpreter

I just finished a small functional interpreter for an university course. To be precise, the interpreter itself is not functional, but it understands a functional, LISP-like language/syntax. The whole project is written in Java 7 and provides an interface to all Java classes on the class-path, too.

I also tried to create a small IDE in Swing. I built an editor with syntax-highlighting and code-completion (thanks to the RSyntaxTextArea project), an environment inspector and a small debugger to keep track of the stack. Take a look at it.

I called it ThoFu for Thomas’ Functional Interpreter. I think it teats good… You can get some brief impressions from the slideshow below.

The whole project is open, you can find it as an Eclipse project on my Bitbucket account. It contains the actual code, all libraries, screen-shots, unit tests and (of course) some documentation like UML diagrams. Here are the links to the GIT repository:

Bitbucket: https://bitbucket.org/wordless/thofu-interpreter
Git: https://bitbucket.org/wordless/thofu-interpreter.git

Here is the executable JAR-file (Note: You need Java 7). Just download it, double-click it and go-ahead:

Executable program: ThoFu Interpreter.jar
Read-Me: README.md

And this is how it goes. First a simple “hello world” program:

Now, a more sophisticated one. Here’s a quicksort-algorithm for my interpreter. It contains some user-defined functions, multi-line statements and some comments.

And this is how the Java API works. The code will create a JFrame with a JButton and a JLabel. When you press the button, the listener will change the text of the label from “click me” to “hello“. The syntax is inspired by the Java Dot Notation by Peter Norvig. I used the Apache Commons Lang library for the reflection-tricks to load class and so on.

You can just copy and paste the code snippets into the editor or save them as common text files and open them. They are also in the repository. The JUnit tests contain many more examples as well.

For those who are interested in the topic, you can find my resources (libraries, tool and literature) in the Read-Me.

Best regards,
Thomas Uhrig

Tools to understand Java code

I have recently read a question on Stackoverflow whether there are any tools to help understanding Java code. Somebody asked it, because he started to use a pen and a sheet of paper to get the clue of some code given to him. Not uncommon.

But the problem was, that nobody tried to answer the question, instead giving him tips like “learn Java” or “read tutorials”. I think they have misunderstood the question – because there are definitely tools for that:

  • A good IDE just like Eclipse is one basic tool to understand code. It helps you in various ways:

    • It shows the structure of folders and files of the project. You can easily get an overview of everything. Just import the project and have a look what you got.
    • It gives you the ability of syntax-highlighting (trivial, I know), but also the ability to format code like your are used to in a second. That helps reading it, even (or especially?) when you have some experience in the language.
    • It shows you the JavaDoc comments right away at every position in your code. So you will always have the documentation with you when needed.
    • It provides tools such as a debugger, a call-hierarchy view and many more. All this tools will help you to get an understanding of how the code works.

    And it can to much more for you. So it’s really worth to get familiar with your IDE.

  • UML is a widely used standard for modeling and visualizing code. The purpose of UML is simple and exactly what was asked: it should help you to understand code. The strength of UML is the abstraction. You can easily visualize a big architecture without mention any detail at all. On the other hand, you can add any detail you want if it is important for the understanding of the system.

    The basics of UML are not hard to learn, a quick look at Wikipedia should be enough to draw a class diagram. But UML is also enough standardized, that it could not only be read by humans, but also by machines – so you can generate it (so called round-tripping)!

    Tools like ObjectAid helps you to generate class diagrams as easy as possible. Just install it in your IDE, create a new class diagram and drag all Java classes in it.

  • Tests, especially unit tests (e.g. JUnit tests) could be also very useful to understand the code. A good test is something like a additional documentation or a contract on code-level. It exactly defines how a method can be used (e.g. input parameters) and what it should make (that’s what the test is testing ;)). So, if you don’t understand what a method should do and you have tests, take a look at them. And what if you don’t have any tests? Write your own ones! This is a good approach to explore an API in a structured and repeatable way. Whenever you are not sure what the API does, try to create a test about your assumption.

So, what to do if there is a bunch of new code?

  1. Import the project to your IDE.
  2. Get an overview of folders, files, packages and so on.
  3. Explore the code: What’s in the JavaDoc? What types are used? What about the call hierarchy?
  4. Run the unit tests and try to understand what the methods are doing.
  5. Try to run the debugger for a test or two.
  6. Draw or generate a UMl diagram.

I have uploaded some screenshot in the slideshow above for the open-source RSyntaxTextArea library from Fifesoft. But you will also find some good tutorials in the internet for every point mentioned before. Try to get familiar with at least some of the tools.

Best regards,
Thomas Uhrig

Automated UI testing with Swing & FEST

Testing an application is hard, but testing an user interface (UI) is even harder. FEST addresses this issue for Java Swing applications. It enables you to write easy and readable functional tests for your UI. Working together with JUnit, it lets your functional UI tests feel like common unit tests within your test suite.

FEST is a context-sensitive testing-framework, which means that the position of your UI components, their size or color isn’t important for the test (of course you can tests this criteria if you want). FEST identifies all UI components by an unique ID – their name. Therefore, your UI layout can change, but the tests will still work.

By the way: Because all components in your UI must have a unique name, it’s a good idea to use a Factory to create your components and to make sure that they all have an unique name.

To start with FEST is really simple:

  1. Download FEST from their Google Code repository and put fest-swing-x.x.jar as well as all JARs in the lib folder of the ZIP-file to your classpath.
  2. Make a Swing UI, perhaps something like this:

  3. Now, go ahead and write a (JUnit) test:
  4. Let your test run and see how FEST is interacting live with your UI.

FEST uses the java.awt.Robot class to interact with your UI. Robot is part of the JDK since version 1.3 and provides a low-level API to simulate user interaction for AWT or Swing application. FEST encapsulate this class into an abstract and easy to use API.

The difference between common JUnit tests and functional tests using FEST is the level of test-execution. JUnit tests are working on isolated classes and methods whereas functional tests (with FEST) are working on the real UI shown to the user. This real UI can be composed of many single objects that should be tested altogether. Also, functional test doesn’t work on a method-level – they are working on the same level as the human user simulating “clicks”, “selects” and “keys”.


Best regards, Thomas Uhrig.