Now, I’ve never been much satisfied by on-rails platforms, seriously, it’s not my world. Even more, being more a software engineer than a web engineer, my interests in that kind of products have always been kinda mild.
When I first met Grails (10 months ago) I was skeptical -as always- but it took me less than 1 hour to realize what was going on in my computer, and I was shocked. Everything was over the top. The persistence layer is SUPERB, the separation of the controllers and the UI is perfect as much as the languages needed to develop them (and their organization inside Grails). The time needed to understand all the basics? 1 hour.
Still, I HAD to start a test project and see how much my first feeling was correct and be certain this marvel of technology was ready to suffer the pains of a real full blown production environment. Folks, it really met my expectations. This thing… is amazing.

Of course it has some downsides, in 10 months I had my oh-oh here and there.
First of all, in production you might not need a super powerful machine to run it (unless your traffic needs it), but in development… well get ready to heat your processors and disk.
Secondly (by the time I’m talking, I’ve haven’t seen Grails 2 yet), sometimes the development environment simply stops working. “This is broken, this does not compile” you know, the kind of mysteries that makes you bang on the keyboard like a monkey. You just need to get in touch with Grails common oopses to fix that in an instant, but the very first times, it’s going to be a little troublesome. Note: this kind of issue are likely related to the Eclipse plugin, rather than Grails itself.

I’m no fanboy. I hate fanboys. But this framework makes me very close to one…

GO GRAILS! 

http://aragozin.blogspot.com/2011/12/garbage-collection-in-hotspot-jvm.html

I’ve been using a Mac for 4 years now and I’m pretty pleased by the overall performance. The machines are pretty good, the OS mixes the best of the two worlds (*nix and Windows) with a nice added flavor. But what I discover these days is I’m not a Mac user. I will never be, nor I want to.
The first signs that something wrong was happening showed up when the IPhone was released. It was nice, futuristic, Apple scented. And with a horrible Bluetooth layer that was making it impossible to have it talking to other devices but IPhones and Mac.
“WTF” I said “… did they meet any technical limitations? Bluetooth generally sucks, but everybody managed to have it talking with almost everything”.
“Nah” a Mac user friend of mine said “It’s their decision”.
“Why’s that?” I asked, but the answer bothered me. “Well, they’re making their own business like that. If you want the device, you’ll eventually get into Apple’s world, totally”. Questioned about the fact this is ‘right or wrong’, that friend of mine said it’s “absolutely right”.
At first I didn’t actually realized what it was going on.

Last  year, I upgraded my camera to a professional one. The camera manufacturer was making two professional models, I picked the smaller one. Ah, I was using Aperture by the way (at that time 192€).
When I got back home with my first shoots I was all excited, but when I tried to import the pictures using Aperture I found out that Aperture wasn’t supporting the camera’s RAW format. “How strange” I thought, considering the Mac was easily able to read them. But not Aperture.
After a small search, I discovered that Aperture was actually able to import the bigger camera version RAWs, but not the smaller one.
“WTF, it’s the same format!” I thought and after a small search, I discovered that it was exactly the same format with a header field value that stated one model or the other.
I thought of a mistake and searched other people having the same issue. I found that many reported the same problem.
Some time later, Apple announced that there was a way to solve the problem: a paid upgrade to the new version of the software.
Mac users, again, stated this is absolutely alright, because “they have to make money somehow”.

I did not upgrade and used IPhoto for the first import operation (irony…).

Now, today I’m working on some important pictures challenging at least 5 other depressing bugs (1 blocker) that Apple states to be fixed in the new fantastic version of Aperture. And again, Mac users say this is “normal”.

What puzzles me is not only how the stand there stating “you buy the toy and then shut the fuck up” but how they actually managed to brainwash any goddamned Mac user on the planet. How come people working in the IT field I would generally consider intelligent and competent in this discipline, would end up saying “if you don’t pay, you don’t get the bugfixes, it’s normal”.

iMindControl.

Let me finish with the famous Apple 80s TV ad, the one against the IBM “evil empire”.

Who’s  the evil empire now?

Since this is my major trend these days, here’s another language for the JVM! Err… nope, not exactly. The language subject to our attention is a clean, fast language that then gets converted to Java language!

Endorsed by the Eclipse Foundation  -people we like and respect-, XTEND includes all the must-have functionalities these new languages must have.
No intention to be mean… but the syntax looks quite like Groovy, but hey… I always agreed with the thesis that every good idea should be copied to extend the benefits of a great improvement, and I’m not going to regret it now!

Sure thing the Eclipse support is gorgeous.

Give it a look, it’s pretty neat!

http://www.eclipse.org/Xtext/xtend/

Sure it’s changing it’s target, and it’s doing that naturally. In the early ’00s there were Java desktop application popping up anywhere. It was slow, not responsive at all and ugly. Things changed during the years, SWT became a super glam framework in Java desktop programming and I used it A LOT with good results (but can’t say pleasure). I agree there are far better languages and frameworks for the client side, but no matter what Apple says, Java is here and will stay.

But the truth is the best Java ecosystem is server side. J2EE applications rock the enterprise, servlet containers rock web applications.

Still, Java is getting old. Being old means being wise, having a huge background and being able to face almost any situation. It’s not the framework. It’s the language. And languages are subject to fashion, changing needs, will to improve.
Especially with this recent big interest in functional languages an mixed “compiled+interpreted” languages, Java is helplessly behind.
Reinventing a language (some people do…)  must be a beautiful experience. I never tried that and probably never will, but it must shake your world. Still, as my friend and researcher Francesco Zanitti told me yesterday (he’s working on much more advanced stuff compared to my today’s topic), theory and real world are so distant in computer languages some can get demotivated.

Java rocks, but is in need of a grandchild. A successor. A language that can take the hierarchy of Java and bring what’s been done so far to another level, adding new possibilities rather than limiting what’s available now to get to a new frontier. Some may say this limits the possibilities to improve, to invent, but the fact is this is not a contextual language, nor a scripting engine. I’m talking about a commercial language that has to be able to add spice to something that already works well. That can handle complexities that can scare the crap out of you. It doesn’t necessarily have to be “born from Java”, it can also come from elsewhere, but the fact stays: to obtain adoption, you have to pull current knowledge and wisdom out of Java.

If I had solutions to this dilemma, I wouldn’t be here writing. Still I have some major suggestions for you to extend your interests on what’s out there:

Scala is a very intriguing, elegant programming language. It integrates both object oriented and functional programming and can interact with Java pretty well, resulting a flavour that is, in my opinion, unique. The project is mature and the success stories are not few: one for all Twitter.

my pick:
Groovy  shares many things with Scala, also the syntax has a lot in common. Object oriented and functional programming work as one and the interaction with Java is absolutely surprising (no extra work at all). The learning curve is ridiculous because Groovy basically accepts all Java syntax and lets you learn what else it can offer. It’s not too elegant, nor too fast,  but incarnates beautifully what I meant in this article. The project is not fully mature in my opinion, but is endorsed by SpringSource and used as main language in the Grails web framework (that has many success stories).

I’m certainly missing some great tools. These are just two good languages I had the luck to work with directly and had fun with. I’ll be writing more about Groovy soon, but in the meantime, take your time to try them yourself, it’s worth it.

So I found out this library, named Scribe written by the brilliant software engineer Pablo Fernandez  that definitely helped a lot.
I copied and run his server side authentication example and worked like charm.

I’m taking his example for Twitter right from here site here (hope you don’t mind Pablo) https://github.com/fernandezpablo85/scribe-java/wiki/getting-started :

OAuthService service = new ServiceBuilder()
                           .provider(TwitterApi.class)
                           .apiKey("your_api_key")
                           .apiSecret("your_api_secret")
                           .build();
Token requestToken = service.getRequestToken();
String authUrl = service.getAuthorizationUrl(requestToken); Verifier v = new Verifier("verifier you got from the user");
Token accessToken = service.getAccessToken(requestToken, verifier); // the requestToken you had from step 2
OAuthRequest request = new OAuthRequest(Verb.GET, "http://api.twitter.com/1/account/verify_credentials.xml");
service.signRequest(accessToken, request); // the access token from step 4
Response response = request.send();
System.out.println(response.getBody());

And guess what, it worked like charm with LinkedIn also (just changing a few details you can find by yourself).

This is all beautiful… a pity what I had to implement was a client side authentication. The user authenticates on a LinkedIn popup, generates a cookie with an auth token in it that is then sent to our server that must use it run an exchange with the LinkedIn server to obtain a real access token… This is a very powerful authentication process, but implementing it is, again, a work of patience.

And again, reading through LinkedIn developers forums, Scribe shows up again, used like this:

OAuthRequest req = new OAuthRequest(Verb.POST, "https://api.linkedin.com/uas/oauth/accessToken");
req.addBodyParameter("xoauth_oauth2_access_token", jsnpToken);
Token token = new Token("","");
service.signRequest(token, req);
Response resp = req.send();
String body = resp.getBody();

where “jsnpToken” is the auth token passed through the cookie and “body” contains a string describing the real access token you’ll use to sign further requests.

Wasn’t that easy?

Thanks Pablo!

The circles are more than another paradigm to express Facebook friendships.
Of course they’re different because you can belong to more circles, creating feed groups. For instance, I have a “metalheads” circle where I put my friends who enjoy heavy metal and post videos and music streams just for them, without spamming around. So circles actually are circles of interest, increasing the quality of your feed. Some of them also belong to the “technocrats” circle where I post technology news. In an ideal world where everybody uses it this way, your feed would be always pertinent to your interests.

