Testing Flex RIAs: The Aftermath

On August 12, I participated Farata’s symposium for Enterprise developers for the second time. But unlike the first time, I was on the other side of the barricades. I presented my research in the field of functional testing of Flex-based RIAs. Since my previous preso at NJFlex user group, I  figured out how to include automatic functional testing in enterprise application development life cycle.

In these presentations, I demonstrated what a Flex developer needs to know to prepare his or her  application or even a single component to painless UAT or QA testing. Using the tool FlexMonkey form GorillaLogic I demonstrated the basic concepts of interaction with Flex Automation API and components instrumentation. And for dessert, I showed how to automatically run functional and unit tests  on each code commit to the version control system. The screenshot above is an illustration of what I was talking about – instrumentation of components, introduction to FlexMonkey – an open source Flex-enabled testing tool, and Jenkins – one of the best open source continuous integration servers. The entire enterprise RIA development cycle was sampled.

Stop! Why am I trying to write the transcript of my preso?

If you missed the event, you still can download my presentation slides from here. Find the sample source code here. And ask your testing-related (or not) questions in the comments to this post.


Vik Gamov

RIA Integration: Bits and Pieces. Part 1.

There are many ways to have various software components to communicate in Java EE enterprise architecture.  The same is applicable for integrating rich Internet Applications written in Adobe Flex and Java EE systems. Let’s consider the following scenario:

An application A is being developed using Flex-BlazeDS-Java, and it needs to integrate with a third-party Java-based Web application B, where the users must register, otherwise they can’t continue using the application A.
Of course, to implement this scenario you can engage some of the business process management software packages that will allow you to describe and configure the workflow with minimum or no coding. But the less moving parts are used in the architecture the better. Here’s the pretty simple way to implement our scenario.

Step 1. When the user presses the button on Flex view, the code is being executed inside the virtual machine – Flash Player, which in turn is sitting inside HTML wrapper.    So the first goal is to make a call from inside the Flash Player to the outside world. Using the ActionScript class ExternalInterface you can map the internal function, say registerUserAS() to the wrapper’s JavaScript function registerUserJS(). You have to write both of these functions yourself.

Step 2. The JavaScript function registerUserJS() opens the URL of the application B in a separate Web browser window, where the user registers as required by the application B.

Step 3.  In the application A, develop and deploy Java servlet, say RegistrationCompleteServlet that can be called by the application B when the user successfully completed the registration. During this call, the application B will pass to the servlet a Data Transfer Object  RegistrationInfoDTO, with all required registration details.

Step 4.  The RegistrationCompleteServlet and BlazeDS are collocated in the same Java Servlet container(e..g. GlassFish, Tomcat, et al). The RegistrationCompleteServlet initiates a push of the RegistrationInfoDTO to the BlazeDS destination RegistrationDest with the routing to the proper client. How to push the data to the client over the AMF protocol is described in our book Enterprise Development with Flex.

Step 5. Almost forgot to mention that during the startup, our Flex application has created a Consumer subscribed to the messages from the destination RegistrationDest. As soon as the RegistrationInfoDTO is published to this destination, Flex client will receive it and let the user into the next view with a nice greeting, “Thank you, Yakov for registering. Your credit card information has been validated”.

That’s’ all there is to it. I’ve included “Part 1” in the title of this blog, because hoping that this will become a series of writeups on integrating Flex and Java EE.

Yakov Fain

Hacking or Design Patterns?

Earlier this year, I made a statement defending hacking in an interview for Oracle. Yesterday, I found a thread on theserverside.com where java developers were sharing their view on the subject. In this blog I’ll take the same two quotes there ignited some arguments and will try to explain my point of view.

1. “Recently, I’ve been running a seminar for a small group of Java developers. Several times they’ve asked me, ‘Is this code an example of MVC pattern?’ I got the impression that implementing MVC had become an end in itself. Using Design Patterns is not a dogma. Just write the code that makes sense. Not everything that makes sense has a named design pattern.”

