Interesting Stuff on the Web Feb 1st-7th


Docker have started talking about a new framework, calling it a Container-As-A-Service. There aren’t many details out yet, outside of a white paper, but it sounds like it will be a complete integration of the different docker services. More information will be provided at an upcoming webinar on Feb 16th, 1PM EST!


Finally this week showed many awesome steps forward with Docker Compose including the ability to set custom IPs and host aliases on containers! Also the Splunk integration will hopefully help get Docker more use in enterprise,


With the recent release of the AWS Certificate Manager and the ability to get SSL certificates for free, the base assumption is that you would use these everywhere! Ryan Brown points out the integration between AWS Cloudfront and Cert Manager isn’t quite there yet.. and then provides the full set of code for you to create a new Type to provide the integration!

This wasn’t the only awesome post by Ryan, he spoke with Speaker and provided another in-depth post of implementing the AWS API Gateway as a method of being a proxy passthrough to other APIs, and to keep the costs down, using AWS Lambdas!

Finally to wrap up some of the AWS stuff, was a new whitepaper by Puppet Labs, where they have been working to make managing nodes in the cloud easier by generating certificates based on the instance id, and keeping a track of running instances.

Puppet AWS Integration


Git hooks are very powerful, and this post really starts diving into some of the possible use-cases! I really like the post checkout check to include the branch’s current build status.

Git Hooks

Github posted about sub modules – linking and embedding projects in one repo. As they point out, this is an edge case, embedding external dependencies. I hadn’t even realized that git has these commands to make this easier to manage and thankfully the post goes step by step through a use case of implementing this with an existing project.

Finally one of the best things I saw this week was the Git Large File Storage. This was always a pain – debating what should go into source control, what is an artifact.. Turns out we could have just been using this, where you can configure it to store certain file types into lfs and the rest to your repo!


After college I rarely ever think about the underlying structures behind my code – the network stack, how the code is converted into assembly.. this is what made this post about firewalls and TCP sequence numbers so interesting.

Laura Frank posted a great introduction to Go concurrency patterns, starting off with what concurrency is, how it is implemented and end with a couple of great links including this one to help you visualize concurrency!

Go Concurrency Fanning

Cool stuff

Well now for some stuff that just doesn’t really fit anywhere else.. and first off are these awesome eagles.. sorry.. Anti-Drone devices 😉

Anti Drones

You don’t need to worry that this will boost the eagles confidence enough to take on us – thankfully science has thought ahead and we now have exoskeletons to combat the future eagle army!

This started off sounding awesome – the second life of the VR realm, AltspaceVR had just been released for the Gear VR.. Sadly it turns out that this is only for the consumer edition and no joy for the Note 4 users.

Now for anyone who likes leds, and trying to make Arduino led cubes, then you will love the 512 led Tittle and its awesome implementation! Hopefully they set this up with IFTTT integration, using this as a build light could be great fun 😉

And finally, for anyone who really wants to excel as a developer this Monday-Friday guide is a life saver!

Code Phage – Coding the Future

Roomba Path


At ACM SIGPLAN‘s recent PLDI, Programming Language Design and Implementation, conference several MIT researchers presented an automated bug fixing tool, Code Phage.

What really makes this tool stand out is that it is language agnostic, and doesn’t even need the source code! It will figure out what the other program is doing and implement that check with my own application.

The basis of this is in good design – that I’ve decoupled my classes so that for example my image processing class only deals with just that – processing images. Now I’m not the first person to process images and there are hundreds to thousands of projects that do this. Have I thought of all use cases? Not a chance – but if you took all the projects you should have a really robust set of use cases.

Code Phage relies on this – that I have a defect that someone else has coded correctly. It would need a database of these applications and the inputs that work for each.

Now with this dataset, I provide it an input that runs successfully in my application, the baseline, and an input that crashes it. Code Phage will search its database to find where both inputs are successfully processed. This stage is known as Donor Selection.

With a Donor application selected, Code Phage maps out the branching the application takes as it processes the baseline input. The idea is that when the error input is processed, the donor application will deviate from the baseline at a check that my application is not processing.

