02
May 2013
AUTHORMike Benner
CATEGORY

Development

COMMENTSNo Comments

Ruby Standard Library Talk at MountainWest 2013

Daniel Huckstep gave a great presentation on what you can do with the Ruby Standard Library, definitely worth a watch.

24
Apr 2012
AUTHORMike Benner
CATEGORY

Development, General

COMMENTSNo Comments

Sometimes You Have To Go Backwards

Your metrics are showing a decrease in performance and users are starting to complain. You start digging through the performance metrics, source code and your stack to find inefficiencies and places you can gain that performance back. What if you do not find any low hanging fruit and solutions are going to be invasive, complicated and time consuming? While those things may need to be done, do not just dive in and start the surgery, stop and ask who am I doing this for?

Humans are driven by numbers. Why do you think there are some many top 10 lists, 5 easy steps to be a guru, etc? Most developers just start attacking the problem with the goal being to get those numbers back in an acceptable range. Maybe they through up some caching, rewrite some queries or upgrade a server. Ultimately they get the numbers back into that arbitrary acceptable range, wrote some fancy code and might have wasted their time.

Yes, I said wasted their time. We need to step back and look at more than the performance numbers. Look at the analytics for your app. What does the actual user usage look like? How does that data looked when overlaid on your performance metrics? Look for the patterns and correlation of the datasets. The insight you gain might surprise you and point you to where the real problem lies. If you find a rarely used feature(s) seriously consider removing them. You may be surprised how one such feature can bottleneck the system.

Removing a feature that is causing a table lock or extreme CPU spikes can free up those resources allowing the rest of the site to flow and  with the usage data you can assess how valuable that feature really is. If you can’t decide one way or the other, ask your users. At the end of the day you may need that feature but your users can live without it for increased performance while you work on a better long term solution.

Don’t be afraid of throwing that hard work in trash. While it may seem like your app is moving backwards what you are really doing is improving your user experience, code and performance maintainability and doing so with the right combination of data to back up this decision.

22
Nov 2011
AUTHORMike Benner
COMMENTSNo Comments

Deployment, What Really Matters

Do It LiveAt AuthorityLabs we have a saying, “We’ll Do It Live“. This goes to the fact that anyone in the company has the ability to deploy any part of our system to the production environment. There are no keys to the kingdom as it were and it is a rather large kingdom.

Many companies nowadays have this policy and rely on their tests suites and continuous integration systems to catch bugs and failing tests but that to me is the easy part. What we have found over the last year is that it is rarely a bad test or worse a missed test case that causes us problems. It is usually something under performant code or infrastructure issue that pops up at scale. We thinking about our issues we started looking at how we could handle this without taking away the ability for anyone to deploy updates as quickly as possible.

What we found was missing was metric driven deployment. The concept isn’t new, but it is overshadowed with all the talk of CI and continuous deployment. Now when we deploy something, we have a dashboard that show us all of our critical metrics (work throughput, server loads, queue lengths, etc) and these are watched looking for variations that are out of line with the norm and expected. It is amazing what you will see once you hit certain scale thresholds. This system let’s us to a couple of things.

We can rollback the deployment and reevaluate the code, spin up additional resources to make up for the drop, make changes to our infrastructure to deal with things like connection limits or whatever. This has had an interesting and welcome side effect. We now monitor and check many more metrics than before and have a better idea of the health of our system. It also has caused us to think about our code in a different way. We now put more thought into how it is going to affect the system as a whole and immediately add support for any new metric we think will need to be tracked for new features.

Does this mean we have fewer issues? No (we are doing it live remember) but we are able to deal with them faster and in a better way. We aren’t just rolling back after someone complains and then investigating. We are seeing in real-time the actual problems and correcting them were they need to be corrected.

I will follow this up with a post on our tools (Scout , New Relic, etc) and some of the internal things we have done to tie this together. In the meantime sit back and enjoy Mr O’Reilly do it live:

04
Sep 2011
AUTHORMike Benner
COMMENTSNo Comments

What Can We Learn From Embedded Development

We recently kicked off Gangplank Labs over at Gangplank and for the last month or so I have been working with the Arduino microcontroller, XBee wireless, Epilog Laser Engraver/Cutter and a slew of sensors. I do not have a background in Electrical Engineering and have never really played with the embedded side of development other than the Basic Stamp starter set when I was younger, so I dove head first into this relying on my experience in software development. That got me off to a good start, but I hit road blocks I had long ago forgotten about.

In this day and age of cheap processors, cheaper ram and even cheaper storage all on a virtual machine out in the ether of the internet it is easy to lose site of some of the problems experienced in the past and even easier to over come those problems by throwing more “power” at them to improve performance.  Well, that luxury doesn’t exist in the embedded world.  Yes things have gotten better and cheaper, but they still have a larger impact on your design than spinning up an instance with Amazon AWS. That was my first problem, the program has to fit on a limited and fixed storage device. I couldn’t just keep including libraries to make development easier. I had to get selective, creative and sometimes even roll my own. I found myself reading the source of the libraries in much more detail than say a gem I would include in a Rails app.

