“Select Gifts On Sale”

Those were the words prominently displayed in the window of a Pier 1 Imports today, and they are so very wrong.

• Gift: [n] something acquired without compensation
  
  If it’s on sale, you have to purchase it to get it. If you have to purchase it to get it it’s not a gift.
• In this sentence “Select” reads as a verb, and you can rest assured that they don’t want you to actually select the sale items because the sale items are the ones they’ve cut the profit margin on to entice you into the store to hopefully buy items that are not on sale. Ignoring the fact that the “Gifts” aren’t actually gifts they should either use quotes to indicate that someone has referred to these gifts as “select” and thus making it clear it’s an adjective, or they could have used “selected gifts” instead.

Yes you can easily interpret what they meant to say but the point is that you shouldn’t have to interpret their meaning. The people who made that signage (actually it was a static window decal) are being paid good money to construct English promotional material. Were I their employer I would feel gypped to think that my employees a) couldn’t correctly construct a four word sentence and b) not one person in all the meetings that this surely went through was bright enough to catch these obvious errors.

On a related note can someone please suggest a word with the same meaning as “gypped” that doesn’t have the negative racial connotation? Are the Romany considered a race?

When it comes to DRM “protected” music people tend to be either completely ignorant as to how it affects them, or even that it affects them, or they’re religious zealots who have such extreme viewpoints you can’t have a sensible discussion about the issue.

But there’s one simple exercise that will explain just how dangerous DRM is to you and your friends:

• What computers were people using ten years ago?
• Can you run the software from those computers on your current computer? Does anyone even support or update the software from then? Would you want it even if they did?
  
  Macs were running OS 7 in 1996. Windows was Win 95.
• Considering that Moore’s Law essentially says that computers will double in power every 18 months do you really think that the computers we have ten years from now will even remotely resemble the ones we have today?

With that in mind what will become of the DRM “protected” music you buy today from iTunes, or almost any other online music store, if the software to unencrypt in can be reasonably expected no neither be supported, nor runnable in ten years?

Your warranty / guarantee says a lot about you and your products and shouldn’t be considered some legal thing to what you will and won’t reimburse the customer for when things go wrong.

Your company sells quality products or services right? Shouldn’t you stand behind them as if they were as good as you claim they are?

Let me give you an example. I’m looking for a new messenger bag because my current one has two holes and is starting to break down in other areas. I want something nice, that will last me a more than just four years and I’d narrowed down my search to two bags. The Ogio Hip Hop (in spite of the name) and the Ground Shinumo. I was having trouble deciding between them. The Ogio had pictures of the inside (on various sites) that looked like what I wanted but no reviews and the Ground had great reviews but no pictures of the inside. They both claimed to be durable and to use uber-fancy materials to resist wear, but every bag that isn’t pure crap claims that.

So I thought, “hmm If these are really good bags the manufacturer will stand behind them.” So I go over to their home pages to see. Ground’s warranty says:

Our lifetime warranty guarantees that the materials and workmanship in every product we make will stand up to the use for which it was intended. Our warranty does not cover damage resulting from accidents, improper care, or the natural breakdown of materials over extended use and time. Defective or damaged products must be returned to us for evaluation (they must be cleaned before you send them). We will repair or replace them at our discretion. We will repair damages resulting from accident or improper care for a modest fee.

In other words, they guarantee they didn’t screw up when they manufactured it and even accidents or improper care “for a modest fee” which probably means whatever it cost them to make your bag. Not bad at all, admirable even, but not spectacular.

Ogio’s warrantee though:

Ogio International guarantees its entire *non-golf line of products for the **lifetime of the product (original sales receipt required). This warranty covers the product for the original owner against defects in materials and workmanship only. If the product ever fails due to a manufacturing or material defect, then Ogio will repair or replace with like product at our discretion. This warranty does not cover damage caused by normal wear and tear, accident, improper use, or the natural break down of colors and materials over time.

**Expected “lifetime” of Ogio products depends on customer usage.

The first thing they do is redefine “lifetime” to be some vague number they can never be held to that is somehow tied to how much you use it, and only applies to the person who happened to pay for it (original owner). You have to keep the receipt for the “lifetime” of the bag and you’re shit outta luck if it was a gift. Accidents, improper care? Tough luck. I especially like redefining “lifetime” in such a way that their support of their products ends up being inversely proportional to how useful the product is. If they make something you really want to use it’ll wear out faster so they’ll support it less. If they make some crap product you never want to use they’ll support it longer. Thus punishing the people most likely to spread the good word about them.

