what do I know

A couple months ago a few of us at work thought it would be worth looking into some of the newer programming languages and frameworks that have been receiving a lot of buzz. We were particularly interested in some of the productivity boosts that have been preached as a result of using these solutions. We decided to focus on the creation of a proof-of-concept (PoC) for one of our major web sites (sort of a stripped down CMS solution). The PoC consisted of two implementations, one using Groovy and Grails, and one using Ruby on Rails. On the Ruby side of things, we decided to look into JRuby, rather than the MRI or Rubinus implementations, since the majority of our development efforts rely on the JVM. Based on the success of this process, we are even open to considering these technologies as a possible replacement for ColdFusion and its assortment of frameworks that we currently use in our web tier.

I decided to move forward with Groovy and Grails in the first implementation. Its syntax seemed to be the most like Java which is what I am most comfortable with. I spent about 4 weeks learning the basics needed for Groovy and the Grails framework. From the little I’ve used it, I really like Groovy as a language. Learning Groovy was a cinch. The availability of closures, the use of builders to simplify configuration, and the emulation of formal properties using Groovy Beans are all great features. After seeing the amount of work being put into Groovy Swing integration, I can’t think why anyone would want to write a Swing UI in straight Java again; the syntax was just as simple as MXML without the markup. I am curious if any classpath conflicts would occur between dependencies in Groovy and our own projects, but I didn’t look into this any.

As far as Grails goes, I am really impressed at the work put into combining the technology stack on which the framework is based. The biggest and most notable feature I like is its tight integration with GORM. The use of GORM as the relational mapper truly makes working with the database effortless. Integration with legacy databases is fairly simple if you want to re-use your Hibernate mapping files, or if you want to do the configuration yourself in your domain classes. Because of GORM, you can approach pretty much any web application focusing solely on your object model; our shop follows this practice already as do most Java shops, so this is a big plus. On the templating side of things, I am pleased to see the work put into GSP. One of the main reasons we went with ColdFusion was because of the simplicity it provided over JSP, so GSP is a welcome attempt at change. Another feature I really like about Grails is the ability to create service classes to hook into, and expose, JEE endpoints with the utmost of ease. I didn’t get a chance to play with these, but from what I’ve seen in the plug-in section, it looks like working with JMS, SOAP, JTA, and a few other standards is ridiculously simple. Yet another feature I really enjoyed was the integration with Spring Web Flow. The scoping in Grails seems so natural; flows are very simple to construct and alleviate a lot of the hacking most developers have to put up with in the session scope. Finally, bundling an application into a WAR is provided out of the box so creating a Grails app and dropping it on your favorite JEE server is fairly effortless. From the little I got to work with the Grails framework, you can tell the team’s focus is clearly to improve Java in the web tier and they are on the right track. I know offering Spring integration is definitely a big draw for me since we use it so heavily in most of our initiatives.

Keeping in mind I worked with Grails 1.0 RC1, I did run into some difficulties with the framework. The first and biggest frustration I encountered was when working with domain classes. When I changed a domain class, while the built-in Jetty server was running, the server would attempt to reload the Spring context but just hang. As a result, I would have to take about 30s or so ever time I changed a domain class to bounce the built-in Jetty server. I’m not sure if this has been fixed since I played with it, but this really deterred me from working with Grails. One thing that I got frustrated with was what seems like a limitation in GSP. I wanted to create a view to edit a domain class which had a one-to-many relationship with another class. A pre-selected multi-select list box seemed like the perfect HTML widget to use. I was unable to find a way to automatically have GSP generate this for me. I searched the user forums, but I only found a post that said an implementation wasn’t available at that time. I didn’t search for a JSP library that may help, but maybe this could have been a viable alternative short of writing the code to render the HTML myself.

