Recently in Cairngorm Category

So I have challenged the Adobe Consulting team with producing some technical guides around Cairngorm - short 2-4 page documents - that capture some of the approaches, techniques and ideas we have been implementing on projects worldwide, where we are building Rich Internet Applications with Cairngorm.

So many of the common questions aren't necessarily best responded to with more code, more interfaces, more abstractions and more framework classes, but are really questions about strategy and tactics.  Working with modules.  Strategies for internationalisationand localisation.  Working alongisde Flash Media Server. Cairngorm alongside data management services in LCDS.  Implementing a best-practice secure login.  Creating your first Cairngorm project.  How do you manage view-states.

So here's my question: if we were to write 10 technical guides around how we use Cairngorm, each guide not necessarily being code (or entirely code) but just sharing with you the techniques, tradeoffs and considerations we have passed from project to project, what would those topics be ?  They may be the simplest of topics "how do I create a Cairngorm project from scratch", topics around using Cairngorm within your delivery approach ("what strategies are there for improving unit-test coverage in Cairngorm projects") to the downright advanced ("how do I pronounce Cairngorm ?").

I'd welcome community feedback; I'll collate a list of topics, and then we'll see if we can't let the community vote on the first technical guides that we'll produce.

I look forward to your input.

So with MAX 2007 Chicago behind me, and MAX 2007 Barcelona ahead, I'd like to put out some brief notes on our plans and intentions for Cairngorm.

Let's start with clearing up some uncertainties. In our Adobe Consulting Birds of a Feather, we played a few games with the audience to warm things up, including a game where 3 consultants would make a statement each on a topic, only one of which was true, and the audience had to correctly guess which one was true.

So the two lies about Cairngorm were that "we're building a lightweight version of Hibernate for AIR, and because it's lighter than hibernation, we're going to call it Slumber". That was a lie. And we also said we were going to rename "Cairngorm" to "Mount McKinley" so people would stop complaining about how to pronounce it. But that was a lie as well. So neither of these 2 things are fact :)

We've pushed the changes we pushed out as beta through to Adobe Labs, as you saw on Alistair McLeods blog. So that's now the stable version of Cairngorm for you to develop against.

I want to be very clear, in case it hasn't been - if you are continuing to build RIA with Flex and Cairngorm, and these RIA are front-ends upon Service Oriented Architectures, where you are invoking services and handling their responses - whether that be RemoteObject, WebService or HTTPService - then the current microarchitecture remains our advocated architecture for you. We have no intention of changing that in a future version of Cairngorm, so please don't hold out waiting for anything else because you think there might be big change a comin'. There's not.

However, we've been doing a LOT of deep-thinking around data oriented architectures, which are the kind of architectures that evolve as you begin to leverage LiveCycle Data Services, in particular the data management features of LCDS. Peter Martin presented a deep-dive into that current thinking - and as he preluded his presentation with, we aspire to solidifying this thinking into repeatable best-practice that we can bake back into Cairngorm. However, right now our thinking is strategy and architecture as much as it is reusable classes that we'll bake into Cairngorm. Alistair McLeod is going to give this presentation in Barcelona, and we'll be opening up discussion online as well about some of our thinking, and we look to compare our data points with many of yours before we bake this into Cairngorm. What I do see happening however, is that Cairngorm Enterprise will evolve to include best-practices for data oriented archtiectures as well as the current best-practices we advocate - and will continue to advocate - for more service oriented architectures.

Exciting stuff.

We also care a great deal about making Cairngorm developers more productive; we plan on sharing some work that we have been doing around Eclipse plug-ins to increase your productivity, but it's early days yet and we've not had the bandwidth we hoped for to drive this into the community. Hold tight, but it's coming!

