Apollo 11 - Could we do it again?

July 16, 2009 marks the 40 year anniversary of the Apollo 11 launch. Four days later, July 20, the Eagle landed on surface of the moon. It all started with the famous speech by President Kennedy. It's still one of my favorite presidential quotes.

"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too."

If you are at all interested, be sure to check out We Choose the Moon. This site will be doing a real-time replay of the entire mission. They will include all the transmissions as well as a lot of great information. I know I will be checking the site out often. There also are a few Twitter feeds to follow: @AP11_SPACECRAFT, @AP11_EAGLE, and @AP11_CAPCOM. [update: sorry, I needed to fix the Twitter links]

I was too young to really remember the early landings when they happened, but throughout my life, I read and watched everything I could on Apollo, Gemini, and Mercury programs. I can't get enough of it. It's one of the things that got me into science and computers.

Now, 40 years after the launch and a lot of software projects under my belt, I often ponder whether we could land a man on the moon in same amount of time. Kennedy made his speech on May 25, 1961, and Neil Armstrong stepped foot on the moon July 20, 1969 -- a little over 8 years. Never mind the political climate and government project differences between now and then, I'm thinking about whether having all the computing power available today would have helped or hurt. Think about it. Apollo worked because thousands of very smart people did the work computers would do today (ironically, today it's in an effort to use fewer people). The problem is that all that smarts would require mountains of code and would be nearly untestable for all possible cases. As an example, Boeing's 777 has 2.5 million lines of code to deal with one aircraft. Add in the 3rd party code, and you're talking about 4 million lines of code. That software project took 4.5 years to complete. The problem is that as complicated as the the 777 is, it's nothing compared to a moon mission. The number of contingencies to handle in software would be crazy. So, you can try to build a brain to handle everything, or you can park a very smart brain in front of a computer and let them make a decision. Which is going to be more flexible?

Now, don't get me wrong. A project like this would be a dream, but I also understand that if you wanted to do it in 8 years, you would not be able to automate everything. Too much code, not enough time to test it. As another example, the F22 Raptor project started in 1981, and the plane did not go into service until 2005. 24 years -- ouch. I still would LOVE to see it happen though. Maybe this time Mars will be the goal.

Let me leave with one of my favorite calculations done for Apollo. Obviously, to step foot on the moon, you have to get there first. It's close to 250,000 miles from Earth, but thanks to space you don't have to run your engine the whole way. All you need to do is complete a forward pass from one moving object to another, but be sure to take into account the gravitational affects of at least 3 celestial objects. Newton would be proud.

Apollo

You're in orbit around the Earth, start your engine and get yourself to what speed? What direction? Once you turn off the engine, you will coast for about 3 days, and if everything goes right you will be in lunar orbit. Too fast or wrong direction, and you miss and go off into space. Too slow and you end up a pancake on the moon. With not much more than a slide rule (anyone even know how to use one of these things?), the Apollo scientists calculated lunar orbit to the exact second. Not bad. I know it impresses the hell of me every time I think about it.

Thoughts? BTW, anyone know the equations?

Government honours veterans of Bletchley Park at last

Government honours veterans of Bletchley Park at last - V3.co.uk - formerly vnunet.com The surviving staff from Bletchley Park will finally(!!) be recognized, nearly 70 years later. Their work was thought to have shortened the war by 2 years and saved millions of lives, but until the 1970's they weren't even allowed to reveal what they did.

“After many years of having to keep their critical wartime work top secret, it is tremendous that this contribution has finally achieved recognition.”

All I can say is that it is about time the people that helped develop computing get some recognition.

Checkout Hoptoad by thoughtbot, inc.

I've been using Hoptoad for about two months now, and I'm sold. Hoptoad is a product by thoughbot, inc. Previously, I've always used the excellent exception_notification plugin. The exception_notification plugin is easy to use, and it works great. However, there are a couple of problems with it.

  1. You could flood your inbox if there is a bad problem on a popular page.
  2. It's difficult to collect all the emails and track errors.

Enter Hoptoad. Hoptoad solves both problems, and it is super simple to use and setup. It's free for one project and two users. If that isn't enough for you, the premium services are very reasonable.

How does it solve both problems? First, Hoptoad will still send you an email when there is an error. However, it won't flood your inbox if there are hundreds of the same email. Second, Hoptoad provides a simple web-based system that groups your errors by exception class. That makes it easier to track down problems. Finally, you can mark errors resolved so you don't have to wade through noise to solve the real problems.

Hoptoad installation:

REMOVE EXCEPTION_NOTIFIER

  1. In your ApplicationController, REMOVE this line:include ExceptionNotifiable
  2. In your config/environment* files, remove all references to ExceptionNotifier.
  3. Remove the vendor/plugins/exception_notifier directory.

INSTALL HOPTOAD_NOTIFIER

From your project's RAILS_ROOT, run:

script/plugin install git://github.com/thoughtbot/hoptoad_notifier.git

CONFIGURATION

You should have something like this in config/initializers/hoptoad.rb.

HoptoadNotifier.configure do |config|
  config.api_key = '1234567890abcdef'  # You get your key when you sign up
end

(Please note that this configuration should be in a global configuration, and is not enrivonment-specific. Hoptoad is smart enough to know what errors are caused by what environments, so your staging errors don't get mixed in with your production errors.)

Once you do the above, any Exception not caught by your controllers will be sent to Hoptoad where where they can be aggregated, filtered, sorted, analyzed, massaged, and searched.

Now, if you have read anything I've done before, you know I do a lot of asynchronous processing with Workling. By default, Hoptoad will not log errors from anything outside of your controllers. Fear not. Hoptoad provides a webservice API to send errors. Here is an example.

In workling/lib/workling/base.rb:

    # takes care of suppressing remote errors but raising Workling::WorklingNotFoundError
    # where appropriate. swallow workling exceptions so that everything behaves like remote code.
    # otherwise StarlingRunner and SpawnRunner would behave too differently to NotRemoteRunner.
    def dispatch_to_worker_method(method, options)
      begin
        self.send(method, options)
      rescue Exception => e
        raise e if e.kind_of? Workling::WorklingError
        logger.error "Workling Error: runner could not invoke #{ self.class }:#{ method } with #{ options.inspect }. error was: #{ e.inspect }\n #{ e.backtrace.join("\n") }"
        # DND: Let HopToad know of the issue
        params = options || {}
        HoptoadNotifier.notify(
          :error_class => "Workling Error - #{e.class.name}",
          :error_message => "Workling Error(#{e.class.name}): #{e.message}",
          :request => { :params => params.merge(:worker_class => self.class.name, :worker_method => method) })
        # DND: end of change
      end
    end

Now, any error not caught by your workers will be sent to Hoptoad for processing. You can use a similar method from Rake tasks or any scripts that run outside of controllers. Remember, Hoptoad will collect errors by :error_class, so you can use different classes to separate errors into bins based on where they came from.

Give Hoptoad a try. You will not be disappointed.

Bargaining for Advantage

Bargaining for AdvantageIt's not a programming book, but I recommend "Bargaining for Advantage" by G. Richard Shell. You may not be making multi-million or multi-billion dollar deals (yet!), but the techniques described here work just as well when negotiating an architectural detail or project. Plus, it's pretty interesting to read about how some of the big players made and lost their deals. Check it out. You may find that you have a different strategy when you negotiate your next deal. Remember, deals are made all the time, and it's not always a big business deal.

Good stuff.

June 6, 2009 - 65th Anniversary of The Great Crusade

OK, I know I'm a little off my usual topics again, but today is an anniversary. In the early morning hours on a Tuesday morning 65 years ago today, D-Day paratroopers began jumping into the French countryside. At first light, six divisions of soldiers from the United States, Britain, and Canada began landing on the beaches of Normandy.  The beaches all had code names Omaha, Utah, Gold, Juno, and Sword. The United States landed on Omaha and Utah. The British took care of Gold and Sword, and the Canadiens landed on Juno.

Just prior to the invasion, General Eisenhower read what is now an historic passage:

"You are about to embark upon the great crusade, toward which we have striven these many months."

Obviously, you can read about the Normandy invasions everywhere, so I'm not going to describe all the events again here. I will, however, talk a little bit about my experiences touring the area as well as introduce you to Charles Durning.

Who is Charles Durning? You probably know him by his movies. His film career began in 1965. Some credits include "The Sting", "Dog Day Afternnon", "North Dallas Forty", "The Best Little Whorehouse in Texas", "O Brother, Where Art Thou?", and dozens of others. What you may not know about Charles Durning is that he survived two most horrific periods in WWII. You wouldn't know because like many veterans of that era, he rarely spoke about it until years later when asked.

Durning was awarded the Silver Star and three Purple Hearts. He was among the first wave of troops that landed on Omaha Beach. Suffice to say, the nickname of "Bloody Omaha" is descriptive because of the more than 2,200 casualties suffered on 6 JUN 1944.

By 17 JUN 1944, Durning was back in England recovering from  shrapnel wounds in the left and right thighs, the right hand, the frontal region of the head, and the anterior left chest wall. He was pronounced fit again on 6 DEC 1944, just in time for the Battle of the Bulge and his second historical experience.

In 2008, Durning received France's National Order of the Legion of Honor (each year France honors 100 veterans that served with distinction in France). At the ceremony, he described his experiences during the Battle of the Bulge. Early in the battle, Durning was stabbed 8(!) times during a hand-to-hand fight with a young German soldier. The fight did not end until Durning was able to reach for a rock and bludgeon the German soldier to death. He said when it was over he wept with the dead German soldier in his arms.

Soon after, Durning was taken prisoner and would have been shot on the spot were if not for an english speaking German officer that accepted his surrender and had his wounds tended to (the 8 stab wounds - one to the chest). As a prisoner now, Durning was led to a small town called Malmedy. It is here that the infamous Malmedy massacre took place. At Malmedy, some 150 prisoners were rounded up and dozens were executed. Durning and two others of his group managed to escape the carnage. There were many incidents in an around Malmedy, resulting in 72 bodies being discovered.

Durning was on the TV show "Rescue Me" this year. It was here that I was reminded of his service and felt the urge to talk about it. I'm thankful for men like Charles Durning and thousands of other's like him. Like most veterans, I agree that the true heros are the ones that didn't make it back.

I was lucky enough to pay a short visit to Normandy many years ago. The visit was far too short, but I was able to stand on Omaha and Utah beaches and see what men like Durning faced. Think about 2-3 football fields of open beach to cross with an amphitheater of cliffs all around. Unlike what you see in the movies, it's not the machine guns right in front of you that are the most dangerous. It's those to the side. This is one of the reasons some units saw casualty rates of over 50% in the first few minutes of the landings. Powerful stuff.

In this time of robots and smart bombs, we will thankfully never again see mass invasions and infantry action. I only hope it isn't replaced with something far worse. So today, while you are enjoying a wonderful Saturday, send a "Thank You" to those men and women that started the Great Crusade to clear Europe of Nazi tyranny 65 years ago today.

Platform Engineers or Rock Star Engineers

I've hired a lot of engineers over the years, and one of the first things I'm always asked to add to the job description is "must have experience in XXXX platform." I sometimes put it on there to make people happy, but I rarely will disregard an engineer because they do not have a lot of experience in a particular platform. Give me a Rock Star, or even a very good/great engineer, and I guarantee you that person will run circles around the average engineer with platform experience. Now, if you can find the Rock Star with platform experience -- BONUS! The only time I deviate from this plan is if the project calls for someone to "just get it done and fast." Then I need to pay more attention to platform experience because I don't have time to wait for the new platform to be learned. I've lost track of how many times this simple fact has been proven to me. The qualities of a great engineer carry over to any platform, and a great engineer will pick up a new platform quickly -- mostly because they love learning new things. If you're starting out in software development, concentrate on being a great engineer. That's far more valuable than an engineer that knows a platform.

What makes a great engineer? To me, it's pretty simple. You have a passion and ability to craft outstanding, maintainable, and testable code. You know your algorithms, design patterns, and data structures like the back of your hand. Finally, you posses the other skills necessary to round things out -- communication, time management, risk assessment, strategic and detailed design, and quick decision making (and sticking to those decisions). You can write a loop in Java? I don't really care. You understand dependency injection or how an outer join works. Now we're talking.

What do you think?

Bletchley Park Snubbed by British Government

UK Snubs Support for Home of WWII Enigma

Here we go again. Bletchley Park continues to get little love. Here we have what is basically one on of the birthplaces of modern computing. On top of that, the group of people that worked here, along with their US partners in Building 26, did more to shorten WWII and save countless lives than just about any other group. Makes your life as a military leader a whole lot easier when you know what your counterpart is up to.

It seems now that the UK will not give Bletchley Park the same status as Imperial War Museum.

"We have no plans at present to associate it with the Imperial War Museum," Lord Davies said. "The House is all too well aware of the significance of designating any area in association with a museum of that rank, but I want to give an assurance that Bletchley Park will continue to develop under the resources made available to it."

OK, I know I'm a little biased because I'm a history buff, but I'm also aware of the history of my profession. Without these two groups of scientists, we might not have the same level of computing we have today. This is where Alan Turing (of Turing Machine fame) cut his chops.

Let's not forget about these people and what they did. I know it was super-secret, but it was almost 70 years ago now. 

 

Workling Timing Issue

As you probably noticed already, I use Workling a lot, and I wrote about it a few times (Part 1, Part 2, Part 3). One minor gotcha to be aware of is that you need to make sure you handle it when Workling is too fast. A common use of Workling is to make a call in an after_save method. For example:

class User < ActiveRecord::Base
  def after_save
    MyWorker.asynch_geocode_address(:user_id => self.id)
  end
end
class MyWorker < Workling::Base
  def geocode_address(options = {})
    user = User.find(options[:user_id])
    user.geocode_address
  end
end

Pretty straight forward, right? Unfortunately, what you will find is that often your worker will get called so fast on create that ActiveRecord hasn't committed the transaction yet, and User.find will fail. To get around this, you need to write your workers that could be called from after_save/after_create to handle this condition. Instead of the above, you need to do the following:

class MyWorker < Workling::Base
  def geocode_address(options = {})
    retries = 3
    begin
      user = User.find(options[:user_id])
      user.geocode_address
    rescue => err
      if (retries -= 1) > 0
        sleep(0.2)  # Give ActiveRecord a chance to save
        retry
      end
      raise err
    end
  end
end

Now we catch the exception that ActiveRecord throws when it can't find the new user yet. Waiting a short time and trying a few times gives ActiveRecord a chance to commit the record.

Enjoy asynchronous processing...

Thousand Yard Stares: Ruins and Ghosts of the Battle of Peleliu

Thousand Yard Stares: Ruins and Ghosts of the Battle of Peleliu, 1944, 2008 « The Wired Jester In reference to Memorial Day, I came across the above link. More than most battles, Peleliu is one of those that defines sacrifice. The amount of suffering and carnage endured on that small island in the Pacific is difficult to imagine. This is where the term "thousand yard stare" came from.

Thousand Yard Stare, Tom Lea

"With the Old Breed" by Eugene Sledge

Prior to going to Peleliu, Lea was known more for 'Go America!' paintings, but something changed after that. No longer was it a matter of glory. It was survival.

Peleliu is also the subject of what I believe to be one of the finest wartime biographies ever written. If want a real description of combat and sacrifice, you must read "With the Old Breed" by Eugene Sledge. Sledge was on the island for entire 4 months of fighting. 10,000 Japanese soldiers and about 2000 Americans died on this island 3 Miles Long and 1 mile wide, but that wasn't the worst of it. You have to read the book to fully understand his descriptions of living among corpses for days/weeks in 100 degree heat.

Again, thank you to all those that serve and have served. Freedom is not free, and I try to remember every day what it took to create and keep what we have in this wonderful country of ours.

Next post will be back to technical stuff.

Gotcha with find_each and find_in_batches

Rails 2.3 added a couple of nice new methods - find_each and find_in_batches. Both methods accomplish the same thing in a slightly different way. Unlike a normal finder these methods grab objects in batches instead of all at once. For instance, if you have 500,000 users, you don't want to do the following:

User.find(:all).each { |user| user.some_method }

The reason is that you just loaded all 500,000 records into memory, and your server is not happy. Instead, you could do:

User.find_each { |user| user.some_method }

By default, the above will only load 1,000 User objects into memory, and your server will thank you. If 1,000 is too big/small for you, use the :batch_size option to change it. The find_in_batches method is similar except that it provides the array to the block instead of one object at a time. For example:

User.find_in_batches do |users|
  users.each { |user| user.some_method }
end

If you ever used the wonderful will_paginate gem, you are probably familiar with the concept from the paginated_each method that will_paginate provided.

So, what is the problem? The problem is that you have to aware that unlike paginate_each, find_each and find_in_batches work by setting up a with_scope block. Therefore, if you need to do any other finds on that same model, the scope will apply. Usually this only affects relationships, but it isn't hard to forget. Here is an example:

# This is a purely made up example
class User < ActiveRecord::Base
  # There is a last_login_at attribute
  named_scope :recent_login,
              lambda { |*args|
              { :conditions => ["people.last_login_at >= ?", (args.first || 1.week.ago)] } }
  belongs_to :parent, :class_name => "User", :foreign_key => "parent_id"
end 
User.recent_login.find_each do |user|
  parent = user.parent # This will include the recent_login scope.
end 

It's no different than other with_scope issues, but it isn't as obvious. You can get around it by doing:

User.recent_login.find_each do |user|
  # Got use send because with_excusive_scope is protected.
  User.send(:with_exclusive_scope)
    parent = user.parent # This will include the recent_login scope
  end
end

Now, go and be kind to your server with find_each and find_in_batches - just remember the scope.