Fly-mart.com has been live now since the first of the year, yeah I know the logo sucks – I’m working on that!  Traffic has been steadily growing, though the site is still in beta and is not taking payments, I’ve been very happy so far.  One thing that’s been heaven’s sent is HopToad.  Despite being diligent with regard to testing, some things slip.  HopToad is right there and in one particular incident, I was busy fixing the code before the customer even had a chance to finish his email to support (me).  Good stuff!

Anyway, one of the issues I ran into early in the project was the inability on Heroku’s app environment to write to the file system. If you’re using “paperclip” – this is kind of an issue, though it’s relatively easy to work around,  Paperclip can easily integrate with Amazon S3.  The big problem though came with testing.  For some, still unexplained reason, I was never able to get my Cucumber or RSpec tests to successfully connect to the S3 service, I consistently got a connection exception.  I didn’t really think this was worth chasing down as ultimately I really didn’t want the tests to hit S3 directly.  My first thought was to use some sort of web tier mock to trick the code into thinking it was talking to S3.  There were a few examples I found regarding how to get this to work but again I had little luck with my own codebase.  I’m not sure it was because I choose R3 or some other reason, but again no joy.

I was thinking that what I really wanted was the ability to define different behavior depending on the environment.  For example, production and development I wanted actual S3 calls and for testing I would be perfectly happy to have my Paperclip image files land on the local hard drive.  I had a conversation with a good friend, Ryan Daigle who agreed with the approach and could also offer some code to get me bootstrapped.  What follows is the relevant code with commentary.

Step 1 - Modify your app/model/asset.rb class slightly

The thing to notice is that the normal paperclip code that you’d expect in your asset class it replace by the “stores_file_as” helper.  Most of the paperclip configuration as well as the mechanism to detect the environment and act accordingly has been moved into there.

        

          

              
class Asset < ActiveRecord::Base
  include Helpers::AssetStorage
  
  
  before_validation :clear_asset
  belongs_to :ad, :polymorphic => true
  
  stores_file_as :image,
                    :styles => {:micro => "75x43", :thumb => "128x95", :medium => "300x300", :large => "500x500"}
  validates_attachment_presence :image
  validates_attachment_size :image, :less_than => 1.megabytes
  validates_attachment_content_type :image, :content_type => ['image/jpeg', 'image/gif', 'image/png']
  
  def delete_asset=(value)
    @delete_asset = !value.to_i.zero?
  end
  
  def delete_asset
    !!@delete_asset
  end
  
  alias_method :delete_asset?, :delete_asset
  
  def clear_asset
    self.image = nil if delete_asset? && !image.dirty?
  end
  
end

# == Schema Information
#
# Table name: assets
#
# id :integer not null, primary key
# ad_id :integer
# created_at :datetime
# updated_at :datetime
# image_file_name :string(255)
# image_content_type :string(255)
# image_file_size :integer
# image_updated_at :datetime
#
          

          

            view raw
            asset.rb
            This Gist brought to you by GitHub.
          
        


Step 2 - Add a app/helper/helpers.rb module

The idea here is to delegate the heavy lifting of the paperclip configuration to the helper module but more importantly to detect
the environment and configure the appropriate behavior.  In my case, I wanted 'dev' and 'prod' to use the actual S3 environment while
the test environment should use the local file system.  Not only does this keep the charges lower for S3 but has the added benefit
of speeding up the tests.  Alternatively you could externalize the configuration in a DSL but I really didn't see the point.



        

          

              
module Helpers

  # Conventient way to setup filesystem attachment uploading when in dev/testing
  # and use S3 otherwise
  module AssetStorage

    def self.included(within)
      within.class_eval do
        extend ClassMethods
      end
    end

    module ClassMethods

      def stores_file_as(asset_type, opts = {})
        filename_interpolation = opts[:filename_interpolation] || ':style.:extension'
        options = use_local_storage? ?
                filesystem_default_options(filename_interpolation) :
                s3_default_options(filename_interpolation)
        options = options.merge(opts)
        has_attached_file asset_type, options
      end

      private

      def use_local_storage?
        @use_local_storage ||= !(Rails.env.production? || Rails.env.staging?)
      end

      def s3_default_options(filename_interpolation)

        # Akamai URL -> origin URL -> Rails env
        # N/A -> origin.staticassets.development.theslap.digitaltoniq.com -> development
        # staticassets.theslap.digitaltoniq.com -> origin.staticassets.theslap.digitaltoniq.com -> staging
        # staticassets.beta.theslap.com -> origin.staticassets.beta.theslap.com -> beta
        # staticassets.theslap.com -> origin.staticassets.theslap.com -> production
        {
          :storage => :s3,
          :s3_credentials => "#{RAILS_ROOT}/config/s3.yml",
          :path => "/:style/:filename"
        }
      end

      def filesystem_default_options(filename_interpolation)
        {
          ## Add any local file system options you may want here ...
          # :url => "/assets/:class/:slug/#{filename_interpolation}",
          # :path => ":rails_root/public/assets/:class/:slug/#{filename_interpolation}"
        }
      end

    end
  end