2. “Abusing design patterns is not always the fault of Java developers. I find the approach used in the enterprise software shops similar to medicine in the US. In my opinion, lots of doctors here practice ‘protective medicine.’ They are trying to protect themselves from malpractice law suits. Enterprise managers and tech leads also try to minimize the risk introduced by lower-skilled developers who are part of every team. Yes, abiding to object-oriented principles definitely helps in making code readable, but this does not always translate into better performing applications. If hacked-up code produces great results, apply it without worrying whether another developer will have problems understanding it.”

I work for Farata Systems, a consulting company that makes a living by developing rich Internet applications utilizing Adobe Flex and AIR and Java EE. We are a small company (about 30 people). We do consulting as well as develop our own software (both commercial and open source).  The number 30 is important here. Many years ago, a respectful person taught me that until the company is under 30 people it’s efficient because there is no need to hire middlemen managers. The founders of the company can run the projects themselves, and there is no ballast.

After several years of running the company with two other geeks, I couldn’t agree more.  We can afford to cherry pick developers, which large company can’t.  I’ll tell you more – we can afford having people who don’t have to stick to design patterns just to ensure that Joe Smith who became a programmer after attending 6 months of vocational school will understand the code. We can afford to build teams not with code monkeys who were shoved into our throats “because XYZ is our offshore partner and we have to keep them busy”. We are also working with offshore developers, but only with those who can do the job and can read/write the code regardless if it belongs to M, V, or C tiers.

Design patterns were not created equal. It’s OK to bash Singletons.  They are easy to be blamed for being a replacement for global variables. But MVC is still considered to be good.  Unfortunately, it’s not about three tiers any longer. Java architects enjoy creating layers. They’ll be happy to explain anyone how these extra layers will make your application very configurable and flexible. Layers are best friends of consulting firms who have sharpened their skills in creating beautiful powerpoints with nice round-square rectangles filled with color gradients. Thick arrows going from left to right shows how “with our consulting company you’ll move from here to there in just a couple of years”. The arrows must leave no doubts in the minds of hiring managers that “these guys can do it”.

And most importantly, these multi-tiered diagrams will explain the hiring manager of a large corporation that it’s OK that Satish is weak on the front end and Boris never worked with the back end…if you know what I mean. This multi-tiered design can turn both Satish and Boris into code monkeys who will do nothing but inserting their business logic into easy to understand location and the framework will do the rest. Design patterns promote the lowest-denominator-skills software development.

You may be surprised, but even such a sacred cow as dependency injections is not a must. Believe it or not, pretty much any application can be created without DI. I’m not kidding. No XML configuration files to process. Popularity of dependency injection in the middle tier is based on the necessity of integration techniques to allow upgrades and replacement of large pieces of technology with their new implementations. To be fair, I need to praise Java EE 6 for smart and light implementation of DI that doesn’t make you drown in XML.

Applying DI in the front-end applications on top of the frameworks with well designed event model is an overkill on the desktops and suicidal on smart phones and tablets that need to be optimized for memory and speed. We see bigger consultancies still doing it because it is a proven and easy to sell solution. Unfortunately, starting a new Flex project with an analysis of which MVC framework to choose seems to become a habit in enterprises.

My interview statement that writing the code that works is the ultimate goal is applicable only in teams that can afford to employ skilled professionals. If for whatever reason you can’t, go with the flow and rely on injections that somehow will put the collection of Orders into your Customer object.

Finally, to make this blog even more thought provoking, I’ll touch upon yet another sensitive subject. Who do you need to write code for – humans or computers?  On one hand, the code must be readable, cause the same piece of code is being read a lot more often than being written/modified. On the other, the code must be efficient.  For example, in financial trading applications adhering to design patterns is a low priority item. Speed is the king there.
Recently, I showed one chapter of my new Java tutorial to a very experienced Java developer. He was surprised that I included an example of BitSet there. This is what he said – word for word, “Perhaps your experience is different than mine, but I don’t think I’ve ever seen this class used in practice. It really feels a bit old-fashioned, and C-like. In 2010 I’m not sure anyone writing code in Java really worries about this level of saving bits. Maybe it still relevant in some embedded systems, but do those systems actually run Java?”

