My blog is moving!

Hello all - thanks for stopping by 2.0 A Go-Go. But now that the new LightRail website is live, I am going to be moving my blogging activity over there. I will still be posting the same RIA and general software development related content there, but the blog will be maintained and controbuted to by the entire LightRail team, including my CTO Jason Stahl, who is the best developer I know.

So please update any links you might have to our new blog, The Station. Thanks!

Appcelerator - First Impressions

I have a little time today, so I figured I would start coding up a little app using this new RIA framework called Appcelerator that I have been introduced to in the last month by some PR representatives from the framework’s development company. At first I thought that I needed another RIA framework to consider like I needed a hole in my head, but a few things caught my eye initially about the framework:

1. You write code in XHTML and CSS, with some JavaScript (so far I haven’t had to write a single line)
2. Hand in glove integration with popular server-side languages (Java, Ruby, PHP, Python)
3. Event driven UI through a neat messaging framework built in to the Web Expression Language

Numbers 1 and 2 are nice, but number three is where Appcelerator has me very excited. I am in the process of refactoring ReCESS to use the Cairngorm Micro-architecture. A big reason for that is to make the UI more event driven. But that process is turning out to be rather tiresome, as every time I want to create a new event, I need to write six ActionScript classes to implement it. Lame. The good part about it is that Cairngorm provides a nice level of abstraction between back-end server data (coming in the form of XML, JSON, whatever) and my UI logic, because my UI can bind to domain-specific models rather than raw XML. But the whole messaging piece is kind of cumbersome, and requires a lot of work to do something that should be easy.

Enter Appcelerator’s messaging system - let’s say I have a link, and when that link is clicked I want to make a block of HTML pulsate for effect. I would do something like this:

<a on="click then l:link.clicked.event">Click Me To Do Stuff!</a>
<div on="l:link.clicked.event then effect[Pulsate]">
    <p> This is important text </p>
</div>

What is happening here is that an event called “link.clicked.event” is being published when the link is clicked. The div block on the next line is subscribing to that event, and when that event is published, will make the contents of the div pulsate (using Script.aculo.us under the covers I think). No scripting necessary to make this happen. Server interaction is handled via this messaging framework, but I’ll get into that in another post. The utility of this publish/subscribe method should be clear - when I need something else to happen when that click event is published, all I have to do is subscribe again:

<a on="click then l:link.clicked.event">Click Me To Do Stuff!</a>
<div on="l:link.clicked.event then effect[Pulsate]">
    <p> This is important text </p>
</div>

<div on="l:link.clicked.event then show" style="display:none">
    <p> This text will be visible after the click </p>
</div>

Cool beans. To do that same event-driven goodness in Flex, I would have to either write a script to execute when the link was clicked to procedurally pulsate or show the text if I was being sloppy, or create a Cairngorm Event and Command, register them with the front controller, and create new state variables in my model locator to toggle visibility and whatnot. Again, it works pretty well, but I just did that same thing here in Appcelerator with a tiny fraction of the code.

More to come on the overall Appcelerator experience, but after my first few minutes actually coding with Appcelerator, I thought that easy messaging system was the bee’s knees. It was kind of an adventure getting my dev environment set up, but the project is still young (and based on my brief experience, full of potential as well).

Windows Presentation Foundation - bringing sexy back to the thick client

Things have been kind of whirlwind for me over the last month or so - in that time I have started (and now moved on from) working on the snazzy new Lawson Smart Client, designed by the good people at Frog Design and brought to life by the UI developers at Lawson in Stockholm and Saint Paul. A WPF application targeting the .NET Framework version 3.5, the Smart Client is already drawing raves for it’s attractive and approachable design, a departure from traditional enterprise software products in general.

I was able to do some minor enhancements on the product during my time with the team, and in the space of a month received a serious crash course in C#, WPF, Visual Studio 2008, and the .NET framework in general. Given the brevity of my foray into this arena, I will readily admit I am in no position to judge the framework authoritatively. But before returning this blog to the web, where most of my interest and expertise lies, I thought I would do a pro/con list for connected WPF desktop applications, like Smart Client.

Why Smart Client and connected WPF desktop apps rock:

1. It’s still easy to leverage server side and give your thick app some reach. Asynchronously accessing server-side data is not all that difficult, and the client remains responsive throughout, just like an RIA written in Flex or OpenLaszlo.
2. Graphical firepower - sweet Lincoln’s mullet, does the Smart Client look pretty. WPF makes it possible to achieve some pretty stunning visuals in your UI.
3. Tight integration points with Microsoft Office and other applications. To me, this is the big selling point for users coming back to the desktop, especially in the enterprise. If I am a pencil-pushing spreadsheet jockey, it is going to be a big deal if my application interfaces nicely with Microsoft Office, which I am likely to use to get my job done for 80% of my day. The .NET framework makes hand in glove interop attainable for desktop applications.

Why Smart Client and connected WPF desktop apps suck:

1. Tied to the desktop, which means less reach and portability than if your app was executing in the browser. One caveat here is that I don’t know all that much about Silverlight, Microsoft’s answer to the Flash player. Apparently, this provides a runtime environment for WPF apps written in XAML to run in the browser as well. But I wonder how well a WPF app, written with heavy dependency on C# for the desktop, is going to translate to the web.
2. More complex applications, heavier weight framework, and highly dependent on Visual Studio 2008 for productivity.
3. Selling your soul to Bill Gates - to me the big draw of the .NET framework over the JVM or thin clients delivered over the web is, like I said, deep integration with other Windows applications (notably Office).  But the drawback of that is… deep integration with Windows applications.  Forget vendor lock-in, this is more like vendor indentured servitude.

While there are some drawbacks that are associated with going back to the desktop, the payoff in user experience can be great.  For an enterprise-focused app like Smart Client it makes a lot of sense - at the cost of a lot more complexity and expense to develop and maintain the product.  Hard for Lawson techies, but at least customers stand to reap significant benefits.

Dark Side

My career has taken something of a left turn over the last few days - I am currently retraining myself as a C# developer, building a Windows client application using .NET 3.5 and WPF. More to come on these topics as I begin to unlearn what I have learned.

of medieval castle defense and the rich web service client architecture

As I was working today, I thought of another advantage of the rich web service client architecture I have grown so fond of - fewer application entry points to secure. And this realization got me thinking about something else - moats, drawbridges, and scalding oil.

Defending your application from attack is not all that dissimilar from defending a castle. If I am a feudal lord intent on building an impregnable fortress, there are a few things I generally want to do - the most important of which is to limit and ferociously defend the entry points to my castle. Most medieval forts and castles I have seen (I am thinking Helm’s Deep from The Two Towers here), have huge, thick stone walls surrounding one main gate - that’s it. And defending that gate, they have huge iron doors, a drawbridge, possibly a moat filled with flesh eating reptiles, and any number of deterrents to keep unwanted guests on the outside looking in.

The stone walls allow the defenders to be able to concentrate their defense on a small number of weak points. Thusly can a smaller defending force keep a massive army of uruk-hai at bay until first light on the fifth day. Why wouldn’t we want to build our webapps in the same way?

In a traditional HTML app like you might build with Struts or Rails, there are a large number of inputs on a large number of forms that all require validation. Ideally, any business logic you write which modifies the state of the model will have logic in place to make sure that the values they are getting are valid, but in practice sometimes the validation done at the controller level is the only validation that is done on the input to a system. This is less of a problem in Rails where model objects are always self-validating, but when there isn’t a 1:1 mapping between form inputs and model values, it gets much trickier. And in a Struts app, where there are sure to be a few levels of abstraction involved in getting form input and converting those values to business objects, the trickiness level goes up considerably. Frameworks abound to make these tasks simpler and configurable, but it does not relieve the pressure on the developer to defend all these entry points to the system.

However, if your back end is designed as a collection of web services, the number of entry points to the business functionality of your application goes down considerably. And given that their structure is so similar, it is easy to lay down effective layers of defense like filters and a restrictive API. If you have complete control of the entry points to your application’s business logic, then you can defend them much more effectively. Do this, and you can safely thrust down your staff and shout - “YOU SHALL NOT PASS!”

JBoss Seam - Java’s Rails Killer?

