Skip to content

Berkeley DB Java Edition – Gotcha Log

October 17, 2014
tags:

This post is simply a log of Berkeley DB burns or gotchas written as rules to be remembered. The post will be updated as time goes by.

1. Don’t just change your enum constants willy-nilly and deploy

If you are in development mode, running your app on your local lightweight container, then this one is easy to forget. Its good to get into the habit of having a staging environment with Berkeley DB in write-to-disk mode, even on your local, so that you can occasionally get burnt by Exceptions such as this one and so remember it.

java.lang.IllegalArgumentException: Deletion and renaming of enum values is not supported: STANDARD

at com.sleepycat.persist.impl.EnumFormat.initValues(EnumFormat.java:93)

Software Vendor Marketecture – Ruling The Roost?

October 10, 2014

Skyscrapers don’t get built with one pagers, and neither should software, no wonder our software skyscrapers often degrade to sprawling horizontal shanty towns.

If you are a stakeholders in a large scale enterprise development project, and all you have in terms the presented software architecture viewpoint documentation is the one page Marketecture diagram used to sell the solution you are in deep trouble.

This is one of the fundamental problems with the software industry, projects often kick off with specifications that are nothing but Marketecture and so nothing close to a Software Architecture Document (SAD). Marketecture is without a doubt valuable, but it is not the same thing as a SAD and not the hallmark of an engineering discipline. Skyscrapers don’t get built with one pagers, and neither should software, no wonder our software skyscrapers often degrade to sprawling horizontal shanty towns.

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 what 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)
Follow

Get every new post delivered to your Inbox.