Ten years ago I was working on developing an equity trading system for a Wall Street company.  It was a J2EE application with a heavy use of messaging. A trading order had to be sent to a queue, and this was an object with about 50 fields with yes/no values.  Using BitSet for sending a set of flags (bits that are set to 1 or 0) instead of text or numbers is the most economical way to do this. Did I care that a programmer who’d be reading my code a year from now won’t immediately understand that just a couple of bytes carried had tons of information about the order? I did not. This piece of code was not readable, but efficient.

IMO, in the ideal world of inhabited by skilled software engineers, the code has to be written for computers. But we don’t live in the perfect world. So I don’t insist.

Yakov Fain

Flex Camp Wall Street – next Monday

A good mix of practitioners and Adobe Evangelists will be presenting on various topics related to using Adobe Flex in the real-world projects. Farata Systems will be represented by Victor Rasputnis and myself. Hope to see you there.

Victor will show you how to generate complete CRUD Adobe Flex/BlazeDS applications based on Hibernate framework on the Java server side. Clear DataBuilder Eclipse plugin will assist us in annotating Java interface without the need to do manual coding and configuration. You will see remote lazy loading of the collections, server-less transactions controlled from the client and, integration with Adobe Fiber – a model-driven development environment of Adobe LCDS… but with BlazeDS.
I’ll talk about making networking of Wall Street applications reliable with BlazeDS. Loosing a trade order is not an option. But using free and open source BlazeDS for Flex/Java communications doesn’t guarantee 100% of all your clients’ orders will reach the destinations. This talk is an overview of networking problems of Flex-BlazeDS enterprise applications with the demo of the error-emulating protocol, which concludes with introducing of reliable AMF channels.

Visit the Web page of Flex Camp Wall Street for more details.

Yakov Fain

The workshop on auto-generation of Flex/BlazeDS/Hibernate CRUD

The workshop on auto-generation of Flex/BlazeDS/Hibernate CRUD with CDB is uploaded in General Docs at Sourceforge https://sourceforge.net/projects/cleartoolkit/

Hibernate support has been introduced in CDB 4.1. If you are interested in SQL or POJO-based generation, stick to the previous version of CDB and refer to the CDB 4.0 workshop PDF, which is also located in General Docs.

I’ve recorded screencasts. The first screencast is about supporting entities in CDB 4.1. It starts from the finished application and then I explain how it was generated. The second one is about using hierarchical collections with entities.


To use or not to use Flash/Flex portals for Web sites

Last week I was thinking about design of the main view of a new project for a new client of ours. This application is interesting in that it can deployed as an enterprise RIA as well as a tool to be used by any consumer connected to the Internet.

The mockup of the main view looks clearly like a Web portal with a number of portlets, which can be maximized, moved around, and independently communicate with the server(s).  But… This Web site has to be discoverable to bring more and more new customers.
Here comes the quiz. Can you see why the previous two paragraphs have an important logical issue, which represents a misconception sitting in minds of many creators of Web content?

Being a Java developer, the JSR 168 is always in my mind and the first annoying thought is, “I can create a traditional HTML/JavaScript Web site with portlets, some of each are Flash Player SWF’s and the others are regular HTML/JS markup. This will give to search engines enough of a textual chew to digest plus the benefits of more animated, engaging, and better performing (sorry, Steve) Flash content”.  If some of you want to bring these dopey and groundless Adobe statements that Google is indexing Flash content with special secret, mighty, but headless Flash Player, please, get real or show me the money.

I know how to create a well looking and performing Flex/Flash based portal. I know how to cut this RIA into pieces, how to run this project, how split the job between team members located all around the globe. I don’t know just one thing – how to make this Flash-based portal d-i-s-c-o-v-e-r-a-b-l-e on the Web.

