• Read more about Twitter Could Make Money By Charging Per Follower

It's probably not a new idea, but amidst its rising popularity, and increasing speculation that Twitter might charge commercial users, I wonder if charging business users on a per-follower basis might be one way the service could make money.

In the world of print, advertisers are charged on the basis of impressions, usually expressed in CPM (cost per thousand). It costs more to advertise in Wired than it does in Model Railroader. (No offense to model railroaders.)

But wait, you say. Isn't everything online free? (Of course not, but thank you for asking.) Online advertisers pay Google AdWords based on the popularity of the term and on the number of clicks, measures which represent the number of people who have opted (agreed) to view the advertising content. (The term social media, for example, costs $2.28 per click. Save money by buying three word terms like social media marketing and social media PR for just $.05.)

In other words, marketers have tacitly agreed that they are willing to pay based on cost per impression. When someone follows a company like Southwest Airlines, Zappos, or Dell, that represents something equal to a click, and in fact, may be more valuable, as it indicates agreement to view multiple, ongoing advertising messages from the company.

This proposal raises a number of issues of course. What is commercial use? Clearly a Fortune 500 company promoting its goods and services is engaged in commercial activity. So, too is a crafts person with an Etsy account or a real estate agent, but they don't stand to achieve the same commercial advantage as the larger corporation. This seems inequitable, although, to be fair, they would pay Google AdWords the same dollar amount for the same words and clicks.

Non-profits, schools, public safety, public health organizations and many other classes of users are non-commercial and should not be charged based on their follower count (and no one is saying Twitter plans to charge them.)

But the intensity with which Twitter users pursue any and every strategy to grow their follower count, including offering expensive prizes like laptops to attract new followers, demonstrates recognition of the value of a large number of followers.

The question is, how many will continue to recognize this value when they are asked to pay for it?

• Read more about Git Hooks, Presently, Mice, Sharks, and Zombies

Way back in the day we used to use Campfire and Subversion. Time happened, it’s the future, and now we use Present.ly and Git. Remember how those commit messages would just show up in Campfire whenever anyone did an svn commit -m ‘whatever’? Wouldn’t it be nice to be able to publish Git commit messages to Present.ly just like the old days with Campfire and Subversion?

We can do it. We’ve been doing it. We’re doing it right now.

The first thing you’ll need to know is that Git has hooks. Lots of them. They live in the hidden ‘.git/hooks’ folder in your project. Their names are relatively descriptive and tell you when these hooks will fire. The one we’re particularly interested in right now is ‘.git/hooks/post-commit’.

Open up that file, there’s stuff in there, delete it and add the following hotness instead:

Once you’ve updated your account, username, password, and the group to which you want to send your messages – you need to make this bad man active so it will fire at your will. The zombies will never see it coming:

chmod +x .git/hooks/post-commit

Keep in mind that none of these hooks will fire unless they are marked as executable. This will bite you; it did me, and I’m still recovering. It’s okay son, that’s how we earn our stripes.

Make some changes, queue ‘em up, hit commit, and BLAM: you’re knee deep in dead zombies and commit messages! But how do you kill something that’s already dead…

• Read more about Yet Another Twitter Monetization Strategy: 'Claimed' Hashtags

So everyone and their cat have made predictions about how "Twitter":http://www.twitter.com/ will and could monetize (what, you haven't heard of Sprinkles the economic forecasting cat?). I have one more idea, but it's not because I think that this necessarily will happen so much as because I think it would be a fantastic feature to have for businesses on Twitter. The concept is 'claiming' a hash tag.

Now the main Twitter interface pretty much ignores hash tags, but "Twitter Search":http://search.twitter.com/ does not and I see it as a given that hash tags are here to stay. So for hash tags that have to do with an event, a company, or other kinds of definable entities there should be a special text advertising block that can be purchased at the top of the tag search that will allow the entity that the tag is about to explain and maybe provide a few links.

For example, with all of the "endless tweets about SXSW":http://search.twitter.com/search?q=sxsw I think it would be useful both for the SXSW organizers *and for the people looking at the tag* to have a block at the top that says something along the lines of "SXSW is a conference held yearly in Austin, TX that encompasses video, audio, and interactive media" with a couple of links to pertinent information. This provides a context to people clicking through to the Twitter Trends #SXSW tag who wouldn't otherwise know much about the conference and gives SXSW another way to promote themselves.

This system would have to have some pretty stringent acceptance requirements, you wouldn't want competitors to be able to claim their opponent's tags etc. but I also think it has a lot of promise for providing a revenue stream for Twitter and actually useful information for users. I'm not a market prognosticator, and I think it's actually pretty unlikely that this would come to pass, but I do think that it would be an interesting new way to advertise on the web.

• Read more about Document Your Models the Easy Way

At a recent DCRUG meeting, I was surprised by how many Rubyists, novice and experienced, were unfamiliar with two great documentation tools: annotate_models and RailRoad.

I suspect this is because they relate to the dreaded “d” word: documentation. This is a shame, because these two tools make basic documentation a cinch.