Whether or not you have decided to drink the Kool-Aid and join the Ruby on Rails cult, the enterprise Java world has been smacked upside its ideological head by the ease of use, development speed, and seamless integration of this web application framework which continues to grow in popularity. Java EE has built a reputation of being difficult to configure, slow to develop, and fraught with mind-numbing chores which detract from the applications developers are trying to create. The Rails approach of a web framework that is “opinionated” in such a way that many design and implementation decisions are made for you (and the corresponding work done for you as well) has shaken up the enterprise Java world where developers usually are tasked with creating and configuring a large ecosystem of complementary technologies.

In response to Rails’ implicit critique of Java EE, a group of top level talent from JBoss (including Gavin King, creator of Hibernate, which is to my mind Java’s killer app) has created a full-stack web application framework known as JBoss Seam. This Java web framework assembles JSF, EJB3.0, and Hibernate/JPA components in a single package which is configured to run with a small amount of manual configuration on the JBoss application server. Could Seam represent that reformation that might bring heretical Java developers worshiping false Ruby idols back to the flock?

GWT Honeymoon Turning Sour

If you’ve been keeping up on my ramblings on the blog related to RIA development and the various contenders in this space, you have probably read some very positive comments from me regarding Google Web Toolkit - along with the admission that my experience with it has been limited. Last night I decided to give a real application a go and dive into one of their example applications, the DynaTable Example. On the screen it looks pretty slick, and demonstrates some of the cool asynchronous stuff GWT can help you pull off.

But the more I dove into the application and started to change stuff around, the more I started to realize how hard this was to work with when compared to a similar application written in either Flex or OpenLaszlo. 

RIA Platforms Compared

In my inaugural post about the general utility of RIAs, the candidates I identified for implementation of an RIA were listed as Adobe Flex, Open Laszlo (LZX), and Google Web Toolkit (GWT). I made vague mention that they had their own strengths and weaknesses, but I thought I would dedicate a little web space to throwing in my two cents about what I think those strengths and weaknesses are. Is there a clear winner of the three, one toolkit that developers should focus on at the expense of the others? I don’t really think so. Much of that decision is based on the requirements for your project. But Flex, GWT, and LZX are certainly not created equal for all tasks, and I hope to give you a sense of what tool is going to be the best choice for your project.

Building a software dynasty

An interesting article on how to approach software projects can be found here - in broad summation, it attempts to define software development as a “series of resource-limited, cooperative games of invention and communication”. This makes a certain amount of sense and helps to lay the groundwork for a successful software development process. It acknowledges that a software system almost always must continue to evolve over time, and that the desire to make future enhancements and extensions of a system easy to incorporate is always at odds with the need to finish a current iteration of the software within a specified time frame. Author Alistair Cockburn (pronounced Co-burn, the Scottish way), seems to suggest that the wise software development organization will make the maximum investment possible in making future enhancements easy while still satisfying the functional and delivery time constraints placed on the project. He also uses the game metaphor to express the importance of the cohesion, communication, and ability of the team - which brings us to the topic of this disucssion.

I think the game metaphor becomes even more powerful when you apply it to building a software development organization - particularly when one uses a professional baseball organization as a model for comparison.

Rich client user interfaces simplify overall application architecture and development

In the enterprise Java world, the RIA (Rich Internet Application) platforms Adobe Flex, OpenLaszlo (hereafter referred to by it’s markup language LZX for brevity), and even Google Web Toolkit (GWT) are often sneered at as gimmicky, or because (in the case of Flex and sometimes LZX) they utilize the Flash player as a runtime environment. After all, what serious application is written as a Flash movie?!? Much better to go with tried and true, HTML-generating JSP tag libraries and template tools, which we know work pretty well to create the view layer of our applications - right? But as application user interface requirements become more complex, these tools (and more generally, HTML) start to become cumbersome. AJAX tools and frameworks can be used to meet these requirements and create some pretty stunning results, but the development of these applications is treacherous both in terms of complexity and browser compatibility. After wrestling with the quirks between IE 6, IE 7, and Firefox for the 36th straight hour with a suspect JavaScript debugger, reasonable people might start to wonder if there isn’t a better way to create rich user interfaces for the web.

Enter the RIA platforms Adobe Flex, Google Web Toolkit (GWT), and Open Laszlo (LZX). While very different in style and implementation, all three tools allow web developers to more easily develop rich user interfaces that are hard (if not impossible) to pull off with hand coded (or generated) HTML and JavaScript.