For example, consider a simple Compass class which defines just one public property, “direction” and, four constants representing each cardinal direction: North, East, South and West, respectively. In JavaScript, this could be defined simply as follows:

Technically, there is nothing problematic with the above class signature; the defined constants certainly provide a much better design than conditional comparisons against literal strings throughout implementation code. That being said, this design does lead to redundancy as every instance of Compass which needs to evaluate the state of direction requires conditional comparisons.

For example, to test for Compass.North, typically, client code must be implemented as follows:

Likewise, simular comparisons would need to be implemented for each cardinal direction. And, while this may seem trivial for a class as simple as the Compass example, it does become a maintenance issue for more complex implementations.

With this in mind, we can simplify client code by defining each state as a specific method of Compass. In doing so, we afford our code the benefit of exercising (unit testing) Compass exclusively. This alone improves maintainability while also simplifying client code which depends on Compass. As such, Compass could be refactored to:

Based on the above implementation of Compass, the previous conditional comparison can be refactored as follows:

Comparator API

To simplify implementing conditional comparisons, I have provided a simple Comparator API that defines a single static method: Comparator.each, which allows for augmenting existing objects with comparison methods. Comparator.each can be invoked with three arguments as follows:

Taking the Compass example, the previous comparison methods could be augmented without the need to explicitly define them via Comparator.each:

The above results in the comparison methods isNorth, isEast, isSouth and isWest being added to the Compass type.

Comparator: source | min | test (run)

“We are in the midst of a revolution across a variety of screens”

You may recall first hearing the notion of a “Multiscreen Revolution” during the keynote at Max 2010. If you take a moment and think about it that’s a rather profound statement, and by all apparent indications a very true one.

This is also how Kevin Lynch, CTO at Adobe, begins his recent article, aptly titled “The Multiscreen Revolution” in which Kevin provides a succinct breakdown covering the driving forces behind this revolution and how it is guiding the future of the Flash Platform.

Allow me to digress for a moment as, in a way, for me at least, the “Multiscreen Revolution” tends to conjure up the hypothetical notion of a Multiverse. This may be a suitable analogy I suppose as we have been focused in a predominantly Personal Computer based reality for many years, and while this remains relevant, it is no longer exclusive.

I have been giving a lot of thought lately regarding designing software in a multi form factor paradigm and felt I would share some initial thoughts on the subject. Keep in mind much of this is still quite new and subject to change; however, I have made an attempt to isolate what I feel will remain constant moving forward, particularly in the context of developing native applications with the Flash Platform across a variety of screens.

First, User Experience Design

My initial thoughts on the implications of what a Multiscreen paradigm will have on the way we think about the design of software are primarily concerned with User Experience Design (UX Design). While simply using CSS3 media queries to facilitate dynamic runtime layouts will be needed for most HTML based web applications, I do not believe these types of solutions alone will allow for the kinds of compelling experiences users have come to expect. Sure they are useful, and for some HTML based websites they may suffice. However, in the context of more complex applications, RIAs in particular, but also just about every application developed specifically for a PC, too, I believe UX Design will need to encompass the best of what a particular form factor, “screen” or whatever you prefer to call it, has to offer, be it a PC, smartphone, tablet or TV.

For example, it is extremely rare that a UX Design intended for users of a PC will translate directly to a Mobile or Tablet User Experience. The interactions of a traditional physical keyboard and mouse do not equate to those of soft keys, virtual keyboards and touch gesture interactions. Moreover, the navigation and transitions between different views and even certain concepts and metaphors are completely different. In simplest terms; it’s not “Apples to Apples”, as the expression goes.

With this in mind, UX Design should remain at the forefront of Software Design, and in order for that to happen UX Design will not only need to continue to reflect the needs of users, but also by leverage the capabilities of the particular devices and screens on which an application will run. This is necessary as it better serves the needs of users in new and useful ways. Likewise, UX Design will need to account for the limitations (resources in particular) of those same form factors.

Second, Architecture

Mulitiscreen design obviously poses some new challenges considering the growing number of form factors which will need to be taken into account. The good news is most existing well designed software architectures have been designed with this in mind all along. That is, the key factor in managing this complexity I believe will be code reuse. A common theme amongst many of my posts, code reuse has many obvious benefits, and in the context of Multiscreen concerns it will allow for different screen specific applications to leverage general, well defined and well tested APIs. Code reuse will certainly be of tremendous value when considering the complexities encountered with Multiscreen design. Such shared APIs can be reused across applications which are designed for particular screens or extended to provide screen / device specific implementations.

For example, the Architectures I have worked on are designed such that each is broken out into specific modules (libraries) which, on a high level, are typically as follows:

• unittesting-support: Provides convenience extensions of unit testing and mock frameworks.
• commons: Provides all generic, reusable APIs which have no dependencies outside of those of the Flex Framework and Flash Player API.
• framework-support: Provides reusable extensions of a particular framework. There can be multiple framework-support libraries, each of which would be specific to an individual framework; e.g. parsley-support, swiz-support, robotlegs-support, cairngorm-support, springactionscript-support etc.
• business: Provides domain dependent, business specific reusable APIs which are common amongst all projects within the business domain. This includes domain models, shared services, Presentation Models, UI components and anything else which is specific to the business domain. While all of the previously listed libraries could be used with any AS3 / Flex project, the business library is intentionally coupled to the domain.

All of the above projects are used by the different business applications, allowing for significantly reduced complexity of each individual application. Moreover, each library provides isolated test coverage which allows for a greater sense of confidence when building applications which are dependent on them. This type of structure also lends itself well with common SCM and build conventions, allowing for simplified branching and versioning.

Architectures designed similar to what I have described above I would consider to be “multiscreen ready” (provided they are optimized and efficient) in that much of the underlying implementation has already been completed, tested and proven. What’s left is the mobile, tablet or TV application designs which should be mainly concerned with UX, particularly interactions, navigation and device capabilities. From these screen specific UX Designs the application architecture is mainly focused around view concerns specific to those devices; leveraging the existing APIs as needed. This is where the Presentation Model Pattern (which I have been recommending for years) or similar patterns will be of great value.

I also anticipate additional libraries being abstracted in addition to those I have listed above as a result of these device specific projects being developed. For example, I could easily imagine “device-support”, “mobile-support” and “tablet-support” projects which would provide reusable APIs specific for those screens so as to be leveraged across applications. In fact, I am working on libraries such as these at the moment.

Reusable libraries are nothing new; however, their role now is perhaps even more important as it is quite likely that multiple implementations of the same application will be needed for the various form factors and contexts. Existing reusable libraries may also need to be further optimized to provide the best performance against the slowest devices in order to be considered suitable for devices with the most limited resources. A natural side effect of such optimizations is that implementations of an application targeting the fastest form factors (typically, PCs) will benefit greatly.

Some Concluding Thoughts

In short, I believe both users and developers alike will be best served by providing unique User Experiences for specific screens as opposed to attempting to adapt the same application across multiple screens. One of the easiest ways of managing the complexity of multiscreen design and development will inevitably be code reuse.

I also believe the main point of focus should be on the medium and small form factors; i.e. Tablets and Smart phones. Not only for the more common reasons but, also because I believe PCs and Laptops will eventually be used almost exclusively for developing the applications which run on the other form factors. In fact, I can say this from my own experiences already.

While there is still much to learn in the area of Multiscreen Design, I feel the ideas I’ve expressed here will remain relevant. Over the course of the coming months I plan to dedicate much of my time towards further exploration of this topic and will certainly continue to share my findings.

Written by two of my favorite technical authors, Andy Hunt and Venkat Subramaniam, and published as part of the Pragmatic Bookshelf, Practices of an Agile Developer provides invaluable, practical and highly inspirational solutions to the most common challenges we as software engineers face project after project.

What makes Practices of an Agile Developer something truly special is the simplicity and easy to digest format in which it is written; readers can jump in at any chapter, or practically any page for that matter, and easily learn something new and useful in a matter of minutes.

While covering many of the most common subjects on software development, as well as many particularly unique subjects, it is the manner in which the subjects are presented that makes the book itself quite unique. The chapters are formatted such that each provides an “Angel vs. Devil on your shoulders” perspective of each topic. This is quite useful as one can briefly reference any topic to take away something useful by simply reading the chapters title and the “Angel vs. Devil” advice, and from that come to a quick understanding of the solution. Moreover, each chapter also provides tips on “How it Feels” when following one of the prescribed approaches. The “How it feels” approach is very powerful in that it instantly draws readers in for more detailed explanations. Complimentary to this is the “Keeping your balance” suggestions which provide useful insights to many of the challenges one might face when trying to apply the learnings of a particular subject. “Keeping your Balance” tips answer questions which would otherwise be left to the reader to figure out.

I first read Practices of an Agile Developer almost 4 years ago, and to this day I regularly find myself returning to it time and time again for inspiration. A seminal text by all means, I highly recommend it as a must read for Software Developers of all levels and disciplines.

In general, it is much easier to understand what a VO is not by first understanding what a Domain Model is; therefore, I will begin by providing a general definition of a Domain Model.

Domain Models

A Domain Model is anything of significance which represents a specific business concept within a problem domain. Domain Models are simply classes which represents such concepts by defining all of the state, behavior, constraints and relationships to other Domain Models needed to do so. Essentially, a Domain Model models a domain concept, such as a Product, a User, or anything which could be defined within the problem domain outside the context of code. Domain Models promote reuse and eliminate redundancy by defining specific classes which encapsulate business logic, state and relationships. As the domain concepts change, so to do the implementations of the Domain Models.

Value Objects (VOs)

As the name implies, a Value Object, more commonly referred to as a VO, is an object which simply provides values. VOs are entirely immutable; that is, all properties of a VO are read-only and assignments to those properties are specified only during object construction; after which, the properties of the VO can not be modified and, by design, should not require changes.

VOs are typically used to provide an aggregation of conceptually related properties whose values describe the state of the object when instantiated and do not require any real concept of identity or uniqueness. While there are some edge cases (such as validation), more commonly than not, VOs do not implement any specific behavior. Conceptually, think of a VO as being nothing more than an object which holds a value or series of related values which describe something about the object when created. A typical example of a VO could be a UserLogin object which simply holds the values of the specified username and password when created. It is important to make the distinction between a VO and a Domain Model as, a VO is not a Model, but rather, a VO is nothing more than an object which holds values and could be used to describe any context.

And that’s it

Hopefully the above descriptions of both Domain Models and Value Objects will clear up any confusion surrounding the two concepts; ideally, making it easier to understand when to use each.

The point to keep in mind is that Domain Models simply model the domain, while VOs simply describe a contextual state.

For example, consider a simple test against a class Car which has an instance of class Engine. Car implements a start method which, when invoked, calls the Engine object’s run method. The challenge here lies in testing the dependency Car has on Engine, specifically, how one verifies that an invocation of Car.start results in the Engine object’s run method being called.

There are two ways of testing the above example of Car, which in unit testing nomenclature is called the System Under Test (SUT), and it’s Engine instance which is Car's Depended-on Component (DOC). The most common approach is to define assertions based on the state of both the SUT and it’s DOC after being exercised. This style of testing is commonly referred to as State Verification, and is typically the approach most developers initially use when writing tests.

Using the above Car example, a typical State Verification test would be implemented as follows:

Figure 1. CarTest, State Verification.

From a requirements perspective and therefore a testing and implementation perspective as well, the expectation of calling start on Car is that it will A.) change it’s running state to true, and B.) invoke run on it’s Engine instance. As you can see in Figure 1, in order to test the start method on Car the Engine object must also be tested. In the example, using the State Verification style of testing, Car exposes the Engine instance in order to allow the state of Engine to be verified. This has lead to a less than ideal design as it breaks encapsulation and violates Principle of Least Knowledge. Obviously, a better design of Car.isStarted could be implemented such that it determines if it’s Engine instance is also in a running state; however, realistically, Engine.run will likely need to do more than just set its running state to true; conceivable, it could need to do much, much more. More importantly, while testing Car one should only be concerned with the state and behavior of Car – and not that of its dependencies. As such, it soon becomes apparent that what really needs to be tested with regards to Engine in Car.start is that Engine.run is invoked, and nothing more.

With this in mind, the implementation details of Engine.run are decidedly of less concern when testing Car; in fact, a “real” concrete implementation of Engine need not even exist in order to test Car; only the contract between Car and Engine should be of concern. Therefore, State Verification alone is not sufficient for testing Car.start as, at best, this approach unnecessarily requires a real Engine implementation or, at worst, as illustrated in Figure 1, can negatively guide design as it would require exposing the DOC in order to verify its state; effectively breaking encapsulation and unnecessarily complicating implementation. To reiterate an important point: State Verification requires an implementation of Engine and, assuming Test First is being followed (ideally, it is), the concern when testing Car should be focused exclusively on Car and it’s interactions with its DOC; not on their specific implementations. And this is where the second style of testing – Behavior Verification – plays an important role in TDD.

