./databyte

CarrierWave 0.6.0 testing change

Have you ever stubbed out the call to url in CarrierWave to trick out your Uploaders during specs?

Well as of 0.6.0, that’ll give you a nice error: 

     SystemStackError:

       stack level too deep

So you’ll want to change the url method to call super (see gist).

Pwn that feature

It’s easy to start down the path of creating a feature or just making a change until you hit a roadblock. It may have you cut a corner, half-ass your testing or otherwise do a less than awesome job.

I periodically work with the guys at @gojee and they’re building out this new feature using CSS3 animations. Testing those CSS3 animations in Safari 5.1 look great and it works just as you would expect across Chrome and Firefox (sorry IE, you don’t get animations). However in Safari 5.0, it’s not all sunshine and rainbows.

It’s easy to say “well, Safari 5.0 is only 7% of our users so let’s not worry about it so much” and degrade them to static images. However, the idea to use CSS3 instead of Flash was someone’s decision.

Guess whose working on making it work across as many cool browsers as possible including Safari 5.0 tonight? Yep, that person who championed the decision but also the entire team. From chickens to pigs, everyone’s helping to change and test the feature.

They’ll end up pwning this issue and not stop until it’s done.

Ask yourself:

• Would you delay your next feature until the current one’s perfect?

• Would you pay extra to have the tools your team wants or needs? And not the same equipment your mom would get (unless of course she likes SSD).

• Would you focus on fewer better features instead of many crappy ones?

After reading Steve Job’s biography and remembering a blog post on ServerFault about The Awesome Factor. The phrases “amazing or shit” and “just make it awesome” come to mind, respectively.

Everyone needs to own their own part. It can’t be one person staying up late testing everything, tweaking and ultimately making it awesome. It should be everyone owning their own change, helping out their teammate and making it awesome.

TL;DR: Own it - Love it - Just make it awesome!

Hydra - good, Hydra on Heroku - not so good

Hydra is a great tool for Rails development as it can distribute your tests to remote machines.  In my current project, we’re running Ruby 1.9.1 on Rails edge with RSpec 2.0 beta so not everything works right all the time.

The biggest culprit is having Heroku attempt to install our development and test gems.  In particular, if you list gem ‘hydra’ within your Gemfile for Heroku - rake no longer works.  You get a helpful message like this:

%  heroku rake routes --app your-app
(in /disk1/home/slugs/192557_b2246d5_db92/mnt)
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:32: warning: already initialized constant RAKEVERSION
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake/alt_system.rb:32: warning: already initialized constant WINDOWS
WARNING: Possible conflict with Rake extension: String#ext already exists
WARNING: Possible conflict with Rake extension: String#pathmap already exists
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:404: warning: already initialized constant EMPTY_TASK_ARGS
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:452: warning: already initialized constant EMPTY
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:960: warning: already initialized constant RUBY_EXT
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:964: warning: already initialized constant RUBY
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1033: warning: already initialized constant LN_SUPPORTED
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1242: warning: already initialized constant ARRAY_METHODS
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1245: warning: already initialized constant MUST_DEFINE
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1249: warning: already initialized constant MUST_NOT_DEFINE
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1253: warning: already initialized constant SPECIAL_RETURN
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1259: warning: already initialized constant DELEGATING_METHODS
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1569: warning: already initialized constant DEFAULT_IGNORE_PATTERNS
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1575: warning: already initialized constant DEFAULT_IGNORE_PROCS
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1612: warning: already initialized constant FileList
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1638: warning: already initialized constant EARLY
/disk1/home/slugs/192557_b2246d5_db92/mnt/.bundle/gems/gems/rake-0.8.7/lib/rake.rb:1968: warning: already initialized constant DEFAULT_RAKEFILES
rake aborted!
stack level too deep
/disk1/home/slugs/192557_b2246d5_db92/mnt/Rakefile:10:in `<top (required)>'
(See full trace by running task with --trace)

So the fix is to exclude execution of the entire block by Heroku:

source 'http://rubygems.org'

gem 'rails', '3.0.0.beta3'

## snip ##

if RUBY_PLATFORM =~ /darwin/
  group :test do
    gem 'rspec', '2.0.0.beta.11'
    gem 'rspec-rails', '2.0.0.beta.11'
    ## snip ##
    gem 'hydra', :git => 'git://github.com/ngauthier/hydra.git'
  end
  
  group :development, :test do
    gem 'wirble'
    gem 'hirb'
    gem 'awesome_print'
    gem 'ruby-debug19'      # does not support 1.9.2
    gem 'ruby-debug-ide19'
  end
end

If you run linux (as I do half the time), then check for this environment variable:

if ENV[“SHELL”] != “/usr/bin/git-shell”

Don’t show your cards - defense in depth

I recently went to visit a popular Ruby and Rails website called the Ruby Toolbox at http://www.ruby-toolbox.com/

On my arrival, I had a friendly “Application Segmentation Fault” message.  Even more useful was the stack trace (I bolded the awesome parts):

/home/slugs/127160_40c7b71_f0a5/mnt/.gems/gems/rails-2.3.5/lib/
rails/gem_dependency.rb:119:Warning: Gem::Dependency#version_
requirements is deprecated and will be removed on or after 
August 2010.  Use #requirement
** [NewRelic] New Relic RPM Agent 2.11.2 Initialized: pid = 20162
** [NewRelic] Agent Log found in /disk1/home/slugs/127160_40c7b71
_f0a5/mnt/log/newrelic_agent.log
>> Thin web server (v1.2.6 codename Crazy Delicious)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:52877, CTRL+C to stop
** [NewRelic] Connected to NewRelic Service at collector7.
newrelic.com:80
/home/slugs/127160_40c7b71_f0a5/mnt/.gems/gems/rails-2.3.5/lib/
rails/backtrace_cleaner.rb:25: [BUG] Segmentation fault
ruby 1.8.7 (2009-12-24 patchlevel 248) [x86_64-linux], MBARI 
0x6770, Ruby Enterprise Edition 2010.01

Security is about defense in depth.  Not only are you supposed to change your passwords, but you make them hard to guess.  Not only do you check your firewall for open ports, but you make it impossible to have unauthorized applications send packets out.

So needless to say, you pull away a few layers of your security when you spit out folder structure, internal listening port, web server name/version and other product version information.

In the case of Heroku, it’s not exactly a secret that they run that flavor of ruby, rails, and web server.  Though I didn’t know it was those exact versions and that they were running REE.  Still, they shouldn’t advertise it.

Git? Mercurial? Or does your DVCS really matter?

There is much talk on the social networks such as Twitter and Blogs regarding Git over Mercurial and vice-versa.  If you don’t know much about Distributed Version Control Systems (DVCS), you should just browse the home pages of Git and Mercurial then head over to Wikipedia’s entry for DVCS.

Besides rampant personal opinion, there are two good write-ups that I’ve found comparing the two packages.  Neither article is completely accurate but the comments do shed light on the inaccuracies.

Let’s start with Google’s DVCSAnalysis for Google Code.  The main inaccuracy in this document are rebasing support added to Mercurial (which is noted after the point) and the last two bullet point under Mercurial advantages which can be overcome by configuration within git.

The third bullet point under Google’s analysis concerns maintenance of git repositories.  First a little research on why you need to ‘git gc’ which summaries to the need of removing duplicate objects and compacting objects in your git repository.  This is where git’s configurations come into play.  In particular, you can ignore the need for maintenance by running:

git config --global gc.auto 0

The fourth bullet point under Google’s analysis concerns history not being sacred on git repositories.  This can only occur if you force a push.  As noted in the comments, you can run this command on the server to disallow such actions:

git config --system receive.denyNonFastforwards true

The other good write-up I found was by the Python core team when they chose a new source control for the Python project.

They did a great job of writing out scenarios and a sample set of commands for each VCS to compare.  For me, “Backport” looks complicated in git whereas “Separation of Issue Dependencies” looks complicated in anything but git’s stash command.

Their final points conclude three reasons for choosing Mercurial over git.  The first point is an obvious pain point for Windows users of git - there just isn’t any good support for git under Windows.  The other two points are not as applicable to the general developer but you can read the article to see if they apply to you.  For one, I’m not partial to if the underlying software was written in Python or not but, obviously, the Python core team feels differently to use tools written in their language of choice and I can completely understand their position.

In the end, the similarities between the two systems are so profound that it’s my personal belief that both systems are very solid and neither is the wrong choice.  They were both started at the same time (2005) for the same reasons (as a replacement for BitKeeper).  If you need great HTTP support or Windows support, Mercurial is a much easier path.  Git has found good communities in the Linux Kernel and on GitHub.  With the use of Mercurial for Google Code and Microsoft CodePlex, the community around Mercurial is growing and growing fast.  You can’t go wrong with either choice and you’ll probably need to use both if you’re an active developer in the community.

Someone doesn’t have to lose for another to win.

Edit: (2010-04-22) Another great site: http://whygitisbetterthanx.com/

Edit: (2010-04-23) This is the ultimate answer: http://gitvsmercurial.com/

Technology 10+ years ago

I’m moving out of a house that I’ve spent almost 10 years in, with boxes from before then. This time, I’m being a little pickier with what I bring since it’s NYC and space is at a premium.

While going over boxes of “junk”, I’ve noticed:

• JavaScript hasn’t come too far from the basics back in 2000.
• I’m glad I don’t have to program in COM or, worse, DCOM anymore.
• PGP never really took off like I thought it would.
• I miss OS/2.
• I sure did have a lot of dial-up and telnet hosts written down.
• PixiNet was my first real ISP in Hawaii after local dial-up modem banks and MILNET (part of the old DDN).
• Apparently over Christmas break during ‘99, I printed out a list of all known ports (119 pages) and started figuring out what each was for and known vunerabilities of each.
• Man did I print a lot, good thing I have EverNote now.
• I still miss OS/2.

Growl 1.2 installation stuck at Preparing Growl

Turns out if you have the iPhone Simulator running when upgrading Growl, it will get stuck while Preparing Growl for installation.  The hangup occurs as the installation process starts after the Package Installer has taken in your input and authenticates your Admin rights.

Looks as though the iPhone Simulator conflicts with any Package Installer over at Open Radar.

Apple tries too hard to keep their iPhone OS under lockdown under SDK conditions knowing that jailbroken phones exist.  They should open it up.  What’s the concern?

Social Media Certification - No!

I’m trying to process this article proposing the question, “Is it possible to really be an expert in Social Media Marketing?” and should a certification exist for such an expert.

I have three simple answers:

1. Your marketing personnel should already use social media to reach customers.
2. Your customer support personnel should already use social media to help your customers.
3. Your product managers should already use social media to engage your customers.

An “expert” in social media should be measured by how you apply social media to better your product, your people, and all your other customers.  Certifications can be built into marketing degrees if necessary, but the best approach is to simply gauge a person’s past experiences and performance.  And it’s a good thing that social media experts can show off their work online.

So stop calling yourself a Social Media expert.  It’s Marketing with a sprinkle of social media on top.  You still need to know how to sell it, how to pull customers in, and how to improve everything along the way!

MacPorts after upgrading to Snow Leopard

Following the advice from MacPorts, I’ll just do a clean and uninstall.

sudo port clean installed
sudo port -f uninstall installed

Good thing I did this before starting my upgrade from 10.5 to 10.6 although you could still run the command if you reinstall MacPorts after the upgrade but don’t uninstall any of your ports.

sudo port list installed > ~/Documents/port_list.txt

I’ve read previously that the best way to build on Snow Leopard may also be with the universal variant as manually rebuilding attempts were resulting in more successes going that route.  The problem is that all dependencies for universal built ports need to also be universal.  Normally you would add this default to your /opt/local/etc/macports.conf.  But from the MacPorts manual, “Universal keywords are used to make a port compile on the Mac OS X platform to run on both PPC and Intel processors.”  So I’ll just skip it for now.