Smoke Tests for your System

When you run our smoke tests from a console we show the
results to the terminal.

Me and another team member took our most recent lab week to do something incredibly un-sexy.  Our resumes have no new libraries, buzz-words or languages that we can add.  We decided to use some old-school tools to create a very tactical set of smoke tests for our system and for the back-end systems that we depend on.

Our system is used by many clients.  When we get requests we then turn around and talk to about 20 different back-end systems.  Many times we are caught in the middle when there are anomalies found by our clients.  When this happens we have to turn to the logs to see if there's a problem with a system we depend on.  We also didn't have much visibility when our systems were not acting as they should.

A more boring example of an HTML report we can generate.

The principle is this.  Create a shell script that will run a bunch of other shell scripts in a directory.  If the script sends back an exit status that is bad (other than 1) we will consider that test failed.  The runner has a simple check for that and will echo PASS/ FAIL based on what we get back.  We also color the text green or red based on the results.  3/4 of my career has been about making red things green.

The output is so simple that my wife looked at a screen with a bunch of red and said, "that doesn't look good."  I'm not sure if we'll opensource it, there isn't much intellectual property to speak of.  We decided to set up the scripts to run in a cron job once an hour and generate an HTML report showing the same type of data.

We set a low bar on the smoke tests, sometimes they use cURL to POST a SOAP request and we just look at the response to see a specific piece of information is present.  Sometimes we just use NMAP to convince us that the port is warm on the far end and NMAP at least thinks it's the right type of application.  The idea is that these tests should be written in 5 minutes.

We're not sure how these will be used.  We hope that folks that support operations (including developers) will see new problems that come up not only as an opportunity to diagnose the matter at hand but to also add another smoke test that will give us a more clear indication of the problem the next time around.

This was an incredibly tactical bit of software that won't win us any design awards but it has already paid off a handful of times.  I regret that we didn't put something together like this sooner.

Back to 5/3/1 for 2013

Starting the year off with a round of 5/3/1.  Of course because Jim Wendler isn't as smart as me I had to tweak it some more.  I don't like interspersing pull movements within my push days.  So I consider the deadlift day a mini-pull day, I throw in some shrug/ upright rows.  Also I added an additional day to his 4 day template for just pull.  It's not programmed like 5/3/1 just AMRAP for 3 sets of pull-ups.  Which for me probably means about 5 total pull-ups.

Similar to what I was doing at the end of last year I do the main exercise for more volume after the 5/3/1 set each day.  This is almost like the boring but big routine in the 5/3/1 book.

More on the shrug / upright rows.  I really like that exercise.  I pick a weight that would be challenging for upright rows.  For me that's about 135.  I do 2 shrugs with the barbell then I do an upright row.  10 reps get very challenging.  It hits the traps great.

I recently began trying out 20 rep assistance work for legs.  I'll do squat and deadlift like normal then for example on squat day program in 20 rep quad extensions.  I don't have measurements but this has made jeans fit much tighter in the right places, good stuff.  I've had to bring the weight down.  I also limit the range of motion on quad extensions and I haven't noticed any new knee badness from the exercise.

I continue to really focus on the neglected delts on press day.  I was doing all cable work but I'm mixing it up a little bit with the medial delt db raise.  I don't do any direct tricep work on press day.

I have lowered my squat numbers from last year.  I'm not worried about the numbers so much, I want to keep that good form, really sink it in.

Maven 3/ Maven 2 mixup on Mac

At first my Mac was all:

~/opt/maven/bin>mvn --version
Exception in thread "main" java.lang.NoClassDefFoundError: org/codehaus/plexus/classworlds/launcher/Launcher
Caused by: java.lang.ClassNotFoundException: org.codehaus.plexus.classworlds.launcher.Launcher
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

And then I'm like (in my ~/.bashrc)

export M3_HOME=$OPT/maven
export M2_HOME=$M3_HOME
export PATH=$M3_HOME/bin:$PATH

So now it's all:

~/opt/maven/bin>./mvn --version
Apache Maven 3.0.4 (r1232337; 2012-01-17 02:44:56-0600)
Maven home: /Users/demian/opt/maven
Java version: 1.6.0_37, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"

Java JDK 1.7 on Mac 1.8.2

I've been doing Scala and Groovy at the day job for about a year now.  For some side work I thought I'd use Java, there obviously aren't enough semi-colons in my life.  I haven't touched 1.7 yet and setting it up on my Mac wasn't incredibly intuitive.

