Simplify your code review process

Managing a repository can require tedious administrative work, and as pull requests increase, it becomes even more complex. Today’s review flow lacks important visible information that leads to serious management issues.

Rivi is an innovative tool that automates repository management. 

I've recently launched a hosted Rivi service (at http://rivi-cm.org ). 

Simply by adding a rules file (YAML) to your repositories and you can take advantage of the service.

Using crane for github-like docker development

Note The version of crane described below is a modified one. Find it on my github fork.

If you’re custom to working with github that you’ll recognize the following flow:

1. You fork a repo (e.g. user/foo)
2. You commit and push code to your fork (e.g. bivas/foo)
3. You create a pull request (PR) to merge your changes with original repo.

This approach is usually referred to as upstream remote and branching model is taken from git flow.

The docker flow problem

When working with docker, you pull and push images to a registry. Usually, when using your own registry, your push, pull, tag, build cycle might get messy.

1. You pull company/foo from registry.company.co
2. The pulled imaged is now locally tagged as registry.company.co/company/foo
3. You write a Dockerfile to build a dependent image:
   a. Start with FROM company/foo ?
   b. Start with FROM registry.company.co/company/foo?
4. So you decide to tag the pulled image as company/foo Remember: You can’t use ARG in FROM directive, so your registry prefix is there for good (or until refactored)
5. Completed your local tests and you wish to push. Again, your tag your image and push it as registry.company.co/company/foo

Why can’t we simply do - pull, build, and push? Let someone else deal with the registry and tagging.

The crane flow

