Archive for June, 2007

Book Review: Mavericks at Work

June 25, 2007

Mavericks at Work (MAW for the remainder of the review) is a book which claims to explain “Why the most original minds in business win.” This book attempts to follow in the tradition of Built to Last and Good to Great, even frequently citing those books. Unfortunately it doesn’t live up to the same level of extensive research backed up by solid statistics and writing. MAW starts out strong with many interesting examples into the some of the most creative and successful businesses in recent times. Unfortunately, since many of the creative companies are different in entirely unique ways (some even in exactly opposite ways), nothing can really be drawn from the stories. It also seems for all the examples given in this book of a creative company there are plenty examples of failed companies trying similar creative solutions.
When I started reading this book, I thought it was solid and easily worth the read, but by the time I had finished the book, that was no longer the case. If you want a feel-good, inspiring business book, this might be what you’re looking for, but if you’re hoping to implement ideas for your own business, I think there are better books out there for that. I feel like the first quarter of the book was very strong and filled with interesting and powerful examples of creativity in business. The first half of the book was still decent but falling apart into less compelling examples that really didn’t show how creativity directly led to success. The last half of the book could have basically been summed up by “creatively motivating your team and hiring the best employees for your company is great for business.” This is explained and restated far too often using examples that don’t seem creative or innovative, just mildly amusing and appropriate for particular companies. Obviously the out-of-the-ordinary hiring practices at Pixar aren’t the same as a bank.
Some of the topics covered that I found interesting and informative, all of which were in the first half of the book, are listed below.

  • Not Just a Company, a Cause: Strategy as Advocacy

        What ideas are your company fighting for? Can you play competitive hardball by throwing your rivals a strategic curveball? Successful companies have a set of fundamental reasons for a company’s existence beyond just making money.
  • Competition and Its Consequences: Disruptors, Diplomats, and a New Way to Talk about Business

        Can you be provocative without provoking backlash? Why strategic innovators develop their own vocabulary of competition.
  • Ideas Unlimited: Why Nobody is as Smart as Everybody

        How to persuade brilliant people to work with you, even if they don’t work for you. Why grassroots collaboration requires head-to-head competition. How one open-minded leader inspired the ultimate Internet gold rush.
  • Innovation, Inc: Open Source Gets Down to Business

        Why smart leaders “walk in stupid every day.” How a 170-year-old corporate giant created a new model of creativity.

Overall I felt MAW was an average business book, it did have some above-average areas. The appendix goes into amazing detail with mini-reviews of the best books, blogs, videos, and interviews that inspired the book. Often I found that the description of a source (which included web resources) was a great way to get detailed information on specific areas or chapters that were of interest to you.
Website: Mavericks at Work

Advertisements

Book Review: Crossing the Chasm

June 20, 2007

After reading it on and off for a few months now (I never seem to find the time to sit down and really read books anymore), I finally finished Crossing the Chasm. If you’ve never heard of this book, it’s a how-to manual for successfully marketing technology products to the mainstream consumer. Sound boring? It is, especially if you aren’t passionate about marketing (which is why it’s taken me so long to finish). Skippable? It’s definitely not. It’s full of important ideas and should be required reading for any startup founder.
Lots and lots of good things have been said about this book, so I won’t go into too much detail. The basic premise is that even if you have a lot of early users, you need a specific, focused effort to win over the mainstream consumer market. And that’s not easy.
There are tons of good ideas in Crossing the Chasm but I’ll briefly discuss two that were the most immediately useful to me.
1. Dominate a niche segment first. Yeah, I know, you’ve undoubtedly built a vast, elegant system that can be used in many different ways and contexts. We’re programmers, we like to abstract. But that doesn’t matter. You can’t compete at all fronts at once. To succeed, you need to pick a niche to which your product is the most compelling and dominate it. Then you can move on to other market segments. Notice I didn’t say to pick the largest niche or the one with the most potential revenue. Pick the pond in which you can be the biggest (or only) fish.
2. How to build your pitch. The book has a great section on the important parts of a good pitch. The most interesting part was how to identify your product by using two other products as references. First, you identify a market alternative , which is the current preferred way your customers could solve the same problem your product solves. This doesn’t need to be technological – Rotten Tomatoes’ market alternative would be the movie reviews in your local paper. Secondly, you identify a product alternative – a product that has similar technology that customers are familiar with, but that is focused on a different market segment. For instance, a product alternative for Rotten Tomatoes might be Metacritic (this requires the mainstream customer to be familiar with Metacritic, but bear with me, it’s an example). While Metacritic has reviews for films, TV, music, and books, Rotten Tomatoes focuses entirely on movies (and has additional content that is of interest to moviegoers). Instead of just describing your product, you can use these two alternatives to more easily convey your product to potential customers and investors. Before reading this book, our pitch really stunk – even though our product idea is good. We’ve used the tips and have gotten much better at getting our idea across in a way others can immediately grasp.
The book goes into a lot more detail on these ideas and presents a whole lot more. I had exactly zero previous experience with marketing before reading this book, but the book doesn’t assume any expertise, so I came away from it feeling like I had learned a lot. If you’re developing a new technological product, I highly recommend adding this one to your long and growing “to-read” list.