I had to do more poking around to arrive at this than I wish I had to.

Finding the actual download from Oracle is easy.

After installing Java 1.7 from Oracle I added this to my ~/.bashrc to actually use it.  Not sure if the install should've done this or if I missed some steps I was supposed to take.


export JRE_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/
export JAVA_HOME=$JRE_HOME
export JDK_HOME=$JRE_HOME
export PATH=$JAVA_HOME/bin:$PATH

And holy cow Oracle does not make it easy to find out how to download the JDK 1.7 API documentation.  Got to have it local for coding on an airplane.

Central Acadiana JVM User Group

I am attempting to set up a JVM user group here in Lafayette, LA.  Central Acadiana JVM User Group will hold it's first meeting this upcoming Monday at Buffalo Wild Wings in Lafayette, LA.

I come from Denver where the JVM is very popular.  Most of the work I have done and the people I have talked to in Denver are doing it right; in a more light-weight way.  I imagine most parts of the country are doing JVM work are using heavy application servers from Oracle or IBM.  I haven't done that since 2004.  Anything I've done since then that needs to go over HTTP runs inside Tomcat.  

I think Java is big in Denver because of the telecommunications background.  People worked with C and Unix.  A transition to Java made more sense than .NET.

In Lafayette, as far as I can tell .NET is big for enterprise development.  There is a lot of embedded development going on and that of course is down in C.  There's also some LAMP and ColdFusion.

So yeah, I'll let you know how it goes.  As you can tell from the icon I chose for the meetup, I don't expect a lot of people to join in.  If another human shows up interested in the JVM I'll change the icon to something other than the forever alone guy.

Podcasts

Here are the podcasts I follow these days.

• Java Posse
• The Scala Types
• The Groovy & Grails Podcast
• Career Tools
• Chariot TechCast
• Chariot Developer News

Another Look at Play2

Matt Raible has some good writeups on Play2.  We switched to Scala about a year ago.  For lab week, a few of us evaluated Play earlier this year.  At the time I mostly worked with the persistence layer, anorm.  Our conclusion was that it wasn't quite ready for what we wanted to do.

Just recently I finished a lab week and decided to take another look at Play.  Here are some conclusions.


Overall
The big question is, compared to what.  At work we use Grails on the web side and Scala on the back-end.  The reality is that we leverage front-end engineers to help us make Time Warner Cable web sites look and behave well.  In our situation I don't think I can recommend it.  But if you're in a hardcore Scala shop and your Scala engineers can do enough of the front-end work then Play might be a good option.

Working with routes and templates felt a lot like Android development.  You work in a non-code DSL to create your routes and that turns into code that you write against.  Same for templates, they just turn into functions.  sbt run fires up their own netty server, it's solid.  It does a great job picking up changes. I didn't restart the play development server for a few days and it didn't miss anything.  Play also gives you helpful error messages in the browser when there are problems.

Routes
They're handled in a text file.  I guess it's good because there's no cruft surrounding the definition of your routes.  It's bad because I think Scala is the perfect language for defining an internal DSL to handle routes.  It'd be great to have IDE support while working with routes.

Controllers
Everything feels very idiomatic to Scala.  For example optional parameters are (drum-roll) Options.  Play doesn't have you use servlet filters, you just wrap functions.  The controllers themselves are not easy to test but there are workarounds such that you can do good unit tests.

Templating
It's familiar to someone used to Scala.  Templates are just functions and have input parameters with types.  This gets statically checked and your IDE will bark at you if you send the wrong data type into a template.  I think that's awesome.  The templating is not as rich as Groovy Server Pages.  For the actual templating work there is no good IDE support.  It'd be great if TypeSafe took this on.  The templating that Play gives you would be painful for front-end engineers that are only familiar with HTML, CSS and JavaScript.

Testing
They have utilities to help with testing.  All the examples use Specs, I haven't got the Specs memo yet, still using jUnit (get off my porch).  The biggest problem is that the controllers are objects so it's hard to do good unit testing.  I found a workaround that someone suggested.  Basically your controller is a class, in this case taking a dependency via the constructor.  Then the object that you tell Play about in the routes extends that class.  This seems to work in my toy example.

object MockUp extends controllers.MockUp(new ProductionGuidCryptoServiceProvider()) {}