So after the Groovy and Grails experience, I dove into JRuby and Rails. Being that I scare easily at the sight of anything new, a colleague recommended Dave Thomas’ Rails book to get started; I also had other colleagues as resources to help in times of need. Since I’ve become more familiar with the Ruby syntax I must say there are some language aspects I do like. Mixins available at the language level are a lot handier than I would have thought, especially in the context of Rails. Properties and module level methods were nice to work with as well. I can definitely see where the “enough rope to hang yourself” analogy comes from however; I encountered a lot of variations on how to syntactically accomplish the same task. From a configuration standpoint, I also had to do some work to setup my environment. In the end, I had to pull down JRuby (1.03) and install the rails (1.2.6), activerecord-jdbc-adapter, and warbler gems as well as update my JDBC driver. Since JRuby is just an implementation of the Ruby language, however, I was able to use any Ruby reference, tutorial, or example I could find and had no issues.

As far as Rails goes, I was pleasantly surprised by how easy it was to get started. One of the biggest things I like about the framework is the inclusion of data migrations. You are required to interact with the database at a certain granularity but those interactions are abstracted by writing Ruby code. I’m not necessarily a fan of this granularity, but from a maintenance perspective, this is one of the best solutions I’ve encountered for managing an application’s database. I am also glad to see to see the FormOptionsHelper class. When data binding isn’t sufficient, the FormOptionsHelper class provides a lot of convenience methods to help work with select boxes. Tasks such as pre-populating a multi-select list box were extremely simple using options_from_collection_for_select. Lastly, I really liked the work done to integrate the use of REST into the framework. Working with ActiveResource seems fairly straightforward and doesn’t require as much configuration as I expected; that being said I haven’t worked much with this feature yet.

Based on my limited experience with JRuby and Rails, there were a few things of which I am wary. I haven’t looked into this much, but having two language cores available in JRuby freaks me out a bit. Without guidance or standards, I can definitely see a junior developer using Java implementations when Ruby ones are available forming a strange mixture of code. Another point to watch is the current maturity of the tools to migrate a Rails application to the JEE platform. ActiveRecord JDBC and Warbler are still under active development (although close to 1.0 releases) and it did take quite a bit of investigation to get my PoC working with our existing environment. Additionally, I don’t like ERB as a templating language. This is a personal preference, but it reminds me of PHP which I dislike for its heavy use of scriptlets; I really prefer using tag-based markup for templating. Finally, and probably the biggest thing I don’t like, is Rails’ implementation of ActiveRecord. ActiveRecord is cripplingly associated with the relational model rather than your application’s object model. A simple relationship such as belongs_to doesn’t relate to a composition relationship between a parent and child object, it relates to which tables contains the foreign key in your relational model. I designed my PoC with an object model in mind and had quite a bit of frustration, semantically speaking, trying to migrate that model into the mold for ActiveRecord. I felt like my focus was on the database for the most part and that seemed contrary to the goal of the framework.

Ok, so enough for my probably useless feedback, let me tell you what we decided to do. My personal preference lies with Groovy and Grails. The side of me that needs a solution in the immediate however, led to my choose JRuby on Rails. Let me explain. When I worked with Groovy and Grails, my learning curve wasn’t with the language, but with the framework. I found myself having lots of difficulty accomplishing tasks that I had expected to be fairly effortless. I associate a lot of these difficulties with the current state of the Grails framework. This is not meant to come off with a negative connotation, but with the perspective that Grails is the “new kid on the block” and still needs polish. When I worked with JRuby on Rails, the learning curve was with the language, not the framework. Rails met my expectations regarding the work needed to accomplish my goals (short of the ActiveRecord hoopla). Rails has the current advantage over Grails since it’s had the opportunity to be exposed to its community for 2 major iterations now. Getting an environment configured and working is a one time cost; I don’t count this again JRuby on Rails although it was easier to manage with Groovy and Grails. Additionally, running on JRuby provides us with the minimal level of Java integration that we need to re-use our existing architecture. JRuby 1.1’s focus on performance and very eminent release as well as Eclipse tooling support via RADRails are also an added plus.