Pretheory.org

June 18, 2007

Pretheory is a company developing software for profit, but that doesn’t mean that we don’t have more altruistic goals and projects as well. As we grow our business, we also hope to grow our philanthropic endeavors as well. It is with this intent that we launch Pretheory.org. Currently Pretheory.org will mostly be a placeholder for future projects and list a few various charities that we support.
We currently support the following charities.

Hopefully we can expand this list as we grow and learn about other good charity organizations.

Adventures in Testing, Part I : Running Your Tests

June 11, 2007

I’ll admit it – I’m a test nerd. As much as love the creative process of writing an app, I’m equally fascinated by the problem of verifying all that code.

Although my real passion is in writing dynamic testing systems, I’m also a big believer in static tests – AKA unit, functional, and integration tests. Luckily, Ruby and Rails make it super easy to write tests.

Writing good tests is obviously important, but there’s also a hidden art to running your tests. You’d think this would be pretty straightforward and, when you just have a few tests, it is. But as you write more and more tests, it takes longer and longer run them all. And the longer it takes to run your tests, the less useful they are to you.

There are two ways to speed up your tests. Obviously, one way is to increase the speed of running each test – for example, by writing more efficient tests (for instance, by using mocks) or by getting a faster machine.

The other way is to run fewer tests. Although this seems dangerous in theory, in practice it’s really useful. When writing some code, you generally know which tests are most likely to break, so it makes sense to run a subset of your tests. Similarly, if you’ve just caused some tests to fail, you’ll likely want to continue to run just those tests until they pass. Just make sure to run all your tests before moving on to your next task – and definitely run every test under the sun before you even think about checking code into source control.

With that in mind, let’s survey some of the ways you can run your tests:

Rake

The simplest way to run your tests in Rails is with Rake. Simply run one of the following commands in your project directory

rake – Run all your tests. Equivalent to running rake test
rake test:units – Run just your unit tests
rake test:functionals – Run just your functional tests.

Well, you get the idea. Run rake --tasks | grep test to see all the test tasks at your disposal. As you’ll see, Rake is awesome at running all your tests or important sets of tests.

The problem with Rake is that you don’t have much control over which tests you are running. As I mentioned earlier, you might just want to run one testcase or even just one single test. Which brings us to …

Ruby

You can have finer grained control over your tests by invoking the Ruby interpreter directly. Let’s say you only want to run all the tests in one file. You can simply do:

ruby test/unit/foo_test.rb

Much better. On my machine, running all my unit tests via Rake took 10.7 seconds, whereas running just one specific test file took just 2.3 seconds.

But the fun doesn’t stop there. Oh no. Let’s try running just one specific test.

ruby test/unit/foo_test.rb --name=test_bar__some_test

Down to 1.9 seconds. What’s even cooler is that ‘–name’ can take a regular expression so you can run a group of tests (or even save time by not typing out the entire test name):

ruby test/unit/foo_test.rb --name=/test_bar/

OK, let’s review the results of my very non-scientific performance experiment:

* All unit tests via rake (110 tests) – 10.7s
* All tests in a single unit test file (7 tests) – 2.3s
* One test within a single unit test file – 1.9s.

What’s going on here? Even though I am running 1/110th of the tests, the tests only run about 5.6 times faster.

The problem with both Rake and Ruby is that it takes a long time to load the Ruby interpreter every time you run the tests. This is a small fraction of the overall time if you have lots of tests, but if you are just running a few tests, it really sucks. It would be nice if we could keep the Ruby interpreter in memory and just run the tests we need, so we turn to …

autotest

autotest is part of the awesome zentest suite. It’s easy to install:

gem install zentest

Now simply navigate to your project directory and run ./autotest

autotest will start by running all your tests and reporting any failures. Now for the sweet part – autotest will monitor and analyze both your application and test code and automatically run only those tests that validate code that has changed since you last saved. That’s just so freaking cool.

