FizzBuzz of the day

Like many pieces of code, there is always a story behind it.

Your FizzBuzz solutions of the day – using operator precedence to get a result

Or on one line.

 

Skiing Tahoe

A friend asked me the other day about skiing in the Tahoe area. This was for him and his wife getting back into skiing after being out of it for a few years.

Note: I will update this page, but for now I thought this table was really useful.

Destination Resorts

These are all resorts that are higher priced and have lots of acreage to choose from. They will have more village options for apres ski and lodging options at the base of the mountain.

Name Base Elevation Vertical Drop Acres Ticket Price
Heavenly 6565ft 3502ft 4800 acres $140
Northstar At Tahoe 6330ft 2280ft 3000 acres $140
Squaw/Alpine 6200ft 2850ft 6000 acres $134

Classic – Midsized Resorts

Served by classic lodges and you’ll have to commute to and from them. They are smaller in size and typically have lower ticket prices than the Destination resorts.

Name Base Elevation Vertical Drop Acres Ticket Price
Homewood 6229ft 1650ft 1260 ac $74
Mount Rose 8260ft 1800ft 1200 ac $104
Sierra-At-Tahoe 6639ft 2212ft 2000 ac $93
Sugar Bowl 6883 ft 1500ft 1650 ac $103

Small

These are the small resorts in terms of acreage, many will still only have fixed grip chairs (slower) and less vertical feet to ski. The upside is that the ticket prices and lesson prices are lower which can make for great learning hills.

Name Base Elevation Vertical Drop Acres Ticket Price
Boreal 7200ft 500ft 380 ac $59
Diamond Peak 6700ft 1840ft 655 ac $64
Donner Ski Ranch 7031ft 1000ft 505 ac $59
Soda Springs 6700ft 652ft 200 ac $69
Tahoe Donner 6750ft 600ft 120 ac $47

 

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 (http://www.geometer.org/sgi/wsj.txt)
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.

 

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.

Conclusion

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.

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.

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.