Spring, MVC and Groovy

If you'd ever find yourself choosing the whole Grails stack only because it is sooo much easier to setup a project by comparison to pure Spring MVC I strongly recommend you try out the new Spring MVC on Groovy Maven archetype. That sucker punches in Spring in an easily selectable version, Groovy (1.8.6) and the groovy-eclipse compiler (also 1.8.6), JUnit and Spock, JavaMelody for monitoring - basically all you need to create a web application using Groovy, some IoC container, an MVC framework and test all that in a reasonable fashion.

http://www.testdriven.org/spring-groovy-web-archetype

Give it a shoot. If there's something you'd like to add to it then by all means - drop a note on GitHub.

Have a nice day!

Fatal dual mistake

http://bit.ly/GIbHyi
http://bit.ly/Hu5Ugl

The video material is in polish but it goes pretty much like this:

A group of anti-terrorists slams on doors of some people, kicks'em, slacks'em, drags'em over the floor, throws some grenades - basically they are dealing with some kind of bad guys. However they are "mistaken" so they say "Ups - sorry - never mind" and go one floor above. Then they do the same thing one floor above and again "Ups - sorry - never mind"... Third time's the charm, right? So there he is! The so goddamn dangerous car thief with a gun.

WHAT THE FUCK?!

Is anybody with a gun a terrorist these days?! Why don't you guys at the police go and RTFM what terrorism actually is! And if you ain't got a manual about it there's plenty of material on the net about it! A car thief ain't one of them - that much I can tell you. He's a thief, probably a murderer if he kills someone. But if that really is the case that owning a gun makes you a terrorists then those poor man and woman have been terrorized by terrorists because they did have goddamn guns. Big guns!!!

It's outrageous! I can't believe I'm living in a country where a car thief is a terrorist, where innocent people are being treated as criminals with an "Ups! Sorry! Nevermind" attitude afterwards! WHAT THE HELL IS GOING ON!?

Spock - the testing as it should be done

It's not very often when I get really excited about some piece of software. I'm not saying it doesn't happen because that wouldn't really be true but those times when I get the willies just after taking a brief look at something are really rare. Today is that day. Today I met Spock.

Well technically speaking, I met this guy, Luke Daley, on 33rd Degree conference when he gave a talk about Spock and how it differs from what you can do with regular JUnit tests.

OK. Enough of about the conference - let's see some code!


If you put this into an example.groovy file and execute it it'll actually run 2 unit tests. On the test we see the following sections:

• We see that Spock is being grabbed (excluding Groovy since Spock tries to pull in some non-existent version)
• We then create an Example Specification (that's how you should read the class declaration line)
• We then say that we define that a sum of a and b is equal c (whatever those are)
• Then some magic happens: we say that we expect that a + b is equal to c
• And last but not least we define the set of data to create separate tests in a tabular, fitness-like form

Here's the output of that script (you should run it yourself to see it really do all the work!):

JUnit 4 Runner, Tests: 2, Failures: 0, Time: 15

Isn't it great? You spent about no time creating a few lines of code, got 2 test cases in return that execute in no time and are no match for JUnit's @Parametrized tests (which sucks big time by the way).

This is obviously the absolutely simplest example possible. There's a lot more to Spock than meets the eye here and the deeper you go there the more you wonder how's all that even possible. This is why I'll stick to Groovy as the most versatile, universal, non-problematic and powerful language ever created for the JVM.

Who broke the build massacre

Recently it's becoming more and more popular to create gadgets that "attack" or "shame" the one that broke the build on Jenkins. Some of them are really creative and funny!

This doesn't change the fact that it is outrageous and completely unprofessional that such "tools" are even needed. All that under the assumption that the person that did break the build (or even made it unstable) couldn't care less about it.

So my advice to you: do care about the stability of your work! Or else don't do software development - it's out of your league! You don't fit in!

REST Service - the two words that make no sense

It's been bothering me for like ages and I finally decided to put a blog post about it. Let's start with a couple of definitions:

WebService - a way of servicing someone (like "giveMeSomething" sort of way) over the web

REST - Representational state transfer. We're transferring a representation of the state (of someone) - not servicing anybody.

To see why is this so damn important first let's see what classic SOAP web services look like in practice. They consist of 3 things:

1. WSDL / XSD (description)
2. Endpoint (URL)
3. XML (data)

In fact there's one most important thing to note: the "endpoint" is/has usually a verb: "go get some flowers", "fetch history", "make me pretty" - you get the idea, right?

Now on the other hand REST has nothing to do with verbs - REST deals with nouns: people, cars, addresses, gasoline, money... So how do you make a person give money for gasoline for their car to allow them to get to a certain address they are heading?

WebService: MySuperDuperWebService.makeHimPay(Double money)
REST      : GET /person/54623445/account/1/balance (get the current balance)
            PUT /person/54623445/account/1/balance + current balance

The difference here is you're not giving a REST place orders other than update, delete, retrieve.

So the next time you'll be tempted to say REST service please bear in mind there's no such thing. What is however named as a "REST service" is a URL, that responds (usually) to POST (cuz that's so damn easier to pass data to) that has no predefined schema (usually..) and that instead of giving you back XML hands you over JSON (possibly using JSONP). That my friends is a definition of a JSON Service and has nothing, absolutely nothing to do with REST whatsoever. Even worse is the term RESTful web service. My God is that a horrible thing to say. It seems like the service being referred to rusts in peace and should never ever be called.

Make the world better for a change!

ExtJS inheritance strategy

I've been struggling for quite some time to come up with a strategy for writing ExtJS code so that no matter what kind of class I'm extending everything looks the same. Today I've finally ended up with what I wanted :). In this case I'm working with Ext 2.0.2 but it should apply without any changes to all versions of this wonderful library.

Challenges

I've set a goal to be as follows:

1. Instances will have proper class names and not some generated names
2. Declarations will present themselves in the code exactly the same way regardless of the base type
3. The code will look understandable

The template

First we need a namespace so that the global one doesn't get polluted:

Then we need to define the constructor (this will give the actual name for the class later on:

And finally we'll implement some public methods:

This way the actual class is "Namespace.ClassName" and not some wierdo, public methods are cleanly separated and default configuration is in one place.

As a bonus this pattern works for every single class - no matter if it is a component (GridPanel, Window) or not (ie. Store)

I hope this will make someone's coding adventure a little bit less messy :)


Have a nice day!