Then there’s L.L. Bean’s guarantee.

Our products are guaranteed to give 100% satisfaction in every way. Return anything purchased from us at any time if it proves otherwise. We do not want you to have anything from L.L. Bean that is not completely satisfactory.

They’re not kidding either. There are many tales of people having returned worn out, beat up bags and things to L.L. Bean and had them replaced, for free, with the current year’s equivalent. Guess which company I want to buy a bag from?

In the end I think I’ll get the Ground bag. I’d love to buy from L.L. Bean but I’m picky about bags and they don’t have anything that really strikes my fancy except maybe this nice sling bag which a co-worker happens to have. Before I looked into the warranties I was really leaning towards the Ogio bag. But now, I’m willing to risk the internal pockets not being exactly what I want because they stand behind their product, whereas Ogio is doing everything in their power to get out of it.

What does your warranty/guarantee say about your company and it’s products or services?

The cranium of a good developer is filled with ideas for new applications. Most of them tend to bounce around with little energy and eventually succumb to entropy. Some ideas are made out of bouncier stuff and eventually reach escape velocity, at which point they are launched down the arms and funneled out the fingertips. You can tell just how cool an idea is by the speed of typing relative to the developers average words per minute.

A short while later there’s a working prototype, and, should things go well, a fully fledged app will follow. But, most of these apps have no goals, no mission in life. Sure they do something, hopefully well, but for the most part they’re like teenagers, and, like most teenagers, they’ll either figure out what they want to do in life or wander around aimlessly until they figure out what they want to do, start doing something nobody cares about, or simply keel over dead.

But what if they knew what they wanted out of life?
Your, application’s mission is it’s heart, it’s driving force. What is it’s purpose in life?

Google’s mission could be “To be the world’s best search engine.”, but how is that going to drive Google forward in any meaningful way? Where’s the vision? No, Google’s got bigger goals than that. Their mission is “to organize the world’s information and make it universally accessible and useful.” Admittedly it’s not a terribly rousing mission but take a second and think about the implications of it. To do anything useful with “the world’s information” you first have to have it. Just imagine what that means for it’s infrastructure! And how about making it useful? Well, that requires tools. Making it accessible is a combination of incredible search technology (we are talking about all the information in the world here) and tools that can handle the various types of information: text, video, audio, various forms of structured data like schedules, locations, etc.

Flickr ’s mission could be “The best place to store, sort, search and share your photos.” but honestly, how lame is that?  Their mission is to be the “eyes of the world “:

That can manifest itself as art, or using photos as a means of keeping in touch with friends and family, “personal publishing” or intimate, small group sharing. It includes “memory preservation” (the de facto understanding of what drives the photo industry), but it also includes the ephemera that keeps people related to each other: do you like my new haircut? should I buy these shoes? holy smokes – look what I saw on the way to work! It let’s you know who’s gone where with whom, what the vacation was like, how much the baby grew today, all as it’s happening.

And most dramatically, Flickr gives you a window into things that you might otherwise never see, from the perspective of people that you might otherwise never encounter.

Flickr’s mission is all about vision, maybe a little to much so because it’s so non-specific. Stuart Butterfield obviously has a good grip on how it affects them, but anyone else reading just the mission wouldn’t really get it. But that’s ok. What’s important here is that there was a mission and that the people behind it understood it’s implications. What good is it to be the world’s eyes if nobody can see through them? Flickr is driven by it’s mission to build tools to let you see through those eyes.

But missions don’t just help you plan. They help keep you on track. Every nifty feature you want to add to your app should be run through the filter of your mission. Eyes aren’t about statistics or value or anything like that. They’re just about seeing, and that’s why you won’t find any analytics or ways to earn money form your images, or anything else like that on Flickr. If your app’s mission is to be “The easiest way to do X” you have to ask yourself if that new set of 20 different configuration options actually make things easier for people or just serves to confuse or intimidate them?

So build your rough prototype. Get that initial burst of creative energy out. Then, sit back and ask yourself what it really wants to be in life, and let that drive every new feature you add and provide you with the confidence to cut out everything else .

I was consumed with dreams about Stephen Hawking’s black hole entropy formula last night, which is frustrating because the math is, sadly, beyond me. But, I mention it to you today because, knowing so little about black holes my mind instead kept trying to change it into an formula to calculate the Financial Entropy of a webapp subscriber.

So, I put it to you, dear reader, have you, or any of your math enabled friends, come up with a formula for calculating the finincial entropy of a webapp subscriber? If you haven’t, but you could, there are many many entrepreneurs who would sing your praises and happily buy you a drink.