end
          

          

            view raw
            helpers.rb
            This Gist brought to you by GitHub.
          
        



Happy Hacking,
Peter

I figured the first thing that I ought to do it to figure out the answer to the question Rails 2.x or 3?

To the initiated, that’s probably a pretty simple question but for someone like me, coming back after a long “it’s not you, it’s me” thing, it wasn’t that easy.

First there was the stability question.  R3 is relatively new, which led really to two questions: Is it stable and is there enough documentation out there to get me going?  I didn’t really dwell on the stability question long.  First off, I know that the Ruby/Rails community (for the most part) are test Zealots.  That and there’s tons of eyeballs out there on the code also brought me great comfort.  What I wasn’t sure of though was all the gems and plug-ins.  How much of a departure was R3 from R2.x and how long will it take the ecosystem to catch up.

The documentation question also had nested concerns.  The Rails community is great at producing how-to’s and tutorials but again, how fast are they to react to the new Rails version?  My normal “go to” sources peepcode.com and railscasts.com seemed to not quite be there yet, though working on it.

I also wanted some industrial strength goodness that I could tap.  I don’t think I could take another “build a blog in 15 minutes” tutorial.  Though interesting and helpful, many of these resources don’t really delve into the nitty gritty of a production application and cover deployment, testing and some of the other tips and tricks hard won by seasoned rails developers.

I was lucky enough to come upon Michael Hart’s excellent Rails 3 tutorial “Ruby on Rails Tutorial: Learn Rails by Example”.  As it turned out it was almost exactly what I needed.  Though the example used in the book is the often used “Twitter Clone”, it was comprehensive enough to be interesting and engaging.  Most valuable though was picking up tips and tricks and helpful plug-ins along the way.  Believe it or not, I had never used git before.  When I’m not stuck with CVS, I’m likely using SVN.  Similarly, Hart introduces TDD via RSpec, Heroku, setting up your environment and of course all the R3 goodness including a vast universe of gems that have proven invaluable.

Up for next week … I’ll start researching/brainstorming a workable layout and doing battle with CSS and ERB!

The Back Story

So as an architect for a *big* networking company, I really don’t write a whole lot of code.  I guess that’s what happens as our careers move forward.  I’ve traded my syntax color highlighting and code-completion for bubbles and arrow.   I’m probably a glutton for punishment but Viso doesn’t give deprecation warnings and I miss the challenge of making things work.  If you’re a developer, you know what I mean.

I’m also passionate about aviation.  One of the aviation communities most active sites for selling and buying aircraft is a site called Barnstormers.com.  I know, you’re asking: “what does this have to do with Ruby on Rails?”.  Sit tight amigo, we’re getting there.  I’ve been on barnstormers a lot.  It’s active and I suppose it gets the job done but a more 1990′s site I couldn’t imagine.  Web 1.0 is alive and well with a visually busy layout, flashing GIFS and blinking ads.  I’ve been thinking … what if somebody manned up and did a really nice web 2.0 Rails, AJAX blah blah blah site.  If anything it would be a good exercise to tackle some real-world programming issues.

The Challenge

Could I design, test, build and deploy a soup-to-nuts application in 30 days (give or take, hey I’ve got a life too you know). This fits into several personal philosophies of mine: First, don’t spend a ton of time or money trying to launch a business. Agile and rapid is not only a good tenant for software but for businesses too. So off to the whiteboard we go. I thought it might be fun to do a blogging series detailing this adventure and to document getting back together with an old flame – ah Ruby… I missed you!!!