So we have our registry at registry.company.co, our images are prefixed as company and all our Dockerfiles begin with something like company/foo. We extended crane to support our flow of pull (from official registry), build (locally on developer workspace, and push (to a user registry for backup). The entire flow keeps the original image name as company/foo but knows when to change tags to support other flows.
Here’s an example crane.yaml file:

containers:
  os:
    image: company/os
    build:
      context: os/
    pull:
      registry: ${DOCKER_REGISTRY}
 etcd:
     image: coreos/etcd:2
     push:
       skip: true
 service:
     image: company/service
     build:
       context: service/
     pull:
       registry: registry.company.co
     push:
      registry: registry.${USER}.company.co
      override_user: ${USER}

The added directives:

• pull.registry = which registry to pullfrom
  
  • crane will pull from registry.company.co/company/foo and locally tag it as company/foo
• pull.override_user = which user to pull as
  
  • crane will pull the specified image as ${USER}/foo and locally tag it as company/foo (useful when testing against your version of the container stack.
• push.registry = which registry to push to
  
  • crane will push to registry.company.co/company/foo the image locally tagged as company/foo
• push.override_user= which user to push as
  
  • crane will push the specified image as ${USER}/foo the image locally tagged as company/foo (useful to backup your images in registry)
• push.skip = skip the image when attempting push (useful when dealing with community images)

Now, a developer can easily work with FROM company/foo directive without dealing with re-tag. She can also modify company/foo and keep a backups without the need to re-tag the entire images stack.
We have a github-like development cycle of “forking” (pull) the official registry, pushing images to your private registry for development and backup (push). Once the developer is satisfied with the modifications - she creates a normal pull request to the modified Dockerfile.

Duration to Human Readable Format

Any developer at some point writes this kind of code snippet:


And how often the above developer wishes to output this duration variable in some human readable format?
Here's a short utility to perform such conversion


Enjoy (and don't forget to credit in case you borrow this code)!

Factory Pattern

Continuing my series on Design Patterns (builder, strategy), I'll focus on one of the most commonly used patterns in object oriented programming - the Factory Pattern. 

In fact, there are actually 3 different patterns named factory (in some form): Factory Class, Abstract Factory, and the Factory Method. Each pattern has a different intention or use case but all handle the same problem of creating object instances during application runtime. Factories usually hold some creation logic and don't have much purpose if the object created can be easily constructed outside the factory.

Factory Class
Used to create an instance that is difficult to construct in normal initialization. Such difficulties may involve wrapping our instance with cache or other AOP operations. Some frameworks, such as Spring Framework use BeanFactory to initiate Beans by integrating with Spring's application context and provide the framework features on newly created Beans. A simple use case may be as follows:
Usually, it's good practice to hide your class construction from being accessed through different flows. A better way is to replace new with a factory class.

Abstract Factory
Next level of hiding our class initialization after the Factory Class. Here we're creating a hierarchy of factories that construct a super object (interface). We select the specific Factory Class to invoke during application runtime.
Factory Method
We've manage to hide the construction of objects from our use case flows but still our factories use new to construct the object. It is perfectly OK to initialize some objects with their constructor. There are times, however, when this isn't the best practice. For example, the constructor is too complicated, or we want to create a default instance with a particular set of arguments. In Java's Locale, such behavior is perfectly described in the Locale.getDefault() method, which constructs an object after reading system properties, without the user interacting with the object's constructor.
To summarize, it's good practice to hide your object construction in order to enhance your application modulation. Factories are perfect for that purpose but don't over use them or you'll end up having an empty layer around a simple object construction. Factories can also help in your clients' use cases by providing them with helpful construction methods (such as Factory Method or methods of a Factory Class).

Comments / Suggestions are welcome.

Prevent EhCache From Storing Null Values in Cache

For quite some time we've been using the @cacheable annotation in our application to enable cache on designated use cases. As a default behavior, any flow passing through the annotated method is cached by the calling method (with arguments, if applicable) as key and the returned value as the cached value. EhCache uses an Element object to keep records in the cache store so that even if we return null from methods, an element entry will be cached (EhCache also stores thrown exceptions if you wish it).

But what if we don't want to cache nulls? There isn't any configuration attribute you can set to prevent such behavior. So how do we handle such a scenario? We can write a CacheEventListener to remove null value entries. The CacheEventListener can look something like this:
EhCache requires a factory to be declared in order to enable it to use our customized listener. Since my event listener is stateless, it can be used as a single instance. So my corresponding factory can look as follows:
Now we need to tell EhCache to enable this factory on cache events. ehcache.xsd supports declaring cache event listener factory per cache configuration. Declaring such factory on the target cache is as follows:
Now elements are removed if their cached value is null. Use wisely.

Running Play Framework Application on CloudFoundry

I've been waiting a long time to give CloudFoundry a try. Few minutes after the press release announcement I was on the waiting list, waiting to get my account activated. While waiting (not so long but I just can't sit still without doing/learning something new), I started reading and trying to work with Play Framework. As soon as I got my micro account approved I started my journey of running a Play Framework application on CloudFoundry cloud instance.

I've used Play Framwork v.1.2.2 and CloudFoundry micro VM rc1. I've also used the VMC tools v.0.3.12. I started by taking the introduction application and basically configured it to work on the cloud. I'm sure there are better ways to configure Play but for a very simple configuration, most of the information shown below should be enough.

First of all, it's required to add a dependency to CloudFoundry runtime library to obtain services information, such as MySql connection URL and credentials. This library isn't on Maven Central reposiroty so I had to add a repository to my dependencies.yml configuration file.



After updating my Play application dependencies I was ready to write a PlayPlugin for reading CloudFoundry service information and keep those setting for DBPlugin connection creation. All Play configuration is stored in Play.configuration and can be easily altered if you place your modified plugin prior to other plugins.



To start the CloudFoundryMySqlBootstrap before DBPlugin I simply created a play.plugins file located in the application app folder.



My Play application was ready to be pushed to the cloud. All I needed now is a WAR to deploy.



Got it :-)
Using VMC push command I created and started my Play Framework application and published it.

As show on the browser http://playframework-demo.cloudfoundry.com:

Try it or another Play Framework demo application deployed on http://playframework-contact.cloudfoundry.com/

Disclaimer at the time of writing this post, I'm a VMware employee, not part of the CloudFoundry team, but just to be honest. :-)

EDIT: There's a Play Module now available http://www.playframework.org/modules/cloudfoundry

Why Do We Care?

I am sure you are all familiar with it; every development group has at least one crazy yahoo who keeps shouting: clean code, more unit tests, continuous integration, decouple layers, quality, quality.... quality!! If you are such a person - Thank God and welcome to the club :-)

Why would anyone willingly take a role of Software Development Don Quixote? Let's try to analyze it.
First of all, what are we fighting for? Money! strangely - no. Promotion! again - no. We're fighting to get better dev tools, raise code quality, reduce bug cycles, reduce maintenance cost, reduce new features cost. Odd, but none of the above will give you any personal gain. The only ones gaining from this are our software product, our company and eventually - our clients.

Why do we do it? we do it because we care. Simple equation: when you write bad code - you don't care. We get paid for our work and we're trying to give it's worth in coding. When you justify your salary with skilled labor: you're not doing anything special - you're just doing your work.
For example, let's take a restaurant scenario: every time you go there you have to return your order several times because it's not properly made and when you examine the kitchen you see an old stove, dirty pots and pans. You wouldn't think the menu worth anything, right? Same goes with code, when you examine your tools, code quality and development cycle - is it worth your paycheck?

Why do we care? we care because we are pros! We take pride in our work and wish it to be as professional as possible. We strive to elevate quality around us, we are eager to learn more and we keep fighting those small code quality battles. We attend tech talks, meetups. We join forums, exchange technology ideas, form software groups (e.g. Software Craftsmanship) and try to set an example to other developers.

So, are we really that crazy for doing all of the above? No, we're professional developers.