Flying Spacebar

The technical blog of Lee Jones. var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-5335542-6']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(ga); })();

[flyingspacebar]

Put the answer close to where the question will be asked.

[flyingspacebar]

A great comparison of one-piece-flow versus large batches in the context of software delivery.

[flyingspacebar]

Waste is unrealized potential.

[flyingspacebar]

Leave it better than you found it.

A good tip for working in an office and life in general.

[flyingspacebar]

A problem is the difference between the current condition and the target condition.

A thought from studying lean thinking and continuous improvement

[flyingspacebar]

A different kind of standup

A daily standup meeting typically involves everyone answering three questions:

1. What did you do yesterday? 2. What are you planning to do today? 3. Is there anything blocking you?

These questions are very task focused and are really about getting work done. Nothing wrong with that, but questions are pretty powerful. They indicate values. They shape behavior. We start thinking in terms of days and tasks and roadblocks.

The catch is that the work we do is limited by the capacity and capability of the people doing it. If the people never improve then the work will more or less be the same. It may even decline over time.

What if we started focusing more on the people doing the work instead of just the work itself? Would the investment lead to higher productivity? Would we see an improvement in quality and innovation? Perhaps we’d get better at solving problems that inevitably come up. Maybe we’d get better at system design with a little more reflection and evaluation. Maybe we’d actually learn something from all this work that we do together.

What if we asked questions at our daily standup that were more like these:

1. What did you learn yesterday? 2. What did you teach someone yesterday? 3. Who are you becoming today?

These questions indicate that we value growth and development of team members. The better our people become then the better our work will be also. The questions we ask each day matter.

[flyingspacebar]

Standardization is the Foundation for Improvement

A system or process is difficult to reason about if the components are inconsistent. This unnecessary complexity and makes it difficult to improve. A thought from reading The Toyota Way.

[flyingspacebar]

DevOps is a cultural movement focused on collaboration and delivering value to the customer.

Me

[flyingspacebar]

Using HAProxy with backend servers that require a specific domain

By default, HAProxy will pass through the domain of the incoming request to the backend as part of the Host HTTP header (ex. Host: mysite.example.com). Sometimes a backend service will only respond to requests for a specific domain (ex. different-domain.example.com). In that case, you can configure HAProxy to rewrite the Host HTTP header for all requests that go to that backend:

backend example_service mode http balance roundrobin reqirep ^Host: Host:\ different-domain.example.com ...

Note: HAProxy will not rewrite the Host header for httpchk health checks. If you need those also, you'll want to add the Host HTTP header to your backend's health check:

option httpchk GET /testing-endpoint HTTP/1.1\r\nHost:\ different-domain.example.com

[flyingspacebar]

Elasticsearch Names Are Hilarious

ubuntu@ip-10-28-37-168:~$ curl --silent https://raw.github.com/elasticsearch/elasticsearch/master/src/main/resources/config/names.txt | shuf -n 1 Dragon of the Moon

[flyingspacebar]

Net::SSH and Net::SCP with Key Based Authentication

Today I was working on a project that has [resque](http://github.com/defunkt/resque) workers that are managed by by [god](http://god.rubyforge.org/). The task of these workers involved using [Net::SCP](http://net-ssh.rubyforge.org/) to copy files from one server to another. The original implementation used username/password authentication for the SSH connection, but during this update I wanted to switch this to SSH key based authentication. From the command line, I ensured that the user the worker was running as could connect to the remote server by SSH key. Then I removed the password from the worker code and it could no longer connect. It was not using the SSH key. I suspected it must be something different about the environment that the worker was using. After turning up nothing in Google, I tried out a hunch. The hunch was to set the `HOME` variable in the god watch environment: God.watch do |w| ... w.env = { 'HOME' = "/home/rails", 'RAILS_ROOT' = "/var/www/myapp", 'RAILS_ENV' = "production" } ... end It worked! The worker could then connect to the remote server with no problem.

[flyingspacebar]

Rails 3 Markdown Undefined Error

When upgrading an app to Rails 3, I hit the following error: undefined method `markdown' for #<#

[flyingspacebar]

Migrating a live application to new hardware is like trying to replace the engine in a moving car without losing speed.

[flyingspacebar]

Reasons I Prefer iTerm Over Terminal

# Reasons I Like iTerm over Terminal # I tend to forget the reasons why I choose certain tools, so here are 4 reason I prefer iTerm over Terminal. ## Full Screen Mode ##  Full screen mode allows iTerm to take over the full screen. This is great for three things: * focusing on a single task * getting maximum space for terminal output or editing files * impressing people by looking like you're in [The Matrix](http://www.collegehumor.com/video:1886349) :) Joking aside, full screen mode is awesome. I found a way to emulate full screen with Terminal using a keyboard shortcut for Zoom, but this does not use the entire screen and sometimes behaves unexpectedly. ## Smart Text Selection ##  When I select text at the command line, it is often a path. The fastest way to select text in apps is double clicking on a word or line. Terminal.app stops the selection at the first slash or period it encounters (when double clicking), but iTerm is smart enough to select the whole path for you. With iTerm, you can even define what characters you want to considered part of the same selection. I frequently copy file paths, ip addresses, and domains during the day so this is very handy. ## Growl Notifications ##  I run long tasks in the terminal that don't require me to watch every line of output. I just need the result of the task. With Terminal.app I have to manually check the terminal to see if it is finished or if it experienced an error. With iTerm, I can get a growl notification when a command finishes or an error occurs. This really helps my work because I can get back to the command line as soon as the task is done and proceed on the next step. ## Easy Tab Navigation ##  I use FireFox and TextMate frequently through the day, and I enjoy the ability to switch between tabs with the CMD + short cut. If I want tab one I enter CMD + 1. Terminal would interpret this as I want window 1. I usually only have 1 window open, so this is not necessary for me. This may be a legacy issue for Terminal.app since they did not always have tabs. **Bonus: The "Home" and "End" keys work in iTerm!**

[flyingspacebar]

Learn To Waste Time

In late 2009 I had a project at work that I knew would be impractical to "test" with the usual method: refresh and click... click... click... debug... refresh and repeat I was tired of "testing" Javascript code this way and was glad to find the QUnit javascript testing library. I liked how small and simple QUNit was, but I did not find any examples of how to use QUnit on a project. There are some helpful examples of tests (see below), but I had trouble understanding how it all fit together for a project. I planned to have a large number of tests. It looked to me that QUnit expected all your tests to be in one file. You could split your tests into multiple files, but they you would need to run each file individually to see your test results. I wanted to group my tests into different files, but I wanted one page where I could review the results of all tests. I thought this was a downfall of QUnit. I solved the problem with Test Loader, a jQuery plugin that throws all your test files into iframes and reports back the results on a single page. Brilliant! I was pretty pleased with myself. I even came up with a way to view results from cross domain tests. In summary, I encountered a problem, fixed it with a plugin, and posted it to github. I even used the solution on a future project. You may already know, but it turns out I created a fake problem. Because I misunderstood the way QUnit works, I encountered a problem that was only in my mind. I crafted my own solution before I realized QUnit was capable of what I wanted to do. I realized this when jQuery 1.4 was released. I was looking at the source code, and went directly to the tests. I found QUnit and lots of tests organized into separate files, but the results showed up on one page. Perfect! You see the results of the jQuery 1.4 test suite on one page. For a second I actually thought... "how did they do this, did they use my plugin?" Well, they are not using my plugin. In fact, they are not using any plugins because QUnit does this by default. That was the moment I realized I had wasted several hours developing a plugin that was not even necessary. I was pretty upset. I realized I could have put that time to more useful development project. After a short while though, I was glad that I had worked on the project, because I really learned a lot about jQuery and QUnit. I learned about unit testing as well. It reminds me a little bit of the contrived examples that people use in tutorials like "Hello World". The example itself is pretty useless, but you learn about the tools in the process of following the tutorial. Lesson learned: make sure I am solving a real problem... and if I find out there was already a solution - make sure to learn something in process. ## Related Links: * [Documentation on QUnit](http://docs.jquery.com/QUnit) * [QUnit on GitHub](http://github.com/jquery/qunit) * [Blog post on using QUnit by Gavin Huang on Nettuts](http://net.tutsplus.com/tutorials/javascript-ajax/how-to-test-your-javascript-code-with-qunit/) * [Test Loader - an unnecessary tool for QUnit testing](http://github.com/leejones/test_loader)

[flyingspacebar]

Test Loader Released

I recently posted Test Loader on GitHub. Test Loader is a way to gather all of your QUnit javascript unit tests into one handy page.  It is like a dashboard for your tests.

It is usable in the current state, but needs some css love and some documentation. I hope to do some documentation and a screencast in the near future on how I am using QUnit and how Test Loader fits in.