Eclipse to IDEA

Why consider a change?

I have been using Eclipse for many years, and still really only used a small part of its capability.  I had always been reasonably happy with it, despite the occasional issues, I fully appreciated the fact that I was using free software (although I did make a couple of small donations).

But a couple of years ago I started getting problems with its interactions with Ubuntu.  Now to be fair to Eclipse, some of the underlying issues were almost certainly outside Eclipse itself  ..  but I had been losing time from menus disappearing and SWT related random crashes for a long time.

At a suitable break point in developing V7,  I decided to upgrade to Eclipse Luna.  Initially I thought all was well, but when some (but not all) menus stopped working I admit I just lost patience.

So I tried Intellij IDEA.

Making the Change

I knew of course that changing from something very familiar would be a bit of a challenge, so naturally I started with the Community Edition of IDEA.  

Trying to do some very simple things took time, because I had to find out how to do them.  Now the IDEA documentation is pretty good, but sometimes you just have to know the right words to find what you are looking for.

It wasn't helped because I only code in my spare time - my current day job doesn't require it - so I was forgetting new things between sessions.  But I resolved to be patient and give myself a chance to find my way around ...

For reasons I can't explain, I find I use keyboard shortcuts more than I did on Eclipse.  Ironically, if I had used shortcuts more on Eclipse the changeover may have been easier as you can select an Eclipse key mapping for IDEA.

Anyway, after a bit of early frustration just getting used to the differences, I came to like IDEA, and I've been using it for about 3 months now.  The biggest single reason is still that it doesn't crash, or have quirky menu issues.  

My favourite feature is the Live Templates - much more powerful than the Eclipse equivalent and can be a real time saver by generating code for your common coding patterns.

I like the Gradle integration too .. with Eclipse I always used the command line for Gradle, it was just easier.  No great problem, but Gradle actually just feels like part of IDEA.

Of course there isn't the huge array of plugins that Eclipse has available, but even so, there are quite a few;  it seems that most, if not all, of the common requirements would be covered.

Paying the Price

Now the Community Edition is only for pure Java, and for a while that was enough.  But it doesn't take long before you stray into needing the licenced (called 'Ultimate') version.  In my case, I wanted to run a web app on Tomcat, which isn't supported via the Community Edition.

So then I was faced with buying a licence, or returning to Eclipse ... and the licence would cost more than I had contributed to Eclipse. 

I decided to go ahead, still mainly because of stability, but also because I keep finding features, often quite small in themselves, which just make coding a bit easier ... and I am fortunate enough to be able to afford a personal licence.

I must admit though, that I still feel a bit guilty about leaving Eclipse  ... I've always been a keen supporter of the open source movement.

Vaadin, Guice and Quartz

Progress

I can't believe it is so long since I posted to this blog.  I guess I must have been busy!

Those who have read previous posts will know that I have been working on a project called V7 to provide Vaadin, Guice and Shiro integration, with some I18N and navigation support thrown in.

Making Time(r)?

Quartz has become a popular scheduler for Java, and I wanted something to test my V7 design to ensure that I could integrate and add in a library without too much difficulty.

I have recently committed an implementation for this, so there now also an optional V7 library for Quartz, already integrated with Guice.

Observations

I do find some of the Quartz API a little strange, but despite that the integration seems to be fairly robust.  And to be fair, I guess Quartz is popular for a reason - it works!

One thing which I find strangely missing (and I know I am not alone) is the ability to define dependencies between jobs.  

But .. it works, and is now integrated with V7.

JUnit asserts and assertThat

Keeping it simple

Now let's be honest, how many of us enjoy writing tests?  They are pretty tedious, even if some of the results are a bit of a surprise!  After all, the last thing we want is for writing tests to be a challenge - as soon as that happens, the test code is likely to need as much debugging as the code under test.

So the simpler it is to write clear tests the better ...

The path to fluency

Like most developers, I started off using JUnit's Assert methods ... assertEquals, assertTrue etc.  I went to TestNG for a while, and frequently got the expected and actual values the wrong way round.

A while ago, I found Fest "fluent" assertions, then at version 1.4.  I was much happier with that, and found that the claim to fluency was generally valid, and certainly led to more meaningful test failure messages.

But 1.4 was being retired, and 2.0 under development.  I tried early versions of 2.0 and there seemed to be some issues with type recognition, requiring some odd casting.  To be fair, these were milestone versions of Fest and these issues may have been fixed before 2.0 was released.

In the meantime I stumbled across the native JUnit assertThat() method, with Hamcrest matchers, being shipped with JUnit.  I hadn't noticed when this was first released, but I thought it may be a good time to migrate back to native JUnit.

Er, no. It wasn't.  Although the intent of JUnit assertThat() is similar to Fest, I quickly found that I was getting tangled up with the syntax, even allowing time for changing away from Fest.  I then found AssertJ, a fork from Fest 2.0 which seems to be more open to extending what can be "asserted".  So that's where I've ended up, and I am back to being nearly fluent again.

So what's the difference?

It's actually quite hard to quantify why I prefer AssertJ/Fest 2.0, except that it feels more natural - and it does seem that IDE auto-complete gets better results.  This is all purely subjective, and you may find it otherwise.

Fest 2.0 is practically identical in use to AssertJ, but AssertJ seems to be more open to extending the library... and let's face it there are plenty of things to test. 

Having said that, I am certain that all the assertThat() implementations (AssertJ, Fest, Hamcrest) are far more readable (and writeable)  than the original JUnit  Assert statements and all can be extended with custom matchers.

So if you want get more out of writing tests, I'd recommend giving AssertJ a try ... and if you are still using assertEquals, definitely give at least one of the assertThat() implementations a try.

Running a single test in Gradle

Although very simple I had trouble finding the syntax for this.

gradle -Dtest.single=MyTest test

Vaadin 7, Views and a Sitemap (part 2)

Time Flies

I can't believe it is so long since I last posted.  Holidays come and go, and eventually the sun came out.  In my part of the northern hemisphere anyway!

Progress

I described the idea of a Sitemap to define the structure of a site in my last post.  I did actually then get round to writing the documentation - and rather unusually wrote it before developing the code.

I won't repeat that documentation here, hopefully that is clearly enough written (although questions and feedback are always welcome either here or on the forum).

So I now have a Sitemap and associated options, which can be used to generate a set of standard pages, mostly to to with user account management.  More importantly, it lets you describe the structure of your site fairly simply - making good use, I believe, of the main components of Vaadin, Guice and Shiro to simplify development.

It comes with a user navigation tree, created automatically from the Sitemap to enable the user to find their way around.  Eventually, there will also be a breadcrumb to go with it ...

Tutorial

I am in the process of creating a tutorial, which I hope will make things even clearer ....

Vaadin 7, Views and a sitemap

The Start Point

I needed to start on another application - a small one, but one which would benefit from the work I had done on V7.  So I started to build the app (and re-write some of the documentation, of which there is still more to do).

I was quite pleased with the speed with which I had a skeleton app with the core features of V7.

But I dislike writing the same code twice (or writing code once which has already been written and tested by someone else!)

I should say here that I still think Vaadin is a great product, I am just building on it for a particular set of, hopefully, common use cases. 

The "Problem"

When I looked at how I had structured V7, I could see that I was in danger of duplicating page related definitions.   There was still a strong chance of mismatches occurring between URL and View mapping, and navigation components.  And in my view, anything dependent on accurate typing of String literals is likely to cause a maintenance problem at some point.

I felt it was an improvement on the standard Vaadin 7 - but there was room for improvement. 

The Idea

The idea, then was to abstract out the structure of the site into a sitemap.  A sitemap is hardly revolutionary, but in this case it is an input rather than an output.  It acts as the specification of page layout and includes:

URL to View mapping

Packages which contain Views

URL redirection

I18NKey selection

and a fairly comprehensive report

Report

The report identifies a number of sitemap error conditions - things like missing Views, I18NKeys, redirection loops.

Generation

To be honest "Generation" is not strictly the correct word - there is no code generation, but I cannot think of a better term.  

The sitemap created from sitemap.properties is used in a Guice module to map URLs to Views, and is of course available for injection wherever needed.  One obvious use - and the reason I started on this track - is  to use the sitemap with navigation controls.

The sitemap.properties file gives quite a good description of what is needed, but yes, I need to get working on the documentation, too. 

Vaadin 7 I18N - part 2

Completing the I18N Picture

For some reason I forgot to post the fact that I did complete the I18N task I set myself.  Perhaps because it was not quite as difficult as I expected.

When I looked at some of the new Vaadin 7 code, I discovered that the FieldGroup class provided much of what I needed.  (FieldGroup is the successor to the Vaadin 6 Form - and in my opinion, substantially better).

So within V7 now is a reasonably complete I18N approach, though seriously lacking in translations.  For that reason I have not yet added a facility in the demo to switch locales.