My blog has moved

I’ve been working on a new blog called Experience Craftsmanship. For here on in that’s where I will be blogging, so jump over and join me there.

MAX 2010 – Day 1 – It’s all about the screen

It’s all about the screen. There is an explosion of new devices and screens. The desktop, phone, tablet and TV. Multiply that by the various screen sizes and we have a challenge confronting us, but the opportunity for innovation is endless. Specifically, it is interesting to see the various tablets coming on to the market and the different screen sizes. Who got it right or is there room for a range of sizes?

I am blown away by how well Adobe is positioned to own the screen. Flash really is everywhere. The product team has done a tremendous job making it available on all these devices and  adapting and optimizing it for the hardware.

Where’s there is Flash there is AIR. If Flash is our trojan horse then AIR is our army. Its ever expanding APIs make it easy to develop applications that are specific for the device by allowing us to leverage their individual capabilities.

It’s just so easy!

You can start building multi-screen applications today by downloading Flash Builder “Burritto”.

There are also significant improvements for designer-developer workflow, which you can use in Flash Catalyst “Panini”.

.

My First Mosaic Application

Adobe LiveCycle Mosaic is a recent addition to the LiveCycle family that offers some interesting possibilities in the enterprise. As many of us experience when developing large enterprise applications we need to start thinking about modularization for performance or to segment the application to allow development teams to work on independent areas.

To get an application in to production for the first time requires a lot of resources, especially if compliance is required, for example FDA software validation. However, we rarely stop once the application go-lives. We want to release new features and modules, but we don’t want to re-test the whole application. There is a new version of the Flex SDK that we want to use, but we don’t want to migrate the entire codebase. So we think about using the Marshall Plan.

We are dealing with a lot of complexity and big architectural decisions. Mosaic helps to remove the complexity by providing an application framework for building and deploying composite applications. It also provides tooling for Flash Builder to improve developer productivity.

What follows is three steps to walk you through building your first Mosaic application. From there you can explore Mosaic in more depth so you can start using it as part of your enterprise architecture for building scalable and extensible Rich Internet Applications (RIAs).

Prerequisites

  • Flash Builder 4 (I recommend using the Eclipse plugins with Eclipse for Java EE Developers)
  • Apache Ant

Step 1: Getting Mosaic running

  • Download the Mosaic trial
  • Extract the Mosaic download (if not auto extracted)
  • Open a command prompt and change directory to where you extracted Mosaic (<MOSAIC_HOME>)
  • Change directory to <MOSAIC_HOME>/standalone
  • Create a logs directory (e.g. mkdir logs)
  • Change directory to <MOSAIC_HOME>/standalone/bin
  • Run startup.sh / startup.bat (if running Mac OS X or Linux you may need to change the permissions on your files – chmod 755 *.sh)
  • Start a browser and open http://localhost:8080/mosaic/about, when promoted to log in enter designer/password
  • If you see the Adobe copyright and Mosaic version then Mosaic is running!

Step 2: Install and run the samples

  • At the command prompt change directory to <MOSAIC_HOME>/samples
  • Run ant (enter ant at the command line)
  • Ant should run for ~9 seconds and you should see BUILD SUCCESSFUL
  • In your browser open http://localhost:8080/mosaic/#/applications/Basic
  • You should see your first Mosaic application
  • Now try the AIR client, run <MOSAIC_HOME>/bin/release/Mosaic.air
  • Take the time to explore the other samples, the table at the bottom of this page has all the URLs

Step 3: Build your first Mosaic application

  • Download the Mosaic ES2 plugin for Flash Builder 4
  • Start Flash Builder (Eclipse)
  • Go to Help > Install New Software…
  • Press the Add… button
  • Enter a name e.g. Mosaic
  • Press the Local… button and select the folder containing your Mosaic plugin folder (assuming your download was auto extracted)

  • Press the OK button
  • Check Adobe LiveCycle RIA Tooling

  • Press the Next button and follow the wizard to install the plugin
  • Create a new Flex Application (File > New > Flex Project)
  • Create a new MXML Tile (File > New > MXML Tile)

  • Press the Finish button
  • When prompted to Confirm Project Changes press the Yes button

  • Update your tile to show the obligatory Hello World:

  • Open the Run Configurations (Run > Run Configurations…)
  • Select Mosaic Launcher
  • Press the New button
  • Make sure your Project and Tile are selected

  • You should now see your first Mosaic application!
  • You will find more details of using the plugin and debugging here

Additional Resources

Adobe wins Blue Button through User Experience

The Adobe User Experience team created the vision demo that won the Blue Button challenge for managing health records.

You can read more about Adobe and Blue Button here.

LCDS Security

Every major release of LCDS goes through an external security audit, you can view the report in the LCDS product PDF portfolio (the portfolio also includes a great performance brief).

The LCDS attack surface is very small, but there are a number of things to consider:

  • Use AMF in production (also consider AMF for performance as it is better at handling large complex Object graphs).
  • If you are using AMFX use LCDS 3.1, which fixes a number of known XML vulnerabilities. If you are unable to upgrade to LCDS 3.1 then you should apply this security patch.
  • Use secure channels (refer to Using LiveCycle Data Services ES2 Version 3.1).
  • If you are using the proxy service then secure it as per this post.
  • If you are concerned about XSS attacks then validate incoming client data using a custom queue processor (refer to Using LiveCycle Data Services ES2 Version 3.1).
  • Try to ensure end users are on the latest Flash player.
  • Ensure RDS is not enabled in production (comment out the RDSDispatchServlet in web.xml).
  • Make sure your app server is secure per best practices of the vendor (you should also look at Hardening and Security for LiveCycle ES, which provides some general recommendations).

