When making a choice in the tech world there are two wide-spread approaches: “What’s better, X or Y?” and “Should I use xyz?”. The “or” debate is always an entertaining topic usually ending in an absurdly hilarious flame war. The “Should I use xyz?” is a subtler, more prevalent question in the tech community leading to an extensive amount of discourse. Fairly rational, usually with some good insight, but still a time consuming task. I’ve fallen victim to both approaches when exploring a technology decision. What I realized is I’m asking the wrong question. There are only two things I should ask:
As much as I wish a LinkedIn profile could be a substitute for a resume, it’s not, and I needed an updated resume. My previous resume was done some time ago with InDesign when I was on a design-tools kick. It worked well, but InDesign isn’t the best choice for a straight forward approach to a resume and I was not interested in going back to word. So in honor of my friend Karthik’s programming themed resume I had an idea: program my resume. My requirements were simple:
For the past few years this blog ran apache + mod_php on an ec2-micro instance. It was time for a change; I’ve enjoyed using nginx in other projects and thought I could get more out of my micro server. I went with a php-fpm/nginx combo and am very surprised with the results. The performance charts are below; for php the response times varied little under minimal load, but nginx handled heavy load far better than apache. Overall throughput with nginx was phenomenal from this tiny server. The result for static content was even more impressive: apache effectively died after ~2000 concurrent connections and 35k total pages killing the server; nginx handled the load to 10,000 very well and delivered 160k successful responses.
I was shocked to learn the number of sites which failed to handle the spike in web traffic during the Super Bowl. Most of these sites served static content and should have scaled easily with the use of CDNs. Scaling sites, even dynamic ones, are achievable with well known tools and techniques.
A few months ago I helped a developer looking to better embrace test driven development. The session was worthwhile and made me reflect on my journey with TDD.
Writing tests is one thing. Striving for full test coverage, writing tests first and leveraging integration and unit tests is another. Some people find writing tests cumbersome and slow. Others may ignore tests for difficult scenarios or code spikes. When first working with tests I felt the same way. Over time I worked through issues and my feeling towards TDD changed. The pain was gone and I worked more effectively.
TDD is about speed. Speed of development and speed of maintenance. Once you leverage TDD as a way to better produce code you’ve unlocked the promise of TDD: Code more, debug less.