Archive

Archive for the ‘tech’ Category

cool tools, cool project

November 30, 2012 Leave a comment

i’ve had the good fortune to work on a green field Rails project. Here are some of the “i would not want to do without” tools used on this project

  • ruby 1.9.3 – so much faster than 1.8. wow. 
  • rails 3.2 –  rails just keeps getting better and better.
  • mini-profiler –everyone should want a fast app. found lots of unoptimized queries.
  • sass — sass makes css fun!
  • coffeescript — coffeescript makes javascript feel like ruby.  that’s a good thing IMO.
  • poltergeist/phantomjs – headless javascript testing. so much better than having Firefox popup.
  • rspec — i love the rspec DSL.
  • capybara — super useful for our request specs.
  • devise — it works.  easy to use.
  • vcr — essential for service tests. call out once, but cache after that.
  • cancan — great role system, easy to use.
  • kaminari — works great for paging (along w/ jquery.pageless)
  • sendgrid — send notification emails, easy w/ sendgrid
  • librato — low level metrics like rows written on some models,
  • machinist — love blueprints that are either persisted to db or not.  easy to use.
  • redis — super fast key value storage.  great for caching.
  • resque & resque-scheduler.  for asyn and cron jobs, easy to use, fast.
  • simple_form — a great improvement over standard Rails forms
  • airbrake.  you want to know when exceptions happen!
  • activeadmin.  most everyone needs a admin backdoor to their app right?  here it is!

 

Neat stuff that we use that i’m not huge on

  • inherited_resources — i prefer seeing the controller actions explicitly.  it makes peer review on-boarding new people easier.  less magic.

Other essential tools & practices

  • a great, easy to use CI system.  We use CircleCI.  nearly turnkey and hooks into github nicely. 
  • incremental checkins.  We use git, github, topic branches, pull requests, and ey cloud deployment commands.
  • peer review of pull requests:  either the code is pair programmed or the pull request is peer reviewed prior to merging into master
  • Pivotal Tracker.  A great simple tool that does the job.
  • NewRelic:  essential for app performance monitoring.
  • Mixpanel:  great for funnel analysis.  we measure all activities in our app and important properties for those activities.
  • Twitter bootstrap.  it’d be great to have the luxury of a talented designer, but we didnt.  this did a great job.  it’s important to get a designer in there eventually, or your app will look like a twitter bootstrap app.  this might be ok for a captive audience, but not mass consumption.

Using this great toolset has made this project a joy to work on.  Hope this helps others.

Categories: tech

our development team having some outdoor fun together

Our development team knows how to have fun. wahoo!!! What’s life but lots of tiny fun moments strung together? I think that doing non-work, outdoor things like this together creates the most durable of team bonds. And helps encourage each of us to get regular (outdoor) exercise which makes for stronger brains, body, & smiling personalities. Fun + stronger body & brain + team bonds equals a great place to work!

Here are a few pics from a recent thursday evening mountain bike adventure. We rode together, we helped each other when there was #Fail, we had fun with each other. Times like this strengthen the team.

Categories: tech

code smells

Here’s a slide deck on code smells in ruby I recently put together to show our development team.

Once everyone has an idea of why understanding and reducing code smells is important, then the benefit gets distributed when others use knowledge in pull request reviews.

Categories: tech

open source

made a open source contribution to the Chronic gem last night.  as always, feels good to help out the community.  we use other people’s open source work, we give back.

Categories: tech Tags:

a great software development project

I’ve had a long history of working on software projects. This history started off in C & then moved to Pascal, C++, C#, and now to Ruby/Rails. I’ve worked in consulting, IT, a handful of big name software shops (Microsoft, Amazon, RealNetworks), and smaller name software shops (Symyx, G5). I’m currently very pleased with the project i’m on, and wanted to share some of my observations of what i think makes this great software project, and a few other observations I’ve learned along the way.   I consider the below points a team & project recipe for keeping good people happy and delivering value.   My current company is G5.  My current project is G5 Reputation Manager

Here goes..

People. Keep teams small, focused, autonomous.