The genius of this program then comes into play, the researchers were able to map this process branching independent of the donor application, and by performing the same process branching on the recipient code, i.e. my application,it can pin point where this additional branching is required. Finally it can convert this branching logic into my specific language and update the source code successfully.

As the trend doings further decoupling, moving towards micro-services etc, this will really take developers out of the weeds of their programs and allow the to concentrate far more on the design and flow of their application.

The Stuff Behind the Fluff – A Recap of NFJS!



Last weekend saw the traveling roadshow of a technical conference, No Fluff Just Stuff Software Symposium Tour, arrived in Boston and I got to attend!

The tour features a number of fantastic speakers and the only issue is the problem trying to figure out which sessions to attend. I was able to cover a fair few which I hope to detail in depth in future postings.

I got an introduction to lambdas and streams by’s Venkat Subramaniam. It was great to see Venkat in person and interesting how his style was so similar to his talks online, foregoing slides in favor of live developing! He really drove home the benefits of functional programming with the following:

List<Integer> values = Array.asList(1,2,3,5,4,6,7,8,9,10);
int result = 0;
for(Integer value: values) {
	if (value > 3 && value % 2 == 0) {
		result = value * 2;


And then converted into the following:

List<Integer> values = Array.asList(1,2,3,5,4,6,7,8,9,10);
      .map(e->e * 2)

I caught Danny Brien‘s talk on HTML 5 Mobile Apps which took, for me, the unexpected turn of utilizing  html5 elements with javascript and CSS to take a packaged web app (Cordova/PhoneGap) and use it to behave more like a native application.

The slickest part of his talks was seeing Ionic in action as a method of live development. Alter your files, save, and the phone automatically reloads the page with the changes. The time cost of pushing native apps is certainly noticeable and this could help loads here!

Craig Walls gave an introduction to Reactor, a Spring framework. I struggled to see how to incorporate it into our tech stack at work, but the overall aim  of it is designed to allow a spring application process large quantities data to trigger on events. It does change my impression of Spring as a powerful, but slow and bloated framework!

I got a terrific introduction into the Java Messaging System by Mark Richards! He has covered JMS 1.1 and 2.0 across multiple books and O’Reilly videos. This was great in covering the use of JMS and the advances that came with JMS 2.0, advances that were 13 years in development.

I will be digging into Go as a result of Matt Stein‘s talk on Go for Java Devs. He covered the basics of the language, highlighting the differences in syntax between Go and Java.

Raju Gandhi covered both Gradle and Angular JS. It was great to finally get a proper introduction into both of these technologies. Gradle turns out to be incredible powerful, providing the build instructions of Ant/Maven, but allowing you to drop into Groovy to program to create even more complex tasks. Angular JS blew me away with the capabilities that come right out of the box, the fact we now can program controllers in javascript drives home how mature JS has become.

Kirk Knoernschild opened my eyes to how architecture *should* be done – and gave me my favorite quote of the entire conference,

Architecture that doesn’t match the implementation is a hallucination!

For all the talks, I don’t think any have been as practically useful as Nathaniel Schutta‘s Bulletproof Javascript! I came out of this with a host of tech to implement and use ranging from Node JS to grunt for setting up my code to analyzing it with jsHint and the gorgeous Plato to display code analysis results!

Screen Shot 2015-03-02 at 10.00.00 PM

Screen Shot 2015-03-02 at 9.59.36 PM


The conference will be returning to Boston in September, so I recommend folks check it out!


BattleHack Boston


This past weekend involved PayPal’s BattleHack being run from IsoBar upstairs in South Station in Boston! Having not even heard of BattleHack previously, I was in for a surprise with how this hackathon was to be managed.

The event was a 24 hour hackathon running from 1pm Saturday till 1pm Sunday with the aim of building an application that would benefit the community, and to be in the running for the prizes it also needed to integrate PayPal.

Some things really made this hackathon stand out:



The Food

I feel obliged to post this first as it was excellent! A constant stream of new items would appear throughout the hackathon – breakfast, lunch, and dinner. Beers and waffles. Crazy caffeinated items at around 2am.


Development Support

An awesome aspect of this hackathon was the involvement of both PayPal and any of the sponsors. There was always someone there from the company to help you if you ran into issues integrating their code into your application. Rather then pulling your hair out reading an API for the first time, these guys vastly simplified the process. I’d love to see more hackathons taking this approach in future.



How to describe this.. everything else falls into this giant category – from having massages (!) to an area with inflatable chairs to napping to Justin Woo and his amazing ability to keep people in the game! Justin was constantly wandering the floor and coming up with things to keep people awake and energized.

techsupportOur Hack

Given all this support, myself and Rahul hacked our way around Android and Ruby to provide an app we called Empowered Locals. The idea was to provide an application that someone walking around their local neighborhood could create an issue and try and raise some funds from the community to fix it.

With the two of us, I have to admit we got a lot of coding done! There were times we were flying high and times where there may be marks left from banging heads against tables – having a test fail constantly for a good half hour or more before realizing we were not passing the data correctly at all…

PayPal integration was very nice since they provided a sample application to base it off. While the plan at the time was to simple move the money into a separate PayPal account, I see now we could have created an agreement with the donors so that when someone finally steps forward to announce the issue has been fixed, then the money is transferred. Certainly more reading up on the PayPal use cases is required!


The Winners

It was great to see how polished some of the applications were after only 24 hours of coding! I’ll be very interested in seeing if any of the applications continue on to be fully fledged apps that go into use.

The winners were:

1. BUtiful Bois – Two BU students who wrote a mobile application that provides security measures while walking home at night. This included alerting friends if not home within 30 minutes, providing the latest information from local police. Sadly our demo was right after these guys so I was not paying as much attention!

2. Cannery – A group who melded hardware and software together for an important community project. They used android and several shields to graph out data sets in Boston. These would include temperature, noise level etc.

3. Battlestars – A very organized group that developed an app for used with charity runs, whereby donors got alerted as the person runs the course passing set milestones.


In summary this was a blast and hope more people sign up to attend this series!


Android and Robotium (To the rescue!)



Ah, I love a good regression suit that passes after check-in!

This is where Robotium is really making a big difference for me especially as I try and adhere to Acceptance Test Driven Development, ATDD. The basis of ATDD is designing a test around the acceptance criteria/success measures of a story/task/use-case. This is done before development and once you have it passing, that is it – development is done (ok.. plus any cleanup, re-factoring..)!

Given a story, we break this down into the individual tasks the user takes and each task will have an ATDD test. Our story is:

As a User,
I want to find a bar,
So that I can see it's menu

When we break this story down into its individual tasks we get the following list:

1. User clicks “Find Bar” button from the main menu

2. User enters bar name into input field and selects “Search”

3. User is returned the bar’s menu

So each of these becomes a test case which starting off all fail:

package com.robotium.test;
import com.robotium.solo.Solo;
import com.balortech.MainActivity;
import android.test.ActivityInstrumentationTestCase2;
public class BreezeTest extends ActivityInstrumentationTestCase2{
	private Solo solo;
	public BreezeTestTest() {
	public void setUp() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
		//setUp() is run before a test case is started. 
		//This is where the solo object is created.
		solo = new Solo(getInstrumentation(), getActivity());
	public void tearDown() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
		//tearDown() is run after a test case has finished. 
		//finishOpenedActivities() will finish all the activities that have been opened during the test execution.
	public void testMainMenuFindBar() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
		assertTrue("Main Menu's Find Bar button sends the user to the right activity", false); 
	public void testFindBarSearch() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
		assertTrue("Entering a bar's name in the search field send the user to the results", false); 
	public void testBarMenu() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
		assertTrue("The bar's result page shows up correctly", false); 

Then taking the first test we start to build out it out:

public void testMainMenuFindBar() throws 1.5.0/docs/api/java/lang/Exception.html">Exception {
		solo.clickOnMenuItem("Find Bar");
		//Assert that NoteEditor activity is opened
		solo.assertCurrentActivity("Main Menu's Find Bar button sends the user to the right activity", "FindBar"); 

At this point we leave the ATDD and begin building up our Unit Tests and the code to drive those – again the Unit Test written first, implement the java to pass it and so on. At the end when the final Unit Test passes, the ATDD test should pass. Then on to the next one!

Happy testing folks 😉