And here comes the answer to my quiz. Stop confusing Web sites and rich Internet applications! Got it? OK, let me re-phrase it. A Web site and RIA are created for different purposes.  Creating an HTML/JS Web site to present, promote, and make discoverable your RIA is one independent track of your project. And a-f-t-e-r the random user somehow landed on this Web page offer him or her a little link to the real beauty – a Flash-based (sorry, Steve) portal.

That’s all folks. It’s Sunday morning, and I need to go out and get some stuff for the barbecue – having more than 20 people over today.
If you want to discuss it in person, consider attending our Third Annual Enterprise Flex Symposium in New York City. It’s a small event where attendees and presenters can have face-to-face conversations.

Yakov Fain

Enterprise Development with Flex

It’s been almost four months since our book “Enterprise Development with Flex”  been released in print by O’Reilly.  Since day one, it remains in Amazon’s bestseller’s list in several IT categories. This gives me a great feeling given the fact that Amazon re-calculates their stats hourly.
I’d like to share with you some interesting facts that from the times when this book was in its proposal stage. If you carefully look at the book cover, you’ll notice a little logo and the text Adobe Developer Library.  To earn the right to be included in this library our book proposal had to be approved by Adobe engineers. We made it, and are grateful to excellent software engineers from Adobe Flex team, who put their trust in our ability to write such a complex and advanced book.

After the approval process was done, O’Reilly sent us the Flex team members feedback without revealing the names of engineers who wrote them. Most of them were 100% positive. But our special thanks go to one unknown member of Flex team who wrote something like, “I don’t agree with many of the things that these authors write about Flex in their blogs and articles, and I’d rather not approve them, but I will because there are not many people in the industry who are capable of writing such a book.” We don’t know your name, but we consider this assessment to be the best compliment we’ve received so far.

Looking forward to meeting with the members of Adobe Flex team in October at MAX conference.  The authors of this book are going to attend this event in LA in October.

Our praise goes to the O’Reilly cover designers who correctly visualized three authors of this book without ever meeting them in person.

If you bought this book, Farata’s team would really appreciate if you’d spend 10 minutes and publish your review of this book on Amazon. It doesn’t have to be long, but we are looking for getting your honest opinion about our work.

Your truly,
Yakov Fain

Disappointed with Adobe

Was not planning to write this post. It was ignited by the  “Disappointed with Flex” article posted by Valery Silaev, our lead Flex/Java developer.  I’ve been working with Valery on a couple of projects. He’s good software developer. And when he says that he’s disappointed with Flex 4, you should listen.

I really value people who speak up freely and have something to say. Valery is disappointed with Flex 4, but I’d like to take it one step further. I’m disappointed with Adobe.
To put it simple, Adobe is sloooooow. I mean really slow, and I’m not sure what’s the reason.  I know some people from Flex team. They are smart. They can deliver given the right support from top management and proper investment, which is definitely not there.

Let me build the case. Slowly.
Four years ago, when Adobe purchased Macromedia, I was looking for a decent tool for development of the enterprise Web applications.  At that time I was disappointed with Java Swing. Wrong decisions at the top level of Sun Microsystems resulted in having 75% of the computers running Internet Explorer with… ten years old Java run-time. Sun Microsystems won the lousy $10B law suit with Microsoft back in 1998, but lost the battle. Their runtime (yes, the JVM) is not installed at the consumers’ computers.

Four years ago, Adobe’s Flash Player (it’s a VM too) gave me some hope. The runtime was there, the library of rich components  was there too, installing Flash Player was piece of cake. I started working with Flex.

This new for me Flex/Flash community was a bit unusual after Java. It was small.  I had a feeling as if we are in a small country club chanting, “We are the best”.  Flex developers knew each other by names. Adobe Flex technical evangelists were Gods. This was different from Java community of six million of professional developers.

But Adobe didn’t have competition in the area of enterprise rich Internet applications in 2006, 2007, 2008… Until the greatest “Me too” firm from Redmond, WA realized that RIA is the right place to be and IE is not the only browser people have. They started working on this Silverlight thingy. Two years ago they released the 1.0 version that could be ignored – nothing but video streaming was there. At the same time Adobe released Flex 3, which had pretty much everything: 98% penetration of runtime, rich library of components, fast communication protocols, and the server-side component LCDS, that nobody but filthy rich Wall Street firms could afford.