Not only does autotest speed up your tests by only running the ones that you need, it also runs the tests faster, since it doesn’t need to reload the Ruby interpreter over and over. Running the same single unit test in autotest took me about .1 seconds. Hot. In summary: if you’re not using autotest, you should.

I’ve only found two problems with autotest. First, sometimes the analysis algorithm gets confused and runs too few or too many tests (but this happens very, very rarely). More importantly, if you set a breakpoint in your code, autotest will just hit the breakpoint and wait – it won’t drop into an interactive Ruby prompt. To solve these (minor) problems, I wrote…

fast_test.rb

Using Rake tasks, I wrote my own test helper (with an admittedly terrible name). It’s the mutant offspring of the above methods (and it’s included at the bottom of this post, since it’s kind of long).

– Like autotest, it loads the Ruby interpreter once, so tests run faster
– Like the Ruby interpreter, you can provide a regular expression to run specific tests
– Like Rake, you can easily run just your unit, functional, or integration tests.
– Like Ruby or Rake, when you hit a breakpoint, you are dropped into an interactive environment

To use the script, place it somewhere in your application folder (I put it in ./script). Then, in your project directory, open (or create) .irbrc and add the following line

require 'script/fast_test.rb'

Save and close .irbrc and open up a rails console:

ruby script/console

Now you can do the following

test_all – Run all your tests
test_quick – Run just the unit and functional tests (not integration or other tests)
test_units – Run just your unit tests
test_functionals – Run just your functional tests

Again, you get the idea. Also, any of the above methods take an optional test name that is treated as a regular expression. So, to run a single unit test, you could do

test_units "test_name"

which, on my machine, took only .05 seconds. Now that’s how I roll.

Disclaimer: You’re free to use fast_test.rb, but I hereby declare that it’s current implementation may be terrible. Using rake tasks just seemed like the easiest way to accomplish what I needed and it’s worked pretty well for me for the past month or so. If you have any suggestions (on how to improve it or to suggest other, better written alternatives), I’d love to hear it.

Bringing it all together

So which is the best way to run your tests? It completely depends on your needs. I personally have one terminal window running autotest with another one running a rails console with fast_test.rb loaded. I generally let autotest do most of the work, but if I need to use the debugger or run a specific test of tests over and over, I use the console window. One warning: if autotest is running tests, don’t run tests in the console simultaneously – they’ll step all over each others’ toes and cause weird failures.

Like I said at the beginning, I’m a huge test nerd. So if you know of any other ways to improve your testing environment, let me know.

Oh, and before I go, here’s the code for fast_test.rb


### fast_test.rb ####################################
require 'rake/testtask'
def run_tests(sub_dir=nil,test_name=nil, long=false)
Rake::Task.clear
Rake::TestTask.new(:test) do |t|
t.libs << "test"
if(sub_dir.nil?)
t.pattern = 'test/**/*_test.rb'
else
t.pattern = "test/#{sub_dir}/*_test.rb"
puts t.pattern
end
t.verbose = true
t.options = "--verbose --name=/#{test_name}/" unless test_name.nil?
end
Rake::Task[:test].execute
"Done"
end
def test_units(pattern=nil)
run_tests("unit",pattern)
end
def test_functionals(pattern=nil)
run_tests("functional",pattern)
end
def test_integrations(pattern=nil)
run_tests("integration",pattern)
end
def test_quick(pattern=nil)
test_units(pattern)
test_functionals(pattern)
end
def test_all(pattern=nil)
run_tests(nil,pattern)
end

Well, that sucked

June 9, 2007