Keep the team small Small teams collaborate and focus better. Hire people that can communicate. Keep people that can be entrusted with autonomy. As much as possible, separate corporate minutiae from your project. Find another building to locate to if necessary. In hiring,  I’ve seen much better team dynamics and productivity by avoiding the “ninjas, rock stars, hackers, big egos”. You can tell a lot about people thru their twitter feeds. Try to hire a developer on contract for 6 months before bringing in full time. Probe candidates on how interested they are in continual self-improvement. For teams, I think the ideal team size is 2 developers (4 max) and one business owner. That’s it. No QA team to throw code over the fence to, no PM team. The strongest of these team members is the lead. The lead keeps on top of the team’s cadence and best understands the business problem. The lead inspires great work from the team.

Tools. Stay mainstream, lightweight…and delighted!

I am not religious about Ruby & Rails and I prefer to not work with people that consider their tool a godsend and refuse to consider others.  That said, i’m super happy w/ the expressiveness and beauty of the ruby language.  The value of this cannot be understated.  It never ceases to amaze me how deep the Rails community is…there’s a gem for nearly anything you might want to do.  If not, build it and contribute!  On our Ruby Rails project, I’m using a mainstream toolset in our stack that works great (& is invaluable to my skillset):  Pivotal Tracker,  Rails 3.2.3, Ruby 1.9.3,  Rubymine (vi), git, mysql, redis).  You want to maintain rhythm on delivering value to your customers, not spending days worrying why your CI server isnt working w/ your SCM.    Stay on current version w/ ruby and rails!  it gets harder to upgrade in Rails the further you fall behind.  A great suite of tests is invaluable for upgrades.   Use frameworks (like Twitter bootstrap) to speed things along.    Use a collaboration tool like Campfire or FlowDock for team communication (but turn off your growl notifications!)   What i like about FlowDock is the message inbox & the git/airbrake-rss/PivotalTracker integration.  We use AirBrake for exception notifications.  This tool has been great to show us where test coverage is needed and where our customers might be experiencing repeated problems.   

Agile.  Stay lean, short iterations, measure and pivot.

Start the project with a MVP.  Make your best stab at scratching a 10X itch.  Build in ways to measure the features your customers are using.  Pivot, improve, or kill features or direction as early as possible.  What good is it to spend 6 months of your team’s time to build a product that isn’t scratching the right market itch?   Be ruthless about eliminating waste:  don’t do standups if you’re not getting value from them;  don’t insist on pair programming if your team doesn’t favor it.   Stick to the essence of agile:  short iterations, adaption, quick feedback.  The rest will work out.    

Work environment.  Kill the distractions.  Let in natural light.  

Don’t skimp on a quality work environment.  Distractions are the biggest enemy of productivity.  Give developers a quiet, distraction free workspace with lots of natural light.  Natural light improves mood, health, and productivity.   Provide a walking desk and standup pairing stations.  Also, most developers love to work at home occasionally.  If working at home is producing quality commits to git, i’m all for it.   If a developer goes dark, nip that problem early. 

Quality.  It’s not optional.

When we started this project, even under big pressure to deliver yesterday, we started it off not compromising quality.  All code is reviewed, either thru  pair programming or git pull request reviews.  We measure code coverage (simplecov) every few weeks to check for missing holes.  We use flog to measure code complexity and refactor the trouble spots.  Our project code is idiomatic Ruby & well-tested…mostly thru isolated unit tests, and thru some higher level acceptance tests.  I prefer TDD, but dont insist on it.   With TDD, you know your tests are good and you know you’ve written just enough code to pass the tests.   But, depending on the context, sometimes I like writing tests after the code.   I think it’s important to allow some freedom in how developers like to work.   No compromises on making sure your tests are fast!   We do this by isolate business code from framework code as much as possible, isolated unit test the business code and integration test the stack.  Tests are written to the same quality standard as production code.  Make sure everyone on your team is experienced in recognizing code smells, using design patterns,  understands the importance of tests.   Dont be afraid to call out quality violations.  Set the quality bar high early on.   

Leadership.  Ya gotta have it. 

The self organizing team is a myth.   I’ve seen countless examples of great individual skill assembled as a team flounder without a clear leader.  Find, cultivate, and reward developers that show a propensity to lead, understand the business, and stay on top of technology.  Rails programmers can be found at any time.  But a strong technical leader is worth their weight in gold.  