Two years later, Microsoft released three more versions of Silverlight, and the only thing that stopped them from presenting a serious threat to Flex was low penetration of their runtime. Microsoft has tons of cash and excellent engineers. During the same period of time, Adobe has released Flex 4 in hard labor. It took Adobe two years to release the next incomplete version of Flex. Why?

Being a Java developer, I was watching closely the evolution of JavaFX, yet another wannabe player in RIA.  I clearly a similar pattern there. Top-level management proclaims at every keynote that “We are the best” without giving enough juice for engineering teams that work hard developing a product.
The bad guy, Steve Jobs, doesn’t even know what Flex is. He’s not happy with Flash Player. Need to admit, he’s not playing by the rules trying to say that Flash Player is junk and a main reason that crashes the OS. He’s bad, but he’s not stupid. Adobe couldn’t offer a better response than “We love Apple”.

Yes, Flash Player is installed on 98% of desktops, as if we don’t know that not many consumers are using desktops today, and in five years they will become minority.
Steve Jobs, the bad guy, made Adobe moving just a little bit faster and they finally released Flash Player 10.1 in 18 months (!) after the 10.0 release.

Two years for the next and incomplete version of Flex. Eighteen months for 0.1 upgrade of Flash Player. Dumb pricing policy on LCDS that makes it unaffordable for even a small group of loyal customers. Not a Wall Street giant? Get out of here. Is this the way to treat customers?
Let’s get back to the tooling. This smart idea to bring together designers and developer gave birth to yet another prototyping tool called Flash Catalyst. Is it more than just a prototyping tool? Tell me why?

Here comes the Flash Builder (formerly Flex Builder). Flash developers (they haven’t seen any better) were so happy with Flex Builder 3… From the Java developer’s perspective, this was a mediocre and damn slow Eclipse plugin. Flash Builder 4 after two years of development was not a major improvement either. I’m not sure why JetBrains doesn’t want to invest a couple of rubles and add a WYSIWYG designer for Flex. As soon as they do it – Flash Builder is brain dead.

The next target is Flex 4 SDK.   The new Spark library of components with separating the functionality of components and their skinning implemented just half of the components comparing with Flex SDK 3. In two years they could have done better if they were a large company catering for developers.  But they are not. Until Photoshop and PDF remain their main source of revenue, the tooling for software developers will be pushed aside.

Adobe was and remains a small company. They do what they can.  And it doesn’t seem that they can do much more for us, developers.

Yakov Fain
P.S. This is my personal opinion. My employer may think differently.

Where to find enterprise Flex developers?

I’m finishing the third(!) week of teaching Flex. The first half of June I’ll spend doing some regular consulting work, and then another two weeks of corporate training.  The use of Flex technologies is picking up in the corporate world, but hiring managers are clearly facing challenges caused by the lack of qualified software developers on the market.  Solution? Re-train your own people.

Well, it’s not exactly a complete solution, because after a week of training, a senior Java developer becomes a Flex rookie, but at least these people are familiar with business.

Finding a qualified Flex/Java consultant is literally impossible. Enterprise HR managers pretend not knowing that an hourly rate is the only perk consultants  have. Corporations don’t offer competitive rates. Our consultancy has a couple of job requests for Flex/Java consultants from a long term customer from Wall Street, and we’re interviewing people with a little hope to find the right consultants for the money offered for these positions.

Train your own people regardless of what background they have. Recently, I had a student with no practical programming background. I figured it out after he asked me to “explain the benefits of casting”. But this guy was really motivated, and I’m sure he’ll make it.

Our company already has a request to teach Flex to a group of Cobol programmers in September. This should be fun.  The first day should be spent on teaching the concepts of object-oriented programming. So what? Anyone who wants to learn will.