If you're going to be in Barcelona, please drop by and say hi - I'll be giving my talk on Design Led Innovation again, which I really enjoyed delivering in Chicago. It's easy to get into the details of architecture and design patterns, but it's also nice to pull up to 35,000 feet from time to time, and remember that our job is to "build THINGS that PEOPLE will USE" (to paraphrase my colleague, Simon Smith, who leads Adobe Consulting's User Experience practice. I'll also be presenting in the Flex Best Practices panel.

Hope to see you in Spain...

I'm increasingly questioned about how much code-generation we employ when we're developing our own solutions upon Cairngorm; let me address this point with a look to the past, the present, and the future.

The Past - From UML to Code Generation for the Mother of Cairngorm

Way back in the past (1999-2000 timeframe) I was a huge advocate of UML and roundtrip engineering; in fact some of my now Adobe Consulting colleagues were colleagues in a past-life, where we were ardent users of the Together UML tool for Java.  Together were acquired by Borland, and Together UML now ships with Borland IDEs I believe.

Around the same time I began to sip from the agile firehose, I became less interested in UML modelling and model-driven development techniques.  It was around this same time that I first was exposed to the Core J2EE Design Patterns from the Java One presentations by Alur, Crupi and Malks, and developed my first architectural framework using these patterns in Java.  We called the framework "Mesh" (as in a wireframe mesh for the application, remember this was before struts, but same idea) and found ourselves laboriously writing lots and lots of repetitive "handle-turning" code.  Mesh was the mother of Cairngorm I guess, in that Cairngorm took a subset of the design patterns that we leveraged in the Java world.  In Cairngorm, we discarded the Data Access Object (DAO) pattern,  the Business Delegate became a much simpler facade onto server-calls, as opposed to an almost object-to-relational bridge between the Java value-object world and the JDBC PreparedStatement and ResultSet world for Create, Read, Update and Delete methods.  And of course, the value objects mapped very closely to the underlying database structure, as the DAO pattern adapted tables to objects.

We found that any story (feature/use-case) we picked up for development would inevitably be a bottom-up development of "add/augment a database table, update the value object definition, create a new DAO if it was a new table or view on the database, or tediously update lots of SQL queries and iteration over ResultSets if we were simply adding columns to a table, write new methods on the DAO, and then write new methods on the appropriate Business Delegate class to call the new DAO methods, adapting ResultSets into value objects and value object graphs. Only then would the story-specific fun begin, as we implemented Command classes and JSP to render the view. Boring, boring, boring.

With all this tedium, I turned to code generation of the value objects by JDBC introspection of the database metadata (creating value objects per table, and attributes on value objects according to columns in the table).  I'd then code generate the DAO classes, all the CRUD operations and queries, and the business delegate methods for each DAO method.  It was all very crude (perl initially, Java eventually) code generation, and inevitably we'd step in and do some hand-coding or optimisations to the code anyway, which meant we then didn't want to rerun the codegen (it wasn't as clever as being round-trip code generation).

I'd argue that with all this tedious VO, DAO and Business Delegates upon a database tier, the effort for code-generation just about paid off for us.

If you're interested in this kind of approach, from database through Java-tier all the way to creating client-side code (not Cairngorm based) and a view, the team at Farata Systems have created DAOFlex that will do exactly this kind  of code generation, much more elegantly than my home-brew approach at the time as well   There's an article on Adobe devnet that will get you started.

The Present - Adobe Consulting on Cairngorm Code Generation

Right now, I'd say that the amount of code that we would typically usefully generate hasn't really justified the effort; code-generation is a decision that a technical architect will make on a project by project basis, but it certainly isn't in our arsenal of practice-wide techniques that we apply to each and every project.

Peter Martin did make some attempts with the XDoclet 2 work that he did, building on some work by Joe Berkowitz of Allurent.  As you can see from his blog entry, it was a lot of work to create value objects only, which in the grand scheme of our typical projects, don't account for a whole host of development effort and time to maintain.

So in summary; right now we're not employing a great-deal of code generation and don't feel that we're suffering in productivity because of it.  Those coming from a Ruby on Rails background are often impressed at the ability to automagically generate so much scaffolding for CRUD type applications - I think the DAOFlex approach may work for you here, and remember we're never necessarily advocating Cairngorm for your simpler Flex applications anyway.  Someone asked me in blog comments recently whether Cairngorm and Flex could be more complex than Ruby on Rails with AJAX, and I guess sometimes it can be.  However, those are two poles of a spectrum, and in-between there are a number of much-simpler non-Cairngorm Flex approaches that can be taken to rapidly deliver simple applications.  There are times when i think you shouldn't use Cairngorm.