There are a number of useful resources that discuss securtiy:

The following tools can be used to help find and fix security vulnerabilities:

Clean Code Starts in Sprint 1

From my experience whatever you do in Sprint 1 dictates the success of your project. If you opt for a running start and ignore practices such as TDD, Pair Programming, Automation, and Refactoring then your velocity won’t account for them. You face a similar challenge if you have a herculean Sprint 1. Whatever you do sets an expectation with the customer – the velocity achieved in Sprint 1 sets an expectation of what can be achieved in future Sprints. It is incredibly difficult to reset that expectation as your velocity will dip if you decided to start Refactoring or doing TDD or working a 40 hour week.

As professionals we have a responsibility to write clean code from the start. The customer may feel we are moving slowly but we are investing in the future maintainability of the software. Through TDD we are building testable software and providing the team with the confidence to Refactor. In turn Refactoring allows us to evolve our design so they remains simple. The story is similar for the other practices of professional software engineering.

As the software grows the teams has pride in the software they are engineering. The quality is high and its easy to change the software as new requirements are implemented. In the end customer satisfaction is high, why wouldn’t you practice TDD and Refactoring from day-1?

Use of Stage Events

**The Problem**
I was recently asked to look at an application problem around stage events. The problem we were seeing is when the application was resized the **removedFromStage** event and the **addedToStage** event were being fired. This was causing unexpected behavior in the application as there was application logic attached to these events.

Continue reading…

Come work for Adobe

This is a really exciting year for Adobe Professional Services as we are growing! We are building out a Solution Center in San Jose, which requires a team of talented Software Engineers and Quality Engineers. You will be part of a co-located team in a fantastic office space that has been purposely designed to foster teaming and collaboration. You will get the opportunity to work on some of the most exciting and challenging projects that fuse user-experience design with great technology implementation. During my time at Adobe I have had the opportunity to work on projects for clients such as NATO where we built a Mission Support System for AWACS that supports the real-time synchronization of map data.

screenshot.png

If you are a talented software craftsman who has a strong background in enterprise software engineering then we want to hear from you. There is no prerequisite to know Adobe’s technology, although it would be nice, if you are steeped in OO and advocate practices such as Test Driven Development and Refactoring then we will train you in Flex/AIR, LiveCycle Data Services and LiveCycle ES.

We also want to hear from you if you are a leader in Quality Engineering, we need people who can lead the team on process and practice. Ideally you will have strong hands-on experience of all aspects of Quality Engineering such as black-box testing, white-box testing, automation, performance testing and load testing.

In both the above roles a working knowledge of Scrum is a huge plus.

If you want to be part of our team then drop an email to “pmartin@adobe.com”:mailto:pmartin@adobe.com.

The pyramid approach to quality software

**Introduction**

I recently read a blog post from Mike Cohn on “The Forgotten Layer of the Test Automation Pyramid”:http://blog.mountaingoatsoftware.com/the-forgotten-layer-of-the-test-automation-pyramid. I thought this was a great way to conceptualize the different forms of testing and their combined value.

Continue reading…

Design by Contract

I first read about Design by Contract in the book “Object-Orientated Software Construction by Bertrand Meyer”:http://www.amazon.co.uk/Object-oriented-Software-Construction-Prentice-Hall-Resource/dp/0136291554/ref=sr_1_1?ie=UTF8&s=books&qid=1219866553&sr=8-1. Chapter 11 discusses Design by Contract: building reliable software:

_”Assertions and the associated concepts, explained in this chapter, provide some of the answers. Although not foolproof, the mechanisms presented below provide the programmer with essential tools for expressing and validating correctness arguments. The key concept will be Design by Contract: viewing the relationship between a class and its clients as a formal agreement, expressing each party’s rights and obligations. Only through such a precise definition of every module’s claims and responsibilities can we hope to attain a significant degree of trust in large software systems.”_

I also want to cite another great book that has gained favor with many of my peers, “Clean Code: A Handbook of Agile Software Craftmanship by Robert C. Martin”:http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&s=books&qid=1267554535&sr=8-1. Chapter 7 discusses Error Handling and promotes that we don’t return null from methods and nor should we pass null to methods as both invite errors. As it says in the book _”all it takes is one missing null check to send an application spinning out of control”_.

I first used Design by Contract in the late 90′s and the results were dramatic. We saw a big improvement in code quality as we were thinking about the contract between a method and its caller. In the Java world we now have a number of mature Design by Contract libraries such as Contract4J. Take a look at it discusses the theory in more detail than I am.

A while back I created an over-simplified library for ActionScript. It’s really, really simple. There is one main class, Contract, that you can use to assert pre and post-conditions.

It works off a compiler argument (**-define=CONFIG::debugging,true**), for development set it to **true** and your assertions will be checked. For production, set it **false** and your assertions are not checked.

It’s simple but effective. Download it “here”:http://blogs.adobe.com/pmartin/code/Contract.zip.