jonr originally posted this on Jon Rose's Blog.

In the past, I have reviewed a number of the popular frameworks commonly used with Adobe Flex (Flight, Clear Toolkit, Cairngorm, PureMVC, Mate, and Swiz).  At Gorilla Logic, we love to debate the merits of each of these frameworks and the MVC pattern in general.  As an enterprise software development shop, we love architectural things and enjoy being as geeky as possible.  Yet, we continue to be a bit confused with the industry’s over infatuation with MVC and frameworks that exist simply to enforce this pattern (or similar patterns).  So, I started down the path of contemplating what would make up the perfect Flex framework…

Over the last decade, most web frameworks in enterprise development seem to just focus on the architectural piece of the puzzle, which actually provides the least value to those tasked with building real applications.  Look at the vast majority of Java frameworks that do not even attempt to provide a built-in set of components.  Also, in the Flex ecosystem, virtually all the major third party Flex frameworks seem to exist with the primary purpose of enforcing / enabling the MVC pattern, with the notable exception of the Clear Toolkit, which provides an interesting set of enterprise features.

Flex brought on a revolution because it exists first and foremost to make developers highly productive in building cool applications.  Thus, Flex is a complete platform, and is often the only framework needed for building real applications.  It provides the pieces for building within the MVC architecture and a full set of components that meet many of the requirements found in enterprise applications.  When looking at any portion of application development, engineers should only be bringing in tools that specifically satisfy the stakeholder’s functional and non-functional requirements, or address risks specifically outlined for the project.  With the strength of the Flex platform, one should not start with the assumption that they need to add in third party frameworks.

That said, Flex does have weaknesses and can be improved upon or extended in interesting and useful ways.  Also, it can be helpful to have infrastructure that supports developers in properly separating concerns within the application code.  Frankly, if the costs of adopting a third party framework to get this infrastructure is low, then there is no reason to fight against bringing in an outside solution.  Let’s look at a few of the Flex frameworks to see how they measure up in this respect:

Cairngorm: The cost of adoption and long-term ownership is too high, with the high volume of code required for implementing even the most trivial feature, for one to seriously consider this as an option.  The leverage just is not here.
Mate: Mate addresses separation of concerns by providing developers a global event bus for handling events.  This approach fits well with the real way Flex applications are built.  Although, I tend to believe that not all events are global and likely do not all need to be externalized, but this is certainly an important piece of the puzzle.  With a reasonable technical approach to managing events, the overall cost of adopting Mate is low.
Swiz: Swiz is similar to Mate in that it has a limited surface area for developers to learn.  Its primary mechanism for separating things out is the use of dependency injection.  It is fairly elegant in its syntax and easy to use.

While two of the three outlined above are low cost to adopt, they are also limited in the number of problems they solve for a Flex developer.  That’s really what this post is about – working through where the leverage is/should/could/would be in the Perfect Flex Framework.  In part two, I make an initial attempt at providing my requirements for the perfect third-party framework.

admin originally posted this on EricDaugherty.com.

I have participated in more than one fiasco. A close friend (and excellent developer) friend of mine is doing so now. These are generally “successful projects” in most senses of the word, except for one key fact: they don’t deliver anything new, at a cost of several tens or even hundreds of thousands of dollars.

admin originally posted this on EricDaugherty.com.

admin originally posted this on EricDaugherty.com.

jonr originally posted this on Jon Rose's Blog.

As geeks, we love to dive head first into technical challenges, and yet, we are often less interested in learning the business domain and engrossing ourselves in solving the little peoples’ pains, you know, the users.  Focusing on them can have a number of negative effects on us, like having to write code that doesn’t challenge us, or even worse, “What if it doesn’t add anything new to my resume?”

So, we put on our senior engineer hat and plow to the front of our geek kingdom, asserting that we must develop significant long-term infrastructure in the system because it will save the company thousands, if not millions, of dollars down the road.  The infrastructure is not needed to satisfy the agreed upon use cases for this release, but it’s so important that the team would be crazy to omit the work we are proposing from this iteration.  We are so convinced of our own superior planning and genius, that we are unconcerned if no one has recognized how much pain we are saving them from yet, or that it has put the project behind schedule.  They will see some day…

Throughout the industry services are often closely identified with Service Oriented Architecture (SOA).  There is a wealth of quality architectural thinking within the SOA world.  However, there are some fundamental issues that have propagated throughout large parts of the software development industry because of the underlying philosophies found in SOA.