I guess under the present tense, I would like tomention the work that has been done by Eric Feminella in a project he has called Cairngen.  Eric's motivation is to remove the repetition associated with creating Events to be registered with the Front Controller and their corresponding Command classes, by creating the notion of a "sequence" that can code generate stub classes for the Event and Command.  Cairngen will also make it quicker for you to start a brand new Cairngorm Flex project, by creating all the project structure, folders and template classes for a skeleton Cairngorm project.  Cairngen is a server-based solution, leveraging PHP and AMFPHP to manage the code generation from templates - it may work for your workflow, and is definitely worth checking out on Eric's blog.

Though I've never used the product, I noted that WebOrb is now also generating Cairngorm code from templates as well, so that may be worth checking out if you're using WebOrb already.

The Future - Integrating Cairngorm more tightly into Flex Builder workflow

I spoke in my last blog entry, that our Adobe Consulting team are constantly balancing client and project committments, with practice and community committments to deliver best-practices, guidance and productivity tools for those using the same tools and technologies that we do every day.

As we focus on Cairngorm 3, we're also very focussed on enhancing the workflow for Flex developers who are working within FlexBuilder.  We've a number of ideas that are more than simply push-button Code Generation that will yield the flexibilities and benefits that we consider from working with a Cairngorm architecture, and that will furthermore leverage the consistency and predictability of Cairngorm Flex development to assist developers in building applications with Cairngorm and Flex.  That was a hell of a long sentence.  It's still very early days in our development, so we have nothing to preview or share at present ... but hopefully that gives a little insight into where we're going in terms of developer productivity around Cairngorm.  I'm sure the consultants who have this work as their practice targets will release more information, or even previews, as and when they have something ready to share.

If I've missed any other code-generation or general Cairngorm productivity tools in my roundup, please feel free to add them here in the comments. 

But hopefully that shares the current working practices within Adobe Consulting, and gives you some confidence in your own approaches.

I'm really pleased with the following piece of news; Evan Gifford, one of the members of the highly popular flexcoders mailing list discussed with me his hopes to create a community around Cairngorm documentation and eLearning project.

Evan has created a new YahooGroup cairngorm-documentation, which is to be the focus of a community-driven documentation effort for Cairngorm.

Those of you on the flexcoders mailing list have seen Evan work with the community to create some diagrams that help newcomers to Cairngorm better understand how the patterns work together; Evan's vision is to extend this to interactive eLearning modules and tutorials that will aid developers in quickly understanding Cairngorm, and the best-practices around Cairngorm.

I think this is a great step forward; please consider signing up to Evan's list if you'd like to steer the direction of this initiative, or if you'd like to support Evan by contributing to the initiative.

I know what you must be thinking – Steven Webster is suggesting I shouldn’t use Cairngorm ? Well no, not exactly. However, the rapid adoption of the Flex 2 platform that we are currently enjoying has seen us enjoy a tremendous number of new developers to the Flex platform, many of whom are trying to absorb as much information they can in as short a time as possible. When you first become aware of the tremendous opportunities for solution development with Flex, it’s no surprise that you want to ascend the adoption curve as quickly as possible. However, there’s no short-cut to experience, and that’s the topic I want to call out here. If you’re new to Flex 2 or Cairngorm, then I’d love for you to read on a little…

So let me try and highlight some of the reasons I think you shouldn’t use Cairngorm. If this is you, I’m simply asking that you put a little space between where you were before you downloaded Flex, and where you will get to with Flex before you start building applications. That space is where all the invaluable lessons will be learned, that will serve you well in the very near future.

REASON ONE: I’ve never built an RIA of my own without Cairngorm. Not even a mini-one.

I guess this signifies your place on the learning curve; most first-time Flex developers will typically try and learn their way through the framework by building a number of small applications that test their understanding of Flex concepts.

So you’ll perhaps build some applications that just create a user-interface with containers and controls. Then you’ll maybe see if you can create a dynamic user-interface, by calling a web-service, an HTTP service or maybe even some Java business logic you have, and see if you can bind those results (you’re learning data-binding now) to a Data Grid, or other such component.

You might then try and make your application able to update some back-end persistence tier; so now you’re going to write a Java class, or a CFC in Coldfusion, or some PHP using AMFPHP, or maybe even just expose some C# code as a web-service, and see if you can’t invoke some of that server-side business logic to create, update or delete something in a database.

This is a milestone Flex accomplishment.

Next, you’re probably going to write some applications that test your understanding of styling, of states, of effects, and all manner of other Flex features – learning how to write inline ActionScript in an MXML class and invoke those inline methods in click-handlers, or upon creationComplete. You’ll then start extracting some of that ActionScript that’s inline into external classes, and flipping seamlessly between the world of MXML and ActionScript.

You don’t need Cairngorm for any of these applications you’re building above. And more importantly, if the experience of building these kind of applications isn’t one that you share, then you’d be a number of standard deviations to the left of the majority who are building applications with Cairngorm.

So go and build some sample applications, and just get used to working with Flex. Once you’ve done that, go and read the 6-part article series, and see how many of the challenges we discuss, resonate with you in your own development.

REASON TWO: You’ve seen an application built in Flex 2 and Cairngorm 2, and you want to use that as the starting point for your application. Even though REASON ONE above still applies.

The aim of the sample applications that we have released built upon Cairngorm, is to exemplify some of the best-practices when building Cairngorm applications, or to give people something they can pick apart to better understand Cairngorm.

However, these applications are not intended as the starting point for your applications – there are very few customers out there who only have 16 products that they wish to sell, and are therefore candidates for a quick rebrand of Cairngorm Store !

When you’re ready for Cairngorm, I’m going to ask that you take your first step with the Cairngorm challenge at the end of this blog entry. If you complete the Cairngorm challenge, then you’re ready to build more complicated applications with Cairngorm. If you can’t complete the Cairngorm challenge; take a few steps back and re-assess where you are in your Flex learning. Cairngorm will still be there when you’re done.

REASON THREE: Your application has only one or two user-gestures to react to.

So what exactly do I mean here ? I’m trying to measure the complexity of your application – how many different things can the user do with your application, that merit some computation being performed on the client or server. Viewing all products in a catalogue is a use-case. Adding a product to a basket is a use-case. Deleting a product from a basket is another use-case. Taking the basket to the checkout is another use-case. Checking out is another use-case. Ad infinitum. If your application has several use-cases, then the organisation that Cairngorm will bring to your source-code becomes valuable.

If however your application has one or two different views, and a few buttons/gestures that the user can make – then you can probably accomplish the application you are building without Cairngorm. Remember – the team behind Cairngorm are also huge advocates of agile software development, and the doctrines of simplicity that pervade agile thinking. Sometimes the simplest thing that could possibly work, is not to use Cairngorm. Or to paraphrase someone smarter than me, “…the best solution is not when there is nothing left to add, but when there is nothing left to take away…”.

REASON FOUR: You are the only person developing your RIA. Ever.

Many of the benefits we advocate from Cairngorm are from the predictablility, maintainability and scalability of the code-base, when it is organised with “Cairngorm thinking”. It becomes much much easier for developer D to contribute to a codebase that developers A, B and C have been working on, and to contribute to the codebase without making it more brittle to change. Or to quote another agile ambition – it can enable the idea of “collective code ownership”.

If you are the only person working on your application, that’s a good time to take a sanity check on whether Cairngorm is necessary. REASON THREE is important here – if you are the sole developer on an RIA that will have 20-30 use-cases, yes, you’ll benefit in the long term from Cairngorm. But at least use this sole-developer case as a sanity check.

REASON FIVE: You’ve found a bug in Cairngorm.

If you find a bug in Cairngorm, there’s a really good chance it’s too early for you to be using it in mission critical projects. I state this with confidence, because many years ago I was a C developer who kept finding bugs in Kernighan and Ritchie’s C compiler. Every day, I’d find something wrong with the compiler – in fact, come to think of it, I think I was responsible for finding some real clangers in the Pascal compiler on SunOS as well, back in the day.

Well, I say bugs … more often than not (in fact, come to think of it I don’t think I’ve ever successfully filed a bug against a compiler) they turned out not to be bugs. But they almost were … had it not been for the mistake that *I* had made! In fairness, I think Ali found a bug in the Java compiler once, but then he also refused to allow iteration::two to accept a tax refund from Inland Revenue, because he found a flaw in their calculations when we were subjected to a routine VAT inspection. It takes a special kind of pedant to find bugs in compilers, and flaws in Inland Revenue VAT calculations. Hope that this isn’t you.

Seriously; I don’t want to suggest there haven’t been bugs in Cairngorm, and when we’ve been through early betas, like any other software products, we’ve allowed the occasional bug to slip through. However, the Cairngorm releases that we make publically available, compiled as SWCs … we use those a lot. We eat our own dogfood. There are a lot of folks in the community using them, and if you can’t get the basic login sample that we ship to work then I’ll hazard a guess that it’s a flaw in your system setup, not a bug in Cairngorm.

If you’re getting frustrated that you’ve found a bug in Cairngorm, and you don’t know what the error message means – there’s a pretty good chance that a little bit more time spent up at REASON ONE, writing some more sample applications and experiencing compiler errors while you take your baby-steps, will help you steam past the configuration problems you’re probably experiencing with your particular Cairngorm sample application.

CAIRNGORM CHALLENGE

So here’s the Cairngorm challenge. The rite of passage for Flex developers everywhere. Open Flex Builder, and create a new Flex project. Import the cairngorm SWC – that’s right, not the source code, import the SWC.

Now, write yourself a simple Cairngorm application, that displays a datagrid, calls a publically available web-service somewhere, and then renders the results in the data grid.

Here’s a clue – you’re going to register one event with the controller, you’re going to write one command class to get the results, and to update the model locator when the results come in, you’re going to create a business delegate class for your command to invoke the web service with, and you’re going to register the web service with the service locator.

Now this is way overkill for calling a webservice to populate a data grid. But if you’re ready for working with Cairngorm, the above will be HelloWorld.cpp to you (and there will be no bugs to find in the compiler)

I GET IT. I THINK I’M READY FOR CAIRNGORM.

Fantastic. First of all, it’s fantastic, because if you are here, then you’ve wrapped your head around Flex 2, you’re comfortable building little sample applications that leverage all the various features of Flex, you understand the various problems that Cairngorm is addressing – because you read about them in my 6-part article series on Devnet, and because what’s more, you’ve actually encountered or at least became self-aware of the problems that we cite as the forces for the patterns we chose for Cairngorm. Isn’t it great – that patterns are solutions to recurring problems, and you’ve actually experienced the problems first hand ? It gives you a certain empathy with the solution already.

Now that you’re ready for Cairngorm, www.adobe.com/go/cairngorm will continue to evolve with everything that you need to build scalable, maintainable, mission-critical bet-the-business applications upon Flex 2, with a little bit of our thoughts on best-practice architecture baked in.

I’ve been deliberately tongue-in-cheek in this blog-entry, but I’m motivated by a serious point; increasingly, we’re finding developers who are finding Flex 2, and within a heartbeat are then finding Cairngorm. If developers jump too quickly into Cairngorm, it can introduce frustration into a learning curve that should have been much more shallow, and much more enjoyable, and much more focussed on Flex 2.

“But we’re a strategic customer, who are betting the business on Flex 2 and we need to ensure that we’re delivering with best-practices. And we need to be live in 3 months”.

Then that’s where leadership and mentoring are infinitely more important than technology and architecture – and organisations such as Adobe Consulting can help assure you that success.

In the meantime; there’s a great deal of people like you hanging out on Flexcoders, and a greater number of people who have taken this road ahead of you, and are more than willing to give you the help you want. So find us over at www.flexcoders.org if there’s anything we can do to help.

Don’t run before you can walk. Ain’t it always the way.

Dan Harfleet has posted over on his blog about our current efforts within Adobe Consulting to revisit the content on Adobe Labs related to Cairngorm.

We're now devoting some time and effort to increasing the level, depth and breadth of content that will help you be successful with Cairngorm - Dan is soliciting feedback from the community for what would best help them get started, and get productive with Cairngorm. So what do you need; more sample applications ? More getting started articles ? Deeper-dive articles into specific topics ?

Please check out Dan's blog, leave him some comments or drop him a line, and we'll be able to focus the time we spend on this to meet your needs more exactly.

Digimmersion are a company that create stencils for Visio for creating wireframes for Flex development; I notice that they have a great little document that explains to people how to build a Flex 2 application with Cairngorm - you can find it here. For those of you learning to develop with Cairngorm, you may find value from this 30-page article.

It's really satisfying to see that the community is now delivering these offerings around Cairngorm and Flex !

There's now a new easy-to-remember URL for Cairngorm, which we'll adopt as the URL we'll use in any communications/emails. You can now send people to http://www.adobe.com/go/cairngorm. Thanks to the Adobe web-team for arranging this for us, despite the myriad of other changes they've had to do for the Flex Release today!

I'm hugely excited that Cairngorm 2 is now available for download from Adobe Labs, complete with a new home at http://labs.adobe.com/wiki/index.php/Cairn gorm

A number of the Adobe Consulting team have contributed greatly to the Cairngorm 2 project, either directly (by working on getting this packaged for distribution on labs) or indirectly by working with the technology day-in and day-out on customer engagements. I'm sure the team will have their own thoughts and blog entries to share with you in the days and weeks ahead, and look forward to their contributions.

More importantly, I'm deeply excited by the infrastructure of Adobe Labs as an enabling technology by which the community can now become pivotal in contribution. We've put in place a framework structure on Adobe Labs, that we'll monitor and grow over time to embrace the work that the community has done around our offering. We'll be looking to the community to share ownership in the documentation around Cairngorm, the sample examples around Cairngorm, as well as the links to resources that you find useful in getting started with Cairngorm.

The Adobe Consulting team will be using Labs as a place where we can continue to offer insight from the field, and advocate our thoughts on using Cairngorm across the entire Engagement Platform - be that working with Flex Data Services, or using Cairngorm in a Flash Lite or Apollo environment. These are all things we have consultants wrestling and working with right now, and all goodness that we'll be sharing in the months ahead. Your comments and suggestions are now welcome.

There are some changes to Cairngorm 2 from the last beta that we released, that incorporate the community feedback and field-insight that we have received. There's a brief discussion in the release notes for now, with more information to follow through our blogs, and through further refinement of the Wiki content. We had committed to ensuring that Cairngorm 2 was available for you in concert with the Flex 2 release, and that's the promise we've been focussed on keeping for you.

Download it, take it for a spin, and as always, let us know what tremendous user-experiences you're delivering upon Cairngorm 2 and Flex 2 !

It's a hugely exciting time in our community !

Many of you have been asking us publically and privately for latest builds of Cairngorm, and of updates to Cairngormstore, and we've been a bit quiet as to the progress we were making....breaking the silence, I'm now pleased to be able to tell you in a public forum that our behind-the-scenes efforts have been instead focussed on getting Cairngorm approved and ready for a forthcoming release on Adobe Labs.

Almost since the day we became Macromedia Consulting (and then Adobe Consulting), we've been working with the various internal teams at Adobe, from the Flex product team, through to our consulting teams, legal, finance, and all manner of other stakeholders to ensure that we could find a new permanent home for Cairngorm on Adobe Labs.

Don't ask me dates, as we can't reveal anything concrete. Aiming for first half of the year...

What this means for Cairngorm developers everywhere, is that we'll have a top-level project on Adobe Labs, with a Wiki offering an ever-increasing amount of documentation, samples, links to Cairngorm articles, as well as the very latest builds of Cairngorm 2 itself. Many of you have been building your own sample applications with Cairngorm, creating your own documentation, diagrams and tutorials, and we'll have an environment where we can now make these more readily accessible to the wider community.

In the coming days, I'll blog a little more about some of the changes we've made to the final release of Cairngorm 2 that you'll receive shortly. And relax -- any migration efforts on your part, if you've been with us this far, will be minimal. We have taken on-board the feedback the community has been giving us, along with our own field-level experience from our consulting teams, who have been busily developing Flex 2 applications upon Cairngorm 2, on behalf of a number of Adobe Consulting customers.

I trust this news signifies the continuing and increasing committment that we're making to Cairngorm, and our continuing ambition within Adobe Consulting to make our internal best-practices instantly and freely available to the current and future RIA development community.