Skip to content

Amazon Web Services (AWS) Customer Service Agreement: Easy Come, Easy Go

March 16, 2014

Having read the 17 page Customer Agreement I would sum it up with Easy Come, Easy Go.

By that I mean that if I where to start a business using AWS I would operate under the assumption that the AWS leg of my business could be replaced and immediately disabled with no disruption to my end-users and also my responsibilities to them. In a way this flies in the face of being mesmerized by for example the advertised resiliency of services such as S3. I regard this as common sense, but also the AWS Customer Service Agreement is quite forthright in the sense that it reminds their clients, in effect, that it must comply with governmental requests to for example move your data from one AWS region to another (e.g. move all your data from say Australia to the US).

3.2 Data Privacy. We participate in the safe harbor programs described in the
Privacy Policy. You may specify the AWS regions in which Your Content will
be stored and accessible by End Users. We will not move Your Content from
your selected AWS regions without notifying you, unless required to comply
with the law or requests of governmental entities. You consent to our
collection, use and disclosure of information associated with the Service
Offerings in accordance with our Privacy Policy, and to the processing of
Your Content in, and the transfer of Your Content into, the AWS regions you
select.

They can also as per Section 7.2 immediately terminate the agreement under a variety of conditions.

Its not worth spending too much time on the AWS Customer Service Agreement in my mind as long as one’s software architecture and promises to end-users caters for the scenario where AWS is a gonner, for whatever reason.

The Async Retry Pattern: A Great Tutorial

March 3, 2014

Seemingly simple “green path” code can quickly get complex when one considers all that can go wrong. Good old error handling and retries, its all been done before and in so many different ways.

Consider retries for transient errors, one can either re-invent the wheel (done more often than not), or use appropriate library code from Spring Batch (now Spring Retry) in a synchronous fashion, or hand the potential lengthy operation off for asynchronous handling.

When it comes to asynchronous handling, Tomasz Nurkiewicz has done the hard yards and written an informative post along with GitHub code that serves as an excellent tutorial in itself. Kudos to Tomasz!

I’m left wondering that the correlation is between the Java Active Object Pattern and the Async Retry Pattern, the Async part is seemingly the only correlation.

Column-Family Databases (DynamoDB): The Key Trade Off

February 11, 2014

I had some random fortune come may way last year in the form of a four month stint to finish off and deliver on a DynamoDB based project.  The project was handed over to me just as the requirements of the project had changed enough, in retrospect, for a column-family database such as DynamoDB to serve as a painful reminder of a key reason why we use RDBMSs; SQL. Fowler and Sadalage [1] say it best below Section 10.4 When Not To Use.

RDBMS impose high cost on schema change, which is traded off for a low cost of query change; in Cassandra [Column-Family Databases], the cost may be higher for query change as compared to schema change.

As you can gather, the requirements of the project I completed, albeit with the power of SQL sorely missed, was a prime When Not To Use example. But the experience gained is priceless, as is the trade off quote below for future software architecture specifications.

It is worth noting one more thing that Fowler and Sadalage say in the same cited Section, which matches my experience exactly. In essence they do not recommend using Cassandra, and this also goes for DynamoDB in my mind, for prototypes or tech spikes since during the early stages it is unlikely that one will know how query patterns will change. As query patterns change, with DynamoDB, my experience was that the column family design had to change. The effect of such family column design change is summed up by Fowler and Sadalage succinctly yet again [1] below.

This causes friction for the product innovation team and slows down developer productivity.

Yep, I was at the receiving end of the query pattern change burn, but am still grateful for the experience.

[1] Fowler, Martin; Sadalage, Pramod J. (2012-08-08). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence (p. 109). Pearson Education (US). Kindle Edition.

Business Quote to Set The Tone for 2014

January 1, 2014

Some had emerged from the ordeal; others had perished. All had burned brightly in their lives.

This is from the book No Way Down – Life and Death on K2 by Graham Bowley and its the final sentences in the Epilogue. I added the bold font. You may wonder what mountaineering tragedies have to do with business? In my mind I draw parallels between mountaineers and entrepreneurs – regardless of the outcome of a venture trying is a form of success in itself.

The Benefits of Dependency Injection

November 30, 2013
tags: ,

In this post we firstly describe what dependency injection is, as background, and then articulate what the benefits of dependency injection are. We provide answers to these three questions below and also consider whether dependency injection containers should be used in every project.

  1. What is dependency injection?
  2. What Java frameworks or containers provide dependency injection support?
  3. What are the benefits of dependency injection?

What Is Dependency Injection?

When a particular class has a member variable (also called a field) that is an instance of another class then this is a dependency. How the initialization of instance members  happens and who performs this initialization is the crux of dependency injection or the dependency injection pattern.

Normally, without dependency injection, the particular class would have code to initialize an instance variable in a constructor with the two alternatives to this approach being initializer blocks or final methods.

With dependency injection, an instance of the dependency is provided to our particular class by an external party using either the contructor of the particular class or a setter of the particular class. So the external party is the who, and in term of the how this external party performs either contructor injection or setter injection.

Dependency injection frameworks alleviate the need for factories and the use of new in your Java code. Configuration instructions, via annotations or XML, replace new in your Java code. You may still write factories from time to time, but your code will not depend directly on them.

What Java frameworks provide dependency injection support?

The two major frameworks are the Spring Framework and Google Guice. PicoContainer is another alternative.

What Are The Benefits Of Dependency Injection?

In short your code will be easier to change, easier to unit test and easier to reuse in other contexts. We provides explanations for these benefits below, but before we do so, its worth quoting Anand Rajana [1] in terms of his summary:

It facilitates the design and implementation of loosely coupled, reusable, and testable objects in your software design and implementation by removing dependencies that often inhibit reuse. Dependency injection can help you design your applications so that the architecture [container] links the components rather than the components linking themselves.

Your code will be easier to maintain and easier reuse in other contexts.

This is because your object is handed what it needs to work and since it it freed from the burden of resolving its dependencies. When an object is handed what it need to work in terms of its dependencies by a container such as Spring, this is called inversion of control (IoC). One may wonder, why does this, that is IoC, make maintenance and reuse easier? Its because the components (plain old Java objects) that make up your application are loosely coupled as a result of your objects being handed what they need to work – its far easier to swap out a component as a matter of configuration than it otherwise would have been in a tightly coupled architecture.

It is also because dependency injection promotes programming to interfaces which conceals the implementation details of each dependency and naturally this makes it easier to swap out implementations of a given interface. The combination of your objects being handed what they need to work by an IoC container and programming to interfaces significantly enhances loose coupling.

Finally, it is because the centralized control over the object lifecycle brings with it a host of benefits that enhances the maintainability and re-usability of ones code. For example, Spring’s BeanFactoryPostProcessors are able to modify the definition of any bean in the ApplicationContext‘s BeanFactory before any objects are created. A good example of such a BeanFactoryPostProcessor is a PropertyPlaceholderConfigurer which substitutes ${variables} in an definitions with values from .properties files. In addition, a BeanPostProcessor may wrap your beans in a dynamic proxy and add behaviour to your application logic transparently. A good example of behaviour that can be transparently added is transaction management behavior that has been declaratively specified using annotations.

Your code will have significantly enhanced testability

This is because dependencies can easily be replaced with stubs or mocks in unit tests.

Should Dependency Injection Containers Be Used in Every Project?

This is a matter of opinion and so this will be the authors opinion. In short, the answer is no.

One may wonder why the answer is no. It is because one still needs to motivate why one needs all the benefits that come with using say Spring or Guice in one’s architecture. In short-lived prototyping projects maintainability and unit testing may not be the top priority, it could be that the bulk of the effort is say in producing a GUI prototype or experimenting with new technologies. It could also be that reusability is of no concern. Every project is different and thought and motivation needs to be applied to every technology decision.

To give an example of where the benefits of IoC may not be the top priority. The author was handed a micro project (single developer at a time)  that was in trouble in terms of delivery to the client, the top priority was to show the client results in weekly sprints, and the first decision made was to speed up local development and make the existing code generally comprehensible. This involved introducing Maven, the Maven Jetty plugin, JRebel, significant refactoring and much more. Results where delivered, albeit in a tightly coupled manner with hand rolled singletons (factories) and little unit or integration testing. The project later reached a stage where introducing an IoC container made sense in terms of priorities in order to realise all of the cited benefits, above all to introduce testing automation to stub out cloud services.

Although the short answer is no, its worth noting that the long answer is no but in general yes. More often than not prototyping projects go live, and it is in general unlikely that an application will require no maintenance after it went into production. So one should not set up fellow maintainers or one-self up for failure and 9 times out of 10 (if not 9.9 times out of 10) use IoC containers / dependency injection in order to realise the core benefits and that is code that is easier to change, easier to unit test and easier to reuse in other contexts.

References

  1. Dependency Injection, Slideshare, Anand Rajana
  2. Core Spring. Student Lecture Manual. Version 3.2.
  3. google-guice (its worth listening to the presentation, they provide good examples in their slides)
  4. Inversion of Control Containers and the Dependency Injection Pattern, Martin Fowler, 23 January 2004 (somewhat longwinded)

The programming, zbgureshpxre manifesto – what it really means

November 29, 2013

I stumbled across the programming, zbgureshpxre manifesto (by Zed A. Shaw) a while ago and have been thinking about its serious side, that is, what it is really saying.

In my mind its a stab at the unintended side effects of scrum or agile and above all an expression of frustration with individual excellence and programming /software engineering skill not being measured or celebrated.

When it comes the unintended side effects of agile, Dušan Omerčević has done the hard yards and posted a presentation on the topic. To borrow from his presentation, which I would recommend reading as he both elaborates on and provides remedial strategies on each point, these are some of the potential unintended side effects of agile:

  1. Generalization of the Specialist
  2. Extrovertion of the Introvert
  3. Productivization of the Engineer
  4. Suppression of Excellence

Kudos to Dušan for providing constructive strategies to counter all of the above. I would add one more item to the list though, and that is that more often that not agile leads to noisy working environments that lead to low productivity. The solution to an open plan environment is quite simply to do what Joel Spolsky’s Fog Creek Software does (and I believe Amazon Web Services does in Seattle at least). They aim to give every developer a private office. Its well worth reading this post “The new Fog Creek office” and having a look at their office design, but we warned, it may bring tears to your eyes, it really is that beautiful.

Java B-Tree Implementation Index

September 1, 2013
tags:

Tree of lifeIts been a solid 13 years since I completed Computer Science 2 with the bedrock Algorithms & Data Structures  course. Its time to brush up on the fundamentals, starting with the B-Tree.

Here is a list of existing implementations that I managed to find, there was one more but it disappeared from Google Code:

  1. JDM3′s BTree implementationvery well documented and comes with delete/remove functionality which is often missing.
  2. Princeton CS (HTML file) – no delete/remove functionality.
  3. Apache DS B-Tree Base (Mavenized).

I initially used 2. when creating an inverted index but got burned as I ended up needing 1.’s remove method for index maintenance. I only found the JDBM3 implementation after more digging.

Follow

Get every new post delivered to your Inbox.