Will the demand for Flex developers sustain? This week I’ve presented at Atlanta Flex User Group.  Here’s one of the questions I got after the talk, “Does your company experience lower demand of Flex consultants in the enterprise world because Flash is not supported on iPhone?”  Absolutely not.  Rich Internet Applications are being developed at full swing regardless of the fences built by Steve Jobs. iPhone is not a threat for the Enterprise RIA.  The only thing that bothers me is the slowness of Adobe in offering new releases of Flex and related tools and technologies.

While everyone is busy talking about the latest news from the iPhone battlefield or how Android is doing, I’m closely watching Microsoft.  As expected, they are becoming the real competition to Adobe in the field of the enterprise RIA. While Adobe is talking about new Designer-Developer workflow, Microsoft implements it. The penetration of Silverlight runtime is over 50%. Give them another year to build up the muscles…

Anyway, are you looking for senior enterprise Flex developers? Me too.

Yakov Fain

How the Flex Framework Cairngorm 2 Died

When a new version of a software is released, the old version lives for a while and its creators usually care about supporting it. Yesterday, after reading about the release of Cairngorm 3, it’s clear that Adobe Consulting ignores this rule.

For those who are not following Cairngorm evolution, I want to remind that there was a framework called Cairngorm 2, that was a library of classes (built on Model-View-Controller architecture) to be included in the Flex application. I never agreed with the architecture of Cairngorm 2 which was acting as a Crazy Glue and lead to generation of monolithic applications based on global singletons. People who follow my writings or were attending my presentations at various conferences know that during the last four years I was openly stating that Cairngorm 2 has more cons than pros. For example, here’s the just one of of these occasions – a video of the panel on enterprise frameworks at Adobe MAX 2008 (after this blog, I doubt that I’ll ever be approved as a MAX speaker again).

Now, when I looked at the design of a product that’s now branded as Cairngorm 3, it’s clear that Adobe assigned to this project the right engineers (i.e. Alex Uhlmann) and there is hope that this methodology (it’s not an MVC framework any longer) may produce or include useful component libraries.

My first problem is that the Cairngorm 2 has literally disappeared from the face of Earth (the only trace found is the site cairngormdocs.org that has some old documentation).

My second, and more serious problem is that Adobe Consulting up till today has never made a statement that selecting Cairngorm 2 was a wrong path. There are lots of enterprises that some time ago started using Cairngorm 2 (recommendation by Adobe Consulting) just to find themselves with a large monolithic application at hand that took long to download and was difficult to modularize.

A couple of years ago, I lead a large enterprise project for a customer that I won’t name, but will provide some relevant technical details. When I joined, the team was already 5 months into the project. This consumer facing application was producing one 5Mb SWF file. Just recompiling the application in Flex Builder was a lengthy project. I started to look at ways of modularizing this application so the first screen would come up sooner than 90 seconds for customers sitting on DSL connections.

Sure enough, the project has been built with Cairngorm 2 by advise of some engineer from Adobe Consulting (not to be confused with Adobe Flex team). The Cairngorm’s global class FrontController is expected to be a registry for all possible events that travel through the system let alone tons of classes and boilerplate code written just to support that life cycle of the framework itself.

My first suggestion was to start modularization with removing Cairngorm. They asked, “How much?” It would take two man-weeks worth of work, but they didn’t have time for this. To make the long story short, we had to modularize the application in a non-kosher way – the main SWF had a knowledge about all events in every module. Changes in a module’s code can lead to changes in the main applications. Tight coupling in action.

I’m sure there are lots of enterprise teams that were similarly misguided and were marching in a wrong direction under the Cairngorm 2 banner.

With the release of Cairngorm 3, the Cairngorm 2 has vanished. I’m sure, if you’ll hire a private eye, you’ll find its code (has not been updated from about three years) in some SVN repository. But this is not how the new version of the enterprise software should be released.
I’d like Adobe Consulting to state loud and clear, “If your team started development of a large enterprise project with Cairngorm 2, please stop. This was our mistake, and the sooner you switch to Cairngorm 3 or any other lighter framework the better.”

Will it happen? Let’s wait and see.

Yakov Fain
P.S. The views and opinions expressed in this blog are purely my own and don’t represent views of my employer