Last week was all kinds of fun. I had planned on refactoring a lot of code while Danny took a trip to meet his girlfriend in Honduras (she’s been volunteering there). But, just my luck, a mere twelve or so hours after he left, disaster struck.
For the past few years, Danny has hosted a number of sites on a Windows 2003 server hosted by ServerBeach. It’s gotten pretty slow with all the stuff we’ve had on it and we decided Linux would be a lot better for doing real hosting, so we decided about a month ago to switch to a Linux server. Unfortunately, at the time we were very busy with other stuff, so we didn’t get to it.
Well, fate took matters into its own hands. Just after Danny left, the Windows server totally ate it. The data was there, but booting was not happening. To make things just a little more fun, I knew practically nothing about how the server was set up, and all the accounts and passwords were under Danny’s name. Oh, and since phone calls to Honduras aren’t exactly cheap (and Danny had almost zero access to the internet), we could only communicate via text messages. Good times.
So I spent around four days 1) purchasing and setting up a new Linux server b) figuring out what data needed to be moved from the old Windows box and c) figuring out which sites were down and replicating them all on the new server. I’m not exactly an expert Windows or Linux sysadmin, so I was pretty much learning everything on the fly – while the clock was ticking since the sites were all down for a few days straight.
It was stressing and frustrating, since I didn’t accomplish what I had planned to, but on the plus side, we now have a brand-spanking new, way-faster Linux server up and running, which is nice.
Lessons learned:
1. As much as possible, have company accounts for servers and other services. Otherwise it’s a real pain if one person is unavailable.
2. Apparently, just installing automatic updates on W2K3 can bring a machine to it’s knees.
3. Debian is insanely easy to set up (apt-get rules!)
4. Writing code is a lot more satisfying than playing sysadmin.
Bonus Movable Type tip:
I decided to upgrade to a newer version of Movable Type, since our old Windows server was running 3.1. After importing the data from the database, the old passwords would not work. I tried looking up the encryption code MT uses and manually setting the fields in the DB, but no dice.
Then I tried resetting the passwords via MT itself. MT will mail you a new password if you know a user’s secret phrase. Luckily, that phrase is kept in plaintext in the DB, but unfortunately, I didn’t have sendmail or smtp working. So, I included the following line in my mt-config.cgi
MailTransfer debug
and then checked the Apache logs. Sure enough, the mail showed up in the logs – but MT wouldn’t accept the new generated passwords (even though it was changing the password field in the DB!).
I spent a good two hours banging my head against the wall trying to figure out what was going on. I finally just started looking around at the MT cgi scripts and trying various ones. Eventually I stumbled upon db2sql.cgi. Bingo! This fixed everything, which I don’t really understand, since my old DB was SQL, but whatever. Give it a shot if you’re having the same problem.

One small step…

June 6, 2007

We officially released version 0.1 of our web app today to a very small number of friends and family. If you haven’t been contacted, please don’t take it personally – we wanted to get the site a little more polished before we showed it to everyone (it’s really ugly right now).
I will say this – it was a big rush watching the server logs as the first users (besides Dan and I) started playing around on the site. I was completely fascinated for a good 45 min. anxiously wondering which page they would visit next.
All in all, this first iteration went well. We wrote a lot of important features and the site is coming together nicely. I think the biggest issue was that it took more than a week to get the code into shape and release it. I’d really like to get that down to just two days or less. That’s almost entirely a function of our tests (which are good, but still need a lot of work in my opinion) and our deployment automation (I need to take a weekend and work through Pragmatic Project Automation).
Onto the next release…

The trouble with blogging

June 3, 2007

Yet again, I apologize for the utter lack of posts. I’m shocked and ashamed when I realize it’s been almost a month.
I’d like to say that it’s because we’re so being so incredibly productive – and, truth be told, that’s part of it. Since Dan quit his job, it’s been pretty crazy around here. We’ve gotten a whole lot of code written – in fact, we’re hoping to get an early limited-issue release out very soon. Right now, the site feels like my ’93 Saturn: it might be ugly, but dammit, it works (most of the time).
But another factor is that it’s surprisingly difficult to blog while you’re writing lots of code. I sort of assumed that blogging would be a nice break from coding, an activity that I would look forward to in order to organize my thoughts and keep any interested parties up-to-date.
But man, that code lives with you, day and night. You that feeling when you’re positive you know some name or detail but you just can’t remember it? It’s right on the tip of your brain, and it drives you crazy trying to remember it. And usually a day later, you’re having an unrelated conversation with a friend, and you’re like “Battle Cat! He-Man’s tiger was named Battle Cat”, which really confuses the hell out of your friend.
Well, it’s kind of like that, although the Battle Cat moments come less often, and as soon as you solve one issue, your brain immediately starts working on some other problem without your permission. So I end up thinking about code in the shower. And I dream about it. And I catch myself not really listening to friends’ stories because I’m trying to solve some obscure technical problem, even though I’m supposed to be relaxing.
The point is that I’ve got code on the brain, which makes it really hard to do other activities. As much as I tell myself that things like writing blog posts and actually reading (I’m still trying to get through Crossing the Chasm) are worthwhile uses of time, writing more code always seems more pressing. I guess that’s a balance I’ll learn to strike better as time goes by. Or I can always sleep less…
The last, but not least, reason I haven’t posted is that I’ve spent the last five days desperately trying to get our sites back up after our server totally ate it. It’s been quite an adventure, but I’ll save all the thrilling details for another post (and in less than a month, I promise!).