annotate_models

One of the best things about the popular Ruby ORM libraries like ActiveRecord and DataMapper is that you don’t need to spell out the attributes of your models; they are inferred from the database.

Sometimes, though, it is useful to have this information at hand, instead of firing up script/console or your database to answer a simple question like: “Did he call it User.first, User.firstname or User.first_name?”

The annotate_models gem, originally written by Dave Thomas creates a nice comment block at the top of each model, displaying information about the underlying columns/attributes:

 # == Schema Information                                                          # Schema version: 20090311145521                                                 #                                                                                # Table name: groups                                                             #                                                                                #  id                     :integer(4)      not null, primary key                 #  name                   :string(255)                                           #  description            :text                                                  #  created_at             :datetime                                              #  updated_at             :datetime                                              #  status                 :integer(4)      default(1)   #

Producing this documentation is as simple as running annotate in your Rails application’s root directory.

Another nice aspect of annotate_models: it will only modify the headers of models that have changed since the last time it was run.

RailRoad

Another useful view of a Rails application, especially a legacy one, is the big picture: i.e., how do all the models (and controllers) fit together? This can be especially daunting when you are following the trail of :belongs_to and :has_and_belongs_to from one file to another.

A free tool, Javier Smaldone’s RailRoad, can tell you all that information at once, by generating a diagram of the models and key information about them, like names, attributes, associations and inheritance relationships.

A minor inconvenience is that the project’s models are outputted in .dot format. This is easily converted into .svg and .png if, like me, you prefer those formats.

Because I do this often, I have added the following alias to my ~/.bashrc and just run rr as needed.

 alias rr='railroad -M | dot -Tsvg > doc/models.svg; railroad -M | neato -Tpng > doc/models.png'

If you are happy with .dot files (e.g. you are a GraphViz user), it’s as simple as running railroad -M.

Another cool feature: you can use RailRoad to document your controllers too; just pass it the -C flag instead of -M.

Conclusion

Now, I know this hardly suffices as thorough documentation. However, I also know that I’ve been in web development for a decade and most projects I’ve seen have no documentation at all.

Complete documentation would be great, but it is time-consuming and requires good written communication skills — a tall order for your typical software engineer. Keeping that documentation up-to-date with rapidly-evolving software is even more challenging.

These two tools provide great “bang for the buck”. Check out the repository and run these two commands, and suddenly a legacy Rails application is far less opaque.

I run the commands manually, but you may also consider automating it as part of your build process, or even as a post-hook for rake db:migrate.

Either way, you can trust me on this: if you spend fifteen minutes installing these gems, a few seconds running annotate and rr, you will save hours over the course of your projects.

• Read more about Temporarily disable ActiveRecord callbacks

ActiveRecord callbacks can be super-handy, but every once in a while, they get in the way.

I was recently working on a client project and I had to create a rake task to import a large set of data from a spreadsheet.  One of the models that was being imported had an after_save callback that sent out an email notification.  I didn't really want 3500 emails to be sent out whenever this rake task was ran, so I needed to disable the callback while the import task was running.

Fortunately, this is easy to do.

Say you've got a model like so...

class Thing < ActiveRecord::Base    before_save :do_stuff      def do_stuff      raise "This thing is doing stuff..."    end  end  

In the config/initializers directory, I created a file called extensions.rb.  You can call it whatever you like.  I chose 'extensions' because I use the same file for any minor Ruby or Rails class extensions.  In it, I put this...

class ActiveRecord::Base    def self.without_callback(callback, &block)      method = self.send(:instance_method, callback)      self.send(:remove_method, callback)      self.send(:define_method, callback) {true}      yield      self.send(:remove_method, callback)      self.send(:define_method, callback, method)    end  end   

What this does is grab the callback and store it in the method variable.  Remember, this code only circumvents the 'do_stuff' method, not anything declared as a before_save callback.  It then redefines the method to merely return true, yields to the block, and then redifines the the method with the contents of the method variable. 

Yielding to the block allows you to not have to worry about maintaining the method contents, or restoring it once you're done.  Also, if you were so inclined, you could easily modify this code to accept an array of method names and disable all of them

Once the extension is in place, you can do this...

Thing.without_callback(:do_stuff) do    thing = Thing.new    thing.save  end

...without 'do_stuff' ever being called.

Some people will probably argue that if you need to disable your callback, then your model should be defined differently, but I disagree.  I think this is perfectly acceptable in many cases.  Granted you probably wouldn't want to do this all throughout your application code, but I see no problem with using this technique in a test, or data migration, or in my case, a rake task.

• Read more about Social Media Noobs, Gurus, and Hard Boiled Egg Recipes

Some social media experts and veterans look down on social media noobs, aka newbies, or newcomers. (The word noob comes from l33tspeak, an early hacker language now popular among some social networkers.)

This behavior can manifest itself in several ways, such as the snub at someone who dares to say something as -ve as Wow, have you tried Friendfeed? It's pretty cool! The social media putdown artist can respond, Come on, everyone knows about Friendfeed.

