Perspectives: Writings from The Killswitch Collective

Monetize This!

Thu, 25 Jun 2009 09:00:35 -0700

It seems that business pundits are of the mind that many of the successful social networks that exist today are doomed to fail because of a crippling inability to monetize themselves. I've thought about this and I'd like to take a moment to mount my digital soapbox. After much reflection, I think that this is not only a myopic point of view, but that it is exactly this line of thinking that will in fact bring down social networking as we know it.

I'll be honest with you; in college I didn't exactly excel in my Finance, Accounting and Econ courses (and that, as my mother will tell you, is putting it lightly). However, I have been around long enough to recognize good business practice when I see it. I mean think about it, we all are experts in our own right, simply by performing our role as consumers.

As consumers, we reward those that provide useful, reliable, friendly services with our continued patronage. If they provide us with the contrary, we take our business elsewhere. We may not be schooled in the science of supply and demand, but we are smart enough to know when we are getting the short end of the stick.

But I digress… Back to the topic of monetizing social networks. For the jury, I submit Exhibit A: Facebook, the Grand Poobah of the social realm. Facebook seems to be perpetually seeking ways to monetize itself and every time it does, it shoots itself in its very corporate foot.

In November 2007, Facebook launched Beacon, a system where third-party websites can include a script by Facebook on their sites, and use it to send information about the actions of Facebook users on their site to Facebook. Information such as purchases made and games played are published in the user's news feed. While still active, a class action lawsuit was filed in 2008 against Facebook, Blockbuster Inc., Overstock.com, Fandango, Hotwire.com, GameFly, Zappos.com, and any additional "John Doe" corporations that participate in the Beacon service.

In 2008, we loyal users learned of a clause in the network's terms of service that reserved Facebook the right to sell users' data to private companies, stating "We may share your information with third parties, including responsible companies with which we have a relationship." The backlash from this revelation was so great that Facebook eventually removed the clause from their privacy policy when it was updated on November 26, 2008.

More recently, there are reports of rampant "click fraud" occurring within the network's cost-per-click advertising, a service mainly used by small self serve advertisers. In some cases, advertisers have reported gross misrepresentation of click-throughs as high as 10:1 when gauged against third-party metric tracking sites. The site instructed those who have issue with the service to log the discrepancies and submit them to Facebook. After taking the time to collate these logs, advertisers have been rewarded with a reassuring, pre-scripted response letter.

As I list these controversies, I know that they have resulted in little or no change in how the Facebook runs its network and that they have had no effect whatsoever on the exponential increase in FB users (What? Are we supposed to switch to MySpace? Please, that is so 2004).

However, the alternative network twitter , which most social mavens now use almost exclusively, has Facebook worried about its future (for evidence, just look at all of the new, twitter-like features recently added to Facebook). It isn't out of the realm of possibility that if Facebook continues to lose credibility, users will up and take their profiles elsewhere.

WARNING: If you are a devout capitalist, or if your name is Rupert Murdoch, the following paragraph may make your head explode.

What I propose as a solution is simple: don't monetize them, at least not in the traditional sense. There exists in media a perfect example of how these sites can persevere and ensure longevity, but I haven't heard a single pundit offer this idea yet. I suggest that social networks adopt the same model as PBS and NPR. Revenue will come through "donations" that are made by corporations and businesses that wish to participate in this medium. If they are smart, these businesses will realize that they have a vested interest in ensuring the survival of these networks as a communication tool. This will require that that they accept that there is no way to moderate or direct the conversation; the value lays in the ability to facilitate and participate in it.

Not only will this provide a constant stream of revenue, but this model will ensure transparency throughout and allow these networks to maintain the trust and continued participation of its users.

I am not naive enough to think that the CEO's, CFO's, MBA's, etc. that run these sites will ever consider such a drastic course. I understand the need for ever-increasing revenue, especially in the digital world where the necessity for continued improvement requires substantial reinvestment. Only time will tell if Facebook and twitter and their ilk can survive or if the imminent death of MySpace is an aberration and not a paragon. I simply encourage those in charge of running our social networks be wary of how they seek to monetize them in the future, because their track record so far has me worried.

Twitter Backgrounds, Courtesy of Killswitch

Mon, 08 Jun 2009 15:03:52 -0700

Your friends swear it is the best thing ever. Time Magazine is running a cover story on it. You've heard stories of people getting jobs through it.

And finally, you got yourself a twitter account.

Hopefully, you've quickly acclimated yourself with this awesome service and are on your way to becoming a full-blown "Tweep" (person on twitter). And as you've perused through Ashton Kutcher's, Brittney Spears' and hopefully some more informative pages, you may notice that twitter allows its users to post custom background.

Want a unique twitter background? Killswitch is here to help you make your twitter page all the rage with some backgrounds of our very own design.

Just visit the ftp sites and download the images to you desktop.

Changing your twitter background is easy:

1. Log in

2. In top navigation bar, click Settings (or go to http://twitter.com/account/settings)

3. Click the last settings tab, Design

4. Change your text and background colors and upload your background image

5. Save your changes

We've also included a our Grey Things image as a transparent GIF. This way, if you want to add your own touch to this background (our feelings won't be hurt, go ahead!), you can adjust your background color to whatever you please. However, this is a little tricky...

1. From the Design tab, choose "Change background image"

2. Then, click "no image"

3. Adjust your background color to your liking

4. Upload the "Grey Things" GIF

5. Save changes

And the image should show up on top of the background you selected.

Don't forget to follow us on Twitter for more artwork to come!

Digital Strategy In A Recession

Wed, 27 May 2009 12:00:28 -0700

When times are tough, companies tighten the belt buckle (thank you, Captain Obvious). This generally entails companies cutting or severely limiting their expenditures on non-essential projects to free up money for important things…like executive bonuses (ZING!). While businesses are cutting down expenditures across the board, many proactive companies are making concentrated efforts to grow and enhance their digital presence.

Before I write any further, let me address my somewhat biased opinion on the matter. Yes, I am the New Business & Marketing Manager of a firm that sells clients digital services and that would serve to reduce my impartiality. With that said, I am merely pointing out what others have chosen to do with their limited budgets. I just happen to think that they are right.