So stay tuned! In the next installment, I’ll talk about some resources for initially dusting off my eroded Ruby on Rails skills and how I gingerly navigated the Rails 2.x verses Rails 3. SPOILER WARNING! !: Rails 3 rocks!

In the meantime, if you want to keep tabs on the launch, please visit the Fly-Mart.com launch page.

Yeah, Yeah, it’s been forever since I’ve posted.  I’ve been super-busy though… really!  As some of you may know, I decided to give the Glastar, affectionately known as “Whistler” a brain upgrade.  My experience with my Blue Mountain Avionics EFIS was – how should I put this delicately.. “mixed”.  I can’t be too harsh on the BMA folks though.  They’re a smart bunch and they’ve been helpful despite being shuttered as a business for over a year now.  They were definitely fast movers in the market but I don’t think their cost structure was able to keep up with the market.  That’s just a guess though – no insider information!

So  I’ve wanted to put an autopilot into Whistler for quite a while now.  When I started shopping, I was zeroing in on the Trio Pro Pilot.  It looks like a solid unit and it’s gotten good reviews.  One problem though, the price tag.  For about $600 bucks more, I was able to take advantage of the Dynon BMA trade-in program and get the Dynon SkyView plus auto pilot.  GOOD DECISION!  The electronics were easy enough to install.  The mechanical servos, we’ll that’s another story and probably another post.  Suffice to say that it was TOUGH!  I’m happy to report though that the SV sytem has been working flawlessly and after a bit of tweaking, the autopilot is working just great after initially wanting to aggressively bank to capture a track and then “hunting” back and forth to try to stay on course.

The following short clip has also been keeping me busy.  I came up with this business idea (sky-gadgets.com) to mix great video footage with product demonstrations and tutorials to form a little online business.  Trouble is that I have no idea how to video tape much less edit so off I go to get some practice.  I bought a small “lipstick” camera that I mounted on the Glastar’s cage and a copy of Final Cut Express.  What follows is a piece of footage that I edited together from along continuous shot filmed from Suffolk, Virginia (SFQ) to my home base in Chesterfield (FCI)

Click here to view the embedded video.

“I’ve come to realize that there two categories of kit built airplanes: 1) Under construction and NOT flying  2) Under construction AND flying.”

The first long flight of the season is always interesting.  It’s even more interesting if the flight is following major maintenance which was the situation this year.  At the end of last season a friend of mine and I were going to head out on a short cross country.  When I opened the hanger door to start the pre-flight, av-gas fumes flooded my nostrils and made my head feel like floating tissue paper.  Uh oh…  The rubber tanks that I thought were such a good idea at one time had rebelled for the very last time.  I spent a better part of the winter taking the old bladder tanks out and replacing them with the stock aluminum tanks that originally came with the kit.  Ah, had I known then what I know now!  The assumption that the rubber tanks would give more capacity and be safer in an accident turned out to be false, the more capacity part anyway.  Thankfully I’ve never tested the crash worthiness (knocking vigorously on wood).

Last Saturday a friend of mine and fellow Sportsman builder, Dee Whittington and I did a nice little cross country to shake out the bugs.   Mercifully there were none.   Although a little warm and just a touch bouncy, our trip from Chesterfield to Petersburg to Wakefield to Sufflolk to Chesapeake with stops at both Suffolk and Chesapeake for their open house, proved to be completely uneventful.  Can I fly now, huh, can I can I huh??

This weekend it’s back to Suffolk for the annual Festival of Flight Fly-in.  It should be fun!  Fly there, drive there or walk there if you have to!

!!!! NEWS !!!!

I’ve been corresponding with a fellow daring aviator who successfully flew a Velocity from the United States over to South Africa by way of Iceland, Europe and Egypt to Africa.  James Arestad is his name and I watched is Video Blog in snippets over the course of several days.  Apologies to my employer but I couldn’t help myself, his story is just too compelling!  I reached out to James and he’s agreed to do a pod-cast which I’ll post here as soon as it’s done.  In the meantime, check out James’ adventures on YouTube.