Then there was the actual design. Not just the case design, but the actual hardware and component design. Being new to the space, I am unfamiliar with all the different chips and design patterns available and that showed. Once I maxed out my available inputs and outputs on the Arduino I had to once again get clever. Fortunately, I had a few people around I could tap on the shoulder and they pointed me down the right path. The problem here is that I have to order what I need and wait for it to ship to me (and I am very impatient). The first couple of times this was ok, but then every time I would iterate over the design and find a better solution I would have to place an order and wait. This caused me two unexpected pain points.  It was starting to increase the cost unnecessarily and it was starting to delay the project. Being used to downloading and purchasing digital licenses had spoiled me. A little more design and planning up front could have save me a couple of weeks and a few bucks.

Updates are also not as easy.  This is a lot closer to desktop development, but even they still have it easier. If you want to auto update that means increasing your cost to include an ethernet or wifi chip onto your device which could put it out of the affordable price range. This really means updates have to be performed like a good ole firmware update. Download the update, connect the device, click run and pray you don’t brick your device. QA is very important here. Test, test, test and test. Not unit tests, I mean hands on field tests. Once you release the device to another party you have no guarantee you will ever get to patch a bug that is in it. Not to mention what if it was hardware and not software causing the bug?

What did I learn? Slow down and think about how my design impacts project more thoroughly. Be selective and include only what you need. There is not enough room for the kitchen sink. And test, test test. Make sure everything is working as planned and is stable.

I would recommend any developer out there grab their team and a few Arduinos. Create a couple fun project ideas that take additional hardware, pair up and go implement them like you would in your software development world. Let the issues come up, deal with them and then think about how it differs from your development world. After your little retrospective see if there is anything you could bring back to your development team that could help you improve your process.

08
Sep 2010
AUTHORMike Benner
COMMENTS1 Comment

IntelliJ, The IDE for Everything

I don’t even get involved in the VIM vs EMACS flame wars.  Why?  Because I am one of the people that can unify them.  I love a good IDE.  I am willing to put up with the “bloat” to gain the benefits a well built IDE can bring.  Over the years I tried many of them and kept going back to Eclipse, even if it left me unsatisfied.  Last year I started using RubyMine from JetBrains for Rails development and never looked back to Textmate or RadRails.  Recently, I started writing more Flex and Android code, as well as, maintaining older Coldfusion applications.  This drove me back into Eclipse, but left me wanting a RubyMine like alternative.

After some searching I found IntelliJ (another JetBrains product) that actually worked with Flex, Android,

Coldfusion, Ruby and Rails.  I have now used it IntelliJ for all of my development for that last few months and will not be going back to Eclipse anytime soon.  While it is heavy, it runs rings around both Ganymede and Helios on my Macbook Air.

Support from JetBrains has been awesome.  They have been very responsive to all of my questions (although they could have been avoided if they had better documentation) and are constantly updating their various IDEs.  Which is another thing, they have standalone IDEs for PHP, Python, Ruby/Rails, .net, Java and even basic HTML/CSS.  While all appear to be built of the granddaddy IntelliJ, their developers are great about building IDE specific functionality into plugins for IntelliJ.  This allows one of my favorite features, creating modules for different languages in one project.  So now, can have my Robotium Android Tests, my Android app and the web app that provides an api all open in one IDE that is truly useful across the different languages.

It also supports hooks into TeamCity (their CI Server) and YouTrack (their bug tracking software) which is a feature I am looking to try out next.

If you are looking for an alternative I would recommend giving JetBrains a try.

04
Sep 2010
AUTHORMike Benner
COMMENTSNo Comments

Robotium Presentation

Here is the video from the presentation I gave on Robotium (Instrumentation Testing Framework for Android) at Gangplank a couple weeks ago.

[vimeo]http://vimeo.com/14013702[/vimeo]

02
Sep 2010
AUTHORMike Benner
COMMENTSNo Comments

What We All Should Strive To Hear

Today, I had a previous client post a Tweet that made my day.

“Just heard a woman trying to explain Rails to someone. Suddenly thankful for @refriedchicken, who speaks English and explains it well.” via @bullybully32

Communication

As a developer that statement means more to me than any compliment from peers on my code quality, testing discipline or any other technical aspect of my craft.  To be a great developer you need to be able to cross that invisible line from technical geek to average joe when talking with clients and others that do not have a technical background.  Being able to explain solutions and ideas in a manner that they can understand will alleviate frustration and help find solutions that otherwise would have been missed.  If this is an area in which you struggle, there are somethings you can do to practice, learn and improve.

First, call your mom (or other friend/family member that doesn’t have a technical background) and ask them what they would like to know about what you do for a living.  Then take 15 minutes and try to explain it to them in a way that keeps their interest peaked and has them asking more inquisitive questions.  At the end of your conversation have them explain it back to you.

If, at any point, one of you become frustrated, this is a good sign that you should stop and rethink your approach.  Find a subject that you have a common interest in and try to make an analogy between the two topics.  Tying your explanation to a subject they have an interest can you a long way to keeping focus and excitement in your conversation.  Also, taking a deep breath and a moment to relax will help keep frustrations from interfering with the learning process.

Remember conversations are a two way street.  Take time to listen to their questions.  When they start speaking, don’t tune out and start thinking about what you are going to say next.  Listen.  Their questions and inflections can give you clues to what they are struggling to understand even if it is not what their words are conveying.  This is probably the most important aspect of communicating with others.

Listen. Breathe. Communicate.