Padcom's blog

The quality of software - part four

2012-01-30T16:19:00.001+01:00

In today's installment we're going to look at the quality of code from a broader perspective taking into account all the previous installments. I'll try to outline the difference between a good project vs a bad one, even though they both make money.

What is software quality

There is and always have been a huge gap between the end product and the code. That gap has been introduced some ages ago with tapes and cards. They didn't make any sense whatsoever to the end user as much as the code today makes no sense whatsoever to the user of your next brilliant application. Let's face it: programming is an art not everyone can do and even less people can understand (even if they are in fact doing it). So what makes up for a quality product?

There are 2 sides of the story: one is the "make it to the market ASAP" side which tends to solve the problem of competing with others. Depending on the size of the project it might seem like it is a good idea to rush developers into doing the least that'll actually work or to push in some features that'll make the customers so much happier.

The other side of it is that software is created by human beings and that in turn reveals the weakest link in the process of creation. Even though we can be extremely creative in our brilliant ideas we tend to make mistakes, tons of them. The faster you write code the less careful you are and the more bugs sneak in into the final creation...

Sure there are people that get it right the first time, always, but there's so few of them you could put them into the "exception" group for a rule that programming is a very error-prone activity.

So quality in the broader sense is something that is good for both the end user of our software as well as the agility to fix any bugs or introduce new features into the project.

I can fix any bug in the projects I wrote - and do it FAST!

That's a common misunderstanding that one can find bugs within software product they wrote. It is so because we, humans, don't stay the same for the duration of our lives. We tend to learn new things even if we don't admit it to ourselves. Let me tell you that looking at the code that I created 10 years ago scares the hell out of me! And I'm not the only one...

So even though we'd like to think that if we'd be the only ones creating the software we will at some point face the danger that our old idea was plain wrong. Due to the changes that happened to our lives we tend to think differently and curse that brain-dead monkey that wrote this stuff some years ago.

Uncle Bob says: Why did you write it?!

One should always try to be at ones best when writing code. Period. There's no excuse for writing unsustainable code - be it for private use or for the company you work in. There's no excuse to write code that will make you ask WTF every 5 moments. That'll make your life and the life of your fellow developers a living hell. And the worst part of it that it is not only you, the programmer, that will suffer from it - it's everyone in the chain starting with the guy that wrote it and ending with the programmer's worst enemy - the end user... How come? Well first of all you will curse the day you entered the project, then your architect will throw thunders at you for writing that piece of crap, then your manager will tell you that you need to go faster and cut corners and at the end of all this there is the customer that will probably go ahead and buy another solution that will not break as often as the piece of crap you and I created.

My old boss when asked about what is software quality explained it more/less like this:

The quality itself is not a goal for itself. But at the same time it is vital in order to sustain the company and the products it delivers

What it says is there's no one or the other. The world is not gray in this regard. If you make a loan in the code you'll have to pay it back in order to go further...

Summary

The summary of the whole series is quite simple: do TDD, do continuous integration, do pair programming, do code reviews, do make the querulous customer happy! They deserve it. You deserve it. You deserve to do the right thing. And if you can't do that then quit now and never look at software development again.

Grails and Ratpack

2012-01-29T14:19:00.008+01:00

Today I've found out about the Ratpack plugin. Being a huge Sinatra fan I was quite fond of the Ratpack framework to begin with and naturally I was amazed to see it incorporated into Grails as a plugin. And it works!

Let me walk you through a very simple example of using Ratpack inside Grails.

We start by enabling the Ratpack plugin in our application. I called mine app "example" so all the URLs will be prefixed with "/example". To include the plugin you need to add it to grails-app/conf/BuildConfig.groovy like this:

With that in place we'll create a domain class to have some data to display. I'll go with the simplest possible class that represents a person grails-app/domain/Person.groovy:

Simple enough, right? Let's go an make some use of it in a Ratpack file. Create a folder grails-app/ratpack and inside of it a file called PersonRatpack.groovy:

As you can see here all we're doing is responding to the GET method on some root URL. Ratpack uses SimpleTemplateEngine from Groovy. We have to tell it where to look for templates Config.groovy:

So let's create one to display the people from database grails-app/ratpack/templates/list.html:

Simple enough, right? It almost looks like a mix of ERB and expression language from JSP. I think you'd have to ask the authors of SimpleTemplateEngine if those similarities have been made on purpose of if this syntax just seemed to be the only one that made sense...

Anyways, with all that in place we can add some people to the database in our grails-app/conf/BootStrap.groovy file like this:

And that's it! start the application, navigate to http://localhost:8080/example/ratpack and you should see the list of two people on the screen.

Needless to say you can accomplish the exact same thing using a controller and a view. The idea here however is to show you that there is life beyond the standard artifacts and that the beauty lies in diversity!

Hope this will help someone get started with this awesome piece of code!

Intermission

2012-01-19T00:20:00.001+01:00

Today's protest against SOPA and PIPA acts have had a tremendous impact on Internet traffic around the globe. Millions of people have been made aware of the irresponsible propositions of attack on freedom in the Network. You can't name it any other way than censorship which is the public enemy number one by any definition.

I support Wikipedia, WordPress and all the others in their campaign against SOPA and PIPA!

God help us all when the time comes to kill the last free medium on the planet.

You don't get to drive - part three

2012-01-13T23:28:00.005+01:00

In the recent installments we've looked at software development as a discipline that has its own way of working. Its history, however brief, didn't leave any room for being mistaken with anything else. It is the single, most dynamic part of our modern society. But how do people handle it?

If you're young, in Poland it'd be under 18 years old, you don't technically get to drive a car without adult supervision. That's pure theory nowadays but at least that's how it should be. Being young and funky gets lots of stupid ideas into your head like driving over 100km/h in town chasing a friend without knowing the road ahead. Been there, done that. It doesn't mean I was in my right mind when I did it.

There are places where being wild is good. Certainly things where life is at stake are not the kind of ones where you'd expect one to go all in without training but that's what is actually happening all the time. People (including me) are by definition reckless and unpredictable and nothing is going to change that. There's a reason for that: had we been reasonable all the time no big discoveries would have happened. We wouldn't know about the continents of America, we most probably wouldn't know that radiation is actually bad and finally we'd probably die of hunger had there been no brave hunters risking their lives to master hunting animals.

In today's modern world however we do have the opportunity to make less mistakes - at least less of those obvious ones. And with that let me present you with a definition of two words in German:

Verfügen über - to have the knowledge about something, used in the sense "I do have a driving license"

Beherrschen - to have the ability to do something, used in the sense "I do know how to drive a car"

With those two there's little difference, right? Usually if you do have a driving license you should be capable enough to drive a car. But can you? Is that really what is going on?