So that’s the verdict from my PoC, but its not the end of my opinion. Anyone who has read this far and thinks I’m full of shit, ignore this next paragraph unless you want to flame me. I ultimately believe that Groovy and Grails will win out for the majority of users utilizing Java in the web tier. All of the arguments I have made for JRuby on Rails are based around the availability and maturity of its resources. These are arenas in which Groovy and Grails have just recently entered into competition. Groovy is quickly becoming the alternative for those in the Java community who are looking for a syntax with which they are more comfortable that brings a dynamic flare. Although it may have helped, Grails doesn’t seem to have the influence yet to cause the recent spike in popularity that Groovy has received as compared to what Rails did for Ruby. I think Java interop will also become more of an issue as people begin using languages running on the JVM. From the little I’ve seen, I really like Groovy’s approach, it feels familiar. I also think developers, like myself, are looking for re-use from the Java libraries and frameworks that we’ve relied on and with which we have experience. Grails’ tight integration with Spring, Hibernate, and other JEE standards (defacto or not) will make these approaches even simpler. It seems like since Grails explicitly chose to support the enterprise and Rails is choosing to stay out of it. I think Grails over time will have more to offer than Rails for those looking for new solutions on web that are currently using Java. Please keep in mind I’m not saying that Groovy/Grails isn’t currently ready for the enterprise (despite the FUD going around). As I understand it, many have been successful by using these technologies; I’m just saying I’m going to wait a while and see how others have been successful and learn from their examples.

In the end, I definitely think these new languages and frameworks provide a huge amount of productivity compared to how we are currently building applications for the web at the office. Tooling definitely needs some work on the Eclipse side of things, but Netbeans and IntelliJ are providing some great alternatives in the interim. I’m really looking forward to using JRuby and Rails to create our stripped down CMS application, which has recently received the green light. I’m even more excited about continuing to work with Groovy and Grails as their communities grow (and even pushing for its use in the office). Thank you to LaForge, Rocher, Nutter, Bini, and everyone else who has contributed their time and hard work into making Java on the web productive (and fun). I really see potential in the languages being built for the JVM and can’t wait to see what the future holds.

NOTE: Sorry to Jython, Django, Scala, and Lift for not including you in this PoC. For now I’ve spread my wings enough to be dangerous, and by dangerous I mean screw up enough software to retain job security. I hope to find the time later this year to do some more exploring.

Recently, I've been interested in examining the features of non-visual components as it applies to Flex. I don't hear them talked about a lot (at least in the small part of the blog-o-sphere that I read), but I think there are some uses for these types of components that could really catch on in the community. I've tried to put together a sample application to show an example of some of the ideas I'm playing with in my head.

So the big place where I see non-visual components having a use is when attempting to bridge the stateless and stateful portions of a Flex application, mainly in the area of remote services. When I design a web service or remote object to be used by Flex, I typically build it in Java (or ColdFusion) and I design the service such that its methods operate in a stateless fashion. For example, when I call a method on my service, I don't expect previous calls to that method to influence the results of my current call; at least from the perspective of the caller. Additionally, I have the expectation that more information may be required when calling the method since the remote object receiving the call has no context in which to interpret the method call besides the method itself. Now I'm know an argument can be made about whether something truly is stateless or not, but that's not the goal of this post. Let's work with this ad hoc definition of stateless for now.

Flex provides us with a very simple, global means to get a hold of these services: RemoteObject, WebService, HttpService; there are other means by which to connect to remote services, but for now let's take the simple example of stateless RPC-based services. Typically in my Flex applications, I want to emulate a synchronous call from the application to the service (using something that implements IResponder or mapping the result/fault methods manually). Ideally I should have a class abstracting these calls to improve cohesion in the application; frameworks like to use command, delegate, or proxy classes, for example. During the emulation of this synchronous call I usually have my result/fault handler call out to a method on a class to change the state of an object (e.g. - setting values on the ModelLocator in Cairngorm), consequently firing propertyChanged events and/or custom events to update visual components via data binding.