Support the community. Find a way to contribute to open source.

Imagine life with ruby, rails, and the thousands of great gems out there.   We are using open source in our project and we owe something back.  It feels good to contribute. 

Organizational support.   A must have. 

It’s exciting when your CEO comes by your office and gives you real customer feedback on your project.  You’ve scratched a major itch!    It’s also exciting when your CTO pays you a personal visit at your home to let you know about a major customer event evangelizing your project.   It’s been a boon for us that all our project’s stakeholders have aligned priorities.   

Deployment.  Use the cloud. 

We’re using EY cloud.   Easy setup, easy deploys from git, and the best thing is easy spin up of staging clones to do topic branch testing.   When a topic branch is done, it’s reviewed, merged, and deployed.   It’s a joy that i can finish a topic branch, spin off a clone of production and test it there before deploying to production. 

Cadence.  Keep it reasonable & w/ smart use of time-boxing.

Give developers work-time/place flexibility and minimize distractions.  If > 40 hours are necessary, offer developers the option to be paid by the hour or gain a meaningful equity stake.   Dont expect more than a 8 hour day.  Even better is to measure on quality of output, not hours worked, and dont be a time-card puncher.   Treat your team with dignity and respect for their families and wellbeing.  Use meaningful deadlines & showcase-driven time-boxing (e.g., a trade conference where your product is being demonstrated) to maintain workable pressure and then celebrate when you’ve crossed the finish line.   But dont over use the time box or it will suck your team’s soul dry and you’ll find your developers quickly updating their linkedIn profiles.

Rest.  Enjoy.  And celebrate.

Humans are hardwired to pulse.  Pay attention to your physiological needs.  Take frequent breaks.  I like Pomodoro as a tool to encourage focus and force me to take frequent breaks.  Drink lots of water,  eat healthy, and exercise every day.  Sleep as much as your body needs.  Relax.  Your brain and body will thank you.   When you get great news from inside or outside your company, celebrate!    Do fun outdoor things with your team mates that dont involve coding!  Take frequent vacations.  Enjoy being alive and productive.

I hope others find this useful. p.s. I am indebted to my friend, Rails mentor, & co-worker Chris Kraybill, CTO at G5.

Categories: tech

great quotes from a NetFlix employee

January 5, 2012 2 comments

Great quotes from this article: http://perfcap.blogspot.com/2011/12/how-netflix-gets-out-of-way-of.html

Who has teams spread over multiple sites and countries? We don’t. It adds communication and synchronization overhead that slows your organization down. For the geeks, think of Amdahl’s law applied to people. We have as many people as possible in the same building on the same site. 

Who has junior engineers, graduate hires and interns writing code? We don’t. We find that engineers who cost twice as much are far more than twice as productive, and need much less management overheadReducing management overhead is a key enabler for an innovative culture. Engineers who don’t need to be managed are worth paying extra fo

Who has to work with people they don’t respect? It’s much too disruptive. The only way to get high talent density is to get rid of the people who are out of their depth or coasting.  

That also applies to what you might call brilliant jerks. Even if they do great work, the culture can’t tolerate prima donna anti-social behavior, so people who don’t trust others or share what they know don’t fit in  So does that mean we value conformity? No but it’s really important to be comfortable as part of a high performance team, so we look for people who naturally over-communicate and have a secure confident personality type

We’ve trained our developers to operate their own code.

Who has a centralized push cycle and has to wait for the next “train” before they can ship their code? We don’t. Every team manages their own release schedule. New code updates frequently, and the pace slows for mature services. Teams are responsible for managing interface evolution and dependencies themselves

Who has project managers tracking deliverables? We don’t. The line managers do it themselves. They own the resources and set the context for their teams. They have time to do this because we took the BS out of their role.Managers have to be great at hiring, technical and hands on enough to architect what their team does, and project manage to deliver results.

Hire experienced engineers who care, and they will take care of code quality and standards without being told how to.

