Wood and Glass

In the few spare moments I have to indulge my hobbies, I’ve been working to get my lathe back in order after a several-year hiatus.  During my time away from the lathe, projects ideas have accumulated to the point where I’ve begun writing them down so as not to forget.

Turned works that combine wood with other materials hold a special appeal for me.  This style has been especially vibrant in the pen turning community (for examples, the Penmakers Guild gallery).  A while back, I was thinking about how a turned object might incorporate glass (and how to make it without risking life and limb!).  At the time, I just couldn’t see any practical approach to the problem.  It turns out my thinking was too narrowly confined.

On Friday I picked up the October 2010 issue of American Woodturner, and was fascinated by an article describing the efforts of two artists who have managed to bring wood and glass together in a dramatic way.  Eucled Moore and Marilyn Endres have been collaborating to combine inlaid antique glass beads with segmented turning.   You can see examples of their work at http://www.kazistudio.com/. Some of their works incorporate beads in the 10s of thousands and can take months to produce. 

I’m thinking that something like this, on a much smaller scale, would be a fun collaborative project to do with the kids some rainy day (plentiful this time of year in these parts) .  One more project idea to put on the list!

The Trouble with Spark

Recently I’ve been devising some recommendations for migrating our Flex 3.x applications to Flex 4.0, and upgrading from Flex Builder 3 to Flash Builder 4.  For the most part, this has been a trouble-free experience.  As I would expect, Flash Builder imports Flex Builder projects without difficulty, and so long as compiler options selected carefully, applications look and behave as expected. 

Discussions about Flex 4 invariably turn to the new Spark components, and I’ve been working quite a bit to understand the implications of migrating existing UIs to this new component set.  The result, so far, has been some disillusionment.

Adobe clearly states that skinning is a primary workflow process when dealing with Spark components.  Indeed, the default theme for Spark is very plain – much more so than the Halo theme that shipped with earlier versions of the SDK.

The new skinning architecture enforces a much cleaner separation between form and function.  In Flex 3, buttons were rectangular because this was hardwired into the button component.  The Button class in Spark has no appearance-related code; this has been delegated to the skin and the skin can implement any drawing strategy a developer or designer so chooses.

There is no arguing the elegance of this, but is it too clever?  I should make clear at this point that I am coming at this from an “enterprise” development perspective.  I can imagine that designers and developers who work on applications where user experience is paramount would be overjoyed by the expressive freedom that Spark and the new skinning architecture provides. For the rest of us working on “bread and butter” applications that place function before form, practice iterative development and must meet tight deadlines, these aspects of Spark are more troubling.

Sometimes a rectangular button is ok. The traditional Halo theme isn’t going to win any design awards, but it in many cases it was adequate.  When it wasn’t , we could readily customize appearance through properties and CSS attributes.  When these didn’t meet the need, we employed traditional skinning using vector and binary assets.   Elegant? Not really, but it got the job done. 

With skinnable Spark components, it is almost always necessary to tweak some aspect of a component’s appearance because the default theme is not much more than a wireframe.  In some cases you can get by with CSS, but many of the familiar styles have been removed from Spark – presumably based on the assumption that you’re probably going to write a skin anyway, so why clutter up the API with (appearance) properties and styles.  Fair enough, but this where things really being to go south. 

There are two options for creating Spark skins: using code templates generated by Flash Builder or via one of Adobe’s other design tools, like Catalyst.  The skin template for a button is over 200 lines of MXML code.  There is no skin-specific GUI designer, so a developer must go about modifying fine-level detail by hand, monitoring their progress through the code-compile-run process (we don’t use the designer in Flash Builder too much since our UIs are usually too complex to render properly).  Not productive at all.  Moreover it bloats our maintained code base with lots of boilerplate.  And it smacks of copy-and-paste coding, one of the most egregious code smells.

The practical solution seems to be “buy another Adobe product.”  So I downloaded a trial version of Catalyst.  I’m not (by any stretch of the imagination) a designer, but I was able to get a basic button skin set up without too much trouble.  Flash Builder has a new import feature that allows you to import Catalyst project files, which I did.  The first thing I see is a skin called “Button1” in a package misnamed (IMHO) “components”.  Our code bases are rather large, and this doesn’t fit with our code-organization strategy, so I went back to Catalyst to change the naming to something more meaningful.  I couldn’t.  Ok, so I went back to Flash Builder and just changed it there.  Of course, now I’m out of sync with Catalyst (note: Flash Builder does not know how to maintain Catalyst files – it just imports them into a standard Flex project).  Unfortunately, Catalyst can’t import Flash Builder projects.  So now we find ourselves permanently out of sync with design.  This is even more bizarre when you consider that Adobe’s own documentation indicates that there are a number of properties (notably sizing constraints) that will need to be  manually edited after importing Catalyst projects into Flash Builder.  

It was always my impression that Catalyst was supposed to make designers first-class participants in the development process – something we would very much welcome.  Ironically, the limitations of Catalyst, coupled with the necessity of using this kind of tooling to maintain productivity, have actually increased the separation between design and development (at least in the context of Spark).  How do we achieve iterative development when design coding (and design is coding in Spark) is a one-way trip?  What was Adobe thinking?

There are other issues like maintaining two entirely different styling workflows for “legacy” Flex applications that have mixed Halo and Spark components.  This will be burdensome for both design and development teams.

Anybody still reading would be forgiven for thinking “for heaven’s sake just use Halo then.”  Fair enough, but Adobe’s API docs recommend using Spark components where there is overlap with Halo, and I am concerned that at some point Halo peers will be deprecated.   If this is correct, it would have been better to start the transition earlier rather than later.

Adobe would do well to remember that elegance in development tools rarely wins the race.  Witness the overwhelming popularity of Visual Basic in the pre-web era, and the continued proliferation of frameworks to tame JavaScript.  For many of us, the “best” option is whatever helps is get a product out the door with minimal resources, tooling and fuss.  I’m still learning about Spark, skinning and the tooling ecosystem that surrounds all of this, but my impression so far is that these new features will be more of a liability than asset.

Building an AIR Application with Maven and Flex-Mojos

The flex-mojos documentation is a bit confusing about the level of support it provides for compiling AIR applications, so I’m making a note about this in order to remind myself how this works. 

Building an AIR application using the Flex SDK (as opposed to the Flex Builder IDE) is a two-step process.  You first use a command line utility (amxmlc) to compile source code into a swf file. The amxmlc utility is a wrapper around the mxmlc that simply configures mxmlc to use the AIR compiler configuration file.  It is also possible to use mxmlc (just as you would for a non-AIR application) and specify this parameter yourself.  The second step is to use the adt tool to package the swf as an AIR application and apply a digital certificate to the resulting binary (a requirement for AIR applications).  See the AIR developer documentation for more information about building AIR applications using the SDK tools.

Because AIR applications are compiled using the standard Flex compiler, the flex-mojos plugin can handle the compilation phase without any trouble (as an aside, flex-mojos actually uses the flex-oem-compiler rather than mxmlc, but that’s immaterial for this discussion).  As far as I can tell, what the plugin does not (yet) support is packaging the resulting swf as an AIR executable and applying the digital certificate.  Until the plugin supports this functionality, this step is easily addressed by using another Maven plugin to launch the adt utility.

The plugin documentation states that when compiling an AIR application, the <packaging> element in the pom should be set to aswf, which didn’t work for me.  Instead, I set packaging element to swf and configured the flex-mojo plugin as follows.

<plugin>
  <groupId>info.flex-mojos</groupId>
  <artifactId>flex-compiler-mojo</artifactId>
  <version>2.0M9</version>
  <extensions>true</extensions>
  <configuration>
    <sourceFile>Main.mxml</sourceFile>
    <configFile>${FLEX_HOME}/frameworks/air-config.xml</configFile>
    …
    </configuration>
</plugin>

The <configFile> element is the key to making the plugin compile in AIR mode.  The FLEX_HOME property is something we ask our developers to define in their Maven settings.xml file.  I suspect the need to define this property could be avoided by packaging the Flex SDK tools in a zip file and including them as a dependency in the project, but I just haven’t had time to experiment with that approach yet. 

Running Maven with this plugin alone will result in a swf file being generated that can be run with the adl program that comes with the SDK.  To package the swf as an AIR application and apply the digital certificate, use the Maven Exec plugin (http://mojo.codehaus.org/exec-maven-plugin/):

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <version>1.1-beta-1</version>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>exec</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <executable>java</executable>
    <workingDirectory>${project.build.directory}</workingDirectory>
    <arguments>
      <argument>-jar</argument>
      <argument>${FLEX_HOME}/lib/adt.jar</argument>
      <argument>-package</argument>
      <argument>-storetype</argument>
      <argument>pkcs12</argument>
      <argument>-storepass</argument>
      <argument>secret</argument>
      <argument>-keystore</argument>
      <argument>classes/certs/certificate.p12</argument>
      <argument>-keypass</argument>
      <argument>secret</argument>
      <argument>MyApp.air</argument>
      <argument>classes/Main-app.xml</argument>
      <argument>Main.swf</argument>
    </arguments>
  </configuration>
</plugin>

This assumes you already have a digital certificate; the SDK includes a utility that you can use to generate a self-signed certificate for use prior to final deployment.  One gotcha to note here is that if you don’t supply both the -storepass and the -keypass passwords, the build process will hang. This threw me initially since the only password I had was the one used when creating the digital certificate (and what you specify in the -keypass parameter).  I just used the same password for the -storepass parameter and that got it working.

I’m looking forward to the time when flex-mojos supports an end-to-end AIR build.  It is an otherwise excellent plugin, and it has worked well for us.  In the meantime, this serves as a low-impact workaround.

Technorati Tags: Maven, AIR, Flex, flex-mojos

JavaDoc Images

While updating JavaDoc comments on a class that implements a state machine, I thought it might be useful to include a simple state diagram to illustrate all states and allowed transitions (one picture saves a thousand words, right?).  Generating the image was simple enough, but the real question became how to include it in the JavaDoc comment. Certainly I could use a regular HTML image tag, but finding a place to store the image and making sure that it gets packaged with the JavaDoc was looking like a real hassle.  A few Google searches later, I hit upon a technique for embedding an image inline within an HTML file.  Basically it works like this:

1. Prepare and save your image in whatever browser-compatible format you prefer (png, gif, etc.)
2. Base64 encode the binary file.  If your image doesn’t contain proprietary information, you could use one of the many web pages out there that implement a simple base64 encoder. If that’s not an option, It’s pretty easy to roll your own (Groovy would be a good candidate — see the Byte[] class).  Either way, you’ll need to capture the base64 encoded string.
3. Add an HTML image tag in your JavaDoc comment using the following syntax:
   <img alt=”description” height=”50″ width=”50″ src=”data:image/png;base64,Base64EncodedImageData”/>

Now for the catch: it only works in Firefox, at least right now.  I’ve read speculation that IE8 may support this, but it’s only speculation.  I’ve not had a chance to test this with Google chrome yet.  Browsers that don’t support his should display the text shown in the alt attribute, so at least you can tell viewers to try another browser if they need to see the image.

This technique can be used in any HTML document (not just JavaDoc), but the exclusion of Internet Explorer does limit its usefulness in the broader context.  In our case, most our dev team already uses Firefox, so this solution works out pretty well for us.

Technorati Tags: java, javadoc, inline image

Compact null and equals check

I review a lot of code, and a pattern I often see (and implemented myself more times than I’d care to admit) in servlet code goes something like this:

  if (request.getParameter("someParam") != null
      && request.getParameter("someParameter").equals("someValue")) {
        //do something
  }

It’s a perfectly natural coding pattern; the first check prevents a NullPointerException in the second.   However, in this case, the two checks can be folded into one:

  if ("someValue".equals(request.getParameter("someParam"))) {
    //do something
  }

This works because a null value passed to equals() will cause the method to return false.  It saves one call to getParameter(), and also eliminates the allocation of a String variable which goes unused if the null check in the first example returns a non-null value.

RIA Ecosystems

The company I work for recently made a strategic decision to migrate a flagship application from a legacy presentation technology (Oracle Forms) to Adobe Flex.  The process leading up to that decision consisted of a careful evaluation of a wide range of alternatives besides Flex including Windows Forms (.Net), Java Swing, DHTML/Ajax, Silverlight and JavaFX.  Our team had experience with all of these options except for the last two.

Our reasons for settling on Flex were many, but I found it interesting that one of the most compelling factors was something that has propelled our Java strategy in the middle tier — the rich ecosystem of supporting technologies and tools that surrounds the core platform.  Java the language is starting to look a bit long in the tooth these days, but we stick with it because the platform is surrounded by a vast collection of libraries and tools to address the myriad development challenges that we all run into.  There are tools (both from Sun ad the open source/commercial communities) to enhance virtually all aspects of development and deployment.  Indeed, it is often a challenge keeping up with all that’s out there. 

Though more limited in scale right now, there are signs that a similar phenomena may be happening with Flex.  To get a sense of this, consider some of the ecosystem-type things that we’ve observed in the Flex world:

• Automation Libraries: This is one of those “lesser known but potentially killer” features of Flex.  Adobe added an automation library in version?? of Flex which allows UI components to be driven by an eternal program.  Using tools like RIATest or QuickTest that hook into this layer, our QA department will be able to greatly extend the reach of their automated testing efforts.
• BlazeDS: An integration library that greatly simplifies integrating Flex with a Java-based middle tier application.  A key feature for us is an automated mapping layer that converts Java objects to ActionScript equivalents (and vice versa). This feature greatly enhances an RPC-like mechanism that allows Flex applications to invoke methods on Java objects in the middle tier.  Just as important for our needs has been a seamless integration layer with JMS compatible messaging servers in the middle tier.  Moreover, all of this interaction is done via HTTP (or HTTPS), which keeps deployment hassles to a minimum. Public release of the AMF specification (the wire protocol used to transfer data between client and server) has spurred the development of similar products for server-side applications running in PHP, Ruby and Python.
• Third party libraries and controls:  The Flex platform is well positioned to draw from an already-large community of Flash developers making the transition to Flex. 
• Unit Testing: There are several libraries available to facilitate unit testing using the xUnit patterns familiar to developers.  FlexUnit is the Adobe-sponsored unit testing library.
• Ant and Maven Integration:  In the enterprise world at least, Flex applications rarely live in isolation, and I’ve never worked in a shop that relied on an IDE for production builds.  One touch builds, automated builds and continuous integration are the watchwords of the enterprise development world, and Flex can play very nicely in this space.  Flex has long had a set of Ant tasks to drive Flex compilation from Ant.  More recently, we have observed a number of Maven projects designed to integrate Flex into a larger build process.  We’ve been especially impressed with one of the newer efforts, Flex-mojos.
• IDE support:  Adobe’s IDE is a plugin based on the Eclipse platform.  If you come from a Java development background using Eclipse, Netbeans or IntelliJ, Flex Builder is a bit disappointing.  To be fair, it’s a relatively young IDE and it’s certainly better than a text editor.  But for a product driven by a company the size of Adobe and commercial to boot, I really expect better especially given how powerful the underlying Eclipse platform is.  IntelliJ has had some level of Flex support in their IDE for a little while now, although I’ve not actually tried it.  Personally, I’m waiting for Netbeans support; it may be in vain, since as best I can tell there is only a fledgling project on SourceForge.  Still, I remain optimistic given the recent successes they’ve had extending the Netbeans 6.x platform to handle Ruby, Groovy and most recently, PHP.  Regardless, choice is good.

Hopefully the trend will continue.   We have not, to date, seen a similar community rallying around Silverlight or JavaFX.  Of course, Flex has a huge lead over both of these alternatives right now by virtue of its (relative) longevity.  JavaFX isn’t even out of the starting gate, and it’s still not quite clear what it wants to be when it grows up.  Silverlight’s future will be interesting to watch, but it’s facing a decidedly uphill battle against the established Flash install base.  More and more, it seems that support of the open source community is a critical element to success of a technology platform.  Yet the open source efforts around .Net in general have been modest at best.

Hard to speculate on who will come out on top of all of this, and as years of browser wars have demonstrated, there’s room for more than one big player.  In there here and now though, Flex is miles ahead of the pack.

Technorati Tags: Flex, RIA, Java, Programming

Tribute to Mary

During March of 2007, my wife called me at work with news we had be dreading. Her biopsy had come back, and she had breast cancer. It was advanced (stage 3/4) and had spread to the lymphatic system. Our lives literally changed overnight, and within 48 hours I was by her side at Overlake Hospital while she underwent the first of many chemotherapy treatments.

I watched her go through chemo, surgery and radiation treatments, and through it all she faced each challenge with her usual indefatigable spirit. Mary resolved early on that she was going to continue working during her treatment. Needless to say, I was concerned about this, as she teaches high school math and is on her feet all the time. On the other hand, she is not someone who deals well with being idle, so I left it to her. She managed to finish out the year, though towards the end she would practically have to drag herself out the door. We scheduled her surgery during summer vacation, and it came and went as expected. The final course of treatment was radiation. After surgery, we I think we lulled ourselves into thinking that this last phase would be a breeze. It was anything but. The only way I can describe it is to imagine someone setting your spouse’s midsection on fire. Each evening we would embark on a 15-30 minute ritual of cleansing, medicating and bandaging. From the expressions on her face, I knew she was experiencing incredible pain, but she would always remain composed.

At times, the physical effects of cancer pale in comparison to the emotional impact. One thing Mary and I share is a fairly clear vision of where we’re going in life, but for once it seemed impossible to anticipate what the next day would bring. There were issues that that were hard to discuss. There were questions that were too hard to ask. We have two children — now 4yrs and 2yrs. The youngest was blissfully unaware, but the oldest most certainly knew something was wrong, but Mary always did her best to assuage his concerns no matter how poorly she felt.

Almost a year later, and she is now cancer free. We continue the periodic testing that all cancer patients learn to live with which carries its own set of stresses, but we’re glad that we’re able to face this stage.

Anyone who has watched their wife give birth is forever in awe of a woman’s strength. But in reality I had no idea just how strong she really was until I watched her go through this.

I’ve felt somewhat uncomfortable writing this because I don’t feel I am capable of adequately conveying her strength and courage through all of this. Still, I hope it has come through in some way.

I love you Mary.

Technorati Tags: Breast Cancer, Courage

OSGi: Introductory Series

Perhaps one of the greatest things about researching on your own is the freedom to wander from idea to idea with complete abandon.  Today, my wanderings among the fields and pastures of distributed computing have lead me to OSGi.  I like simple overviews, and I came across a really nice series of introductory articles published on EclipseZone by Neil Bartlett.  It’s a bit hard to track down all of the articles as a complete set on EclipseZone, and Neil has kindly assembled links to all of the articles on his personal blog.

Jini

Following on my earlier post, I am well through Jan Newmarch’s book on Jini and it has had the exact effect I had hoped for: it’s causing me to reflect on how I could have approached certain application design problems differently.  When a book causes me to self-critique, it’s definitely a worthwhile read.  Also, thanks to a recent high-cholesterol diagnosis, I have also started to re-listen to the Java Posse interview with Van Simmons during my new early morning walking routine (silver lining to every cloud… ).

The concept of portable data and behavior has undeniable appeal.  I’m still at the stage where my mind is wandering in all sorts of directions, filled with many thoughts (some no doubt tempered by lingering misunderstandings about Jini).

One of the more interesting things I’ve been turning over in my head is how this concept could be applied in a cross-runtime environment (e.g. code originating from a Java-based application that is downloaded to a .Net runtime).  I’ve worked my way to a lot of dead-ends, but it’s interesting to ponder (e.g. what happens when the serialized data and behavior is in a form that both runtimes understand, like ECMAScript?).  Has this concept always been the vision of Linda?

Coming from (primarily) a J2EE background, it’s also somewhat unsettling to discover that Jini may offer a much more elegant alternative to some aspects of traditional J2EE application components, particularly session beans and message-driven beans (well, MDBs used within a local, homogeneous environment).

So, continuing on with the learning journey, I am looking to supplement my understanding of tuple spaces.  I have dug up some material associated with Linda, but I’m finding it slow going. I do wish the JavaSpaces book wasn’t quite so dated, but then again I guess the concepts underlying tuple spaces in general haven’t changed much over the years. 

Technorati Tags: Jini, Distributed Computing, Tuple Spaces

Distributed Computing

So, I find myself with the rare luxury of having a little spare time on my hands these days.  It’s an ideal time to learn something new, and I’ve been poking around for a new intellectual challenge.  I’ve long intended to learn more about Jini (well, I guess it’s now known as Apache River), and distributed/grid computing in general, and there’s probably no time like the present to do so! 

The dilemma with these sorts of things is balancing my tendency to wander into more esoteric areas of computer science with the need to keep up with other, more practical (if not more mundane) aspects of the profession.  Based on what I have read, and trends I have observed over the years, I can’t help but think that this will have more widespread practical application at some point in the future. 

I’m beginning my explorations with Jan Newmarch’s book, Dan Creswell’s blog and a few other resources.  I also intend to re-listen to the the JavaPosse’s interview with Van Simmons (part 1, part 2, part 3) back in the fall of 2006,  a fascinating discussion about the practical application of this group of technologies.

If anyone has any other pointers to some solid information about Jini or related things like JavaSpaces, I would really like to hear from you!

Technorati Tags: Jini, Apache River, Grid Computing, Distributed Computing, JavaSpaces