All that being said, there are a couple of things with this approach that I want to address. First, I'm making the assumption that the class which abstracts the interactions with my service should also remain stateless. No where in the creation of the object am I changing its state so that the behaviors associated with the object may have a different context when executed. Second, I'm making the assumption that the behavior of this abstracting class must be separate from the data it uses. Propagating a change in an object's state via events is the back-bone of Flex data-binding. Not only that, but data binding is very simple to use and code, why shouldn't this simplicity be available in the ActionScript class abstracting the call to the remote service?

So that's enough conceptualizing for now, let's look at some example code. Please note the entire working example can be found at this location.

In this example, we have a very simple phone directory application. A SearchView exists which takes input from the user and announces a custom event (SearchEvent) passing that user input as its payload (i.e. - SearchCriteria). This event is handled by the Application class which in turn calls the find() method on an instance of SearchComponent. SearchComponent is a non-visual component which uses data-binding to propagate changes from the stateless world into my stateful Flex application. The code for SearchComoponent can be found below:

There a few things to note about this component for the purpose of this example:

• A method on a remote service/object is not actually being called, I'm using an XML document to simulate that process.
• I am not actually emulating a synchronous call, I'm allowing the current thread to block on the method call. If I were to emulate the synchronous call, I would suggest using anonymous functions as the result and fault handlers for the remote service/object. The code in this example would be short and not warrant a named method mapping (this is done a lot in JavaScript when registering event handlers).
• Yes, my coding style kinda sucks, get over it.

Now when the find() method is called it does not return anything, instead it updates the component's internal state via the employees property which then fires a propertyChanged event which is handled by ResultsView to populate a datagrid. Additionally, notice that when the object is constructed it makes a call to fetch location and department information to which controls in the SearchView are bound and updated when construction is complete. These values from these controls are used to filter the search performed by the user.

Going back to the conceptual, there are a few questions that come to mind:

1. Aren't components supposed to be reusable? - From my POV, it feels like Flex has already done a great job of handling re-use through the RemoteObject, HttpService, and WebService classes. It seems that if re-usability is needed it would be at the service rather than the non-visual component. The non-visual component in my example is literally acting as a perspective for its service, or what potentially could be a group of services. Right now, however, I'm not sure if there are huge performance issues that may result from having multiple component perspectives for a single or series of services. I would assume for RemoteObject it may not be as big as a hit as it would be for a web service. Maybe this would be based on the remoting implementation you choose (i.e. - LCDS, BlazeDS, WebORB, Granite Data Services, etc).
2. Aren't you just causing side-effects on objects? - In my opinion, it's not doing anything different than what Flex is doing with its visual components. In fact, what I think justifies this particular approach is the fact that you have the ability to notify anyone watching the object when its state has changed; I've always considered side effects as changes in state that I potentially didn't know about as the caller. The Flash movie instance is stateful; why not take advantage of this environment to add state to the classes abstracting our services? I'm building these non-visual components to satisfy the needs of my application, so I will know how they should behave and can to document that formally based on the constructs of the language. Now, if you ask me if this approach should be used for building an API-like interface to a set of remote services, then I would have to say no. The implementer of an API doesn't know how their code will be used in the context of an application, consequently keeping these components as stateless as possible is to the benefit of the API developer; context is limited to the execution of a method call. I think the Twitter API for Flash Developers is a great example of this.
3. Where do I put all of these non-visual components? - This question I believe involves much more conversation about the implementation of these non-visual components. The example application is extremely simple and does not represent the issue of how to handle event propagation. In the example, all events are being propagated to the Application class and emulating a sort of global event system similar to those that I've seen in Flex frameworks with which I've worked. In fact, this is how easyMVC handles its event registration in the ControllerFactory; a ControllerEvent with a user provided type is registered on the Application and no matter where the event is dispatched, it's told to bubble to the Application to be handled by a mapped method in a custom Controller class. I have to admit that I like this approach much better than Cairngorm and PureMVC's approach of building their own global event system. I know both camps have their own reasoning for why they've done it, but I don't think that what Adobe has provided is worth re-writing. On the other hand, does the hierarchical nature of MXML bind visual component layout and construction too close such that without global event systems we can't be productive as Flex developers? On a side note, data binding in practice isn't always the answer to our problems; how a component can take advantage of these non-visual components and still interact with the components it needs to is a mystery to me. This may come back to the nature of MXML as well.
4. Do I need a framework if I use this approach? - This is something I'm still trying to figure out. The biggest use of Flex frameworks I've found is a structured approach for making calls to remote services. I feel like frameworks have way too much boiler plate code and if this approach is practical, a good alternative may exist in place of adopting a framework. It seems to me like Flex frameworks have come from the mindset of the web world where stateless HTTP is king. We don't have to use the Front Page Controller pattern to build rich UI's; I think it's time to move on to different interpretations of the MVC pattern. I always find myself asking, did developers in the Java Swing world find themselves turning to a framework or were the constructs of Swing enough to be productive. If people were productive with Swing and it was a widget toolkit for AWT, why can't the same be true for Flex and Flash?