I'm sure this phenomenon exists in other fields, but it's very common in social media. I think there are several reasons for this. Social media is only starting to be taught in universities, and recognized as a profession, so expert credentials are hard to define and are often something one awards to one's self...

Check out my latest column on Talent Zoo: Social Media Noobs and Gurus to read the rest.

• Read more about Easily Search on ActiveRecord Attributes

Rails’s named_scopes are great, and the ability to chain named_scopes together are even better. I am sure many of us have done something like this before:

   User.active.live_in('Virginia') 

That would give you the active users who live in the state of Virginia. You would define something like these in your User model:

   named_scope :active, lambda { |status| { :conditions => { :status => status } } }   named_scope :live_in lambda { |state| { :conditions => { :state => state } } } 

One recent client project has a model where the database table has 30-something columns. Doing these named_scopes became tedious and repetitive. That makes it not fun anymore.

So Dave Pranata and I wrote the searchable_attributes Rails plugin so we could stop worrying about explicitly defining these named_scopes once and for all.

To use it, you just install it like any other Rails plugin:

 script/plugin install git://github.com/rayvinly/searchable_attributes.git 

The plugin will automatically define a bunch of named_scopes for you if you include this in your model:

 class User < ActiveRecord::Base   searchable_attributes end 

You can then search on your models with something like this:

   def index     @users = User.with_first_name_equal('Gilbert').with_last_name_equal_if_not_null('Arenas').with_address_like('Main Street').with_age_greater_than(25).with_state_equal(['VA', 'MD', 'DC']).with_position_end_with('Guard').with_salary_within_inclusive((100..10000)).with_injured_equal(true).with_join_date_greater_than_or_equal_to(5.years.ago)   end 

Take a look in the plugin’s lib/searchable_attributes.rb for a list of automatically defined named_scopes.

• Read more about The end of free social media? Mar. 10 on BlogTalk Radio

Join Yoshi Maisami, Sumaya Kazi and me on Blogtalk Radio, Socially Speaking, Tuesday, March 10, 2009, 4:00 P.M. EST as we discuss The end of free social media?

As conversations rage on about Web 2.0 business models, enterprise social media and other developments in social business, what changes can individuals and businesses expect, and how can they best navigate the evolving landscape? To give you expert insight on why and how to adapt, join us for a discussion with two of Intridea's senior partners, PR/social media veteran Joel Postman; and Business Development lead, Yoshi Maisami.

• Read more about It's Not Anti-Competitive if Apple Does It

There's a company out there that aggressively bundles its products to ensure lock-in. They have an end-to-end chain of devices and software crafted to create an impenetrable, closed ecosystem. They aggressively squash competition, even refusing to let competing products exist on their platform. Yeah, it's *Apple*.

I'm getting tired of the geek world being Apple apologists. We don't hold them to the same standards we hold other companies, especially Microsoft. They make cool stuff and that seems to give them a pass to do whatever they want. I say its time to stop being complacent.

I love Apple's stuff. It's pretty, and the operating system lets me do my work better. In fact, I don't really think I could do my job if I didn't run OS X. Windows is a terrible environment for developing Ruby, and Linux doesn't have the Adobe suite of products for the design work I do. That's exactly where the problem lies: I *must* use Apple software to perform my job, which means that I *must* buy Apple hardware to perform my job. Apple has a monopoly over my computer purchases and that doesn't sit well with me.

The reason that Apple hasn't gotten in trouble for their blatant product bundling and other anti-competitive tendencies is simple: they've never had the broad install base to warrant that kind of consideration. But with Apple's meteoric success in the consumer notebook market and an ever-increasing market share, how long can that really stay true? If Apple ever tips the scales at Microsoft-level popularity (or even a substantially smaller but still significant percentage of the market) they should be called to task just as Microsoft was.

OS X is an operating system. It "can be run on other machines":http://www.insanelymac.com/ and would be except that Apple says no. I'm sick of being told what hardware I have to use to use their software, and I'm surprised that everyone else seems to not only be complacent with this fact but revels in the "awesomeness" of Apple. I use Apple because their software is the best (and only) tool for my particular job, not because I feel some bizarre affinity to a consumer products manufacturer.

Maybe some day anti-trust hearings will force Apple to open up and allow any hardware to run OS X. Maybe not. One thing's for sure though, they aren't going to do it unless their hand is forced. Maybe that makes them a successful business, but it doesn't earn them my respect.

• Read more about ruby_bosh- an XMPP BOSH session initializer

Hot on the heels of my post on why XMPP will be huge, here’s a ruby library to pre-initialize BOSH sessions in your Ruby web applications. This feature allows you to by-pass exposing your user’s XMPP credentials in your HTML views.

The process follows as such:

There are many XMPP servers and BOSH connection managers out there, but as of now this library has only been tested with eJabberd 1.2+. Please feel free to fork and submit a pull request if you’d like to contribute.

The plugins and documentation can be found at: http://www.github.com/skyfallsin/ruby_bosh

Jack Moffit’s written a Django/Python example here.