Let's try to apply that to software development for a moment. It is obvious you need to study to get the diploma to be a software developer. But does it mean you can do software with it? Can you actually make a living with it? As it turns out yes, you can. The discipline is so vast and by all means so naively taken by so many companies that the moment you step out of school you're ready to go, hot shot! You are the man with the skills. But are you?

In my experience with young graduates and with students it was seldom the case when a young developer right after school was really ready to go. Actually I know only two people that when they came to work at a company with me I felt respect for the wealth of knowledge and humility for things they don't know. And so far it was just the two people I know this far that were open to the suggestion to learn new stuff. There's been sooo many cases where the lack of will to learn new technical skills was demonstrated along with arrogance (not to be confused with confidence) I couldn't even count.

The worst thing about it is they really do get hired! And believe me when I say there are companies where a fresh graduate hired almost off-the-shelve gets the ability to flush the project they are working on literally down the toilette. That means a very young in terms of experience person gets commit access to software that costs hundreds, sometimes even millions of dollars! And we're not talking sporadically - it's how certain companies operate! There's a saying that "there's no person that can't be replaced with a finite number of students". That's how the new markets for software developers came to be.

Obviously in every rule there are exceptions. I know that in the area there are maybe 15%-25% people that really get what software development is all about. And that's actually a very good ratio considering that software development has been announced one of the best paid jobs for graduates and is also viewed as one of the easiest ones in terms of rules.

Yes, rules... What kind of rules are there?

Among those professions I just mentioned there's an MD and a lawyer. Once you're done with your study you don't get to cut-open anybody for any reason, right? You need to gain practice under a trained eye of someone with that experience already there. Otherwise nobody would trust you with a knife doing god knows what to the body of a living soul! Same thing with lawyers. I hope you catch my drift here.

But is it like this with software developers? Do they need to undergo a practice to get certified as software developers that can cut-open (refactor), create and destroy (god-like powers) and provide real value to customers earning big big money for their employers? I think not. I'm sure there are companies that do tend to forbid new hires (freshly out of school or not) to commit anything until they have been long enough with the company to get what they are doing. But it's not always the case. They are hired to do the job, to be resources, not engineers. They are just numbers that mostly do not add up. But there's hope that not everyone is as mad in their doing as the ones I've just mentioned. There's the opensource community that follows exactly the kind of path that it should. You start small, familiarize yourself with the code, maybe submit a patch or two, become a contributor first, gain the trust of other team members and finally if you prove yourself worthy you get the commit access. By the time you get it you'd do harsh things to people for causing harm to the project. I wonder why people do put the information about being a commiter to some opensource project on their CV.. Interesting, isn't it?

More than anything else one needs to remember that software development is about learning and practicing. It's not always something new you need to learn. A lot of times it is something really, really old. Without knowing and above all without practicing it is not possible to "beherrschen" something. Nobody was born with the ability to drive an F1 car. You might "feel it" but you need to train to be good at it. You do need to get your hands dirty!

Have a nice weekend!

The alchemy of software development - part two

2012-01-06T15:20:00.009+01:00

In this installment let me walk you through the valley of shadows nobody using computers wants to look at. Let’s have a look at what creating software feels like, what it actually is and why at the end of the day you should care how it’s done.

Software isn’t some forbidden science. It might be hard to understand by mare mortals but it definitely is not something that you can’t do even if you’re not very much into it. But should you? How does it feel like to be a software developer?

Imagine you have this completely obedient servant ready to do everything without hesitation. You tell it to jump of a 100-story building without parachute and it does it. Right down on its face. Splash! Boom! There’s blood everywhere, harsh words,... But nobody cares - it was your servant and you have had complete control over him. The ultimate power! That’s you and the machine. And programmers do that sort of things every minute of every day when they create software. Up to the point when they figure out that the servant lives longer when he has a parachute that actually opens. Sometimes the servant goes haywire and does things the developer does not expect him to do. Suddenly he might refuse to jump even when all the precautions are in place and ready to go. Jump! Jump! Damn it! Then a moment of revelation happens: the developer instructed the servant not to jump if it’s raining, which makes perfect sense. He just didn’t realize the definition of rain was actually not very precise.

The problem with your servant is that he understands only a very specific language. That language has only two words: a zero (0) and a one (1). Fortunately enough scientists realized that ages ago and created human-to-servant translators called compilers. Other mad scientists though that telling your servant to jump without parachute is a bad idea all along and created safe nets forbidding you to do that at all. That’s how runtime environments like Java or .NET came to be... All of the sudden your servant isn’t so obedient anymore. He has more than one master now and your word means nothing compared to the rules enforced by “The Creator”, be it the one that taught you and your servant to communicate or the one that thinks you’re complete moron that needs to be controlled as much as possible.

In the center of all this there’s the programmer. But he’s not alone! There comes the light at the end of the tunnel! The new hope! The solution to every problem he has ever had.. Miracle! A new technology has been created that is supposed to take the pressure of his back. It’s not a few moments later when he realizes that the light he saw was actually coming from a train heading his way and he starts feeling much more like he was before.

The battle continues. Things are getting complicated because some other programmer comes in. The new guy might actually help but he doesn’t speak the language. Well, they both speak English but in a different way. They have different opinions about the side of the building the servant should be jumping from. Finally they agree that going from a corner makes the most sense. After all it’s the fact of landing that counts, right? It’s not the fact of flying itself (even though the most interesting one) but the safe landing that the crowd will observe. So it even makes sense to go a bit crazy and to tell the servant to wait until he’s about half the way through to open the parachute. This way the crowd will be even better entertained and get the result quicker.

There’s that one last thing the team didn’t take into account. The original developer left and with him the original reason for the servant to exist. He was the one knowing all the why’s and how’s about the jump. The rest (and now there’s like a 100 people working the servant) tries really hard to overcome all the tangled cords. Some of the Gordian knots can’t be solved so they cut them out replacing them with new ones, of a different nature, or even leaving the parachute crippled counting on the fact that the remaining strings will still do the job.

Of course since there’s a huge group of developers some of them are more aware of the actual power they have and others don’t. People are different and that’s actually a good thing. From variety comes evolution, right? Well... If you want to jump on a parachute you wouldn’t put your life in the hands of some young inexperienced fast-food assistant, right? After all he knows nothing about jumping! But hey, that’s what happens all the time! After all how the young will learn if not by killing the servant just a couple of hundred times more? That’s not something the more experienced developers like so they manifest their position very strongly. They say they need to be treated like professionals because they “know”. They create manifests, meet to grizzle about colours of the parachute when at the same time their younger colleagues help the servant meet his destiny a couple times more. The servant has many masters. He tries to listen to all of them but there’s just to many. He becomes the hooker trying to fulfill everyone’s dream...

At the end of all this no one knows why the servant needed to jump. That’s perfectly normal and to be expected. The beauty of software development though is that there’s now a servant on every single tall building because everyone wants to have one! It doesn’t matter if you sell condoms or make cars... Just make the freak jump! We need this!

