Posts Tagged ‘Grails’

SpringSource: A Groovier Eclipse experience

Wednesday, August 12th, 2009

For a very long time developing Grails applications in Eclipse using the Groovy-Eclipse-Plugin was everything but enjoyable for me. Matthias Käppler summed it up best when he wrote:

Grails and Eclipse: Not So Groovy

In fact I struggled to get the Groovy-Eclipse-Plugin installed those days, and after finally having done that I found out that developing Grails applications in Eclipse was really painful for me.

But now with the first pre-M1 release of the next version of the Groovy-Eclipse plugin many things are better than ever. I finally got around using Grails and Eclipse for some of my projects at work but on the Mac at home I still prefer the combination of TextMate and Console.app. I’m looking forward to the final release which should improve UI performance in Eclipse, especially when using Code Assist.

Grails Instruments in public SVN now

Sunday, June 14th, 2009

This weekend I’ve been very busy on Instruments again.

Instruments now sports a core Java library which takes care of caching the states of system usage for the last time. This is included in an all new “InstrumentsService” which will provide the necessary methods to controllers.

At the moment this is all trimmed for using flot. There are no other “export options” for now.

I decided to make this publicly available in my Subversion repository. You can checkout the source tree of the Grails application here:

http://creatified.com/svn/creatified/Instruments/

The trunk includes the latest development version. Don’t forget the “grails upgrade”-command after checking out the source tree.

When you run the app, all you’ll find there for the moment is the following site which will be located unter http://localhost:8080/instruments/

You will then be able to see something like this:

Instruments - CPU

for the CPU usage and this:

Instruments - Memory

for the Memory usage

This will be all for now, be sure to check out your own version – I’ll also be testing this on the Google AppEngine soon.

Eclipse and Grails

Saturday, June 13th, 2009

In the last weeks I’ve been working on quite some different Grails applications. In my opinion Grails is really a great framework.

But one aspect that’s often annoying me is the Eclipse integration. Like many other guys I’d like to use Eclipse because for me TextMate is no full-blown IDE. But the default integration into Eclipse is “incomplete” at best.

Here are some things I encountered with some possible solutions:

Unfortunately the generated Eclipse project files do not include a source link to the plugins directory of your project. Since Grails 1.1 this will be in your home-directory (at least on Unix-based systems) like ~/.grails/{GRAILS_VERSION}/projects/{PROJECT}/plugins, you will have to link this as a source folder when you’re using any plugins (which will often be the case)

The other thing is: if you’re including jars in the “lib” directory under your Grails project you will either add these jars manually to your build path or once again add this folder as a linked source folder.

I hope these issues will be addressed in a future release of Grails, hopefully as soon as 1.1.2 since these should not be too complicated to fix.

The Project Mess Tool [updated]

Saturday, June 13th, 2009

At the moment I’m working on my second project thesis for my studies. The topic I have chosen in accordance with my company is the “Project Mess Tool” (PMT) as we named it.

So what’s this about? In a few words: The PMT is a tool which will allow us to keep track of many quality-relevant metrics our company-website “produces” every day.

Problem

The sites we use for selling products are changed very often due to marketing campaigns. Not only do we have to change some images for that instead these are huge changes to the affected frontends. This of course results in the fact that many parts of our codebase are from older versions which may not be needed anymore.

At the moment we’re in the uncomfortable situation that we often don’t know how our pages really perform e.g. how many of the resources we deliver or keep are really necessary. We don’t know how many kilobytes (or even megabytes?) the average page weighs nor do we know where we could optimize easily.

Possible solution: the PMT

The PMT is designed as flexible as we think it can be. All it basically does is receive data from all different kinds of sources by offering a defined interface (a webservice). This will include information from

In the end we will have information not only like “how many of the CSS selectors we deliver are really used by our pages?” but also “how does this change over time”. So we will be able to track quality with our predefined metrics and check back every week or so whether we have improved in those fields.

Architecture

I chose Grails to build this application – which I’m already pretty familiar with – but we’re also using some core Java libraries to add some features specific to the frameworks and technologies we use. Grails seemed like an ideal candidate for me because it already ships with the really powerful GORM abstraction layer. There are also plugins for other enterprise applications like the Quartz enterprise job scheduler. Grails makes it very easy to run all this stuff so I got done with the first steps pretty soon.

Frontend

At the moment I’m also drawing the first drafts of how the user interface of the PMT will look like. It will probably use Flot which I also mentioned several times.

Conclusion

For me this is a really great project. Not only in its size – it’s definitely the biggest project I’ve been working on until today. But its also a project in which I spend all my effort and time of work this time. I think it will help a lot to improve the overall technical quality of our web frontends.

I’ll keep you updated with all major changes and milestones to the PMT. So what do you think of our idea?

A few updates on GInstruments

Wednesday, May 27th, 2009

After some days off last week I’m on it again… GInstruments definitely on the way I’d like it to be.

First things first: Fortunately Hyperic had placed an exception-statement into its GPL-licensed SIGAR – which allows to include the SIGAR binaries in – for example – Apache-licensed works. For me that’s really good news, because this means GInstruments could also be used in productive environments which I think often would not be GPL-compliant.

Second: One of the basic things I always wanted to have seems really close now. At the moment GInstruments only displays your current system usage – not too useful, because most times you’d be interested in the usage over time, say for the past 30 seconds or so. So that’s one of the core features I’ll be implementing before releasing anything to the public – sorry for the delay, I’m very busy in other projects right now, too.

For the next few weeks I’ll also be testing on various kinds of systems (Windows, Linux, …) and of course testing on Google AppEngine whether they support all the necessary features.

And for a great user experience I’ll also be working very hard on a prototype of the UI.

Some things that will probably make it into the first public release include:

  • logging system usage and events to a set of CSV-files (configurable in later versions)
  • usage graphs on the client-side using flot
  • more? yeah, sure!