But it’s not “friendship”. Or is it?
Ironically, this paradigm expresses the concept of friendship much better than FB friendship.
Think of it: friends are, first of all, people you share interests with. Moreover, you can consider someone “friend” without the counterpart to do the same. You might want to share something with him/her, but he/she might not be interested in doing the same and at the same time, find your entries interesting and pertinent.
In FB Friendship, the relationship must be mutual. But in Google+ it doesn’t happen.

So belonging to a circle must not be “approved” by the counterpart, but ironically, the whole system allows a much greater privacy. In Facebook all friends have almost equal right to read your information (with some exceptions you can set in your privacy settings), on the contrary on Google+, you have a  smooth, powerful discriminant that is the reason you’re related to that person and this is a killer feature for other platforms.

What I hope is people will be able to quickly understand the best way to use it, increasing the quality of everyone’s experience in Google+.

Though I’m quite sure most people joined Google+ because there’s no FarmVille…

I was captured in optimization facts lately and I ended up chasing the true advantages in using final stuff correctly (in Java of course). But much before I could state I have an opinion, I found myself trapped in a strange JVM… mystery.
What I wanted to understand is if the JVM can listen to our ‘hints’ to take the final stuff  and use it inline.
This topic has been subject of many talks, mostly because it’s hard for the JVM to determine whether a field won’t change at runtime or not. This could be obvious at first sight: final fields won’t change. But when reflections come into play, well… you’ll never know.
So can reflections change a final field? This is the question. And the answer is: WHO KNOWS? If you look at this document, you’ll notice it’s a long and painful story.

Since there’s nothing better than trying stuff yourself, I tried to discover it by doing a simple test program.

public class Malicious {
	public final int testField = 5;

	public static void main(String[] args) throws Exception{
		Malicious m = new Malicious();
		Field f = m.getClass().getField("testField");
		f.setAccessible(true);
		f.setInt(m, 7);
		System.out.println("f: "+f.getInt(m));
		System.out.println("m.testField: "+m.testField);
	}
}

Before I tell you the results, let me first say that I used:

- MacOSX 10.6.4
- 1.6.0_22
So you won’t get upset if you get different results on different environments.

RESULTS:
f: 7
m.testField: 5

Honestly, this makes no sense. No security exceptions, nothing, just different values. And of course, if I remove the final keyword, what I get is:
f: 7
m.testField: 7

I’m honestly happy to state that a final field cannot be modified via reflections. I’m less happy to say the behavior is not supported by a homogeneous communication because I only got a security exception when I tried to remove the setAccessible line.

I’m back writing on this abandoned blog telling you a sad story about unstable technologies and epic fails.

SVNKit is a marvelous library that lets you write programs which interact with Subversion repositories and working copies. If you’re Eclipse users you’re probably using it as connector in Subversive.

It’s a wonderful tool, I love it but the disaster I’m going to tell you about… well, will clearly show you that not all the glitter is gold.

Scenario:

- A WebDAV server
- Various OSX clients with Eclipse (and SVNKit of course) on board which mount a personal remote FS

The users easily connects to the webdav server, connects Eclipse workspace to the remote FS, work work work, and then commit. Work work work, and then commit. Work work work and then commit.

The big FAIL in this story is as follow:
The commit operation via SVNKit brought the  mounted unit in a strange state where whenever you save, the saved data never reach the WebDAV server. Everything looks good on the client, but the server does not get a single update. The only one understanding there’s something wrong is SVN that, if asked, tells you no resources have been modified since last commit, but of course you don’t keep checking over and over do you?
If you disconnect the unit at this point, all changes since last commit will be lost!

I’ve checked and double checked, ANY program based on SVNKit melts your mounted unit.

Using native Subversion solves the problem entirely, but how many tears did I cry for this? LOTS.

Hope this helps!

Ah, almost forgot: useless to say that on Linux and Windows worked like charm!

public <E>E toObject(HttpServletRequest request, Class<E> type)
                 throws InstantiationException, IllegalAccessException {
  E inst = type.newInstance();
  Method[] mets = inst.getClass().getDeclaredMethods();
  for(Method m : mets){
    if(m.getName().startsWith("set"))try{
       String varName = m.getName().
                           substring(m.getName().indexOf("set")+3);
       varName = Character.toLowerCase(varName.charAt(0))+
                                         varName.substring(1);
       String val = request.getParameter(varName);
       if(m.getParameterTypes()[0]==Integer.class)
           m.invoke(inst, Integer.valueOf(val));
       if(m.getParameterTypes()[0]==Boolean.class)
           m.invoke(inst, Boolean.valueOf(val));
       if(m.getParameterTypes()[0]==String.class)
           m.invoke(inst, val);
      }catch(Exception e){e.printStackTrace();continue;}
     }
   return inst;
}