Hope you’ve enjoyed the trip!

Modern state of software development - part one

2012-01-06T13:19:00.000+01:00

Throughout the history the software industry has undergone a number of changes in moods, best practices, reinventions of the wheel, reincarnation of old ideas and sunset of countless technologies. Looking back at what has happened in the last two decades in both software development as well as software complexity is really astonishing.

The evolution has truly changed the world as we know it. The foretold End Of The World “scheduled” for this year by Mayan calendar is actually a work in progress. The world as our parents knew it doesn’t exist anymore. Cars are capable of performing maneuvers one had to learn alone (like parking) and it doesn’t take The Great Oracle to be almost certain that in the near future controlling a car will become obsolete all together. Same thing with TV sets becoming not a view-only experience but communication centres, refrigerators controlling the state of food by (almost) themselves or finally cell phones being sold without the capability to make phone calls but with a 24/7 Internet connectivity. All those things exist because there’s a need and all of them are driven by software.

Since the early 70’s the software industry is the single, most energetic part of our western society. The only other one capable of keeping up is its twin brother, the hardware industry. But even hardware is designed with software these days. Ironic, is it not?

In the middle of that is the most incredible, demanding and abstract profession out there, a program writer. Oh wait - we’re not program writers anymore! We are software developers!

That brings me to the merit of this blog series: what is actually software development? Is it really a profession, like a carpenter or shoemaker? A shoe is something I can wear, right? It’s a real thing made of real components. I can use a table made by some carpenter to have the evening meal with my family. Or maybe it’s more like a T-Shirt? But can I touch the software?

Certainly you can have fun with it! Games are the biggest time devourer ever :) I'd argue that if it wasn't for computer games the whole computerization wouldn't take place at all. It's through games that we have shed the fears of our parents about a computer being the Satan's tool of mass destruction. Who knows? Maybe they were right? The fact however remains unchanged that current generation of western civilization can't live without computers. And computers need software...

Have a nice day!

jQuery and posing JSON data to the server

2012-01-03T23:14:00.004+01:00

Today a good friend of mine asked me how to post JSON data to the json-rest-api plugin using jQuery. As it turned out using $.post() doesn't do the trick...

Well it's not impossible but very inconvenient if you have to do it a lot. First you need to use the $.ajax() method, not the $.post() one. Secondly you need to specify the contentType parameter for the receiver to be notified that the data is in that format. And last but not least it is crucial to properly serialize your object to string.

The last part can be done using JSON.stringify() but writing this over and over again is painful. Here's a gist (raw) you can use that adds a sister version of $.post called $.postJSON that does exactly the same thing as the original one but sends data in JSON format instead of form post.

Parameters are exactly the same with the single difference that the default expected data format is "json", which makes sense if you're working with JSON services.

Happy coding!

Grails, Heroku and spring-security-core

2011-12-28T21:01:00.000+01:00

This one is going to be quick, but made me spent almost 2 hours to google it...

If you install the spring-security-core plugin and want to deploy your application o Heroku you'll end up with a nasty-looking exception like this:

java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use RequestContextListener or RequestContextFilter to expose the current request.

If you google for No thread-bound request found you'll find some Jira issues that'll tell you pretty much nothing besides that it is a Grails issue.

Among other search results is also this one stating that the actual issue is with the webxml plugin being snatched in the wrong version and that you need to force Grails to use the right one like this:

BuildConfig.groovy:
compile ":webxml:1.4.1"

I have no idea why Burt Beckwith will not upgrade the webxml plugin dependency to 1.4.1 (which does fix this bug). Until that happens just put the line above in your build config and life is good again.

See ya!

Grails routing plugin family updated

2011-12-03T19:33:00.000+01:00

It's about time the routing plugin providing EIP functionality for Grails be updated to work with the latest version of Grails which at the time of writing is 2.0.0.RC3. And so today the plugin has been updated to 1.1.4-SNAPSHOT with the plan to release 1.1.4 by the time Grails 2.0.0 final will be out.

Here are the highlights of 1.1.4-SNAPSHOT:

Apache Camel core libraries updated to 2.9.0-RC1 (with the plan to upgrade to 2.9.0 final once it gets out)
Apache ActiveMQ (routing-jms plugin) upgraded to 5.5.1

Also the example project has undergone some extensive upgrade:

rewrite from ground up with Grails 2.0.0.RC3 (so all the bells and whistles like resource plugin and webxml plugin are there)
extended the example route with an example of processor that's defined as Spring bean.

The last feature is a response to an issue posted on GitHub that had to do with providing access to services from processors which Camel is already capable of - it just requires some additional work but it is so not without reason.

I hope you'll enjoy!

Grails 2.0 - the power is back

2011-11-28T02:21:00.000+01:00

Recently I've been bitching about the stability of Grails 2.0 and specifically the lack of it. Tons of stuff was just wrong: the new GSP parser was buggy like hell, hot-reloading using the new agent just didn't work - you name it. But with the RC1 release most of it is gone and the new version of Grails starts to look like something you could actually use!

Hot reloading.

Since its early days Grails was the number one framework and that in most part due to its hot-reloading capabilities. You could just change a view, controller or service, wait just a few seconds and the result would emerge after refreshing the page. That presented a huge advantage over classic Java EE development where a single change in the code forced the developer to recompile and restart the whole application. That's why I hate regular Java EE development with a passion. Sure there's the Java Rebel thingy but it costs money - a lot of money!

Grails 2.0 uses a different approach than the one in 1.x series but a similar one to Java Rebel. There's a Java agent that does all the heavy lifting of incorporating new code into existing application. So let's summarize what works and what doesn't:

- reloading controller - check
- reloading services - check
- reloading url mappings definition - check (with the exception of mapping to HTTP codes)
- reloading domain classes - not working
- reloading Groovy sources under /src/groovy - check!
- reloading Java sources under /src/java - check!

There might be other areas but the general impression is really awesome!

New scaffolding templates

Well.. they are nice and green and dandy and... well I liked the old ones better (from the general look-and-feel point of view). The new ones still use the word "main" for everything: CSS, template and the application.js. Does anyone knows who made that stupid decision to call "main" or "application" something that should be called "scaffold"??? In the current state of things if you're thinking about doing anything serious with Grails you should install the templates and rename them to something that makes sense, like for example main.gsp -> scaffold.gsp or main.css -> scaffold.css. Other than that it's looking really good! Just the fricken naming...

Resources and other capabilities

Well, finally the resources plugin made it into the core! So from now on the problems like having lots of small JavaScript or CSS files and cramming'em together for the release version are gone. This is probably the only platform out there (besides ASP.NET :D) that does it right from the start. Granted it doesn't come for free - you need to configure it properly and it can be an unpleasant experience all along (unlike in ASP.NET where it's actually a part of the page itself). But at the end of the day it is really useful and you should use it.

Also the Datasources plugin found its sibling in the new release! This will be a blessing for everyone that needs to work with multiple databases in their Grails applications. In the databases plugin configuration was "almost" like the one you'd normally have but different enough to make you curse the creator more than once. I'm delighted to say that this has been unified and finally all datasources can be specified in the same configuration file, DataSource.groovy. Yay!!!

And last but not least - testing. Finally someone took the hard dependency on old 3.x JUnit and flushed it down the toilette! Man that was really what I was looking for. All test cases are now JUnit version independent and use the coolest Groovy feature ever: Mixins!
Finally testing domain classes in isolation is possible and doesn't make you puke at the mockDomain() call every time you see it. Finally the power is back!

Plugins

I've received some notifications that the plugin architecture has change a bit and that some of my plugins (namely the json-rest-api) don't work properly. It's sad but not unexpected. The general idea is that plugin authors will have to take a good look into regression before they can 'certify' their plugins as 2.0-ready.

Summary

The general feeling of Grails 2.0 is really great. Finally playing around with most of the UrlMappings is simple and fast (which it wasn't in 1.x), testing is fun again (even with Spock and the like) and all the rest is just great. So I guess the final message should be "go and use and forget about 1.3.7 that has been around for like ages".

And finally I really need to get this out of my chest: when it comes to regular Java EE development like with JSF (outch), Struts or what have you one should really go kick some corporate butts to get them to start thinking again that web development shall not be a nightmare anymore. We have the technology, you know, to make it right for a change!

Go spread the word!

Why using a plain-text editor is a good thing

2011-11-06T22:26:00.001+01:00

For the past years there's been a boom on the market for web applications. Along with that the possibilities for supporting technologies grew like never before. This has a two-fold implication.
First it is imperative that we recognize the need to write less and do more - that's where the new languages come in. Second it is obvious that new languages tend to emerge a lot faster than companies would like them to and as a result the fat IDE support is missing.

Obviously enough it's going to make for a strong case for plain-text editors (probably with some syntax highlighting like the good old vim or emacs). Those editors don't bother making deep sense of what the code really is. All they care about is that it is text.

"But I need refactoring support to be productive" you might say. Well, refactoring in new languages tends to be a lot less tedious than in (for example) Java where changing a file name leads to all sorts of changes that need to happen just to do this simple thing. New languages like F# for example (which is not all that new if you take into account its roots) have some refactorings kind of built in into the language and most plain-text editors support it out of the box. I'm talking here about method extraction and the way the Tab key works in most modern editors on more than one line of text.

In addition to that many new languages give you the power of succinctness never seen previously in specific areas. Take CoffeeScript or LessCSS for example. With those two new languages you can put together code in such a manner that when compared to the original language you'd write it in (JavaScript and CSS) can cause your head to explode.

At the end of the day it is up to you if you want to write more with (for the most part) good IDE support or if you're ready to give up some of that luxury in favor of more readable and less error prone code. But remember: the less code you have the less bugs you're going to have and that alone should make you want try out the latest inventions.

Have fun!

Hazelcast and Grails

2011-10-16T19:05:00.003+02:00

If you'll ever find yourself in need to partition your Grails application in order to provide high or availability or if you're lucky enough in order to increase processing power because your database is already not the bottleneck (which it will be for a long long time) then you should definitely check out Hazelcast and its Hazelcast WM module. Configuration is dead simple (a few lines in web.xml) and the thing is capable of auto discovery using multicast so you just add instances of both the Hazelcast distributed cache as well as instances of your application and everything just works.

Man, it's been a while since I found a tool that just does the job no questions asked and Hazelcast definitely is one of them!

And live is good again :)

Creating standalone applications with Java and Maven

2011-10-16T12:52:00.000+02:00

The challenge

In this installment we're going to take a look at what does it take to create a standalone Java application that's a little bit more sophisticated than the famous Hello, World. Let's start with the simplest example:

package org.example;

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

To compile and run this one we need to invoke the javac compiler, package it to some jar file (say example.jar), create a manifest file (or not..) and start the application passing on the proper classpath and class name that is the entry point to our application. This might look something like this:

java -cp . org.example.Main

The "proper" way

I know for a fact that Maven can be a pain in the ass if used by some inexperienced fellow that wanted it to do everything but didn't know how to ask for it. For example for tasks that Maven is good at like specifying dependencies using Ivy and Ant for it makes no sense, right? Well, you wish! I've seen those kind of nonsense a lot of time with pom.xml reaching out beyond the magic 100k boundary...

Instead of cranking up the heat I'd like to see people develop simple mojos solving one problem at a time and not resorting to ant or anything like it. But above all, for crying out loud, use what's already there to do the job!

Doing Spring in standalone Java application

If you can imagine how hard would it be to prepare a standalone Java application that uses external configuration, external libraries and resembles what users are already used to (the bin folder, the lib folder, maybe some conf or etc for the configuration files) you'll appreciate the fine job application assembler is going to do for you.


<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>appassembler-maven-plugin</artifactId>
    <version>1.1.1</version>
    <configuration>
        <copyConfigurationDirectory>true</copyConfigurationDirectory>
        <configurationDirectory>etc</configurationDirectory>
        <repositoryName>lib</repositoryName>
        <repositoryLayout>flat</repositoryLayout>
        <programs>
            <program>
                <mainClass>org.example.Main</mainClass>
                <name>example</name>
            </program>
        </programs>
    </configuration>
</plugin>

That's pretty much it! All you have to do now is to call maven to do your bidding.

mvn clean package appassembler:assemble

Please note I didn't change anything in the application itself. Well that's because it's not a post about how to instantiate Spring in a console application but rather how to package everything so that it works as expected. You can take a look at a fully working example on GitHub.

Have fun!

Eclipse hint: Aptana Studio

2011-10-08T13:00:00.000+02:00

I know I wrote the other day that I don't use Eclipse and I don't when working with anything else that Java. You just can't get away editing Java code on any serious level in any plain-text editor because the language is not designed to do it (like Groovy or Ruby for example). Recently I've been doing some research on what's available out there in terms of plugins and I've stumbled upon Aptana Studio. Even though I don't plan to code in Ruby any time soon I've decided to install it and give it a try.

All things considered I have found the one piece of that "studio" that has convinced me that working with Eclipse might be fun: the Terminal window :)

Imagine you're working with your project and all of the sudden you need to do some command-line processing (for whatever reason). With Aptana Studio it's extremely easy: you just right click on a node in project explorer or package explorer and select Open in -> Terminal :D

Man I like those little discoveries that make my life easier...

Gitorious - a working guide to install

2011-10-06T22:14:00.002+02:00

Finally someone did a guide on installing Gitorious on Ubuntu 11.04 and it WORKS!!!

Go check it out at http://coding-journal.com/installing-gitorious-on-ubuntu-11-04/