Glastar N275PA

A funny thing happens when you spend 10 years of your life building an airplane: You don’t fly much.  The other thing that happens is that sooner or latter you actually have to get in the airplane you built and fly it!  Should I worry about the left-over parts I had after I finished?  All kidding aside, maintaining your currency is a big deal and not nearly as easy as it seems.  There are two things that are in short supply while you’re building: money and time.  Two years after I first flew my experimental Glastar I found myself lacking a level confidence having only enough flight experience to be legal,  But am I safe?  Probably, but not in anything but in the best of circumstances.  For this year’s BFR (bi-annual flight review) I wanted to go back to the basics.  I ended up designing my own BFR that zeroed in on the areas I thought were lacking.

Prior to this “Design your own BFR” epiphany, I ran across probably one of the best aviation resources currently on the net.  We heard Rod Machado speak at Sun and Fun this year.  His talk was excellent and of course he sprinkled his presentation with his trademark Machado humor humor.  One of the things that Rod suggests in his really excellent book “Plane Talk” is to zero in on the things you’re most uncomfortable with and design training around it.  A designer BFR was born.

I found a really great CFII at New Kent Aviation who agreed to work with me on the aspects of flying that I was most concerned with.  My BFR this year is comprised of a 10 hour block of ground school and instruction that covers the following:

• Engine failures en-route, in the pattern and during take-off
• In flight emergencies such as fires, electrical failures, stuck gear and any other think we can dream up
• Night flying and night currency
• Complex aircraft check-out
• ATC communications, flight following and trips into class ‘C’ airspace

This seems like basic stuff and it is.  Any Private Pilot student will get all of this and more during their training and will be proficient after their check ride.  After the check ride though a funny thing happens: you start doing the stuff you want at the exclusion of the stuff you should be doing but don’t have to be doing.  Case in point: VFR flight filing and flight following.  I know that pilots have mixed feelings about filing flight plans but the way I see it, it’s cheap insurance.  Free insurance actually.  Why not use it?  Why not use everything at your disposal for that matter to make flying safer.  Like Rod says: safe flying is all about controlling and minimizing risk and we have control of more of those factors than we think.

Technorati Tags: experimental aircraft, flying, Glastar

I had a really sticky problem.  I’m building a web 2.0 application that aggregates data from disparate social media sites.  The good news is that MANY sites have really great, REST API’s while many do not.  My nemesis was Google Blog Search.  Sorry Charlie, no API!

What to to?

I’ve burned several nights trying to work around this problem with mixed results and very disappointing results.  Plugging away and looking at dozen’s of different ways to tackle this problem, I finally settled on an approach suggested here by igvita.com.  While this got me 90% of the way there, I had to do a bit of twiddling to get it to work properly.

First, the igvita.com article didn’t explain how to submit data.  No big deal, you can pass the search criteria in on the requesting URL:

@url = "http://blogsearch.google.com/blogsearch?hl=en&ie=UTF-8&q=ruby+rails"

So far, so good.

The next trick is to use XPATH to locate and snag the piece of data you’re interested in.  This is where Firebug completely rocks.  If you’re not using Firebug for web development, you’re either a glutton for punishment or have been living under a rock for quite a while.  In my particular case, the only piece of data that I was interested was the number of hits on the particular query:

The igvita.com article goes into detail regarding how to find the right Xpath by leveraging Firebug.  Firebug pretty slick and the article does a great job explaining how to use it, so I won’t go into the details here.  The problem is that the HTML needs to be converted to XML before the XPATH will work properly.  Below is the Ruby code in its entirety:

require 'rubygems'
require 'open-uri'
require 'hpricot'

@url = “http://blogsearch.google.com/blogsearch?hl=en&ie=UTF-8&q=ruby+rails”
@response = ”

begin

# HPricot RDoc: http://code.whytheluckystiff.net/hpricot/
doc = Hpricot(@response)
xml = Hpricot.XML(open(@url).read)

# Retrive number of comments
number_of_hits = (xml/”/html/body/div[5]/table[3]/tbody/tr/td[2]/font/b[3]“).inner_html
puts “Number of hits: #{number_of_hits}”

rescue Exception => e
print e, “n”
end

Happy hacking,

Peter