A great first example is the recent launch by The New York Times of its TimesReader 2.0 . Here is an industry that is, by all accounts, dying. It seems that every month there is news of yet another prominent newspaper going bankrupt, and while the Times will no doubt survive this print holocaust, it has not been immune to the pitfalls that plague its industry contemporaries (see Reuters' article "S&P cuts New York Times rating deeper into junk status" ). Realizing that in order to survive and remain an industry-leader, the Times has chosen to invest in developing the first truly "digital newspaper".

Competitive advantages are all the more important in today's tough marketplace. One of the best advantages a business can leverage in a recession is customer service which, when executed correctly, builds consumer loyalty and can distinguish a business from its competitors. The web provides businesses the opportunity to interact and engage customers in an expedited and convenient manner, provided that they embrace emerging technologies and digital trends (note to cellular companies, your online chats are even more infuriating than your 800 lines). Domino's Pizza recently committed to improving dialogue with consumers by hiring a consulting agency to assist them in strengthening their relationships with consumers through online communities. As stated in their press release, Domino's seeks to "continue to incorporate social media into their overall communications plan, expand consumer trust, and build excitement in new services and products."

But investing in digital doesn't have to mean investing large amounts of capital. For example, take what some small businesses are doing with the free service Twitter . New Orleans based Naked Pizza, recently launched a Twitter-specific marketing campaign that proved to be rather successful. In a test run April 23, an exclusive-to-Twitter promotion brought in 15% of the day's business. And while Twitter has yet to offer a comprehensive analytics tool, the simple daily tracking of how many users you are attracting shows at a macro-level how your outreach via the service is fairing.

Does bolstering your digital presence make your company "recession-proof"…probably not. It isn't a cure-all and it can certainly require some investment when funding is tight. However, going digital (as it pertains to your specific industry and audience) arms your company with a proven means of communication in a time when traditional methods are proving ineffective.

Or you can always think of it like this: In this economy, it couldn't hurt to try.

Super Easy Number Tracking with FatNum.com

Mon, 16 Mar 2009 09:43:28 -0700

What's Your FatNum?

Numbers are a big deal. Whether you're talking about business, family, fun, personal goals, a lot can be simply boiled down to one big, fat number...

How many people registered for my app?
How many batches are left in my database import?
How many days left until my birthday?
How many pounds have I lost on my diet?
And so on...

So what's the big, fat number that you need to keep track of? Whatever it is, FatNum.com can help.

What is FatNum.com?

FatNum.com lets you signup and start tracking your FatNums right now! Right away you are given a simple Web interface for creating your FatNums and keeping them up to date. Each FatNum is assigned a five-character code, so you can share your FatNum with others discreetly without having to log in.

For all you programmers who want their Ruby apps to share data with FatNum.com, I've built this RubyGem for easily accessing and updating your FatNums. From the documentation:

require 'rubygems'
require 'fat_num'

f = FatNum.new('your@email.com', 'password')

# get your statistic
response = f.get('e37gh')
response.digit #=> 120
response.description #=> 'batches left'

# update your statistic
f.update('e37gh', 119)

# sure enough, our update was successful
f.get('e37gh').digit #=> 119

There's also some love for all you Mac users out there -- download the FatNum Dashboard Widget and easily track your FatNums from the comfort of your OSX Dashboard!

Any More Examples?

Here are a couple FatNums that FatNum.com is using for itself:

FatNum.com is super simple, almost to a ridiculous degree, but I hope you can find some imaginitive uses for it!

Best Practices for Using and Hacking Gems

Mon, 09 Mar 2009 09:26:05 -0700

If you have built a Rails application, there is a good chance the power of Ruby gems were utilized to quickly add new functionality. In this article, we're going to go over some best practices to follow when using gems within a Rails application. I will demonstrate how needed gems can be specified in your environment, unpack a copy into your application and then we will do a little gem hacking without breaking them.

The application we are about to build won't really be an application, we won't be creating any views, controller or even touch the database. We will be using the Gruff gem by Geoffrey Grosenbach to generate some simple graphs and then we will enhance Gruff with some new options.

Installing and Freezing

Let's get started by creating a new Rails application and installing the Gruff gem.

rails gem_hacks
sudo gem install gruff

Add the following in the Rails::Initializer.run block in your config/environment.rb:

config.gem "gruff"

By adding config.gem "gruff" in our environment the application will look for the gruff gem on start up. If it doesn't exist it will throw an exception. This is much better than having the application running while the portions that depend on the gem error out.

Lets make sure Gruff appears in the application's gem list and then copy it to the vendor/gems directory of the application with the unpack task.

rake gems
rake gems:unpack:dependencies gruff

By including Gruff within the application, we won't have to install the gem on every box the application finds itself on. Also, every developer working on the project will not have to worry about having the same gem version installed.

Making It Our Own

Next let's create a BarGraph class that will require 'gruff'. The BarGraph class will serve as a wrapper method for generating common bar graphs found on the site.

require 'gruff'
class BarGraph
  
end

Every ruby class needs an initialize method in order to create new instances. Add an initialize method inside the BarGraph class filled with Gruff code that will generate a static bar graph for now. Then create the bar_graphs directory inside of public/images.

def initialize
  g = Gruff::Bar.new("400x300")
  g.data :years, [185, 155, 110, 90, 135]
  g.labels = { 0 => "2004", 1 => "2005", 2 => "2006", 3 => "2007", 4 => "2008" }
  g.write('public/images/bar_graphs/test.jpg')
end

Next fire up your console and try BarGraph.new, then go into your public/images/bar_graphs directory and open up test.jpg, it should look like the following:

Making Improvements

Notice how the bar of the lowest value (90) is barely visible? By default, the minimum value will be the lowest value and the maximum will be the highest value. We can customize this by setting more attribute values of the instance. Add the following before the g.write line.

g.minimum_value = 0
g.maximum_value = 200

Let's once again regenerate our graph through the console; now the bar with the value of 110 should be visible.

Great, our graph starts at 0 and we've added some potential by specifying a higher maximum value. Lets make our BarGraph class more dynamic by adding some arguments that can be passed through the initialize method and refactor the code within.

def initialize(values, labels, save_path, options={})
  g = Gruff::Bar.new("400x300")
  g.data :years, values
  g.labels = labels
  g.minimum_value = 0
  g.maximum_value = 150
  g.write(save_path)
end

Now whenever we call BarGraph.new, arguments for values, labels and save_path will be needed. Reload your console and give the following a try:

BarGraph.new( [185, 155, 110, 90, 135], { 0 => "2004", 1 => "2005", 2 => "2006", 3 => "2007", 4 => "2008" }, "public/images/bar_graphs/test_with_arguments.jpg" )

This will generate the same graph as before since we are passing in the same data. If we passed in an array with values higher then 200, however, it would get cut off due to the static maximum value in our initialize method. We can remove the maximum value portion from our initialize and Gruff will default to the highest value in our array. Another option is to add code that will take that maximum value and round it up.

Hacking the Gruff Gem

The auto-rounding of the maximum value would be a good feature to have in other Gruff graphs as well. Since we have the gem source in the vendor/gems of our projects, adding it there might sound like a good idea at first. Later in the project lifecycle, however, the gem might be updated and those custom additions would be lost.

The ideal solution would be to create a new module that would contain our hacks which will be included wherever needed. Whenever the gem is updated and our hacks break, we can easily fix them since they are all located in one place. With that being said let's create our GruffHacks module and save it as gruff_hacks.rb in lib.

module GruffHacks
  class Gruff::Base
  
  end
end

Our GruffHacks module contains the Gruff::Base class which is found in vendor/gems/gruff/lib/gruff/base.rb. Take a few minutes to browse through the Base class as we will be overriding methods from it next. Near the top all the attribute accessors for Gruff are being set. These attributes are shared between all graphs since they are part of base. Lets add a attribute accessor for rounding maximum values called round_maximum_value into Gruff::Base of our GruffHacks module.

Remember we are not editing any code from the gem source, we are only going to use it for reference and copy methods that we will be overriding from it. Next lets copy the entire initialize_ivars method from the gem source into Gruff::Base of our GruffHacks module. At the bottom, after @norm_data = nil, let's add @round_maximum_value = false. The initialize_ivars method is responsible for setting default values for Gruff attributes, here we are setting @round_max_value to false to cancel out the rounding functionality we will add soon. The goal with this module is to enhance Gruff, but to have it function normally if our attribute hacks are not being set.

With the round_maximum_value attribute accessor along with its default value added, now it is time to set the new maximum value when round_maximum_value is true. Add the following method into Gruff::Base of our GruffHacks module

def round_maximum_value=(value)
  if value == true
    rounded_maximum_values = []
    
    # loop through each bar group, grab the highest value, round it up and add
                # to rounded_maximum_values array
    highest_val = @data.each do |row|
      row_highest = row[1].sort.last
      round_to = 10 ** (row_highest.to_s.length - 1)
      rounded_maximum_values << row_highest.roundup(round_to)
    end
    # Set maximum value based on highest rounded value
    @maximum_value = rounded_maximum_values.sort.last
  end
end

Add this after the very last method of GruffHacks, these two helpful methods are created by Charlie from PullMonkey for rounding numbers up or down. Our round_maximum_value method uses the roundup method.

class Numeric
  def roundup(nearest=10)
    self % nearest == 0 ? self : self + nearest - (self % nearest)
  end
  def rounddown(nearest=10)
    self % nearest == 0 ? self : self - (self % nearest)
  end
end

Before testing our new hack, lets include the GruffHacks module into our BarGraph class by adding include GruffHacks after the Gruff require statement. In our initialize method remove the g.maximum_value line and add in g.round_maximum_value = true. If you try regenerating the same graph as before, the maximum value will now be 200 since 185 was rounded up.

Worth the Effort

By overriding the initialize_ivars and adding the round_maximum_value setter into Gruff::Base we are able to automatically add some space between the highest value and the top of the graph by simply setting a single attribute to true. If there is a need to change this functionality later on, we won't have to dig through the gem source and hunt for modified lines. Instead we open up our GruffHacks module and easily find our overridden methods. It is also much easier to add new methods, maybe more style options are needed for the bars or the labels need to be positioned in a different way. Whatever it is, by keeping these enhancements in a separate module makes sharing and updating hacks between applications easier.

As projects grow, it becomes harder to keep up with all the details. Even if you are the only developer on the project, there is a good chance the inner workings will be forgotten months later. By breaking simple hacks into new modules we are minimizing the potential of possible bugs, and any bugs that do exist will be easier to find. Spending a few extra minutes to better organize your code and using the object oriented nature of a language such as Ruby will save time for you and your fellow colleagues.

DataMapper::AbstractAdapter 101

Fri, 27 Feb 2009 12:20:20 -0800

DataMapper is an object relational mapper for ruby with an interface somewhat similar to ActiveRecord's. More than sprinkles on top of a generic SQL adapter, DataMapper is a design pattern for defining repositories and the models that love them. DataMapper differs from ActiveRecord and ActiveResource in that models are encapsulated from repositories while queries and collections communicate between them. One of the most significant advantages to this approach lies in the ability to develop models separately from their repository.

Over the next several articles we will use the Twitter API to explore how DataMapper expects custom adapters to work, executes CRUD requests, handles associations and works with multiple repositories. For now we will concentrate on the basics of DataMapper and querying users from the Twitter API service. Those comfortable with ruby or ActiveRecord should be able to follow along, however I strongly recommend spending time with DataMapper's fantastic documentation if you have not already.

Modeling Our Models

First things first, we should install DataMapper and define a model to represent a user account from the Twitter API. To do that we need to define a module using the DataMapper::Resource module and describe the properties Twitter provides.

gem install datamapper

require 'dm-core'

class User
  include DataMapper::Resource

  property :id, Integer, :field => 'user_id'
  property :name, String
  property :screen_name, String
  property :email, String
  property :location, String
  property :description, Text, :lazy => false
  property :profile_image_url, String
  property :url, String
  property :protected, Boolean
  property :followers_count, Integer
end

DataMapper differs from the ActiveRecord family in that fields are defined in your model rather than being created from the repository's schema. This allows models to be built without an adapter making a connection and avoids the headaches of ActiveRecord-style migrations. Additionally you may specify the :field name to be used for each property, allowing antiquated or confusing field names to be user friendly. Defining a model's properties also allows DataMapper to intelligently calculate by type which fields should be lazily loaded, which may also be customized by passing the :lazy option a true or false value. In our User model we have set the lazy option to false as Twitter provides a user's description by default, and there is no use in wasting an API hit if we do not need to (Twitter limits API calls by the hour). A more in-depth description of DataMapper's lazy fields can be found in the documentation.

The Base Adapter

For the foundation of our Twitter adapter we need to catch any authentication options passed to the initialization as well as write a method for communicating with Twitter.

require 'cgi'
require 'open-uri'
require 'rubygems'
require 'dm-core'
require 'xmlsimple'

module DataMapper
  module Adapters
    class TwitterAdapter

      # Clients can provide DataMapper with a URI string or hash of options when
      # initializing an adapter. We can store these values and use them for each
      # request to the Twitter service if the client provides them. Depending on
      # your repository you may wish to verify authentication here rather than 
      # waiting for the initial request.
      #
      # name:: Name of the adapter
      # uri_or_options:: A uri string, or hash of options used to initialize the adapter
      #
      def initialize(name, uri_or_options)
        # don't forget to phone home!
        super(name, uri_or_options)

        case uri_or_options
        when Hash
          user = uri_or_options[:user] || ''
          pass = uri_or_options[:pass] || ''
          @auth = user.blank? || pass.blank? ? nil : [user, path]
        end
      end

      private

      # Requests a resource from the Twitter API. If the adapter was initialized
      # with the :user and :pass options, they will be used to authenticate the request.
      #
      # method:: Path to follow the base URI 'http://twitter.com'
      # params:: Hash of key/value pairs to be used as the query string
      # returns:: XmlSimple representation of the response from Twitter
      #
      def request(method, params = {})
        uri = "http://twitter.com/#{method}"
        options = {:http_basic_authentication => @auth}

        unless params.blank?
          query = params.map { |k,v| "%s=%s" % [CGI.escape(k), CGI.escape(v)] }
          uri << "?#{query.join('&')}"
        end

        result = open(uri, options)
        return XmlSimple.xml_in(result.read, {'ForceArray' => false})
      end

    end
  end
end

Now we can go ahead and see if we are on the right path, we should get a NotImplementedError when we try to perform any action with our repository.

DataMapper.setup(:default => {
  :adapter => 'twitter',
  :user => 'kscollective',
  :pass => 'snark snark'
})

User.first(:screen_name => 'kscollective') # => NotImplementedError

Fetching Heffalumps And Woozles

In order to continue building our adapter we have to be able to understand the queries and collections DataMapper uses to mediate between the models and adapters. DataMapper::AbstractAdapter defines #read_one and #read_many, both of which accept the query as the single parameter. The query object allows us to determine which model and fields to query along with any possible conditions to limit our results by. Queries also tell our adapter about any possible offsets, limits or ordering, but we will come back to that another day.

Query#model

Each query belongs to a model which we can use to load and return instances fetched from our repository, and may also be used to customize repository requests by type. We can even use the model to DRY up our adapter and work with a single #read method.

class << TwitterAdapter

  def read_one(query)
    read(query, query.model, false)
  end

  def read_many(query)
    Collection.new(query) do |set|
                  read(query, set, true)
    end
  end

  private

  # Each read has a query and returns a set, #read_one and #read_many should provide
  # the set to load the results into. When called by #read_many nothing needs to be returned
  # as the collection is filling itself, however we must return what ever object #read_one 
  # should return back to the client code.
  #
  def read(query, set, many = true)
    raise NotImplementedError # to be filled in later
  end

end

Query#fields

Each query contains a subset of the model's properties specifying which fields to query as well as the order of our values when instantiating each result. Twitter does not provide a means to filter out fields so we will use #fields only to order the values we pass to the model builders.

class << TwitterAdapter
  
  # Map the values from item into an array of the same size and order as Query#fields
  # [id, name, something_else, title] => [1, 'Hello World', nil, 'Cats!']
  #
  def parse_user_values(query, item)
    return query.fields.map { |f| item[f.field.to_s] }
  end
end

Query#conditions

The meat of most queries, conditions is an array of tuples containing the operator, property and value to be considered when executing the request. Each operator may be any of the standard 'SQL' operators (:eql, :in, :gt[e], :lt[e]) and should be used to match the property with one or more values. Because Twitter only provides a method to query individual users by id, email or screen name we can write a method to create an array of key/value pair queries.

class << TwitterAdapter

  def generate_users_query(query)
    result = Array.new
    fields = ['user_id', 'email', 'screen_name']
    
    conditions = query.conditions.select do |condition|
      condition[0] == :eql and fields.include?(condition[1].field)
    end
    
    # each item in conditions is a [operator, property, value] tuple
    for operator, property, value in conditions
      # if an array, each value must be queried individually
      [value].flatten.each { |v| result << [property.field, v] }
    end
    
    return result
  end

end

Mind The Gap!

What used to be the hardest part in using third party resources has now become a matter of building the request, parsing the request and loading the model.

def read(query, set, many = true)
  queries = generate_user_queries(query)
  
  for key, value in queries
    twitter_user = request("users/show.xml", {key => value})
    next if twitter_user.blank? or twitter_user['screen_name'].blank?
    user_values = parse_user_values(query, item)
    many ? set.load(user_values) : (break set.load(user_values, query))
  end
  
  return
end

Recess!

At this point you should be able to query users from Twitter without parsing a single query string or XML response.

DataMapper.setup(:default => {:adapter => 'Twitter'})

user = User.first(:screen_name => 'KSCollective')
puts user.url # => http://www.killswitchcollective.com

As you can see DataMapper can make working with third party repositories as automagical as ActiveRecord. DataMapper itself comes with adapters for the major databases with additional adapters available for CouchDB, Google Video and many others. In a few weeks we will continue building our Twitter adapter, leveraging the power of associations. Until then I highly recommend reviewing DataMappers documentation, the adapters included with the dm-core gem and the base adapter we have just built.