All this being said, this is just my latest idea. As you can tell, I still have a lot of unanswered questions. We are the process of implementing this approach on a much larger scale at work and hoping to solve the questions listed above. I'm always interested in feedback, so please rip this to shreds. I am far from experienced in this arena and am always open to what others have to say despite what some may think.

NOTE: For those who are interested, I began along this line of thinking based of the latest buzz-worthy topics in the programming community. It interested me as to how OSGI implemented their component architecture in Java w/o some language level support (e.g. - formal properties) and why it so popular. I was also intrigued by a proposal put together by Joe Noxel, from the Java Posse, regarding additions to Java for some of the language level elements already present in Flex. Additionally, SOA has come into debate by some of the more experienced professionals in software engineering and SCA (see Apache Tuscany as an example) has been identified as a potentially better alternative. So all this talk, combined with the little amount of component programming I've done with COM+ and .NET, made me wonder. If there is such a huge draw towards component-oriented design is there anything in Flex that we can do to take advantage of these practices? Does having formal properties and support for events as it presents itself in Flex aid developers with the tools necessary to utilize component-oriented design? Is one of those areas specifically the perspective of bridging the gap from the stateful component to the stateless service? Now I know a component has a much richer definition than I'm limiting it to, but this is just the point. To what extent can we, and should we, use components within Flex?

If anyone is in the Orlando area tomorrow night, stop on by the Adogo meeting! We will be raffling off a license for ColdFusion 8 as well as giving away great Adobe stuff to anyone in attendance. Luis Majano will be giving a presentation on the latest version of ColdBox as well as an overview of the framework. Also, I will be leading a BoF on the multitude of ColdFusion frameworks that we have access to as a community. Hopefully I can encourage a good amount of discussion like Max did for our RIA BoF back in August.

Hope you stop by tomorrow, 12/04, at our usual time (7:00 PM) at Devry in Millennia. Highwinds Network Group will be sponsoring the meeting and bringing food along, so worse case you get fed and enjoy some casual CF conversation.

Well I didn't know what to expect from participating in a belated conference via audio files, but I set my expectations low because the conference was intended for a general audience. A lot of the sessions covered material I was familiar with but it was cool to get a different perspective and see what the lecturers were pushing in the community. Overall I think it would have been a good conference to go to. I got some cool ideas for ColdBox that hopefully Luis and I can hash out. If they offer it via audio again next year I'll definitely download it

Elliott Sprehn from Teratech gave this session. He spoke about the use of metadata on objects and their relationships to infer information for use in things like design pattern implementations. He went over how sometimes configuration in frameworks causes a duplication of knowledge because the frameworks needs things spelled out in a specific XML grammar to work correctly. On the conceptual level, he did a descent, not great, but decent job of defending convention or configuration. There were a lot of the framework creators in the audience who disagreed with him, so that was a comfortable listen.

He spoke about some of the great tools that ColdFusion had which made convention-based frameworks very easy to build (e.g. - Named parameters in method calls aiding in writing routes for SES URL support). He went into the GetMetaData() function as well just to show what features ColdFusion offered in terms of introspection. Towards the end of the session he tried to show some examples, and nothing worked. He even came with a few excuses for it, which was again awkward. The session had the potential to be really good, but Elliott wasn't prepared and it weakened his argument.

I was however able to get some ideas for ColdBox from his session. I would like to see the session again, just with a little more preparation.

Rob Gonda gave this session. He went into a basic overview of OO constructs (e.g. - class, object, method, etc.). He then went into the concept of the Factory pattern. The explainations between the IoC and Dependency Injection patterns were interchanged a few times, but Rob was able to get the basic idea across. He explained how to use ColdSpring and the problems it helped to solve in terms of object construction. As he walked through each concept he used Ray Camden's Galleon app to show how object factories could be used to simplify the construction process based on the solution.

It's funny to hear all of the variations with respect to what people call the classes they work with. Rob in an aside mentioned the classifications he likes to give classes:

• Service classes
• Transient classes
• Persistence classes being Transfer and ActiveRecord classes
• Business classes (I think I remember him saying this one, but this may be interchangable with Transient classes)

Just another variation of how to communicate your ideas about OO programming I guess.

I was pleasently surprised with the quality of the content as compared to the rest of the sessions. Great job Rob; nice meeting you at cf.objective()!

This talk was given by Hal Helms. Unfortunately, for the people attending the conference, Hal had his laptop confiscated by the Canadian border patrol on a trip in January. He gave a short talk about civil liberties and then went into his impressions about the current state of the programming job market and his impression of the "threat" of outsourcing. He advocated programming smarter (i.e. - education in software engineering) but acknowledged that this wasn't necessarily something which could guarantee an American edge in the battle for the job market. Hal advocated the idea of getting better via the process of architecting and managing projects from a technological perspective using Interface Driven Architectures (IDAs). This is basically the idea of fortifying some form of prototype and locking down the UI to avoid feature creep later in the development process. Hal indirectly encouraged a huge of time spent on domain modeling which was encouraging to hear.

Overall, it was good to hear any perspective on the state of our industry but the session was a little light on content.

John Paul Ashenfelter also gave this session. He gave a very comprehensive overview of the Ruby on Rails framework and the tools it provides to solve a multitude of common problems faced by web application developers. The context of the session was definitely to draw a comparison between ColdFusion/Fusebox/etc and RoR. No negative connotation went along with the comparison, but you could definitely tell he's a big Rails fan.

John had some very valid points, but I got the same vibe I do from most of the community experts when they present regarding the type of work they do. In my current job we are attempting to build software that is going to last for at least a decade, or so we hope. We're making decisions which are not only helping to shape the software we build, but decisions to better understand the business domain we're working within. I am really curious if most of these consultants have similar concerns? I'm sure they follow best practices and are good at their jobs, but what type of longevity and scale do consultants have in mind? Is the time necessary to build things like canonical data models and SOA's only available to the salaried guys/gals? It seems like consulting is very project/task-based which I associated with very short term goals. I don't know, I'm probably off my rocker.

Anyway, good talk John, thanks for mentioning JRuby too!

John Paul Ashenfelter gave this session. This session turned out the same way it has in the past 2 years, a good overview of what's available in terms of free testing tools. He advocated the use of cfcUnit for unit testing and Selenium for integration testing. John always does a great job speaking and the session was informative.

This session was done by Brian Kotek. I think he did a very good job of distinguishing between the roles that different objects can play within the context of an application. He created, the model and view components of the MVC pattern in an "agnostic" way, such that Mach-II, Model-Glue, and Fusebox could be applied with little work as a controller. He was very clear about identifying the responsibility of objects in the frameworks as it related to his models. I especially like the example he gave regarding listeners acting as adapters in Mach-II rather than as implementors of your application's business rules.

The session was very straight forward, easy to follow, and interesting. Great work Brian! Nice meeting you at cf.objective().