We don’t pay bonuses. We don’t have grades other than senior engineer, manager, director, VP. We don’t count the hours or the vacation days, we say “take some”. Once a year we revise everyones salary to their peers and current market rate – based on what we are paying now to hire the best people we can find

Some of you may be thinking this sounds expensive, but what is the value of being incredibly productive and able to move faster than your competition? 

Give people freedom, hold them responsible, replace the ones that can’t or won’t perform in that environment. Focus on talent density and conserving management attention span by removing the BS from their jobs.

Categories: tech

a tiny ruby retry class

December 31, 2011 Leave a comment

Here’s a tiny ruby retry class.

class Retryable
  def self.attempt(options = {}, &block)
    opts = { :tries => 1, :on => Exception }.merge(options)
    retry_exception, tries = opts[:on], opts[:tries]
    begin
      return yield
    rescue retry_exception
      retry if (tries -= 1) > 0
      raise
    end
    yield
  end
end

Usage is like this

Retryable.attempt do
     #something that might fail, but you want to try it a few times
end
Categories: tech Tags:

a great software developer

November 19, 2011 Leave a comment

over the years, i’ve observed what i think are the top qualities that make a great developer.   IMO, it’s not that they’re ultra-brilliant, or can crank out 10,000 lines of top quality code a week, it’s a more well rounded package of qualities:

passion.  a great developer will always be reading a tech book, experimenting with a new language or library.  a great developer wants to help spread the knowledge around. a great developer is passionate about their craft and quality.

minimal ego.  big egos are not enjoyable to work with.  the more valuable minimal ego comes from solid self-esteem and good grounding.  minimal egos pair better, are more altruistic, and exercise better judgement.

honor/integrity – to self and community.  a great developer will bring honor to his/her work, is trustworthy even when not watched, and contributes or teaches to their community.

balance.  a great developer knows when to take breaks, when to sleep, to eat well.  this person knows to take time off to ski or bike, and to balance work time with family time.  exercise is good for the brain.  a balanced developer brings more to the table.  a balanced developer is better rested, a better thinker, operates better socially in a team.

judgment.  a great developer exercises good judgement gained from experience, common sense, & trial and error. they know not to squander company resources to an ego trip.  they understand that engineering is about balances, and doing the simplest thing to get the job done.  newbies can augment this facet with mentorship/pairing with other great developers.

desire to get things done.  a great developer has a relentless focus on done.  they work in sustainable rhythm, break things down into chunks of success, and celebrate when done.  they know when to not over speculate, they know when to refactor just enough to get the tests to pass and then call it done.  they understand the importance of the value they’re creating.

Categories: tech Tags:

journey from .Net to Ruby

November 19, 2011 Leave a comment

about a year ago, i switched from the .Net stack to Ruby/Rails.  I dont feel religious toward either stack, i think of them both as a tool in my quiver.  i get many questions from .Netters looking to do the same thing, looking for tips.  So, here goes:

  • get your black belt in ruby first.  learn to write idiomatic ruby!
  • go thru the Rails3 tutorial http://ruby.railstutorial.org/
  • pick a good editor (RubyMine is an excellent choice!)

After I got thru these steps, i started to specialize knowedge thru the Railscasts and Peepcode screencasts.  And build stuff in your spare time using these tools!

Categories: tech Tags: ,

memoize in Ruby

November 19, 2011 Leave a comment

Going thru this exercise really helped me gain some depth in ruby programming.  Take advantage of the metaprogramming & singleton classes.

#adapted from Dave Thomas's screencast on metaprogramming in Ruby

module Memoize
  def remember(name, &block)
 
    define_method(name, &block)
 
    orig = instance_method(name)
 
    mem = {}
    define_method(name) do |*args|
      if mem.has_key?(args)
        mem[args]
      else
        bound = orig.bind(self)
        mem[args] = bound.call(*args)
      end
    end
  end
end
 
class Finder
   extend Memoize
 
  remember :find do |*objs|
    expensive(*objs)
  end
 
  def expensive(*objs)
    puts "expensive"
    objs.inject{|m,n| m + n }
  end
end

 
#test it
d = Finder.new
puts d.find(1,2,3)
puts d.find(1,2,3) #expensive is not called here
Categories: tech Tags: ,
%d bloggers like this: