You are viewing the Articles published in

SSH / Telnet client for Blackberry

These days almost everyone has a smart phone. Mobile Phones, particularly smart phones, allow users to easily browse the internet, use email, take pictures, videos, send and receive sms, mms, download native applications and much, much more. We live in a fast-moving world and having devices such as smart phones to help us keep up with this pace is paramount.

Anyone who owns a smartphone quickly realizes that the possibilities with it are endless. For example, I recently found a simple, free application which allowed me to log onto my server from my smartphone; a BlackBerry Curve 8310. I always thought it would be useful to be able to log in to my server from my phone and after doing a quick search I found MidpSSH – an SSH1/2 and Telnet client (with VT320 terminal emulation) for MIDP 1.0 / 2.0 (J2ME) devices.

Since the Blackberry OS provides MIDP 1.0 support and OS 4 provides a subset of MIDP 2.0 support, MidpSSH seemed like it would be a good fit.

Installing MidpSSH is very straightforward – like most installers for Blackberry. UX is straightforward as well, and once installed you can simply start up the client, create a new session (which can be saved, imported etc.), enter the host name and log in. You’ll also probably want to increase the font size as the default is set to “Tiny”, which is a very small font size. I changed this setting to LCD 5×9 which works well.

All in all a simple, yet very useful free application.

Guiding Design with Behavior Verification and Mock Objects

At some point every developer who has disciplined themselves in the ritualistic like art and science of Test Driven Development soon discovers that the collaborators on which a class under test depend introduce an additional layer of complexity to consider when writing your tests – and designing your APIs.

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, 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 is invoked, and nothing more.

With this in mind, the implementation details of 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 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; 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 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.

Global Error handling in Flash Player 10.1

A few years back I had the need to write a global exception management framework in order to provide a means from which unhandled errors could be handled gracefully throughout an application. Initially, I assumed there must be a listener available which could be added to SystemManager or Application, and from there all unhandled errors could be caught; however, after spending many hours trying to find a solution, it seemed this wasn’t possible to achieve in the Flash Player API at the time.

Just recently I found myself once again in need of such an API, and thought there may be something new in Flash Player 10 that I wasn’t aware of. However, as it turns out the only thing I was able to find actually happened to be in the Adobe Bug database; specifically, issue FP-444. It was then that I referenced the feature set for the next revision of Flash Player – version 10.1, and learned that in addition to many other significant new enhancements Flash Player 10.1 will finally introduce the ability to manage exceptions globally!

This is an invaluable feature for all Flash based applications as it will allow for the ability to add a global listener from which you can catch any and all uncaught RTEs. The ability to provide a global exception management mechanism will undoubtedly improve Flash applications significantly as uncaught RTEs can then be handled gracefully by responding to the user accordingly.

This may be one of those new features that isn’t necessarily the main focal point in marketing campaigns. However, it is APIs like this that make life for developers (and QA) much easier and, equally as important, ultimateky have huge payoffs for users.

Coincidentally, this also just so happens to coincide with an open source Exception Framework I am planning to release. The framework will provide a foundation from which more robust exceptions can be defined (in comparison to the generic Error class), as well as common exception types which implement the framework. So if you are interested, check back soon as I plan to publish the framework this month.

Maven dependency resolution with

Ever need to determine what versions of a specific Maven dependency are available in a public repository? Or more importantly, determine if a dependency even exists in a public repository? If so, then, a free, subscription based service available to anyone with a Google account can be used to help quickly and easily resolve maven dependencies.

Usage is simple:

  1. Search Google for the name of the dependency (e.g. concurrent pom) and you will get a list of all groups in which the dependency is under a public repository.
  2. Select the specific group you require
  3. Select the version you require

And that’s it! Now you can simply copy the coordinates and the dependency has been resolved.

While there are certainly other services available which do more or less the same thing (e.g. Maven Repository Browser, etc.), the simplicity of being able to just search from Google is rather convenient.

Thoughts on Cairngorm 3

A week or so prior to MAX, the Cairngorm committee had a rather interesting discussion, during which Alex outlined what the team at Adobe Technical Services had been considering for Cairngorm 3. The meeting was focused on providing everyone with an overview of the collective ideas which Adobe had been gathering internally for some time now, and to also inquire feedback prior to the public announcement of Cairngorm 3.

Prior to the meeting I had anticipated the discussion would be based around a few new patterns and best practices which are currently being advocated, and possibly some additional libraries which help to address recent challenges in RIA development. However, what we discussed was actually quite different – in a good way.

