ahlawat.net

A groovy one liner to recursively calculate the size of a directory.

C:\Users\deepti>groovy -e "s=0; new File('.').eachFileRecurse {s += it.length()}; println s/1024/1024"
41921.6436758041
C:\Users\deepti>

Pretty useful on windows - which unfortunately does not have a command to achieve this.

Ok so another productivity tool hits the market - this time its from the big boys at Spring. Spring Roo is an open source software tool that uses convention-over-configuration principles to provide rapid application development of Java-based enterprise software. The resulting applications use common Java technologies such as Spring Framework, Java Persistence API, Java Server Pages, Apache Maven and AspectJ. Spring Roo is a member of the Spring portfolio of projects.

I was able to install and create an application in under 5 minutes with this thing. Which is great for demo but then I took a look at the generated source code and was not too happy. For a framework that claims to pure java RAD framework there is a bit too much AspectJ in the source folder. In fact its silly the amount of files the generator spits out. The documentation tells you that there is “very little” blackbox and that “you should never be editing” the IDT generated files directly. But for a groovy/java developer who has a lot of web application development experience I am just a little nervous with aspectJ polluting my class files the way i don’t want it too. We use dynamic proxies in more frameworks and places than we can care to think about but there is something about compile time weaving that just makes me a little uncomfortable. Of course this could just be my inexperience with acj and aspectJ talking here.

capture

So for one domain there are a total of 5 source files - 4 of which I should not be touching?

The next thing that was a little bit restrictive was the whole domain modelling - its absoloutely great for simple one-one relationships or many to one relationships but it’s not suitable for slightly more complex types. Also I don’t know how the framework will behave with slightly more advanced but common features of Hibernate (if you are using a Hibernate provider) - like custom hibernate types, hibernate collection of items etc.There is little in the documentation about this - so its hit and try or hit the source code of the project to figure it out.

The scaffold views are not bad but too busy .. from a js/css point - frameworks should ship with minimal style sheets.

I am a little disapointed really I was really excited about this. If I have to choose a RAD framework that will work on a standard JVM I will stick to tomcat + grails.

Here are the advantages of grails as I see it:

1. Cleaner MVC - convention is great /controller/view/id type bindings work great

2. Extremely extensible using plugins, this is a huge advantage and there are some pretty good ones out there from charting to security

3. GORM is great and for the most part works OK

4. Scriptable environment - great little tools like grails console

5. Groovy is great and the framework does not prevent you from using pure java when needed

If you use roo productively - let me know and I will give it a shot again.

So after being a member of the anti Microsoft club for a long time, I finally found myself wanting to write some COM code and decided to pick up a 1350 page C# book and start learning something that any self respecting java developer would never do, learn C# and the .net platform.
The first thing that struck me about C# is the syntactical similarity to Java. All Algol family languages C,C++ etc. share the same heritage so the similarity was not so shocking - but everything from constructor chaining, single class inheritance model and signature based method was strangely similar. In fact I can safely say that if you are a java developer with any experience, you should be up and running with C# in a matter of days if not hours. Similarities apart - here are a few things that I love about C#:

• Operator overloading - this is such an awesome tool when you are writing a DSL or an engineering based application. Groovy allows this for the JVM but C# natively supports it for the .net CLR.
• Implicit and explicit casts - this is an extension to the operator overloading but how many times have we found ourselves writing a utility class that has a single argument constructor that takes a String or a numeric type. What an ingenious idea - using such a feature is common in dynamic languages. I have found myself using the “as” keyword in groovy all the time. With C# you can customize how implicit casting is done.
• Delegates - with ruby on rails and grails radically changing the way web applications are done its quite amazing to imagine a language without delegates and closures. (yes I know all java lovers will say they never needed it), but the fact of the matter is most powerful frameworks either do their magic using template patterns, byte code manipulation or AOP. The concept of closures or delegates is missing from Java (thank god they are finally working on it). C# although not a full fledged functional language has delegates and there is a lot of really cool stuff you can do with them. What I absolutely loved is delegate chaining and multicast delegates. What an absolutely awesome concept built into the language. The listener pattern can be very elegantly implemented with this feature.

I have just begun with C# - as time goes on I am sure I will be adding more stuff to the list. The features are unfortunately not compelling enough for me to pick up C# for any client or live projects that I am doing. I can achive the same things and much much more by using poly-language groovy/java mix. Not to mention the millions of free lines of code and the flexibility that comes with the java platform. But I am very happy with C# so far, definitely not a total waste of time.

module settings for debugging grails applications

I am liking IntelliJ more and more every day. So after weeks of just  using intelliJ for Grails without using the debugger I was finally stuck at a point where I just had to inspect a few varriables to debug a problem. So I fired up the debugger. Getting the debugger started on simple Grails applications works like a charm.

The problem happens when you have a slightly more complex configuration and have a lot of plugins. For example I was using the acegi plugin and the applicaiton failed to pick up the jars in the plugins/acegi-x/lib folder. I had to add them manually to the module libs. The other little nigling thing was that the plugins/xxx/src folders were not included in the src path. You have to add them manually. Not too bad - but clicking on the debug button will still give you build failures.

Inside the src/ folder of the acegi plugin sits a folder called template which is not a src file at all its a gsp styled template. I think the plugin internally uses it to generate the domain classes during plugin installation. This folder has to be mannually excluded from the module src path.

Once you have done this - bingo, the debugger works beautifully.