APIs - Eric Feminella

Practices of an Agile Developer

Of the many software engineering books I have read over the years, Practices of an Agile Developer in particular continues to be one book I find myself turning to time and time again for inspiration.

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.

Comments Off

Web Timing Specification

The Web Timing Specification (draft) aims at providing a standard set of APIs which allow for true end-to-end instrumentation of page load times across browsers.

To quote the w3 spec: “This specification (Web Timing Specification) defines an interface for web applications to access timing information related to navigation and elements.” The API is based on the Navigation Timing and Resource Timing interfaces, respectively.

While I haven’t seen this specification mentioned as part of the HTML5 Family before, in many ways I would consider it to be a worthy candidate for membership as it provides a standards based API through which web applications can be tested for load efficiency. This is obviously something quite useful for any web application as, the ability to precisely measure page load times – and implement optimizations as needed – affords developers the opportunity to provide an improved user experience.

Historically, the ability to accurately measure page load times of web applications has been quite challenging for a number reasons. Just knowing when and where to begin is debatable and, determining the best means of doing so can be a challenge in of itself. Regardless of any current strategies being used, the result is never entirely accurate. With Web Timing developers need not be concerned with these specifics as the API provides the ability to truly measure page load times by encompassing the full scope of loading and parsing a page. This includes the time involved to request, receive and render an HTML document.

For more information, try out the examples in the current supported browsers; IE9, Chrome 6.

July 20, 2010 APIs / HTML5 / JavaScript

Comments Off

Bindable Map

Recently I was going through some old drafts I had pending when I happened to notice I had never published this one, so I am finally doing so now…

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):

[kml_flashembed publishmethod=”static” fversion=”10.0.0″ movie=”https://www.ericfeminella.com/blog/articles/assets/flex/BindableHashMapExample/BindableHashMapExample.swf” width=”400″ height=”400″ targetclass=”flashmovie”]

[/kml_flashembed]

You can download the source, binary and example here.

May 18, 2010 APIs / Design Patterns / Object Oriented Design

Comments Off

Metadata API update for Flex 4

Back in September 2008 I published a post on Class Annotations in Flex, through which I provided an API allowing for a unified approach for working with AS3 metadata. Just recently I intended to use the Metadata API in a Flex 4 project when I noticed it no longer seemed to work as expected. After a bit of debugging, I realized the bug appeared to be related to changes in the result returned from describeType; specifically, the addition of the “__go_to_definition_help” metadata. Considering the Metadata API leverages describeType in order to introspect metadata definitions, this made sense.

I made some simple modifications to the API to work with the new metadata returned from describeType and this resolved the issue. While I was in the process I also refactored operations to return Vectors as opposed to ArrayCollections, as was the case in the original design; effectively optimizing the API for Flex 4 (as well as Flex SDK 3.4).

You can download the source/tests/swc/docs dist here; all of which will be available soon via SVN and a public Maven repository, more on that once it’s ready.

January 30, 2010 APIs / Refactoring / TDD / BDD

1 Comment

Vector Iterator for Flex

One of the many welcome additions to the Flex 3.4 SDK is the inclusion of the Vector class. Vectors in particular are especially welcome as they provide compile time type safety over what would otherwise not be available when implementing custom solutions, such as a typed collection.

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:

var abc:Vector.<String> = new Vector.<String>(3, true);

abc[0] = "a";

abc[1] = "b";

abc[2] = "c";

var it:Iterator = new VectorIterator( alpha );

while ( it.hasNext() )

{

trace( it.next() );

// a, b, c

}

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

October 2, 2009 APIs / Design Patterns / Object Oriented Design

1 Comment

Simple RPC Instrumentation in Flex

On occasion developers may find a need to quickly measure the time it takes for a request to a remote service to return a response back to the client without the need to employ an automated testing tool to perform the instrumentation. This information can prove quite valuable for performing application diagnostics on the client and, when measured in terms of code execution, monitoring at the execution level will always be a bit more precise than that which can be measured by using a Network proxy alone, such as Charles or Fiddler, etc.

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.

// HTTPService

var call:AsyncToken = service.send(...);

call.addResponder( this );

// RemoteObject

var call:AsyncToken = service.someMethod(...);

call.addResponder( this );

// WebService

var call:AsyncToken = service.someOperation(...);

call.addResponder( this );

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:

var call:AsyncToken = null;

call = RPCDiagnostics.monitorToken(service.send(),"methodName");

call.addResponder( ... );

Implementing RPCDiagnostics in place of an AsyncToken:

var call:RPCDiagnostics = null;

call = new RPCDiagnostics( service.send(), "methodName" );

call.addResponder( ... );

Implementing a listener to an RPCDiagnostics instance:

var call:RPCDiagnostics = null;

call = new RPCDiagnostics( service.send(), "operationName" );

call.addResponder( ... );

call.addEventListener( RPCDiagnosticsEvent.EXECUTION_COMPLETE,

handler);

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

RPCDiagnostics
RPCDiagnosticsEvent
Execution

September 20, 2009 APIs / Object Oriented Design / Software Engineering

Comments Off