Technorati Tags: hpricot, RoR, Ruby, ruby on rails

In general, I’m not a huge fan of code reviews but they can be an effective tool if they’re kept in check.  A co-worker asked me to put together some talking points about code reviews, which I did, regarding some of the things I thought would be material to keep in mind for a code review process.  I thought they might be generally useful, so I’m posting them here.

1. In general, I’m not a big fan of invasive, comprehensive code reviews. They tend to have diminished value the more comprehensive they are. I AM a fan of spot checks and quick audits concentrated mainly on those developers that maybe unknown quantities, e.g. new contractors, new team members etc.
2. AUTOMATE whenever and wherever possible. If style standards or code test coverage can be automated (which it can), it should. Tools like CheckStyle and others are invaluable and are huge time savers. They also have the benefit of being impersonal. Nobody gets offended if a tools yells at you. Before anything’s done manually, ask “Can this be automated?” Manual review *should be* the exception, not the rule…
3. If there are formal code reviews, the purpose and the criteria that is going to be checked should be explicitly stated up-front. I’ve seen too many code review sessions spiral into arguments that essentially boil down to “this is NOT how *I* would have implemented it!” as opposed to having a constructive discussion that ultimately adds value to the process.
4. Code efficiency can be a dicey topic. I’ve seen a lot of developers spend hours arguing about the efficiency of a piece of code that might run once per day. A strong moderator that has good mediation skills is important. The reviewers must be mature enough to know when to pick a fight and when good enough is good enough.
5. A good process with well defined roles goes a long way to alleviating arguments and maximizing the value of code reviews. In terms of roles, I would suggest: 1) Moderator 2) Peer 3) Developer who is being checked. The peer reviews and then the three people get together in a meeting and review the results. The moderator mediates and keeps the meeting rolling along and notes any action that is required to be taken. I would suggest a time and scope limited review session. Around 1-1.5 hours seems to work with follow-up sessions as needed. Any longer and eyes glaze over and people’s interest fads…
6. Don’t let perfect get in the way of good enough – again there has to be a good balance and generally this discretion falls to the moderator, hence the moderator should be somebody who has good facilitator skills.

Technorati Tags: Code Review, Coding

Click here to view the embedded video.

This is a bit of an experiement.  I wanted to create a series of “2 Minute Tips” – video screen casts that show how to do something specific in a relatively short amount of time.

This week, I’m doing a screen cast of setting up a Google Alert.  Google Alerts are a must have if you’re doing niche marketing, marketing research or other internet related marketing activities.  It’s a great way to keep an eye on the competition!  Even if you’re not in the SEO or internet marketing space, you should at LEAST have Google Alert set up on your name.  This will allow you to monitor and track what is being published about you on the web.  You’ll be surprised where you turn up!  Don’t be caught off gaurd!  Watch this short video and find out how to set this service up.

Enjoy! Peter

You can’t escape it.  Each morning when I slide the paper out of it’s plastic baggie or turn on CNN, there it is: the constant drumbeat of bad news.  It rains down on us unmercifully like a torrent.  I catch my optimism waning more than I’d like to admit.  I think doubt is natural when all the news seems to be bad.  All this got me thinking about loss and abundance and I felt like writing about it.

I tend to be self examining by nature.  I’m not sure why that it is. I assume everybody self examines but I think we tend to spin and self judge rather than objectively self-examining.  There’s a profound difference.  I’m no exception.  I think that when crisis starts to affect friends and family, it feels like it’s closing it’s grips in on everybody.  I think that is what has me spooked.  In all of my adult life I’ve never gone a pay period without a check.  The only job I ever got fired or let go from was a lousy one selling satellite TV dishes.  I hated that job only slightly less than the previous one which was installing the satellite TV dishes.  The worst thing about the installation gig was crawling into places that hadn’t been crawled in years. Picking at frozen dirt wishing it would cooperate was low on the fun scale also.  The best part was the road trip to the next job because it gave you a chance to warm up a bit in the truck. A decade or so after the manual labor gig, I saw heady days of the dot.com frenzy.  This was a time that you really couldn’t get fired if you wanted.  In fact pay raises were no harder than walking down to the bosses office and casually mentioning the number of headhunters that had called during the day.  With every bubble it seems comes a burst.  The world today seems like it’s waking up to ever more perverse hang-overs.  Collectively we never seem to fully realize that each stroke of luck and good-fortune within it is contained its opposite.  This Taoist concept, try as we might, is inescapable.  What we can control however is the grace and the dignity with which we confront each side of this dichotomy.

