Daniel Huckstep gave a great presentation on what you can do with the Ruby Standard Library, definitely worth a watch.
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.
Deployment, What Really Matters
At 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:
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.
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]
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
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.