Flex on Grails: Take 2, Part 2

This is a follow-up post to Flex on Grails, Take 2.

Task creation

Now that we have a basic working application, let’s improve it by adding some security in there. If your Grails application is still running, you can leave it that way as you won’t need to restart your backend every time you modify it. That’s the whole beauty and productivity of Grails and this plugin.

Flex on Grails: Take 2

A little bit of history

When I first discovered Flex, one of my first obsessions was how to make it work with a Java backend. I’m a java developer at heart and my Java backend stack of choice back then was Spring/Hibernate-based. That’s why I published a series of full-stack articles that became quite popular. But another obsession of mine has always been productivity so when I discovered Grails, it became my new preferred environment and I started looking for ways to plug a Flex frontend into a Grails backend. All of this work culminated in the release of my Grails BlazeDS plugin which worked great but had a few limitations (only Java DTO’s, run-war instead of run-app, etc.). I mean, it worked great… until it didn’t. For some obscure reason, my plugin didn’t work at all with Grails 1.3.x. I fought with this for months, but there were just too many technologies involved (Groovy, Grails, BlazeDS, Spring-Flex, Spring, etc.) and my knowledge of some of those technologies was too shallow to really understand everything happening under the hood. That’s why I called upon SpringSource and/or Adobe to help me or provide the community with a decent Flex support for Grails. And guess what! They listened. A couple of months ago, I got in touch with Burt Beckwith, from SpringSource, who intended to work on that. So he asked me for feedback and really that’s all I did: I explained to him some of the issues I had with the plugin, the typical environment that we Flex developers work with, etc. And today… TADAAAA! The new Flex support plugins are here.

Versioning is Just Too Complex

I’m currently trying to unlearn 10 years of CVCS and Subversion certainties to learn DVCS and Git. And although a lot of people see those as a huge leap forward, I can’t help thinking it’s still way too hard. Versioning is such a basic need, it shouldn’t require that much knowledge. Right now, whether it’s Subversion or Git (or Mercurial, or whatever), the problem is always the same for me: it’s just too low-level. Those systems are designed as if I needed to be a mechanic to drive my car. I don’t care about injectors, gearbox and all that stuff. All I want is to go faster or slower, turn left or right, and that’s about it. Now sure if I’m a mechanic, I can make my car perform much better, but if I just need to get from point A to point B, do you really think I will learn mechanics? Most people won’t. They will just walk there, or ride a bike. And that’s exactly what’s happening in too many companies: “manual versioning”, version numbers in file names, shared drives, even $harepoints, are just poor solutions to a real problem. We need versioning, but existing solutions have an unacceptable learning curve. They’re not smart enough, and they require us to be smart, even though that’s not our main purpose.

Even as a developer, sure I can understand such concepts, but I don’t want to learn what merge, pull, push, commit, branch or update mean. I want to start new projects, participate in existing projects, fix bugs, implement features, refactor my code. Whatever underlying system my company or team is using, whatever technologies I’m working with, my own workflow should not be influenced so much by the tools I use to keep track of my work and collaborate with my team. It should be transparent.

My point is: Git is a leap forward, but it’s a small one, and we need a giant one. We need a versioning system that implements workflows at a higher level, that abstracts away all those silly commands with similar names but different meanings. We need an abstraction layer that can work on top of existing lower-level tools like git, subversion and others, and that can be integrated seamlessly in development environments like IntelliJ Idea or Eclipse (sigh). Sure we will probably lose some power in the process, but we can leave it as an option.

In fact, we need to do with versioning what Maven has done to build lifecycle. Convention over configuration. What are the most common tasks we do on a daily basis:

  • start a new project
  • enter an existing project
  • start fixing a bug
  • start implementing a new feature
  • start refactoring some code
  • switch to another bugfix/feature/refactoring
  • complete a bugfix/feature/refactoring
  • share a bugfix/feature/refactoring with my team or with the world
  • what else?

And then let’s try to map those high-level tasks with lower-level command sequences. And let’s do it in such a way that I can easily change the underlying implementation, or reconfigure certain aspects of it. And why not add the possibility to define your own workflows for other things than traditional dev. In fact, to make things clearer, let’s just call git, subversion and other existing tools “versioning tools”, and let’s design a “collaboration framework”. Exactly like Maven is not a “build tool”, it’s a “build lifecycle framework”.

I’m just ranting out loud here, but what do you think?

How To Introduce Yourself… I Mean Practically

For years, I’ve been using a very simple but very effective technique to introduce myself in job interviews, and I’ve always got some excellent feedback about it. I’m not talking about the content here, but the format. It can always be a bit tricky to introduce yourself without diving too much into irrelevant details, or losing yourself along the way, or boring the interviewer to death. To avoid all that, I’ve learnt this technique at Axen, but since Axen doesn’t exist anymore per se, I might as well share it with you guys, because it’s always a shame to miss a good recruitment because the candidate wasn’t clear enough during his/her interview. So here you go…

WWDC 2010 Review

Still one session to attend about closures in Objective-C, and I’ll call it a week. A little bit of shopping this afternoon in order to spend my last dollars and I’ll be ready for take-off tomorrow afternoon. So it’s time for a little summary of this week.

Overall, it was my first WWDC and I’m very glad I did it, but I probably won’t do it again. San Francisco is definitely a very nice city, and seeing Steve in live, even from very far away in the audience was an interesting experience. I also learnt a few very interesting things and psychologically a conference like this always has the same side-effect on me: first I’m depressed and humbled by all the ambient intelligence, but then it motivates me a lot to move forward, learn and do something about it. So it has definitely been a very positive experience.

Now was it worth the budget I put in it?

Grails/BlazeDS/Flex/iPhone Full Stack Part 2/3

In the previous episode, we built a simple Grails backend for the todolist application. In this installment, we will create a simple Flex 4 front-end for this backend.

The following assumes that you have already installed Flash Builder 4 (formerly known as Flex Builder), either in standalone mode or as an Eclipse plug-in.

Grails/BlazeDS/Flex/iPhone Full Stack Part1/3

A couple of years ago, I published an article on this blog entitled “Flex, Spring and BlazeDS: the full stack!” and this article became very popular. Actually it broke my daily visits record. Today I’m gonna try to break this record again.

In the last couple of years, I’ve worked a lot with Flex and Spring. But in my eternal quest for productivity and user experience, I discovered Grails. Based on the same ideas as Ruby on Rails or Django, it combines a dynamic language – Groovy – with the power of “convention over configuration” to make it possible to create web applications in no time, thus allowing you to spend more time on your user experience.

Of course it’s not the only thing that has changed since then. Flex 4 is now finally out in the open. BlazeDS 4 too. And Flash Builder is finally productive enough for me to use it… in combination with IntelliJ IDEA of course.

All those evolutions in my toolset needed to be integrated, so I ended up building a Grails plugin to do just that: Grails BlazeDS plugin. And since this plugin could not be officially released without a proper demonstration, here we are.

I prepared this tutorial for a BeJUG talk I gave last week. So I want to thank Stephan Janssen and the BeJUG for inviting me… and for staying with me without throwing vegetables at me, given all the failures I had during the live coding session. For those of you who were there: I clearly identified PermGen space as the guilty part responsible for all these blank screens. In fact, since Grails migrated from Jetty to Tomcat as their runtime server, default java memory settings are not enough anymore, so I always configure my projects for that, but of course, in live, I forgot…

Anyway. I’m going to publish this tutorial in three episodes, each one of them being accompanied by its very own screencast on Vimeo (damn Youtube and their 10-minute limit!). But I’ll also publish the tutorial transcript right here for those who want to go faster.

Important note: this tutorial covers the following set of technologies in the specified versions:

In particular, it seems that Grails 1.3 that was just released a couple of days ago breaks Grails BlazeDS plugin. I’ll update both my plugin and this tutorial when I can make them all work together again.

Grails BlazeDS 4 Integration Plugin

One of the main goals I’ve been pursuing for a few months is the integration of Grails with Flex 4. I need to rework ConferenceGuide‘s administration backend to make it more ergonomic so that we can cover more events, and ever since I discovered Flex 4 niceties, I couldn’t think of doing that with anything else. The problem is that none of the existing plugins suited my needs. All of them cover Flex 3 only, some of them introduce a lot of complexity for CRUD generation, some of them use GraniteDS instead of BlazeDS, and the simplest plugin, grails-flex has never gone further than the experimental stage. I did a lot of experiments, talked a lot about it on Grails mailing lists, until Tomas Lin kindly explained to me that maybe I was approaching it the wrong way. I wanted a plugin that would set up a complete environment for Flex developement right in the middle of my Grails application. And I wanted that because I wanted to avoid using Flash Builder (you know… Eclipse… ierk!), mainly because the only advantage of Flex Builder 3 over IntelliJ Idea was the visual designer. But he was right, I was wrong. Flash Builder 4 DOES change everything. It does include a lot of very interesting features that greatly improve Flex development productivity, especially when it comes to integration with backend technologies. And for those features, I can only admit that IntelliJ is not up to par yet. I’m still gonna use it for the Grails part, but Flash Builder will be my environment of choice for Flex 4.

So, once I learnt more about Flex 4, BlazeDS 4 and Flash Builder 4 beta 2, it was time to reconsider my approach and develop a much simpler Grails plugin so that any Grails application could be used in combination with Flash Builder. I just released grails-blazeds plugin to do just that. Here is how it works:

  1. Install grails-blazeds plugin: “grails install-plugin blazeds”. This plugin copies a couple of configuration files into your application and imports all of the required libraries, including BlazeDS 4 and Spring-BlazeDS integration 1.5, both in nightly snapshot versions, since they have not been officially released yet
  2. Create a service to be exposed to your Flex application over AMF, or choose an existing one
  3. Add @RemotingDestination annotation to your service class, and @RemotingInclude annotation to all of the methods in this service that you wish to expose
  4. Edit web-app/WEB-INF/flex-servlet.xml (created when you installed the plugin): uncomment the context:component-scan element and set the base-package corresponding to your service class
  5. Make sure your exposed service methods don’t use Groovy classes, either as argument or return types. This is a known limitation I’m still working on, but if there are some Groovy classes here, Flash Builder doesn’t manage to generate ActionScript counterparts.
  6. Run your Grails application using “grails run-war” instead of “grails run-app”. Once again this is a known limitation: Flash Builder BlazeDS data connection plugin relies on a classical web app layout and doesn’t understand Grails dynamic layout (that is until someone manages to create a Grails data connection wizard for Flash Builder 4)
  7. In Flash Builder 4 beta 2, create a new Flex project with a J2EE server. Here are what your parameters shoud look like, “conferenceguide” being the name of my Grails application and “sarbogast” being my home directory:

  8. Click “Data” menu, then “Connect to BlazeDS…”
  9. In the “Authentication required” dialog box that appears, check “no password required” box, and click OK
  10. You should see your service appear, and you can select it and click Finish.
  11. Your service should appear in the Data/Services view. You can then compose your user interface and drag and drop your service methods to the relevant components to connect them with your Grails backend.
  12. Don’t forget to configure a channelset on your service:
    <adminservice:AdminService id="adminService" fault="Alert.show(event.fault.faultString + 'n' + event.fault.faultDetail)" showBusyCursor="true">
    	<adminservice:channelSet>
    		<s:ChannelSet>
    			<s:AMFChannel uri="http://localhost:8080/conferenceguide/messagebroker/amf"/>
    		</s:ChannelSet>
    	</adminservice:channelSet>
    </adminservice:AdminService>
    

And there you go. Special thanks to James Ward, whose screencasts really helped me get it right. Now the only thing that this plugin misses, beyond the 2 known limitations, is integration with Spring Security, but this is just a start.

Enjoy!

Here Comes Grails APNs Plugin

That’s it. I’ve released my first Grails plugin ever. Woooo! Champagne!

If you follow my Twitter feed, you’ve probably noticed that I’ve been playing a lot with Apple Push Notification service lately (APNs for friends). Indeed, ConferenceGuide still requires a data connection, which can be problematic on a lot of events because they’re usually abroad (and roaming fees are waaaaaay too expensive), and even when you do have a data connection, it’s usually pretty slow… at best. That’s probably why one of the most requested features for ConferenceGuide is Offline Mode.

But getting all the data directly from the server does have at least one advantage: you’re always up-to-date. And experience has shown that sh** happens: sometimes sessions are cancelled at the last minute, or a global sound mixer reboots out of nowhere, thus shifting all sessions by 15 minutes. Those of you who were at Devoxx last November know what I’m talking about. So I needed a way to combine the best of both worlds: being able to browse schedule and speaker information without a data connection, and still get updates whenever something changes and I can find a wifi hotspot or something.

The first part of the solution is the local database. The second part involves sending push notifications. The problem with the latter is that the API provided by Apple is pretty low-level and the documentation is rather scarce. And it’s understandable because they expose a service that should be usable by any server technology, whether it is Java, .Net, PHP, Rails, etc. Fortunately, Java has a huge community and a great Open Source spirit, so it wasn’t long before a few projects were created to build an abstraction layer on top of APNs API. The simplest and most documented one I found is java-apns by Mahmood Ali. But ConferenceGuide server is not plain Java. It’s Grails 1.1 (I haven’t taken the risk to migrate to 1.2 yet). So I wanted to ease the integration of java-apns into any Grails application. And voilà! Grails APNs Plugin.

Special thanks to Burt Beckwith for helping me get started, and Mahmood Ali for developing java-apns!

My Discoveries of the Year

logoEvery year, the main reason why I go to Devoxx is to discover new stuff. For me it’s all about technology watch. The internet and RSS feeds are my main tech watch instrument but there is one thing that is harder to get through RSS: feelings. Conferences like Devoxx are a unique opportunity, not only to see what’s happening but also to sense how the community is feeling about it, which is at least as important to anticipate on what’s going to be important.

Now you’ve certainly read here and there that there have been a lot of talks about Java EE6 and Closures in JDK 7. There sure were, and there was quite a lot of reactions to those. But frankly, I’m not interested in any of those. I’m not interested in Java EE6 because even though it finally leverages the concepts that have been pushed by the community for so long, the very fact that Sun has been so late in implementing them shows one thing to me: it’s not about them, it’s about us. Sun has been trying to partner with big companies around the JCP, to create a lot of business around those standards. And why were those standards so complex? Because there were so many companies involved in their elaboration? Or was there any interest from those companies to create technologies complicated enough to require a lot of consultants, and books, and trainings, and tools to make things easier? If the first option is true, then how did it happen that a gigantic community of individual software developers made it so that Spring, Hibernate and other Open Source technologies became de facto standards?

Which brings me to the second point I don’t really care about: closures in JDK 7. People have taken matters into their own hands. Other languages have appeared implementing some of the missing features of Java: Scala, Groovy, etc. Some other languages have been imported into the Java landscape, like Ruby and Python. I’ve been using Groovy myself for some time now, and I couldn’t be happier with it. Now Sun is coming after the war, but does it matter? What I see here is that it’s good to have a base language, a base platform. But as soon as you start extending it for purely mercantile reasons, or as soon as you start avoiding certain innovations because you’re afraid it might harm your business or the one of your partners, then things go messy. But once again, the good news is that software gives us power. We developers have the ability not only to decide which technology is better, but to build and promote our own technologies. And I think this is why our world is so dynamic and why things change so fast. What I see here is that languages matter less than our ability to create new ones, to solve more specific problems, to provide some more advanced features. And that strengthens my belief that Language-Oriented Programming is the next big step in the evolution of our technologies.

Now about the things I do care about. My discoveries.

kanbanMy first one is definitely Kanban. I’ve heard about it for quite some time. But I didn’t understand why people were already trying to push it forward, even though we are still fighting to push companies away from waterfall messes. It’s even more radical than Scrum and for that it’s very interesting because it gets closer to what software development really is. The key phrase that kept popping in my head during the 3-hour session about Kanban was “It’s going to take the time it’s going to take.” And that’s why it’s brilliant. Now that I understand Kanban a little better, I see Scrum as a compromise. We’ve taken some of the principles of Lean Manufacturing, we have dissolved them into trusted concepts like RUP’s iterative cycles. And for years, we have been trying to pour that cocktail into their mouth. And in doing that we forgot something important: if they don’t trust us, they will never drink the whole thing, all the more so as it looks weird with all those colors not really mixed together. The way I see it, Lean and Kanban are all about getting back to the basics, and relying on trust. We have to build trust first, we have to make them understand that at least some of us are not interested in building artificial business on top of poor practices. That at least some of us desperately want the software we build to have a real impact on their business. We have to show them our good will so that they let us do our job. And they have to understand that the more they trust us, the faster we will be, the more we will be able to solve other problems. Big software vendors and resource providers will not like that, because every new project comes with its own overhead, because their business thrives on poor practices, stupid methodologies and complex technologies. But once again, power is in our hands, it lies in collaboration, not in corporation.

My second discovery was Spring-Actionscript. Those guys really have a thing to do things in a clever way. Cairngorm, PureMVC, Swiz, they all impose some sort of a structure to your Flex applications, forcing you to surrender some great powers of Flex itself in the process. And here comes Spring-Actionscript, more like a toolbox than a real framework. It doesn’t impose anything. It just gives you all the tools you need, all the glue you miss, to make things fit together perfectly. Their asynchronous abstraction is just brilliant, their configuration options are complete, your code just looks better with it, simpler, more natural. I think that’s what I love most with Spring: not only does it create great technology, but it also instigates a whole pragmatic and elegant way of thinking into the minds of a whole generation of developers, thus encouraging the community to come up with their own technologies: Spring Actionscript used to be called the Prana Framework, developed independently by a Belgian guy who took inspiration in Spring for Java. That’s just awesome. I will definitely integrate Spring Actionscript in a couple of Spring/Flex projects. I think I will even update my todolist sample application with it. Stay tuned.

My third discovery is a couple of technologies to detect and prevent coding errors BEFORE they actually happen. I insist on “before” because of my previous post about TDD: unit tests are all about writing code to check that some other code you have already written (or not written yet) does its job. But to me, this is equivalent to the old prevention versus repression debate. TDD is just repression, and it’s tempting to go there only, because it’s always easier to catch the bad guys than trying to understand why they became bad in the first place. JSR-308 and its pluggable type checkers is all about strengthening the compiler so that it prevents more of the most frequent bugs like NullPointerExceptions. It allows us to make our code more expressive, to give the compiler more information about our intents so that we can prevent bugs from happening. Brilliant! Project Lombok also goes in that direction: it adds a couple of annotations and customizes the Java compiler in order to minimize the amount of boilerplate code we have to type. Once again, by doing so, it improves the expressiveness of the language, allowing us to say more things with less words, thus reducing the likeliness of ambiguities and errors. Awesome! Lombok and type checkers will definitely be part of a couple of projects too. The only thing that really made me uncomfortable with both of these presentations was this question: “Why the hell weren’t those techniques in Java 5 already?”

pomodoroMy fourth and last discovery was Pomodoro technique. Once again, heard of it before, but never dug into it. And then we had this guy with a strange Swedish accent in front of us, playing with dolls, showing us handwritten slides with simplistic drawings. And you could hear the disappointed reaction of a lot of people in the room: “sounds nice, but not applicable to me”. That was my first reaction too. Software development requires long slots of concentration because we need time to load the whole conceptual model of what we’re working on into our mind before being effective, and this implies some overhead. But then when someone asked this very question to the speaker, he answered something like “what if you are loading too much? what if limiting the amount of time you are going to spend on a given task forces you to load just the minimum you need to solve the matter at hand? what if it made you more productive?”. And it made me think: “hmmm… It’s worth a try.” So I will probably try that as well soon.

Overall, this edition of Devoxx was great! The first 2 days, I was somewhat afraid that it would be disappointing, because you could feel that everything was “cheaper”, that there were less sponsors, less schwag, less tempting hostesses. But then the most important part was preserved: amazing independent content and a great community spirit. Finally there was an interesting special guest this year: Twitter. Twitter was everywhere. People were tweeting live from the sessions, there was a projection board with all devoxx-related tweets in the hallway. I and a bunch of my colleagues were even using twitter to cover Devoxx live for our fellow Axenian java developers on our intranet. Twitter was really everywhere this year.

So thanks a lot to Axen for allowing me to go there. Thanks to Stephan and the BeJUG for putting it all together. Thanks to all the great speakers and to my colleagues. This was really a great edition and I can’t wait for the next one.

PS: All the talks will be available in the weeks to com on Parleys.com. So stay tuned.