A central theme of the SOA development paradigm is the focus on reuse.  Software developers with even the shoddiest training have been taught to place enormous importance on reuse, where logic is modularized in a single place and used over-and-over.  So, there is nothing unusual about the SOA assertion that services should be loosely coupled and designed to support numerous clients.

A major challenge is that services in a Service Oriented architecture must also be built to support clients that have not yet been formally defined through a requirements process, or even yet conceived.  In seemingly countless instances, this has led to teams completely over emphasizing the reuse of the services being built, while immediate functional requirements are often missed, not completely supported, or in the worst cases blatantly ignored.

Pragmatic software architects recognize the considerable pain the industry has experienced from projects that over-accentuate one software tenet (reuse), while ignoring others.  Overly generic services frequently lead to extended development schedules, and in some cases they are fatal to the entire project. The blame for this trend is not SOA itself of course, but software engineers taking a good concept and overusing it until it becomes a liability.

There are absolutely cases where reuse is the chief priority for the service implementers.  A common example is creating a true, public API, such as a travel booking service developing integration endpoints for their present or future partners.  Or, for an internal IT example, consider the case where the system holding the source of customer records needs to expose the data to multiple systems throughout the organization, and a reusable service is required.  These cases are limited though.  In particular, they are most rare in IT shops, where the insanity of completely over-emphasizing reuse can be at its highest.

Quality architects avoid this trap by working with the following understanding:

• Risks should be identified.
• The business domain should be captured through the requirements process and implemented in its own layer.
• The implementation should only include things that address specific project risks that have been identified or satisfy the functional requirements of the system.

Thus, the system should be built for the immediate needs, unless there is a priority placed on the future in the business requirements, or the project’s owners specifically dictate this as a priority.

Reality check: It is not your money! Building a software system should be focused on the urgent needs of the organization, unless the team is clearly directed to focus on other priorities, which is rare.

admin originally posted this on Saturnboy.

The dream of SVG was probably born sometime in the late 90’s. Version 1.0 arrived in 2001, followed by the current version, SVG 1.1, in 2003. For anyone keeping score at home, that’s over 6 years ago, which is like 120 years ago in internet dog years. Also for those at home, SVG is a portable XML-based vector graphics format (it also does raster graphics), but you’d probably not be reading this if you didn’t already know.

Nowadays, I’m finally seeing some SVG in use. It works natively in all the real browsers (obviously not IE, which requires a plugin), and even on some mobile devices. But most importantly to me, I see it in my day-to-day work in Degrafa, and with the beta release of Flex 4, in Catalyst and FXG.

The vast majority of my experience in SVG is with paths (SVG Spec, § 8) and to a lesser extent Transforms (§ 7) and Filters (§ 15). Thankfully, these are some of the most useful and important pieces of SVG, and they all have nice one-to-one mappings to components in Degrafa and FXG.

SVG Path Primer

In SVG, a path is the outline of some object. It is described as a series of segments, where each segment can be different, either a line, curve, or arc. Path data is most often given in shorthand syntax as a series of commands followed by coordinates (we’ll ignore the long form for now). Let’s illuminate the discussion with some examples.

SVG:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
    "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1"
    width="200" height="200">
  <path d="M 0,0 L 100,0 L 100,100 L 0,100 z"
      fill="#EECCEE"
      stroke="#FF00FF"
      stroke-width="3" />
</svg>

Degrafa in Flex 3:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
        xmlns:mx="http://www.adobe.com/2006/mxml"
        xmlns:Degrafa="http://www.degrafa.com/2007"
        layout="absolute">
 
    <Degrafa:GeometryComposition graphicsTarget="{[cnv]}">
        <Degrafa:Path data="M 0,0 L 100,0 L 100,100 L 0,100 z">
	        <Degrafa:fill>
	            <Degrafa:SolidFill color="#EECCEE" />
	        </Degrafa:fill>
	        <Degrafa:stroke>
	            <Degrafa:SolidStroke color="#FF00FF" weight="3" />
	        </Degrafa:stroke>
        </Degrafa:Path>
    </Degrafa:GeometryComposition>
 
    <mx:Canvas id="cnv" />
</mx:Application>

MXML Graphics (aka FXG) in Flex 4:

<?xml version="1.0" encoding="utf-8"?>
<s:Application
        xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark"
        xmlns:mx="library://ns.adobe.com/flex/halo">
 
    <s:Graphic>
        <s:Path data="M 0,0 L 100,0 L 100,100 L 0,100 z">
            <s:fill>
                <mx:SolidColor color="#EECCEE" />
            </s:fill>
            <s:stroke>
                <mx:SolidColorStroke color="#FF00FF" weight="3" />
            </s:stroke>
        </s:Path>
    </s:Graphic>
</s:Application>

The examples above use the shorthand path syntax to draw a 100px square that starts at the coordinate origin (0,0), which is the upper left corner in SVG and Flex. Beware the coordinate origin when translating Inkscape SVG to Flex. The other interesting thing to note is the amazing similarity between Degrafa and FXG. Who knew all my time learning Degrafa will instantly translate to Flex 4 and FXG? Awesome!

SVG Path Shorthand

Here’s a quick overview of shorthand syntax for SVG path data:

Alas, the beta version of FXG does not support the Arc segment type, which I suspect is due to lack of support for arbitrary arcs in the underlying Flash Player rendering engine but I don’t know for sure. Thankfully, Degrafa offers full arc support (thanks Greg!). If you really need to draw arcs in FXG, for stuff like pie wedges, and are unafraid of getting into a cage match with your trigonometry textbook, you can do a good job approximating arcs with cubic Bezier curves. Alternately, you can just use Degrafa once it gets ported to Flex 4. Lastly, using uppercase for the segment type specifies absolute coordinates. This is the format commonly used by Illustrator and Inkscape when exporting drawings to SVG. One can easily switch to relative coordinates by just switching the commands to lowercase, but I would try to avoid it if at all possible as it tends to make one’s head hurt.

The Many Shapes of a Square

All of the squares above, use this shorthand data:

M 0,0 L 100,0 L 100,100 L 0,100 z

First, a Move to set the pen at the origin. Then, a Line right to (100,0), followed by a Line down to (100,100), followed by a Line left to (0,100). Then, a close (z) to return to the origin.

I can drop the commas if I want:

M 0 0 L 100 0 L 100 100 L 0 100 z

Or drop all but the first Line to make a polyline:

M 0,0 L 100,0 100,100 0,100 z

Or use Horizontal Line and Vertical Line:

M 0,0 H 100 V 100 H 0 z

Or even use relative coordinate (which makes my head hurt a little):

m 0,0 l 100,0 l 0,100 l -100,0 z

Curves

Straight lines are cool, but the real fun in life lies in the curves. Cubic Bezier curves should be very familiar to anyone who’s used a vector drawing program. Let’s replace the first segment in our square with a cubic Bezier segment. Now, the SVG shorthand becomes:

M 0,0 C 25,-25 50,25 100,0 L 100,100 L 0,100 z

When rendered, we get this:

The shorthand command says curve to (100,0), but start out heading towards control point #1 at (25,-25) and end up coming in from control point #2 at (50,25).

Arcs

Again, let’s replace the first segment in our square with an arc segment. Now, the SVG shorthand becomes:

M 0,0 A 50,25 0 0,1 100,0 L 100,100 L 0,100 z

When rendered, we get this:

The shorthand command says arc to (100,0), with an x-radius of 50 and a y-radius of 25, with a rotation of 0. The large-arc and sweep flags are a little confusing so you’ll want to review the SVG Spec, § 8.3.8 if you need to get down and dirty with arcs.

Conclusion

I’m a firm believer in “right tool for the job.” So, when in comes to getting SVG path data into Flex, I’m definitely going to use Illustrator or Inkscape as much as possible, and in the future I might just use Catalyst for everything. But there are a few important situations where the Flex developer absolutely must know SVG. First, if you want to do any kind of path morphing (like this), you’ll need precision control over your path segments. And second, if you want to do any dynamic path generation (like building a multi-level radial menu on the fly – which sounds like a good topic for a future post), you’ll need to manually construct your SVG paths.

Files

• square-path.svg
• square-curve.svg
• square-arc.svg

jonr originally posted this on FlexMonkey :: Flex UI Testing Tool.

You can check out Stu Stern discussing FlexMonkey on a recent episode of the Speak Rich podcast from RIA Revolution. Thanks to Shashank Tiwari for interviewing Stu and covering Gorilla Logic’s favorite testing tool, FlexMonkey.  Enjoy the podcast!

jonr originally posted this on Jon Rose's Blog.