Unlike today, I feel as though you could get your head around the dot.com bubble.  Today’s specter, with antagonists such as “credit default swaps” and “mortgage derivatives” seems different, almost too exotic to explain.  It’s also what finance types call a contagion  – something that isn’t isolated within a given sector or specific market.  No, this seems to be a chain of dominoes that isn’t done toppling over yet.  All this reflecting has gotten me thinking and ultimately led me to read a marvelous book by Victor Frankl entitled “Man’s Search for Meaning”.  Frankl was a Jewish doctor during WWII.  As unthinkable as it was, Frankl, like six million other Jews were summarily rounded up and put into concentration camps.  Many, who were too sick or too old, were simply executed in the gas chambers and cremated.  Frankl describes in his book where a man’s fate was determined by painfully small and seemingly trivial twists of fate:  a simple wave of an SS Officer’s hand, which rail car you were loaded onto, what day of the week it happened to be.  Depending on an apparent random mix of unrelated circumstances it was either a right to the work camp and a chance at living or a left to the gas chambers.  It was that morbidly simple.

Frankl portrays the concentration camp, Auschwitz in his case, as a character which I found interesting.  As unspeakable as the whole “Final Solution” was, Frankl conveys almost reverence  because it provides him a living laboratory for investigating the true nature of man.  In one notable scene, Frankl and his work crew is marching to the day’s worksite.  Because of the extreme conditions, the malnourishment, the cold and disease, the men in his party were in very poor shape.  So poor in fact, where there constitutions that many could not wear shoes as their feet were too swollen from the edema.  On this particular march, the Jewish prisoners passed a convoy of incarcerated criminals.  The emotion that Frankl conveys is one of envy.  Even though the criminals were captive, they probably enjoyed at least an occasional shower, reasonably clean sheets and mail from home.  The wrongfully imprisoned Jews, many of whom had been men of notable position, had been reduced to nothing but a simple number and subsequently treated with as much respect as a number could commend.  These men had literally had everything taken away without exception.  They were stripped to the point where they were envious of criminals and prisoners.  This is a profound example of stratification and underscores just how dire a situation these people were in.

Where is all of this going?  For me, the lesson is simple.  I believe we must be very careful about what we declare a loss.  I don’t want to sell short what it’s like to loose one’s job and still be faced with a mortgage, car payments and dependents.  What I do want to emphasis is our perception of what it really means to live comfortably and how we choose to face adversity.  I don’t want to stand on any moral high ground and declare that we quit complaining about our material loss and get over it because loss and suffering is as individualized as anything.  It’s a matter of perspective and context.  What I will offer however, is what I believe the core message of Frankl’s book is.  Near the end of the part of the book where Frankl talks about the liberation of the camps, two powerful themes emerge.  One theme is fate and the role it plays in all our lives, amplified of course in the context of the Nazi concentration camps.  Even right up until the end, fate nudged the course of events in polar opposite directions.  Just before the allies liberated Auschwitz the Germans moved most of the prisoners out of camp to what they were calling “staging camps”.  Because of a clerical error, Frankl and a companion didn’t make it on the convoy.  They were extremely upset because the staging camp promised a change of clothes and medical aid from the American Red Cross.  Cold, dirty and in need of medical care, they waited, angry they missed the chance to get out earlier.  Latter they learned that the trucks did stop at an intermediate camp where the prisoners were herded into barracks, locked inside and burned alive by the Nazi SS.

The final lesson for me is a simple one.  Frankl speaks at length about the human condition and what man becomes when stripped to an almost sub-primal level.  During a retrospective of his imprisonment, Frankl suggests that it’s not so much what happens to us, but rather it all boils down to how we react.  As Frankl puts it: “We have a choice as to our way”.  So as we go into the new year and we face unavoidable challenges and quite possibly suffering like this generation hasn’t seen, we should keep this in mind.

PJB

Technorati Tags: philosopy economics humanity