Java 8 has revolutionized Java. It’s easily the most significant release of Java in the last 10 years. There are a ton of new features including default methods, method and constructor references, and lambdas, just to name a few.

One of the more interesting features is the new java.util.stream API, which as the Javadoc states, enables

functional-style operations on streams of elements, such as map-reduce transformations on collections

Combine this new API with lambda expressions and you end up with a terse, yet, powerful syntax that significantly simplifies code through the application of projections.

Ahoy!, which is an asynchronous SQS adapter for AWS’s Java SQS library, is now syncing with Maven Central. This means you can easily use Ahoy! in your Maven or Gradle builds.

For example, if you want to spice up your SQS and you use Maven, just add the following dependency for your pom.xml file and you’ll be rockin’ it in no time, baby!

1
2
3
4
5

<dependency>
  <groupId>com.github.aglover</groupId>
  <artifactId>ahoy</artifactId>
  <version>1.0.1</version>
</dependency>

You don’t use Maven? But rather use Gradle? I’ve got you covered!

1

compile 'com.github.aglover:ahoy:1.0.1'

Check out mvnrepository.com for how to include Ahoy! into your SBT build or other dependency management tool like Ivy.

A continuous delivery pipeline that leverages Jenkins and targets Heroku is fairly simple to set up, provided you install the Jenkins Git plugin. With this pipeline, changes to a specific Git branch will result in a Heroku deployment.

For this deployment process to work nicely, you should use at least two Git branches, as you’ll want to have one branch targeted for auto-deploys and another that doesn’t (as it represents active development). For example, following the git-flow convention, those two branches could be named development and master, where changes to master are deployed to Heroku and changes to development aren’t. Thus, you will have at least two Jenkins jobs that monitor each of these branches.

There’s an instructive post on the HipChat blog regarding how their product’s message count has risen from 110 million to over a billion since they were acquired by Atlassian. Central to their scaling strategy to meet data growth was their migration from Lucene to Elasticsearch.

In the land of Ruby there’s a few client libraries for Elasticsearch, however, one stands above the rest with a comprehensive set of features and remarkable documentation: Tire.

With its DSL based API, you’ll find working with Elasticsearch straightforward and a lot of fun. And even though the project’s repository has been renamed to retire, the Tire library

will continue to work…bugs will be fixed and important features will be added.

In my opinion, for the time being, Tire is still superior to the elasticsearch-ruby alternative in terms of features and its elegant DSL.

Single branch development is easy. But this strategy’s easiness blows up once you release code to the general public. If you need to hot-fix an instance of deployed code, while in the midst of a development cycle, single branch development gets in your way by requiring you think. On the other hand, having more than one branch at least allows you to jump back in time via an alternate branch to perform a patch, while not disturbing an unfinished developmental branch. And you can do this without having to think much.

Are you looking to get going with Elasticsearch as quickly as possible without having to worry about installing Java or Elasticsearch itself? Are you looking for a repeatable and automated mechanism for bringing up Elasticsearch instances for developmental and or testing purposes? While there’s certainly a number of Elasticsearch-as-a-platform service providers out there, there’s one other option: use Elasticsearch-in-a-box.

Elasticsearch-in-a-box is a freely available Vagrant base box. What that means is that you can quickly fire up and tear down an Elasticsearch environment with simple commands like vagrant up and vagrant destroy.

Recently, the good folks over at Packt Publishing gave me a copy of their newly published Instant Mockito, by Marcin Grzejszczak. Packt’s Instant series are really enjoyable. The premise of these books is that they’re short and sweet. They’re slightly more than a tutorial; they get you up and running quickly while throwing in a few more facets that go beyond the typical tutorial.

As I’ve written about before, Vagrant is handy tool for creating localized VMs. It’s a lot like firing up EC2 images, but, for the most part, things are localized (you can, by the way, use Vagrant to fire up EC2 images). If you’ve ever used VMWare before, its the same thing, except Vagrant is free. You can create VMs of various operating systems, fire them up, and tear them down all with ease.

Vagrant plays nicely with hip DevOps frameworks like Chef and Puppet and if your installations require a number of components, then these tools are defiantly the way to go. Sometimes, however, a simple Bash script is good enough as in the case for auto-installing some base component, like Java, Node.js or Ruby.

Using Vagrant’s configuration file, aptly dubbed Vagrantfile, you can instruct a VM instance to run a series of steps – these steps can be simple shell scripts, Chef cookbooks, or the Puppet equivalent.

Vagrant is a handy tool for creating VMs. It’s a lot like firing up an EC2 instance, but in Vagrant’s case, everything is localized. And best of all, it’s free.

I tend to favor Ubuntu as my preferred flavor of linux; consequently, all production EC2 instances use a customized Ubuntu AMI. Testing various aspects of this system with various software libraries, however, is initially tested locally using Vagrant VMs. What’s more, you can install localized VMs of other operating systems ranging from Debian to OpenSuse to Heroku’s Cedalon.