The Behavior Verification style of testing relies on the use of Mock Objects in order to test the expectations of an SUT; that is, that the expected methods are called on it’s DOC with the expected parameters. Behavior Verification is most useful where State Verification alone would otherwise negatively influence design by requiring the implementation of needless state if only for the purpose of providing a more convenient means of testing. For example, many times an object may not need to be stateful or the behavior of an object may not always require a change in it’s state after exercising the SUT. In such cases, Behavior Verification with Mock Objects will lead to a simpler, more cohesive design as it requires careful design considerations of the SUT and it’s interactions with its DOC. A rather natural side-effect of this is promoting the use of interfaces over implementations as well as maintaining encapsulation.

For testing with Behavior Verification in Flex, there are numerous Mock Object frameworks available, all of which are quite good in their own right and more or less provide different implementations of the same fundamental concepts. To name just a few, in no particular order, there are asMock, mockito-flex, mockolate and mock4as.

While any of the above Mock Testing Frameworks will do, for the sake of simplicity I will demonstrate re-writing the Cartest using Behavior Verification based on mock4as – if for nothing other than the fact that it requires implementing the actual Mock, which helps illustrate how everything comes together. Moreover, the goal of this essay is to help developers understand the design concepts surrounding TDD with Behavior Verification and Mock Objects by focusing on the basic design concepts; not the implementation specifics of any individual Mock Framework.

Figure 2. CarTest, Behavior Verification approach.

Let’s go through what has changed in CarTest now that it leverages Behavior Verification. First, Car's constructor has been refactored to require an Engine object, which now implements an IEngine interface, which is defined as follows.

Figure 3. IEngine interface.

Note Engine.isRunning is no longer tested, or even defined as, it is simply not needed when testing Car: only the call to Engine.run is to be verified in the context of calling Car.start. Since focus is exclusively on the SUT, only the interactions between Car and Engine are of importance and should be defined. The goal is to focus on the testing of the SUT and not be distracted with design or implementation details of it’s DOC outside of that which is needed by the SUT.

MockEngine provides the actual implementation of IEngine, and, as you may have guessed, is the actual Mock object implementation of IEngine. MockEngine simply serves to provide a means of verifing that when Car.start is exercised it successfully invokes Engine.run; effectively satisfiying the contract between Car and Engine. MockEngine is implemented as follows:

Figure 4. MockEngine implementation.

MockEngine extends org.mock4as.Mock from which it inherits all of the functionality needed to “Mock” an object, in this case, an IEngine implementation. You’ll notice that MockEngine.run does not implement any “real” functionality, but rather it simply invokes the inherited record method, passing in the method name to record for verification when called. This is the mechanism which allows a MockEngine instance to be verified once run is invoked.

CarTest has been refactored to now provide two distinct tests against Car.start. The first, testStartChangesState(), provides the State Verification test of Car; which tests the expected state of Car after being exercised. The second test, testStartInvokesEngineRun(), provides the actual Behavior Verification test which defines the expectations of the SUT and verification of those expectations on the DOC; that is, Behavior Verification tests are implemented such that they first define expectations, then exercise the SUT, and finally, verify that the expectations have been met. In effect, this verifies that the contract between an SUT and its DOC has been satisfied.

Breaking down the testStartInvokesEngineRun() test, it is quite easy to follow the steps used when writing a Behavior Verification test.

And that’s basically it. While much more can be accomplished with the many Mock Testing frameworks available for Flex, and plenty of information is available on the specifics of the subject, this essay quite necessarily aims to focus on the design benefits of testing with Behavior Verification; that is, the design considerations one must make while doing so.

With Behavior Verification and Mock Objects, design can be guided into existence based on necessity rather than pushed into existence based on implementation.

The example can be downloaded here.

Since first publishing an AS3 HashMap implementation back in December of 2006, much to my surprise the original post through which I released the API still yields a good amount of feedback each month.

In the time since I have extended the functionality of the HashMap to include a LocalPersistenceMap and ResourceMap in addition to the original HashMap; all of which implement the IMap interface and can be used interchangeably by client code.

The single most requested feature I have received has by far been to provide a Bindable HashMap implementation, and, just recently, I decided to implement one and share it with the community.

The implementation of the BindableMap is quite straightforward as it simply provides an API which wraps an IMap implementation in order to facilitate data binding capabilities to all read methods of the underlying Map.

Using the various IMap implementations with BindableMap yields some interesting possibilities; specifically when using BindableMap with LocalPersistenceMap as it essentially provides a bindable implementation of a LocalSharedObject, as can be seen in the following example (e.g. add some values and refresh the page):

You can download the source, binary and example here.

For instance, consider the following example to get a better idea of what I mean:

Taking the above example into a broader context, it is quite common to see code such as this scattered throughout a codebase; particularly in the context of view concerns. At best this could become hard to maintain and, at worst, it will result in unexpected bugs down the road. In most cases (as in the above example) the actual code itself is not necessarily bad, however it is the context in which it is placed which is what I would like to highlight as it will almost certainly cause technical debt to some extent.

Considering the above example, should code such as this become redundantly implemented throughout a codebase it is quite easy to see how it can become a maintenance issue as, something as simple as a change to a hostname would require multiple refactorings. A much more appropriate solution would be to encapsulate this logic within a specific class whose purpose is to provide a facility from which this information can be determined. In this manner unnecessary redundancy would be eliminated (as well as risk) and valuable development time would be regained as the code would need only be tested and written once – in one place.

So again, using the above example, this could be refactored to a specific API and client code would leverage the API as in the following:

This may appear quite straightforward, however, I have seen examples (this one in particular) in numerous projects over the years and it is worth pointing out. Always take the context to which code is placed into consideration and you will reap the maintenance benefits in the long run.

From time to time I find myself going back to the seminal text The Pragmatic Programmer as it provides a great source of what should be kept in mind from day to day. I thought I would share some tips from the book with my readers that I find of particular value, and would be happy to explain them at length; in the context of real world software challenges.

Care About Your Craft
Why spend your life developing software unless you care about doing it well?

Provide Options, Don’t Make Lame Excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

Design with Contracts
Use contracts to document and verify that code does no more and no less than it claims to do.

Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

Costly Tools Don’t Produce Better Designs
Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.

Start When You’re Ready
You’ve been building experience all your life. Don’t ignore niggling doubts.

Don’t Be a Slave to Formal Methods
Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.

It’s Both What You Say and the Way You Say It
There’s no point in having great ideas if you don’t communicate them effectively.

You Can’t Write Perfect Software
Software can’t be perfect. Protect your code and users from the inevitable errors.

Build Documentation In, Don’t Bolt It On
Documentation created separately from code is less likely to be correct and up to date.

Put Abstractions in Code, Details in Metadata
Program for the general case, and put the specifics outside the compiled code base.

Work with a User to Think Like a User
It’s the best way to gain insight into how the system will really be used.

Program Close to the Problem Domain
Design and code in your user’s language.

Use a Project Glossary
Create and maintain a single source of all the specific terms and vocabulary for a project.

Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.

DRY – Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Eliminate Effects Between Unrelated Things
Design components that are self-contained, independent, and have a single, well-defined purpose.

Iterate the Schedule with the Code
Use experience you gain as you implement to refine the project time scales.

Use the Power of Command Shells
Use the shell when graphical user interfaces don’t cut it.

Don’t Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.

Don’t Assume It – Prove It
Prove your assumptions in the actual environment—with real data and boundary conditions.

Write Code That Writes Code
Code generators increase your productivity and help avoid duplication.

Test Your Software, or Your Users Will
Test ruthlessly. Don’t make your users find bugs for you.

Don’t Gather Requirements—Dig for Them
Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.

Abstractions Live Longer than Details
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.

Don’t Think Outside the Box—Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”;

Some Things Are Better Done than Described
Don’t fall into the specification spiral—at some point you need to start coding.

Don’t Use Manual Procedures
A shell script or batch file will execute the same instructions, in the same order, time after time.

Test State Coverage, Not Code Coverage
Identify and test significant program states. Just testing lines of code isn’t enough.

Gently Exceed Your Users’ Expectations
Come to understand your users’ expectations, then deliver just that little bit more.

Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.

Remember the Big Picture
Don’t get so engrossed in the details that you forget to check what’s happening around you.

Make It Easy to Reuse
If it’s easy to reuse, people will. Create an environment that supports reuse.

There Are No Final Decisions
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.

Estimate to Avoid Surprises
Estimate before you start. You’ll spot potential problems up front.

Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

Fix the Problem, Not the Blame
It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.

“select” Isn’t Broken
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

Learn a Text Manipulation Language
You spend a large part of each day working with text. Why not have the computer do some of it for you?

Use Exceptions for Exceptional Problems
Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.

Minimize Coupling Between Modules
Avoid coupling by writing “shy” code and applying the Law of Demeter.

Design Using Services
Design in terms of services: independent, concurrent objects behind well-defined, consistent interfaces.

Don’t Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.

Organize Teams Around Functionality
Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.

Test Early. Test Often. Test Automatically.
Tests that run with every build are much more effective than test plans that sit on a shelf.

Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

Sign Your Work
Craftsmen of an earlier age were proud to sign their work. You should be, too.

