Delivering Delight Requires Execution

I do like delight, I really do.

I was wondering last night about why saved searches have sucked for so long. Got thinking about some slides I’m putting together about quality. Part of it is that “move fast and break things” is counter productive to where we need to be, we need to move fast, but letting people internalize “break things” is part of why I think we’ve not put the attention into resolving it (aka excellence).
Maybe it’s —
   Deliver delight by excellent execution
If this was SGI, it probably would have been a BINGO (
Though that’s the concept that I think is important. We can’t delight folks if we’re not striving for excellence. Excellence alone allows us to focus on the weeds and the not the result – think about polishing a rock, prettiest rock ever, still a rock.


Read More

ES6 and Angular + a little GoLang

This post really documents the checkpoint in my experiments with GoLang and Frontend development.  As some people might know that I’ve been playing around with application structure, languages and approaches for a while.

My GoLang AngularJS and ES6 Todo App over at GitHub – it’s the reference for the rest of this post.

File Layout

Some quick to points, general directory structure:

One general note is that I haven’t found an idiomatic directory structure for GoLang application development.  IMHO “app” should be the handlers and have a model/conf directory.  Still a work in progress.

While this is an ES6 experiment, I did look at TypeScript for a bit and while I like it due to being a typed language which should reduce a class of errors. I did have to wonder about is the cost of building the type definition files for projects worthwhile?  In a large organization I could see that this would pay dividends, but not clear from the get go.

What’s good about ES6

For past projects I’ve used CoffeeScript, since that is the standard which Tubular uses for projects and it’s always good to keep your mind working.  Plus as a Python/C programmer at heart I do find the CoffeeScript syntax where the parens are optional occasionally a bit hard to parse.

Top 3 likes of ES6

  1. classes
  2. import
  3. “=>” for functions

While it might be possible to go on, I haven’t had the chance to really fully exercise the language for my little ToDo app.  With the first two items the real need of CoffeeScript is diminished and allows you to program to the standard.

General App Structure

This is where preference starts showing up.  How to structure a good AngularJS application.  I’m sure there is some conventions that I’m not following, either through ignorance or rebelliousness.  The biggest area where I think application standards are interesting is routing.

What I think is important is the ability to say in your main.es6 file:

Then to have todo contain:

 This way you’re having the routing next to the controller, rather than having a massive route.es6 file which documents the whole application.

Note:  You’ll see that I also make use of browserify to load HTML into the controllers directly.  This makes it really easy to compress the whole application into a solid Single Page Application.


I think ES6 is a good framework for building out AngularJS applications. The general problem is application structure, which is always a combination of personal preferences and habits.  That said, the Grunt flow with Babel and ES6 is easy to setup and make the code much cleaner.

Read More

Continuous Integration Process

Was at a wonderful conference hosted by one of Tubular’s investors (FirstMark) where VPE’s, CTOs and key technical leads got together from a bunch of their investments to listen to speakers and have some good round table discussions.  I spent my time participating in a round table on development processes, which evolved quickly from “life is good” to “here is a rough spot we’re having’. It’s really refreshing to have honest communication about your problems rather than having to wear the customer facing hat of the world is perfect and of course we will meet your every need.  Note; Customers we do meet your ever need, sometimes the process is less than perfect to get there.

As we were wrapping up and went to grab buffet lunch. Was chatting about what we would do sooner now that we have a bit of perspective on what it takes to go from two people at a desk with an idea, to an organization.  What’s interesting is that we all agreed that putting Continuous Integration into the process earlier would be better, while this means different things to different people.  At the core —

  1. Setting up git auto builds with Travis CI – everybody thought that was the best place to start, with migration to Jenkins as inevitable
  2. Getting Unit Testing / Integration Testing in place
  3. Getting Continuous Deployment working

Having those three things early in an organization will help lay the fundamentals of a culture that will be more agile and able to iterate faster as the company grows.

Having the first two are bread-and-butter in the modern development practices, having Continuous Deployment is the big nut.  Why? It ensures that the responsibility for delivering quality code never leaves the engineering organization, that makes sure you stay agile.  The moment you introduce QA you will always have large releases, now you have a bottleneck on what goes out and lots of finger pointing at who is responsible.

Question: Who is responsible for code quality?
Answer: Engineering

As leadership in engineering my goal is to make sure that we understand that is our commitment.  So setting up tools early to make it easier to grow cannot be underestimated.

Read More

Principles of Microservices

Some principles that should be followed when designing micro services.

Accuracy – Fail hard or show full accurate results, never in between.

Our goal is to provide precise numbers customers trust. Sending incomplete numbers because our systems aren’t healthy can’t be an excuse, we should follow the rule of “all or nothing”.

Scalability – Predictable way to increase capacity.

Growing only the components that are over loaded. It’s easier to identify bottlenecks when it’s components that are fully instrumented and provide an accurate view of their performance.

Simplicity – Getting the whole picture and how our product is reflected in technology takes no more than one hour for anyone.

It’s important for new and existing team members to understand how system work and be able to jump into any area and figure out details as soon as possible.

Speed – Deliver as soon as we have new feature or bug fix.

Untestable code, long deployment cycles, high degree of dependencies or manual QA-ing are all blockers to make sure customers get fixes and features as soon as possible.  Small components with regression tests yield rapid deployment.

Ownership – Every component of the system is owned

Owner is the person who can answer any question about the service: current state, technical debt, development plan, core metrics, absolute numbers, issues etc.

Read More

Golang and Hive/Impala – Thrift

This started out as a quick project to see about taking a component of our service and migrating it from Python to Go. We’ve been talking about migrating services from the semi-monolithic version to more loosely coupled – the general idea is to move to Thrift oriented services. We have a core component of our system that uses Impala as a key backend, it’s a very stable service that could be logically broken out.

As an exercise for the weekend, started looking at golang and the ability to migrate it. While I can’t share the full code / details. As I was putting this together the resources for Go and Thrift are weak at best.

The first thing is that you need to get your “thrift build” aka Makefile right

Turns out that package_prefix is a big deal, since the thrift build is going to build a collection (not-just one) interface we need a way to make sure that they’re all available and name spaced.

Also – worth noting that HiveThing is a useful reference – though useses Hive Server 2 not beeswax.

The example code I ended up writing is here – hopefully this helps somebody in the future, figure things out just a bit faster.



Read More

NPS for Support Feedback

Quick observation:

At the end of any support email thread NPS rank it.  NPS is based on the key question “How likely is it you would recommend us to a friend?”  However, when dealing with support it’s never a “recommend”.  Could the question be one of these:

  • How satisfied were you with the handling of your issue?
  • How likely would support be a reason for continuing to use our service?

Just thinking that I want to rate a current interaction with a company as a “5” …

Read More