Using DWR with JBoss and EJBs

2011-10-01T23:03:00.000+02:00

Today we're going to get our hands dirty with the Direct Web Remoting (DWR) library in conjunction with JBoss and the EJB mechanism.

The why

DWR is a powerful library for all things related to remote method calls using HTTP. It can serialize lots of things, use DTOs if provided but above all it does one thing so easy it should be forbidden: It allows you to create or retrieve an instance and call its method directly from your JavaScript. This is why I'll always favor DWR over hand-written mechanisms or misuse of REST libraries like RESTfully. REST is all about resources - Ajax not necessarily...

The how

We're going to use DWR version 3.0.M1 as this is the latest available in Maven repository at the time of writing. Creating the project itself is outside of the scope of this post however configuring the framework isn't so we're start with that.

web.xml


<!DOCTYPE web-app PUBLIC
  "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
  "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
  <servlet>
    <servlet-name>dwr</servlet-name>
    <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
    <init-param>
      <param-name>debug</param-name>
      <param-value>true</param-value>
    </init-param>
  </servlet>
  <servlet-mapping>
    <servlet-name>dwr</servlet-name>
    <url-pattern>/dwr/*</url-pattern>
  </servlet-mapping>
</web-app>

As you can see here this is pretty much the basic that you'd expect from a web application that has one servlet in it. The other stuff will be done using a HTML page and a stateless local bean so let's get on with it.

`Service` interface and `ServiceBean` implementation

package com.aplaline.example.ejb;

import javax.ejb.Local;

@Local
public interface Service {
	String action();
}

Nothing fancy here - let's move on to the implementation:

package com.aplaline.example.ejb.impl;

import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

import com.aplaline.example.ejb.Service;

@Stateless(mappedName="ServiceBean")
public class ServiceBean implements Service {
	@Override
	public String action() {
		return "Hello, world! from EJB!";
	}
}

Again... absolutely nothing fancy here - standard Hello, world! style bean. Let's see how we can configure DWR to serve the Service.action() method...

`dwr.xml`

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE dwr PUBLIC
    "-//GetAhead Limited//DTD Direct Web Remoting 2.0//EN"
    "http://directwebremoting.org/dwr/dwr30.dtd">

<dwr>
  <init>
    <creator id="ejb3" class="com.aplaline.dwr.Ejb3Creator" />
  </init>
  <allow>
    <create creator="ejb3" javascript="ServiceBean">
      <param name="bean" value="ear/ServiceBean/local" />
    <param name="interface" value="com.aplaline.example.ejb.Service"/>
    </create>
  </allow>
</dwr>

Now that's the meat I'm talking about! Let's get a closer look at what's in there:

The `creator`

The creator class originally coming from DWR is best suited for other J2EE containers but it has a huge issue with JBoss so we're implementing our own, JBoss-friendly one:

package com.aplaline.dwr;

import java.util.Properties;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

import org.directwebremoting.create.AbstractCreator;
import org.directwebremoting.extend.Creator;
import org.directwebremoting.util.LocalUtil;
import org.directwebremoting.util.Messages;

public class Ejb3Creator extends AbstractCreator implements Creator {
  private String bean = "";
  private String interfaceClass = "";
  
  public void setBean(String bean) {
    this.bean = bean;
  }

  public void setInterface(String interfaceClass) {
    this.interfaceClass = interfaceClass;
  }

  @Override
  public Class getType() {
    try {
      return LocalUtil.classForName(interfaceClass);
    } catch (ClassNotFoundException ex) {
      throw new IllegalArgumentException(
          Messages.getString("Creator.BeanClassNotFound", interfaceClass)
      );
    }
  }

  public Object getInstance() throws InstantiationException {
    Context jndi = null;

    try {
      Properties props = new Properties();
      props.load(getClass().getResourceAsStream("/jndi.properties"));
      jndi = new InitialContext(props);
      return jndi.lookup(bean);
    } catch (Exception ex) {
      throw new InstantiationException(bean + " not bound:" + ex.getMessage());
    } finally {
      if (jndi != null) {
        try {
          jndi.close();
        } catch (NamingException ex) {
          // Ignore
        }
      }
    }
  }
}

What it does is it allows you to specify the interface class as well as full bean name as depicted in the dwr.xml example above.

The `create`

In here we're specifying all the bits and pieces needed for the framework later on to create JavaScript proxy and identify our bean when the time comes. This is the time to see how we can use it, shall we?

The `index.html`

<html>
<head>
  <title>Example</title>
  <script type="text/javascript" src="/dwr/dwr/interface/ServiceBean.js"></script>
  <script type="text/javascript" src="/dwr/dwr/engine.js"></script>
  <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js"></script>
  <script type="text/javascript">
    $(document).ready(function() {
      ServiceBean.action(function(response) {
        $("#output").append("<p>" + response + "</p>");
      });
    });
  </script>
</head>

<body>
  <h1>Example</h1>
  <div id="output"></div>
</body>
</html>

This needs a word or two of explanation. At first we're including a JavaScript proxy class that will serve as a mediator between JavaScript and the server side. Then there's the required engine.js inclusion. This includes all the bits and pieces of client side DWR. Then we're including jQuery from Google CDN because I hate to re-get the library over and over again. Then there's the most interesting part - the usage: The ServiceBean object is created by inclusion of the ServiceBean.js resource. It automatically has a action method that takes all the parameters as the server-side counterpart would (none in this example) and as the last parameter there's a callback to execute after the response is returned. Pretty simple, right?

Bottom line

If you'll ever find yourself in need to call some EJB (or Spring or Guice) managed instances from JavaScript you should seriously consider using DWR as it makes life a lot easier.

As always here is a ready-to-use example for you to check out (tested with JBoss 4.2.3).

I've been using it from within Eclipse thus the name of EAR is "ear" (and thus the JNDI name of the EJB starts with "ear/"). If you run it from command line please update the name accordingly before use!

Have fun!

What the hell is wrong with collections API in Java?!

2011-09-28T20:58:00.000+02:00

Today is the day when steam came out of my ears and I started screaming "WTF?!?!". So what's wrong? Let me explain...

The good part

I came to pure Java from Groovy. I never liked Java as a language in particular (I'd even go as far as "I hated it with a passion") but life is life and I've had to put my hands into the dirty world of legacy Java code once again. Being the Groovy fan for quite some time now tough me that functional programming style is something that makes your life easier and the code itself a lot more readable. That's especially true in regards to collections!

I don't want to bring up obvious examples like sorting a collection using spaceship operator or something along those lines. That's been done to death. Instead I'm going to tell you a story...

The story so far...

Back in the days there have been collections and a handful of utilities to back up the bare collection objects (java.util.Collections). At some point people saw that what the creators of Java the runtime library gave them to play around was not enough so they invented commons-collections. And life was good again because we could do things easily that were cumbersome before. That was in the pre-1.5 days so no generics were involved as you might imagine. That in turn forced the developer to do idiotic type casts from Object to the respective type when implementing for example a Transformer.
After a while Java the language 1.5 came to existence so people sat there and wondered how we can make the best out of it. This is how commons-generic came to be: The same set of utilities but with generic parameters so you can avoid doing silly casts. That must have been a brilliant idea, you might wonder... But as it turns out the compatibility is virtually non-existent so you can stick it up a$$ since everyone else is using the old commons-collection anyways...
If that wouldn't ring any bells yet not so long ago Google came up with yet another professional and good looking collections library, the google-collections project later on included into google-guava. Yet again the same stuff happened: separate predicate definitions, mapping functions - you name it!

Groovy the savier

I know you're going to say that Groovy is a dynamic language and I should back off of Java and not compare apples and oranges together. But then wouldn't it be at least sane to allow some classes/interfaces to be extended in some way? Like they do it in C# or VB using extension methods... Oh and btw. if you're saying that they will be in version 8 I rush to explain that C# had them from 3.0 which is not so far away from Java 1.5 as far as I can remember...
So back to Groovy... If you want to transform some list of objects into another list of objects you have the all mighty collect method that does exactly what you need. If you want to extract just a single property from all instances in collection you just type for example people.firstName and that's it. It's really simple...

But there we are... in Java

If you'd like to make use of your code in all the fancy collection utilities hyper super duper tools you'll have to create your own version of the predicates/mapping functions (to be on the safe side, of course) and then create tons of adapters just to satisfy the compiler and the ever growing egos of collection utilities libraries creators.

Have fun!

CORS filter for Java applications

2011-09-23T18:55:00.000+02:00

Hi there, in today's installment we're going to allow Ajax calls from other domains to be answered and accepted by browsers.

The what

This thing (completely forgotten by many) is called Cross Origin Resource Sharing and works with standard Ajax requests your browser can send. You can read about it in depth on Wikipedia or on the http://enable-cors.org/ site.

The how

Let's get to the meat - shall we? On the http://enable-cors.org/ site there are many recipes for all kind of servers and they respective configuration but what if you'd like to enable CORS just for a part of your application? If you're lucky enough and you're coding your application in Java then there is a standard mechanism to do just that! It's called filters.
Here's the most simple way of implementing CORS response headers:

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class CORSFilter implements Filter {

	public CORSFilter() { }

	public void init(FilterConfig fConfig) throws ServletException { }

	public void destroy() {	}

	public void doFilter(
		ServletRequest request, ServletResponse response, 
		FilterChain chain) throws IOException, ServletException {

		((HttpServletResponse)response).addHeader(
			"Access-Control-Allow-Origin", "*"
		);
		chain.doFilter(request, response);
	}
}

As you can see here all we're doing is adding the Access-Control-Allow-Origin header so that the browser can accept the response sent by server.

You can use this filter as follows in your web.xml:

<web-app>
	<filter>
		<filter-name>CORSFilter</filter-name>
		<filter-class>CORSFilter</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>CORSFilter</filter-name>
		<url-pattern>/api/*</url-pattern>
	</filter-mapping>
</web-app>

Have fun!

Using JRebel from pure Maven in a web application

2011-09-21T23:32:00.000+02:00

Hi there folks!

I'm sure you've read every bit and piece about how to bend Maven to do your bidding. This time I'm most probably going to duplicate a lot of stuff found on other sites but I'm simply sick and tired of looking it up every single time I need it. We're going to configure a Maven web application project to run under Jetty (mvn jetty:run) with JRebel to do the reloading. So let's get started!

Installing Maven and JRebel

That one is a no brainer but for the sake of completeness I list this particular step here as well.

The `pom.xml`

The pom.xml file we're going to use looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>

  <groupId>org.example</groupId>
  <artifactId>war</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>war</packaging>

  <name>Example Web application</name>

  <properties>
    <!-- stop stuppid Maven message about build being platform-dependant -->
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <build>
    <plugins>
      <!-- make sure we're using Java 1.6 and not some stone age version -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
      <!-- enable jetty:run mojo -->
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
          <scanIntervalSeconds>0</scanIntervalSeconds>
        </configuration>
      </plugin>
      <!-- enable generation of jrebel.xml - needed for the agent -->
      <plugin>
        <groupId>org.zeroturnaround</groupId>
        <artifactId>jrebel-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>generate-rebel-xml</id>
            <phase>process-resources</phase>
            <goals>
              <goal>generate</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Running Maven with JRebel

You need to specify the javaagent as JRebel in order for the class-reloading to work. You do that by extending the environment variable MAVEN_OPTS with the following:

set MAVEN_OPTS=-javaagent:C:\progra~1\ZeroTurnaround\JRebel\jrebel.jar %MAVEN_OPTS%

With that in place run mvn jetty:run or mvn tomcat:run and you're all set!

Doing reloading

Please bare in mind that Maven is not Eclipse! When you save a file it doesn't automatically recompile it so in order for the modified class to be reloaded you need to recompile the project using mvn compile!

Well that pretty much summarizes it. It's not very difficult to setup as you see here but there are steps that are not described all in one place so here it is for your entertainment :)

Have fun!

Java 6 has a web server inside!

2011-09-18T13:26:00.003+02:00

The what

I'm into miniaturization - anyone who knows me also knows as much. Probably because I'm not very tall for today's standards but mostly due to the sole nature of small things: they are easy to figure out. For example getting to understand every bit and piece of the whole car (whatever brand) is impossible. In many cases no one would even allow you to go that far. But having a deep understanding how manual shift gear box works shouldn't be a problem for moderately intelligent person... The exact same principle adheres to software development as far as I am concerned. I like small parts I can grasp in short amount of time and have it used right after the learning process knowing what the hell I'm doing. You might think about it in terms of components of a desktop application, a JavaScript library for dynamic web pages or (as I've found out today) in terms of a small set of classes that do exactly what they are supposed to do and you can have them do their thing in a matter of minutes. I'm obviously (as the title suggests) talking here about the embedded web server found in the com.sun.net.httpserver package.

The how

Besides being fixated on miniaturization I'm also a Groovy freak as I thing this is the best language for JVM ever created and there's nobody to convince me otherwise :D For that very reason the following example showing a miniature web application with embedded web server is a Groovy script:

import com.sun.net.httpserver.*

class ExampleHandler implements HttpHandler {
	void handle(HttpExchange exchange) throws IOException {
		def response = "Hello, world!"

		exchange.sendResponseHeaders(200, response.length());
		def outout = exchange.responseBody
		outout.write(response.bytes);
		outout.close();
	}
}

public class ExampleAuthenticator extends BasicAuthenticator {
	static users = [ "john": "john123" ]
 
	public ExampleAuthenticator(String realm) {
		super(realm);
	}

	@Override
	public boolean checkCredentials(String username, String password) {
		return users[username] == password;
	}
}

def server = HttpServer.create(new InetSocketAddress(8000), 0);
def context = server.createContext("/example", new ExampleHandler());
context.authenticator = new ExampleAuthenticator("Example application")
server.executor = null
server.start();

Let's start from the beginning...

The `ExampleHandler` class

This particular class is responsible for generating all the output sent later on to the server. As you can see it's a very minimalistic thing here, even to the point where the body needs to know how big it actually is. The line Exchange.sendResponseHeaders(...) shows that. The rest is pretty self explanatory so I'm not going to drill into it.

The `ExampleAuthenticator` class

This class provides basic authentication for our small application. It's so damn easy anyone will understand it right away but for the sake of clarity here's the bottom line:

Every credential is stored in the static users=[:] map

The meat

Now we have finally come to the good part! The actual use of HttpServer. Here you see how the server is created using a factory method (HttpServer.create) that takes an InetSocketAddress and some other argument I didn't drill down to just yet and gives you back an HttpServer instance ready to work. That instance does pretty much nothing so far other than a response 404 for everything you ask. To change that we create a new application context (very similar to the one found in a Servlet container) and register it under a specific path on that server. In the next line we tell the context that it is guarded by basic authentication - that's my favorite :) - and we're almost all set. The last thing is to (for whatever reason) assign an empty executor that in turn is supposed to have a side effect in the sense that a default executor will be assigned instead. That's weird...

The outcome

In 32 lines we've created a dynamic web application with authentication - ready to conquer the world! That's maybe a lot more than Sinatra or Spark but still - it's something worth knowing about. If you'd like you can utilize it directly from Java and it is still not a lot more code than what's seen here!

Have fun!

How I wrote my own version control system

2011-09-13T20:42:00.005+02:00

This is what happens when people have too much spare time traveling from home to work and back 6 hours a day... They create useless software that allows them to pass the time.

The idea

The idea was to create something that'll be astonishing, maybe not new but great in functionality and to do it in Groovy. I thought what the hell - why not write your own version control system :) Let's call it pico

The credits

The piece is 100% cloned in idea (and most of the solution as well) from The All Mighty And Only True Version control system - meaning Git.

What's it doing?

For now it is really simple: it can commit with a message (the user interface is sooooo cruel - need to work on it a bit), dump a sophisticated log and checkout the latest version. It's faaaaaaar from being complete and most probably it'll never get where Git is today but hey - that's what passing time means :D

But....

It does what it does and is written in Groovy! Granted that I can do better but trust me coming up with a working solution like that in less than 3 hours on a train was my point here - not the beautiful code :) The latter one is due some time in the future to fill the time...

The code

You can find the code as well as a batch file (yes, I am a Windows freak) here.

Have fun!

Grails, multi-tenant plugin and a bag of small issues

2011-09-08T09:30:00.001+02:00

If you'll ever need a multi-tenant solution and you're lucky enough to use Grails going with the multi-tenant-core plugin is definitely the way to go. It's pretty easy to use in the "multiTenant" mode but some strange issues come up when trying yo use the "singleTenant" mode. In this installment I'm going to walk you through a solution that'll allow you to understand how things are and what you should avoid.

The debug solution

To make our "explorer" live easier we're going to provide a custom tenant resolver so that we'll be able to specify a query string like ?tid=1 to select the tenant with id = 1.

package org.example

import javax.servlet.http.HttpServletRequest
import grails.plugin.multitenant.core.TenantResolver

class TestTenantResolver implements TenantResolver {
    Integer getTenantFromRequest(HttpServletRequest request) {
        def tid = request.queryString =~ /tid=(\d+)/
        return tid ? Integer.parseInt(tid[0][1]) : 0
    }
}

To use it just register a bean with name tenantResolver in resources.groovy like

tenantResolver(org.example.TestTenantResolver)

this and you're all set.

The data sources

Although the documentation will tell you that in the tenant configuration DSL you can specify JDBC URLs directly it is unfortunately not true. You need your JDBC datasources registered in JNDI for the multi-tenant plugin to pick them up. It's done in Config.groovy like this:

grails.naming.entries = [
    "jdbc/foo": [
        type: "javax.sql.DataSource", 
        driverClassName: "org.hsqldb.jdbcDriver",
        url: "jdbc:hsqldb:file:target/db-dev-tid-1;shutdown=true",
        username: "sa",
        password: "",
        maxActive: "8",
        maxIdle: "4"
    ],
    "jdbc/bar": [
        type: "javax.sql.DataSource", 
        driverClassName: "org.hsqldb.jdbcDriver",
        url: "jdbc:hsqldb:file:target/db-dev-tid-2;shutdown=true",
        username: "sa",
        password: "",
        maxActive: "8",
        maxIdle: "4"
    ]
]

And then you need to tell the plugin about your datasources:

tenant {
    mode = "singleTenant"
    dataSourceTenantMap {
        t1 = "java:comp/env/jdbc/foo" 
        t2 = "java:comp/env/jdbc/bar" 
    }
}

Catch No. 0 (zero)

Be warned that the tenant 0 (zero) has a special meaning that's not mentioned anywhere in the docs. It means "use the connection returned originally by TransactionAwareDataSourceProxy". This means that tenant with id 0 is off limits for you. Don't ever use it!!!

Summary

Other than the 2 small issues the plugin is really fun to work with. Good job guys!

New guy in town: knockout.js

2011-08-31T23:07:00.003+02:00

Today we're going to take client-side JavaScript to a whole new level with the MVVM pattern using knockout.js.

The "why"

Imagine you're writing an application using, let's say, WPF or Silverlight. What's nice is that you have a clean separation of concerns between what's being displayed in terms of the layout (which is in fact the first V in MVVM) and some object backing up that view (which is the VM in MVVM in this case). This allows the application to be extensible and well structured.
Granted you can make a mess everywhere and MVVM architecture is no exception. You still have to use your brain while coding :)
Up until recently there has been no framework giving you the opportunity to have that kind of clear separation in JavaScript. Granted there have been tools like ExtJS and jQuery to help you out with modern UI elements like calendars and grids as well as low-level operations on DOM and events but there has been nothing so far that'd help you out write in a clear MVVM declarative style. Now there is!

The "what"

That's quite simple: the mini framework is called knockout.js and implements the MVVM pattern in pure JavaScript and DOM (not necessarily HTML but that'll work for DOM creation as well).

The "how"

Well, here's the good part, which will be extremely easy:


<html>

<head>
<title>Example</title>
<script 
type="text/javascript" 
src="https://github.com/downloads/SteveSanderson/knockout/knockout-1.2.1.js">
</script>
<script 
type="text/javascript" 
src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js">
</script>
<script type="text/javascript">
$(document).ready(function() {
var viewModel = {
data: ko.observable("Hello, world!")
};

ko.applyBindings(viewModel);
});
</script>
</head>

<body>
<p>The current value of data is <span data-bind="text: data"></span></p>
<p><input type="text" data-bind="value: data"/></p>
</body>

</html>

See how there's no "Apply changes" button? This is because once you've entered the text into the input box it'll be automatically transferred to the viewModel object and since that's an observable it'll notify all subscribers about the fact that the value has changed and the text on the page gets updated automagically.

Going fancy

I'd like to see some fancy stuff in here like responding to button events and the like. Let's see how we can do that with KO:


<html>

<head>
<title>Example</title>
<script 
type="text/javascript" 
src="https://github.com/downloads/SteveSanderson/knockout/knockout-1.2.1.js">
</script>
<script 
type="text/javascript" 
src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js">
</script>
<script type="text/javascript">
$(document).ready(function() {
var viewModel = {
data: ko.observable("Hello, world!"),
show: function() {
alert("Current value is: " + viewModel.data());
}
};

ko.applyBindings(viewModel);
});
</script>
</head>

<body>
<p>The current value of data is <span data-bind="text: data"></span></p>
<p><input type="text" data-bind="value: data"/></p>
<p><button data-bind="click: show">Click me</button>
</body>

</html>

Again, the same page but with 2 additions:
1. A callback function called show as part of the viewModel
2. Declarative binding of the above function to a button using the last data-bind. Cute, isn't it?

I know that I'll put it to some good use in my next project. Just for the heck of it :) I like the idea that it is completely cross-platform and yet so incredibly easy to use!

JSF 2.0 - Is it really better?

2011-08-30T19:33:00.001+02:00

I know most of you will hate me for the post I'm writing but I have no choice. I really need to stigmatize the framework and make clear to anybody still using it that they have been lost in the woods. Literally...

Like you (as the reader of my blog) already know I hate JSF. I hate it so much that I've dedicated an entire blog and site to bitch about what a pain in the ass it is to use. Being the enlightened man I am from time to time I like to come back to stuff I hate to make sure they didn't do anything stupid like making the framework usable or so. This time was no different.

So I did it. I've installed NetBeans (I usually use the Far Manager's build-in editor but for this exercise I've decided to go crazy a bit and use the full-blown IDE supported by JSF's creators). I've followed the standard File -> New procedure, selected some JSF JPA CRUD example (because I couldn't find anything simple on the net) and started reviewing the app.

First thing that hit me was the really cruel style of the web UI the application presents. In one word "HORRIBLE". Not that it ain't usable - God forbid - but plain "usable" these days just will not cut it. So the GUI is butt ugly - how about the code?

Now that's the place I like JSF most for: the code was just exemplary bloated :D Let me give you some bottom line figures:

1. It's a pure CRUD application. Absolutely nothing fancy. No Ajax or the like cool features whatsoever.
2. It's an application that manages 7 entities (customer, discount code, manufacturer, micro market, product code, product and purchase order).
3. Everything that was generated is 706068 bytes in 72 files!!!

Now compare this to, let's say, Rails, Grails or Sinatra + Data Mapper is about 8 times bigger. I know it is an enterprise sort of thing and that it's not meant for mare mortals. It's the enterprise kind of solution that you'd use at work and not for fun.

Anyways, JSF still sucks, big time. Lot's of hand-written XML, tons of Java code to implement pretty much every aspect of the application (with parts of it having cyclomatic code complexity at the level of 20+). That's just a no-go for new projects that need to deliver solutions on time, on budget and in scope.

One last thing: For crying out loud the web is stateless! Why would anyone force a solution that inherently introduces state which in turn means no scaling possibilities and stupid ideas like "page life cycle" and "control binding"? Why would you ever want to fear JavaScript programming when there are layers of abstraction like Ext JS or jQuery?

I wonder if the MyFaces implementation still differs from the reference one in the way that component libraries will work on one and not the other. I didn't check it out myself - I'm not that brave...

The conclusion is that if you're still doing JSF these days just drop it. Now. It's horrible!

The Process

2011-08-25T23:30:00.001+02:00

I've been working this past few years for a company that utilized Rational tools for issue tracking and source code versioning. Long story short it was a nightmare to use ClearCase and ClearQuest with its stone age web interface was more than annoying but it was to some extent usable.

Nowadays the same workflow is doable using opensource tools like Git and GitHub for anyone. Here's how the process works:

- request a change to the system
- do the changes
- integrate them to the so called main line

Using GitHub it's dead simple:

- file an issue
- clone the repository, do some changes, check them in
- put out a pull request for the maintainer to integrate your changes

All that takes some 2-3 minutes if you know what you're doing and if the test suite you're dealing with is fast enough. Piece of cake.

Now if you'd like know how it looks like using Rational tools (and I mean the good stuff, fully integrated) take a look at the following screen cast.

I hope ClearCase will soon be seen for what it really is: a performance and evolution blocker.

Padcom's blog

The quality of software - part four

What is software quality

I can fix any bug in the projects I wrote - and do it FAST!

Uncle Bob says: Why did you write it?!

Summary

Grails and Ratpack

Intermission

You don't get to drive - part three

The alchemy of software development - part two

Modern state of software development - part one

jQuery and posing JSON data to the server

Grails, Heroku and spring-security-core

Grails routing plugin family updated

Grails 2.0 - the power is back

Hot reloading.

New scaffolding templates

Resources and other capabilities

Plugins

Summary

Why using a plain-text editor is a good thing

Hazelcast and Grails

Creating standalone applications with Java and Maven

The challenge

The "proper" way

Doing Spring in standalone Java application

Eclipse hint: Aptana Studio

Gitorious - a working guide to install

Using DWR with JBoss and EJBs

The why

The how

web.xml

Service interface and ServiceBean implementation

dwr.xml

The creator

The create

The index.html

Bottom line

What the hell is wrong with collections API in Java?!

The good part

The story so far...

Groovy the savier

But there we are... in Java

CORS filter for Java applications

The what

The how

Using JRebel from pure Maven in a web application

Installing Maven and JRebel

The pom.xml

Running Maven with JRebel

Doing reloading

Java 6 has a web server inside!

The what

The how

The ExampleHandler class

The ExampleAuthenticator class

The meat

The outcome

How I wrote my own version control system

The idea

The credits

What's it doing?

But....

The code

Grails, multi-tenant plugin and a bag of small issues

The debug solution

The data sources

Catch No. 0 (zero)

Summary

New guy in town: knockout.js

The "why"

The "what"

The "how"

Going fancy

JSF 2.0 - Is it really better?

The Process

`Service` interface and `ServiceBean` implementation

`dwr.xml`

The `creator`

The `create`

The `index.html`

The `pom.xml`

The `ExampleHandler` class

The `ExampleAuthenticator` class