I suggest keeping these tips, or a subset of them, as well as some of your own, somewhere visible; even if some appear rather obvious, as it will serve as a good general reminder of the things you should always keep in mind.

Essentially, Vectors are just typed Arrays. And while not as robust or powerful, Vectors are similar to Generics in C# and Java. When it is known at design time that a collection will only ever need to work with a single type, Vectors can be utilized to provide type safety and also to allow for significant performance gains over using other collection types in Flex.

I recently wanted to convert quite a few typed Array implementations to Vectors, however, the Arrays were being traversed with an Iterator. In order to reduce the amount of client code which needed to be refactored I simply implemented a Vector specific Iterator implementation.

If you are familiar with Iterator Pattern in general, and the Iterator interface in particular, then usage will prove to be very straight forward. You can use the Vector Iterator to perform standard iterations over a Vector. Below is an example of a typical client implementation:

Using an Iterator with a Vector ensures only a linear search can be performed, which proves useful with Vectors as they are dense Arrays. However, one consideration that must be made when using an Iterator with a Vector is that you loose type safety when accessing items in the Vector via iterator.next(). It is because of this I would suggest only using Iterator’s with Vectors to support backwards compatibility when refactoring existing Arrays which are being used with existing Iterators.

The VectorIterator and it’s associated test are available below:
VectorIterator
VectorIteratorTest

Obviously there are numerous solutions which can be implemented to monitor the elapsed time of a service invocation, however it was my goal to provide a unified solution which could easily be implemented into existing client code without significant refactorings being required.

In order to achieve this I first needed to consider what the typical implementation of a service invocation is in order to isolate the
commonality. From there it is only a matter of determining a solution that meets the objective in the most non intrusive manner possible.

To begin let us consider what a “typical” service invocation might look like for the three most common services available in the Flex Framework; HTTPService, RemoteObject and WebService.

Based on the 3 above implementations we can deduce that the common API used when performing a service invocation is AsyncToken. So to provide a unified solution for all three common Services we could either extend AsyncToken or provider an API which wraps AsyncToken. For my needs I chose to implement an API which simply monitors an AsyncToken from which the duration of an invocation can be determined, thus I wrote an RPCDiagnostics API which can be “plugged” into an AsyncToken client implementation.

RPCDiagnostics provides basic performance analysis of a Remote Procedure Call by providing a message which displays information about the operation duration via a standard trace call. In addition, an event listener of type RPCDiagnosticsEvent can be added to facilitate custom diagnostics and Logging.

RPCDiagnostics can easily be implemented as an addition to an existing AsyncToken or in place of an AsyncToken. The following examples demonstrate both implementations.

Implementing RPCDiagnostics onto an existing AsyncToken:

Implementing RPCDiagnostics in place of an AsyncToken:

Implementing a listener to an RPCDiagnostics instance:

The RPCDiagnostics API and dependencies can be downloaded via the Open Source AS3 APIs page or from the below links:

RPCDiagnostics
RPCDiagnosticsEvent
Execution

When classes, interfaces, methods, properties, identifiers, events and the like fail to follow logical, consistent and intuitive naming conventions the resulting software becomes significantly more complex to understand, follow and maintain. As such this makes changes much more challenging than they would have been had better naming been considered originally. Of equal concern is the inevitability that poor naming will lead to redundant code being scattered throughout a project as when the intent of code is not clearly conveyed with as little thought as possible developers tend to re-implement existing functionality when the needed API cannot easily be located or identified.

Code is typically read many, many more times than it is written. With this in mind it is important to understand that the goal of good naming is to be as clear and concise as possible so that a reader of the code can easily determine the codes intent and purpose; just by reading it.

Teams should collectively define a set of standard naming conventions which align well with the typical conventions found in their language of choice. In doing so this will help to avoid arbitrary naming conventions which often result in code that is significantly harder to determine intent, and thus maintain. Of equal importance is the need for various teams from within the same engineering department to standardize on domain specific terms which align with the non-technical terms used by business stakeholders. Together this will help to develop a shared lexicon between business owners and engineers, and allow for simplified analysis of requirements etc.

Ideally, code should follow the PIE Principle (Program, Intently and expressively) – that is, code should clearly convey purpose and intent. In doing so the ability to maintain a software application over time becomes significantly easier and limits the possibility of introducing potential risk to project deliverables.

In short, conventions are very important regardless of a teams size; beit a large collaborative team environment, or a single developer who only deals with his own code. Consistency and conventions are a key aspect to ensuring code quality.