30 June 2012

5' on IT-Architecture: Four Laws of Robust Software Systems | Javalobby

Interesting point here.  Given there is nothing permanent except change, its important that you build systems that are easy to change later?  Unit/integration tests facilitate change.

5' on IT-Architecture: Four Laws of Robust Software Systems | Javalobby
There is nothing permanent except change. If a system isn't designed in accordance to this superior important reality, then the probability of failure may increase above average. A widely used technique to facilitate change is the development of a sufficient set of unit tests. Unit testing enables to uncover regressions in existing functionality after changes have been made to a system. It also encourages to really think about the desired functionality and required design of the component under development.

28 June 2012

FolderSync • Reg Hardware

FolderSync • Reg Hardware
lets you synchronise your Android folders with SkyDrive and just about every other cloud storage supplier.

FolderSync supports most of the popular commercial cloud wallahs, including Dropbox, SkyDrive, SugarSync, Ubuntu One, Box, Amazon S3 and Google Drive. It also works with FTP, Samba/Windows share and WebDAV remote storage for the DIY enthusiast. It also supports multiple accounts of the same type.

Envers - Hibernate audit tables

Envers - JBoss Community
The Envers project aims to enable easy auditing/versioning of persistent classes. All that you have to do is annotate your persistent class or some of its properties, that you want to audit, with @Audited. For each audited entity, a table will be created, which will hold the history of changes made to the entity. You can then retrieve and query historical data without much effort.

The Netflix Tech Blog: The Netflix Simian Army

The Netflix Tech Blog: The Netflix Simian Army
Imagine getting a flat tire. Even if you have a spare tire in your trunk, do you know if it is inflated? Do you have the tools to change it? And, most importantly, do you remember how to do it right? One way to make sure you can deal with a flat tire on the freeway, in the rain, in the middle of the night is to poke a hole in your tire once a week in your driveway on a Sunday afternoon and go through the drill of replacing it. This is expensive and time-consuming in the real world, but can be (almost) free and automated in the cloud.

This was our philosophy when we built Chaos Monkey, a tool that randomly disables our production instances to make sure we can survive this common type of failure without any customer impact. The name comes from the idea of unleashing a wild monkey with a weapon in your data center (or cloud region) to randomly shoot down instances and chew through cables -- all the while we continue serving our customers without interruption. By running Chaos Monkey in the middle of a business day, in a carefully monitored environment with engineers standing by to address any problems, we can still learn the lessons about the weaknesses of our system, and build automatic recovery mechanisms to deal with them. So next time an instance fails at 3 am on a Sunday, we won't even notice.

Inspired by the success of the Chaos Monkey, we’ve started creating new simians that induce various kinds of failures, or detect abnormal conditions, and test our ability to survive them; a virtual Simian Army to keep our cloud safe, secure, and highly available.

Latency Monkey induces artificial delays in our RESTful client-server communication layer to simulate service degradation and measures if upstream services respond appropriately. In addition, by making very large delays, we can simulate a node or even an entire service downtime (and test our ability to survive it) without physically bringing these instances down. This can be particularly useful when testing the fault-tolerance of a new service by simulating the failure of its dependencies, without making these dependencies unavailable to the rest of the system.

Conformity Monkey finds instances that don’t adhere to best-practices and shuts them down. For example, we know that if we find instances that don’t belong to an auto-scaling group, that’s trouble waiting to happen. We shut them down to give the service owner the opportunity to re-launch them properly.

Doctor Monkey taps into health checks that run on each instance as well as monitors other external signs of health (e.g. CPU load) to detect unhealthy instances. Once unhealthy instances are detected, they are removed from service and after giving the service owners time to root-cause the problem, are eventually terminated.

Janitor Monkey ensures that our cloud environment is running free of clutter and waste. It searches for unused resources and disposes of them.

Security Monkey is an extension of Conformity Monkey. It finds security violations or vulnerabilities, such as improperly configured AWS security groups, and terminates the offending instances. It also ensures that all our SSL and DRM certificates are valid and are not coming up for renewal.