A while back I started to put together a list of cases where it might be better to avoid using Flex and/or AIR, but never posted it.  I ended up concluding that most of the issues can be addressed if Flex is a fit otherwise.  I have never been an engineer that believes that any one technology is a fit for all cases.  The other side of that coin is that I don’t believe that any platform is perfect, and you have to accept the pitfalls of whatever you choose.

Anyhow, I decided I should dust it off and put it out there.  If, for no other purpose, than to have a good reason to post the facetious list I wrote up to go with it.

Here is the list of potential issues:

1. The iPhone:
   If you are building an application that must be available on every platform, including ones that have not been created or released yet, then targeting the Flash platform is not ideal.  That said, the notion of the platform that is portable across all types of devices and form factors comes up frequently, but in most cases it is entirely unrealistic and undesirable to build real applications with this approach.  A better approach is to build applications tailored to each specific device (or at least each genre), such as a native iPhone application with features tailored to a mobile device.
   
   So, in this case the iPhone is symbolic of platforms that do not support Flash and have no published roadmap for supporting 3rd party runtimes.  If you are building an application that truly has the requirement of being the same application on the desktop and every mobile device (which certainly exist), then using Flash is a no go.  In many of these cases, standard browser technologies are the default option (HTML, CSS, and JavaScript).  RIA features can be added by using frameworks like GWT.
2. Search:
   In 2008, Adobe announced their collaboration with Google and Yahoo to make Flash content searchable.  The ability for major search engines to craw a SWF file is a nice step forward.  Yet, if you have consumer-facing content that must be searchable, then it may be best to avoid RIA features in general (not just Flex).  The search paradigm is heavily dependant on the page-based model.  It is a major challenge to build rich applications that can be entered from any direction and properly reconstitute their state.
3. Low Bandwidth Clients:
   If you are building a system that potentially services a large volume of low bandwidth users, then Flex can present some challenges.  The compiled applications are typically quite sizeable.  Flex does allow for breaking up the applications with runtime-shared-libraries (RSL’s).  With that approach, the Flex SDK still has to be downloaded (just not over-and-over).  So, trying to using Flex in this case is a bit of a stretch.
   
   AIR can actually present some real opportunities with offline clients.  For example, Parleys.com has reported that low-bandwidth clients love their application because it can download videos overnight for viewing offline.
4. Content Centric Applications: 
   There is a class of content centric applications that fit the hyperlink paradigm and should never be made into RIAs, such as Wikipedia and Craigslist.  Certainly, there are a number of applications that combine heavy content along with the need for a number of advanced RIA features.  In those cases, Flex / Flash has presented real challenges because of its limited ability to deal with large bodies of text.  Many of these limitations are being addressed with the next version of Flex and the recent release of Flash Player 10.
5. Local Device Access:
   Adobe AIR makes a compelling case for building desktop applications with web technologies, but if you are building an application that requires local device access then it is worth considering more traditional desktop platforms that offer a greater level of access to machine resources.  The community has responded to this concern with the Merapi project, but for those looking for major vendor support this is still a valid concern.

1. You prefer not to have a full featured easily extensible set of components.
2. You like spending time debugging your Ajax applications in all the different browsers and versions.
3. You are a Java developer and too afraid to shell out $250 for an IDE.
4. You believe that you can do anything you ever wanted to do in Perl.
5. You like working in a 10 year old standard (HTML 4).
6. You like the term Open Web, and believe it actually exists.
7. You hate quality applications, your clients, and yourself.

Let me know if you have any additions for either list!

admin originally posted this on EricDaugherty.com.

• TLS/SSL Support
• Configurable sandboxing
  
• Support for white/blacklisting
• Support for spam filtering/virus checking via amavisd-new using a dual MTA approach
  
Data directories are now configurable (incoming/outgoing email storage)
• New Service Wrapper (Tanuki Java Service Wrapper)
  
• More efficient mail dispatching to multiple users at a single domain
• Cleaner shutdown process
• Mail transactions with mail servers employing reverseDNS checks (useful for JES instances on a dynamic IP)
  
• More efficient memory handling
• On the fly POP3/SMTP port listening switching
  
Interfaces to enable extension modules
Migration tool for JES 1.6.1
• Introduction of an automated testing framework
  
• Improved MIME header parsing support
• 8BITMIME, SIZE extensions support
• SASL MD5-DIGEST, GSS-API support
  
• and MUCH MUCH more.