On a related note: a little Googling brings up this fascinating looking book whose price or $199.95 puts it beyond that of anything I’ll buy without having a damn good idea of what exactly is inside. Also, why is it that I never heard the phrase “Financial Entropy” until last night in my dreams?

It was foggy the other day in Boston and I couldn’t help but take some pictures. Something about this picture just makes me feel like I’m home. I don’t really understand it though, because it’s the old parts of Boston that I truly love.

I’m not sure where I originally came across the extract_fixtures rake task (maybe here)but there’s nothing better than using real data to run your Rails unit tests. Well, real in the sense that it was generated by actually using your app. But there’s a problem with extract_fixtures. Once you get some real data to base your tests on you don’t want it to change because it would break your tests. So, after the first run extract_fixtures becomes almost useless because it’ll wipe out the fixtures you’ve been working with.

So what’s a girl to do? Well, in my case the answer is to beef it up a bit. The following version of extract_fixtures takes two optional parameters:

• TABLES=foos,bars,other_foos
  
  Tables takes a comma delimited (no spaces) list of table names that you want to extract. If you pass this in it will only extract those tables.
• OUTPUT_DIR=/some/fully/qualified/non-relative/path
  
  Tell it what directory to output to.

If you improve it further please drop me a line and I’ll add or link to your enhancements here.

desc "Create YAML test fixtures from data in an existing database.  " +
" Defaults to development database.  Set RAILS_ENV to override. " +
"\nSet OUTPUT_DIR to specify an output directory. Defaults to test/fixtures. " +
"\nSet TABLES (a coma separated list of table names) to specify which tables to extract. " +
"Leaving it blank will extract all tables."

task :extract_fixtures => :environment do
  sql  = "SELECT * FROM %s"
  skip_tables = ["schema_info"]
  ActiveRecord::Base.establish_connection
  if (not ENV['TABLES'])
    tables = ActiveRecord::Base.connection.tables - skip_tables
  else
    tables = ENV['TABLES'].split(/, */)
  end
  if (not ENV['OUTPUT_DIR'])
    output_dir="#{RAILS_ROOT}/test/fixtures"
  else
    output_dir = ENV['OUTPUT_DIR'].sub(/\/$/, '')
  end
  (tables).each do |table_name|
    i = "000"
    File.open("#{output_dir}/#{table_name}.yml", 'w') do |file|
      data = ActiveRecord::Base.connection.select_all(sql % table_name)
      file.write data.inject({}) { |hash, record|
        hash["#{table_name}_#{i.succ!}"] = record
        hash
      }.to_yaml
    puts "wrote #{table_name} to #{output_dir}/"
    end
  end
end

Ever since migrations were introduced to Rails I’ve heard nothing but praise for them, and truth be told, they are a far better way of setting up your database than the standard raw sql import. But, that’s where the goodness ends.

The problem is in the concept of going up or down in database versions. The core concept is great, to be able to roll back to a previous version of the database, but the implementation is completely out of sync with the version control systems we use to manage the codebase that depends on that database. I’ll use subversion as an example because (for those of you still stuck in CVS land) every time you do a check in the system gets tagged with a new revision number.

Everything starts out fine. The initial migration reflects the needs of the initial codebase. But after that they’re never the same. There’s no way to now what migration corresponds to what version of the codebase. What if in checkin 400 I add a new migration that changes the schema. A few weeks later I need to roll back the codebase to version 380. What migration number should i roll the database back to if any? Unless you happen to remember what migration number you were on when the codebase was at 380 you’re screwed.

So what’s the solution?

Well, the solution starts with the schema.rb file that’s created every time you run a migration. If you’re like me, that gets checked in whenever it changes and the schema.rb file is always in sync with your codebase. So you’ve always got a representation of the appropriate database configuration for any revision of your codebase. That’s good. In fact that’s better than the actual migration scripts because it’s always in sync. But there’s one more problem…