10-18 Monkey (short for Localization-Internationalization, or l10n-i18n) detects configuration and run time problems in instances serving customers in multiple geographic regions, using different languages and character sets.

Chaos Gorilla is similar to Chaos Monkey, but simulates an outage of an entire Amazon availability zone. We want to verify that our services automatically re-balance to the functional availability zones without user-visible impact or manual intervention.
With the ever-growing Netflix Simian Army by our side, constantly testing our resilience to all sorts of failures, we feel much more confident about our ability to deal with the inevitable failures that we'll encounter in production and to minimize or eliminate their impact to our subscribers. The cloud model is quite new for us (and the rest of the industry); fault-tolerance is a work in progress and we have ways to go to fully realize its benefits. Parts of the Simian Army have already been built, but much remains an aspiration -- waiting for talented engineers to join the effort and make it a reality.

24 June 2012

Spring 3.1 Constructor Namespace

Spring 3.1 Constructor Namespace makes it much neater to use constructor injection but you do need to use debug-compiled versions of classes

23 June 2012

Tracking Excessive Garbage Collection in Hotspot JVM

Tracking Excessive Garbage Collection in Hotspot JVM

Interesting looks like setting "-XX:GCHeapFreeLimit=20" and "-XX:GCTimeLimit=90" will help to ensure that OutOfMemory errors are generated earlier so that an application doesn't remain in degraded state involving too frequent garbage collections.

08 June 2012

GuavaExplained - guava-libraries - Every Java developer should read this wiki in detail

GuavaExplained - guava-libraries

Every Java developer should read this wiki in detail.
The Guava project contains several of Google's core libraries that we rely on in our Java-based projects: collections, caching, primitives support, concurrency libraries, common annotations, string processing, I/O, and so forth. Each of these tools really do get used every day by Googlers.

But trawling through Javadoc isn't always the most effective way to learn how to make best use of a library. Here, we provide readable and pleasant explanations of some of the most popular and most powerful features of Guava.

This wiki is a work in progress, and parts of it may still be under construction.

Basic utilities: Make using the Java language more pleasant.
Preconditions: Test preconditions for your methods more easily.
Common object methods: Simplify implementing Object methods, like hashCode() and toString().
Ordering: Guava's powerful "fluent Comparator" class.
Throwables: Simplify propagating and examining exceptions and errors.
Collections: Guava's extensions to the JDK collections ecosystem. These are some of the most mature and popular parts of Guava.
Immutable collections, for defensive programming, constant collections, and improved efficiency.
New collection types, for use cases that the JDK collections don't address as well as they could: multisets, multimaps, tables, bidirectional maps, and more.
Powerful collection utilities, for common operations not provided in java.util.Collections.
Extension utilities: writing a Collection decorator? Implementing Iterator? We can make that easier.
Caches: Local caching, done right, and supporting a wide variety of expiration behaviors.
Functional idioms: Used sparingly, Guava's functional idioms can significantly simplify code.
Concurrency: Powerful, simple abstractions to make it easier to write correct concurrent code.
ListenableFuture: Futures, with callbacks when they are finished.
Service: Things that start up and shut down, taking care of the difficult state logic for you.
Strings: A few extremely useful string utilities: splitting, joining, padding, and more.
Primitives: operations on primitive types, like int and char, not provided by the JDK, including unsigned variants for some types.
Ranges: Guava's powerful API for dealing with ranges on Comparable types, both continuous and discrete.
I/O: Simplified I/O operations, especially on whole I/O streams and files, for Java 5 and 6.
Hashing: Tools for more sophisticated hashes than what's provided by Object.hashCode(), including Bloom filters.
EventBus: Publish-subscribe-style communication between components without requiring the components to explicitly register with one another.
Math: Optimized, thoroughly tested math utilities not provided by the JDK.
Reflection: Guava utilities for Java's reflective capabilities.