As you are probably aware by now, Cairngorm 3 is focused around tried and tested best practices and guidelines which aid Flex developers in providing solutions to their day to day RIA challenges. These guidelines are primarily based upon that which has been realized by Adobe Technical Services, and also from the Flex community at large. Teams can leverage these guidelines where applicable to help deliver successful RIAs using frameworks of their choosing. While there may be specific frameworks and libraries recommended in Cairngorm 3, these are just that – recommendations. There is generally a framework agnostic approach which I must emphasize is highly preferable to that of suggesting one framework over another. This is precisely what I think is needed in the Flex community, for there is rarely a one size fits all approach to software architecture, especially in terms of specific framework implementations. This is a pretty easy concept to comprehend, as, what works for one team, in one context, may not always be appropriate for another team, or in another context.

Cairngorm 3 is a step forward towards what (IMHO) should be a general consensus in the Flex community at large; there are many existing frameworks out there which help address specific problems, with each providing unique qualities and solutions in their own right. This is the kind of thought leadership which helps a community progress and grow; it should be encouraged, as allowing for the shared knowledge of fundamental design principles and guidelines is something which provides value to all Flex developers, regardless of which framework they happen to prefer.

If there is one suggestion I would propose, it would be to have an entirely new name for these collections of best practices, guidelines and general Flex specific solutions. Personally, I would like to see the name Cairngorm (which, after all these years, I still pronounce as Care-in-gorm) refer to the original MVC framework, i.e. the framework implementation itself, as keeping the name the same while undergoing a different direction is bound to cause confusion to some extent. Whatever the new name would be is insignificant as long as the original name of Cairngorm applied to that of the actual framework implementation. This would perhaps be more intuitive as it would allow for the name Cairngorm to be used to describe a concrete framework as a potential solution, just as one could describe other frameworks; e.g. Spring ActionScript, Mate, Swiz, Parsley, Penne, Model-Glue, PureMVC, Flicc etc.

Most importantly, however, is the prospect of choice, as choice is always a good thing. Moreover, an initiative being lead by Adobe in this area sends a very good message to the Flex community as a whole. I happen to leverage a number of different frameworks and patterns which address different problems. As new problems arise, I employ new solutions where existing solutions may not suffice, or develop custom solutions where none are currently available; never blindly choosing one solution over another. However, in every case, there are typically some basic, fundamental guidelines which hold true and can be followed to help drive a design in the right direction. Regular readers of this blog have probably noticed that the basis of the majority of my posts are heavily rooted within these fundamental design principles, as it is from these fundamental design principles and guidelines that developers can utilize the frameworks which work best for them in order to and meet their specific challenges.

Essentially, Software Architecture is all about managing complexity, and there are many fundamental patterns and guidelines which can help developers mange this complexity. The specific framework implementations are of less concern, for it is the understanding of these patterns and principles – and more importantly, when to apply them, which will ultimately drive the decisions to leverage a one framework over another. In my experience, I have found that the only constant in software architecture is that a pragmatic approach should be taken whenever possible, whereby context is always key, and simplicity is favored as much as possible. Cairngorm 3, I feel, is a nice illustration of this principle.

Advanced Flex 4

This morning I received a copy of the new Book Advanced Flex 4, written by my friend Elad Elrom and Shashank Tiwari, with contributions by Charlie Schulze.

Upon opening the package and browsing the first few pages, I was quite flattered to read:

“I would also like to thank Eric Feminella who has inspired me, mentored me and helped me to become a better Flex Architect. I had the pleasure of working with Eric at Weight Watchers three years ago and I have found that Eric is one of the smartest, yet extremely humble, people I have ever met. He has a deep understanding in OOP, Architecting Flex apps, as well as RIA in general. Check his blog here: and follow him on Twitter: @ericfeminella”

It is always nice to receive recognition for something; however, the real reward is in knowing you have had a positive impact on someone as, this has always been a very real goal of mine.

The book covers an awful lot of ground – everything from Mobile Applications, AIR 2.0, Flash Catalyst, Data Service Integration, consuming Web 2.0 APIs, Flex Mashups, Audio, Video, 3D and more. I especially like the the Chapter on Flash Player Security. The book also appears to follow the theme of traditional software development best practices, that is, the first chapter is on Test Driven Development – test first. A good read by any standards, and I highly recommend it.