**Priming the database**
Most webapps don’t function well with a completely empty database. There are usually some default settings, maybe an admin account to log in with the first time, things like that. And there are a few rake tasks out there to [bootstrap your database](http://rails.techno-weenie.net/forums/2/topics/778?page=1) with the contents of some .yaml files. There are others to [dump your database](http://media.pragprog.com/titles/fr_rr/code/CreateFixturesFromLiveData/lib/tasks/extract_fixtures.rake “warning, that’s a raw rake file”) into the same files for later import, or generating real data to run your tests against.

**Putting it all together**
If you make sure that your your .yaml files for bootstrapping are always in sync (you should be keeping them in sync anyway) then you can avoid the problem entirely by just making your own schema.rb file (it’s just a migration file for all the tables at once) and never running `rake db:migrate` again. Instead run your schema.rb (make sure it forces table creation) and then `rake db:bootstrap`. When you need to modify your database schema don’t make a new migration script. It’ll only confuse matters down the road. Instead, modify your schema.rb and make sure your .yaml files are in sync (you’d have to do that even if you were using migrations).

[Damien Tanner](http://iamrice.org/) points out that migrations are *very useful* when migrating a live site. And I have to agree. My proposed solution is seriously lacking in that department. What would most likely be best is a blending of both concepts. Don’t use migrations to muck about with your database during development. Instead, create migration scripts *only* for migrating data on live sites. Don’t title them “`create_foo_table`” or “`add_foo_column`” but instead name them something like “`live_site_version_4`” or something like that that makes it clear exactly what it’s for and how it pertains to your site.

There’s been a lot on my mind lately. Gears a-moving. Projects in motion. And things to say…

I’ve had a lot to say lately, not that you’d know it from my lack of posting. But, that’s mostly because I find spam really demoralizing and some Arse-hole was manually submitting it! Bots I can understand, they suck but at least it’s just some mindless thing that happened to find a site it knew how to submit to. But no. weblog.masukomi.org was a one of a kind intstallation. So writing a bot for it would be pointless. ARGH someone too the time to manually add spam to all my new posts!

I couldn’t take it.

So, I sucked in my gut, upgraded mysql, (after doubly covering my butt against potentially hosing client databases on this box), and installed [Mephisto](http://mephistoblog.com/) (edge version). I said “screw it” to dealing with making a custom theme. There’s just way too much on my plate right now that I consider far more important. Like:

* The new web based version of ListfulThinking (not released yet).
* Another web app I’ve been working on to support ListfulThinking, then realized I could sell it too!
* Bug fixes for [ServerWatcher](http://serverwatcher.masukomi.org/) (not formally released but available in [CVS](http://sourceforge.net/projects/serverwatcher))
* A book on managing open source projects.
* And the big one you’ll see in a couple days… Caterpillar 3.0.

Caterpillar 1 and 2 were extremely compact news aggregators written in Java with a Swing UI. Caterpillar 3.0 adds Bayesian filtering to find “interesting” articles. Why? Well, you see I, unlike most people, subscribe to a LOT of feeds. 220+ last time I checked. Mostly blogs of programmers like me or people like [Dooce](http://www.dooce.com/) who just rock. But, while I’m definitely the exception you probably do exactly the same thing with Mailing lists. You end up subscribed to many interesting lists, get flooded with so much mail you couldn’t possibly keep up with it all, and then get frustrated because you *know* you’ve missed something interesting in there.

So what’s the solution? The same thing Thunderbird and just about every other mail app uses to keep out spam. Just reverse it and apply it to feeds. Instead of leaning what articles suck (spam) you train it what articles rock.

I’ve been sitting on this for over a year now. It’s a great proof of concept and I knew that with a bit more work it could be something sellable. Except, I have other projects that I am far more interested in working on and I realized that I’d been completely ignoring my own advice on when to set an app free.

As I’ve said before I think that there are some great reasons not to open source an app. The biggest of which money. But far too many developers keep things under wraps because they “might sell it someday”. Well, that’s just what I had been doing. Actually I was serious about selling it for a while but things changed. I met a girl named [Ruby](http://www.ruby-lang.org/) and fell in love. Java…. well, we won’t talk about him. Boys are icky anyway.

So, yeah. I commented out the registration bits, made some bug fixes, and will be releasing it shortly. But, I don’t really have much interest in setting up yet another project and adding yet another source of bugs needing fixing to my plate (what with two potentially profitable and far more enjoyable Ruby on Rails projects on the horizon). So it will be a drop shipment kind of release. Kersplat. code… dribble….

Regarding this site:
The feed is… well, don’t subscribe to it quite yet, I still need to hook it back into feedster which means it’ll probably be repointed within a few days, but it’s late, and i’ve been poking at annoying bits for hours now.

The old articles… no clue. Maybe I’ll take the time to import them. Maybe I won’t.

In the future you should expect a different kind of blogging from me. I’m planning on doing a [Paul Graham](http://www.paulgraham.com/) kind of approach to it. Well written articles (unlike this one) with a point. I’ve got a few queued up in my head already.