Initialization of the SelfDiagnose component is done by reading the resource selfdiagnose.xml which must be located on the classpath of the Web application. This configuration declares the diagnostic tasks that are executed in the context of the Web application. The upcoming release (1.1) will have a new feature that allows you to override the local configuration and dynamically load the configuration from a provided URL:
http://your-app/selfdiagnose?config=http://some-other-server/selfdiagnose.xml
or even a local file can be passed:
In the upcoming release 1.1 of the SelfDiagnose task library, a new task has been added called CheckEndecaService. Endeca is commercial software that provides excellent Search services to e.g. e-commerce web applications. This particular task checks the availability of that service and can perform a simple query. To implement this, the following snippet has been used:
HttpENEConnection connection = new HttpENEConnection();
connection.setHostname(host);
connection.setPort(port);
UrlENEQuery eneQuery = new UrlENEQuery("N=0", "UTF-8");
ENEQueryResults eneResults = connection.query(eneQuery);
Navigation navigation = eneResults.getNavigation();
long numERecs = navigation.getTotalNumERecs();
double time = eneResults.getTotalNetworkAndComputeTime();
Without a full understanding, you can see that this snippet is using classes which belong to the Endeca API package. SelfDiagnose is a open-source library and therefore can and will not have any dependencies on commerical software. So how can we still use this code without the compile time dependencies?. Of course, in order to execute this code, the runtime dependencies must be available. It does not make sense to use the CheckEndecaService if your application is not using it.
Designing and implementing applications that make use of Amazon Web Services such as S3, SQS and SimpleDB, require extensive testing to ensure a robust integration. In addition to scenarios for the “happy flows”, test scenarios should be created to handle the critical exceptional situations. How does my application respond to failures in communication, checksum errors, service unavailability, never ending transactions and extremely frequent or heavy traffic?
In the spirit of test driven development, I see a need for writing up such scenarios and simulate the unexpected behavior of AWS just to verify the correct handling of each exceptional event. Such a Test Drive service would implement the API of services available at Amazon Web Services. It should provide extra control services to put a Web Service in some “testing mode” such as “simulate disk failure”, “simulate terminated http connection” or “simulate invalid access key"or a combination thereof.
I wanted to associate version and build information with every compilation of a Flex project. Such information is useful when deploying to different staging environments (e.g. are you sure you uploaded the correct SWF ?) and helps tracking feedback (e.g. bugs) from users using a particular build.
First, I added a simple resource version.xml to store version and build info:
<?xml version='1.0' encoding='UTF-8'?/>
<version name='0.1' build='124'/>
Then I defined a component Version.mxml to show that information in plain text:
Capistrano is a deployment tool initially created to support the remote installation of Rails applications. One of the assumptions Capistrano makes is that the application (source) can be pulled out of a source code management system such as Subversion.
In case of Adobe Flex applications, compiled sources (SWF,HTML,…) need to be deployed to the Web server. So instead of pulling sources from a repository, I needed to push compiled code to the server.
On a Mac, accessing the current application from QuickSilver provides interesting new possibilities as can been on an episode of the Merlin Show. If you agree that this is something you wanted all along, then follow these instructions to set it up. (Thanks to BOONE).
- In QS prefs, make sure “Enable advanced features” is checked
- In QS Plug-ins, enable the User Interface plugin
- In MacOSX System Preferences–>Universal Access, check “Enable access for assitive devices”
- In QS prefs–>Catalog–>Quicksilver, check and reload “Proxy Objects”
For the Dunelox library, I needed a simplified Flex version of the Spring ApplicationContext which is a generic Hash object containing model objects accessed by a key (String). Visual components that are wired to these models objects need to be updated automatically using the standard event mechanism in Flex.
So, I had a look at the standard ArrayCollection to find out how it notifies components that are wired to elements by index. This gave me the idea to implement the HashCollection as a extension to this class.
For some time now, Amazon S3 Web Services are available to the developer community. Since its inception, several client solutions made their way to the public. S3Browse.com provides both a simple Web Interface and a Java Web Start based client to your S3 accounts. The web client is typically used to create and browse your bucket contents. The Java client is used to upload large files or a large amount of files. S3Browse.com is a free intermediate service to Amazon S3.
Too often developers put logic in so-called Helper classes.
This practice of SPOD (Single Point of Definition) results in a higher level of reusability, so it seems.
But in fact introducing these procedural structured behavioral methods impose a rigid structure.
First of all, (other) developers need to be aware that such Helpers exist to work on their objects.
Secondly, because behavior that should have been defined in the class of the object, is now defined elsewhere. The possibility of re-using such behavoir by inheritance is now unavailable. You cannot just extend an Helper class too!
How can I provide programs with self diagnostic behavior? How can I implement this in a way that has low impact on the way I write programs (or Java classes to be more specific). If programs could run such a self diagnose then perhaps it takes less time to find the cause of an observed problem.
These thoughts are sprung when I found an error in an application that went into production just a few days earlier. The problem itself was easily fixed (just a typo in some properties file) but I was a bit surprised that obviously my tests did not cover this particular execution path. Sure, I should have written more tests to have a higher coverage (JCoverage can tell me what percentage), but what if I had programmed this behavior differently(how?) such that a self diagnose run would have detected it?
