September 2007

Day Two of Startup Weekend: The End is Near

Today was wild to say the least. We’ve got alot of very talented people, but unfortunately not alot whose expertise lies in development. My push for Rails as our app’s platform has positioned me as the sole programmer on the job.

Thankfully, though, I have some good people with me who have covered side-issues and freed me up to just code. Even still, it was quite a stressful day for me. With my mere two months of Rails experience, and no full apps under my belt as yet, I’ve had to accumulate a good deal of working knowledge today.

To aggravate matters, this morning, scope-creep began to rear its ugly head and continued to do so most of the day. By mid-afternoon, my list of tasks had become enough to occupy a good week or two of development, which obviously began to create and increasing sense of doom in me.

I was determined to finish for the sake of the group, but I admit that the thought crossed my mind more than once to simply say screw it and walk out. Eventually, I was able to speak with user experience team and encourage them to refocus the app: deciding what were the most absolute crucial parts and what could be added after our launch tomorrow. Not surprisingly, there was very little that was absolutely crucial for launch, most of which I already have complete.

Tomorrow, I should be able to finish up the rest of the crucial aspects by mid-morning, and begin to work on implementing some secondary matters, just to make the app a little more complete. I’m much less stressed at this point, and I’m actually starting to see the light at the end of the tunnel.

I guess I should mention some of the major developments today. We decided on a name: TipDish. ‘Tip’, is a reference to The Tipping Point, and ‘Dish’ as in ‘the latest dish’. We have very chic user groups. The ‘Dishers’ are the bloggers, social media users, and such who will be putting out the word. The ‘Tippers’ are the PR and Marketing firms who will be submitting press releases. The naming scheme has grown on me a bit throughout the day, and is starting to become a more natural way of referring to our future user base. I do, however, wish the group had come to this naming scheme before I had already created most of the models and controllers. It was not much fun going back through all my code and renaming everything.

Probably the greatest incentive I’ve received from this weekend so far is the sheer support and confidence from the rest of the team. There were points where I was seriously believing that our launch would not go off and it would all be my fault, but the group seems to have had much more confidence in me than I’ve had in myself. I don’t think I would have been able to make it this far without that.

Now, while I’ve been doing all the programming, I don’t intend to convey that I’ve done all the work. I’m amazed at how much the team as a whole has accomplished this weekend. In fact, they accomplished so much that I always had a sense of disorientation when I was finally drawn out from my little cell upstairs to rejoin the group at large for a meeting or meal. I feel extremely honored to have had the opportunity to work with all the people at Startup Weekend Houston, and that feeling will likely continue to grow as we go into our launch tomorrow.

And, FYI, the launch is planned for 2pm tomorrow, which will be impressive, indeed.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati

One Day Down, Two to Go

The first night of Startup Weekend Houston went off without a hitch. Everyone finally settled in around 7:00pm and we started throwing around ideas. There were alot of interesting suggestions, any of which would have likely made great apps. The one that was finally decided upon was a social media directory for bloggers, suggested by Laura Mayes of sk-rt.com.

Essentially, bloggers can register for topics of interests or niche focuses of their particular blog. Then, PR and Marketing firms can view the list of bloggers and contact them directly about press releases, product launches, etc. The blogger benefits in that they get up to the minute and sometimes exclusive information, and the PR and marketing firms benefit from having qualified voices getting the word out about whatever they’re marketing.

A lot of aspects are still in planning phase, but production will begin tomorrow. We covered generally what the site will need to be and what information will be stored and propagated. Registration will be free for bloggers, but the PR and Marketing firms will eventually have to pay for access. Most likely, accounts will probably end up free across the board until the site is officially released, but again, this is still in planning.

The good news is that Rails won the day over a couple of competitors. I fought rather fervently for this, since I believe firmly that especially given the time constraints we are under, we need a fast and simple development environment, and Rails more or less provides both. Our development teams is pretty small at the moment though, but hopefully we’ll get more people out tomorrow. We also have a few people tapping people on the shoulders to get them involved. With any luck will end up with a powerhouse Rails development team and really make something extraordinary out of this app. Course, if you’re a Rails developer reading this sometime between now and Sunday, you more than welcome to join us. Tonight was fantastic, and I can only imagine that things will be just as great if not more tomorrow and Sunday.

I’ll continue to post on the progress of the app throughout the weekend. In the meantime, you can always stay up to the minute on events and happenings at the Startup Weekend Houston website. Also, don’t forget to check in on Channel 2 and Biz Radio, who’ll both be covering the event.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati

Countdown to Startup Weekend Houston

It’s 4:43pm right now and the festivities begin at 6:00pm for the first annual Startup Weekend Houston.

Startup Weekend in general was first started in Boulder, Colorado earlier this year. For those that don’t know what it is, Startup Weekend is weekend long event, running from 6:00pm Friday to midnight Sunday, where a bunch of talented people come together, come up with an idea for a web application, build it, and launch it.

Surprisingly, for being as new as it is, Startup Weekend is getting a lot of press. Word is that Channel 2 will film the event Saturday, we’ll be the featured channel on UStream.tv all weekend, and Biz Radio will be broadcasting live from the event.

As for me, I feel like death (getting sick), and I’m already sleep-deprived, as it is. But, I’m still going, even if it kills me ;). The only thing I’m not looking forward to is work Monday morning after all this.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati

Meet RSpec: Your Friendly, Neighborhood BDD Framework


Hope Ol’ Stan Lee doesn’t have that “friendly, neighborhood” bit trademarked… ah well… life is to short to worry about such things.

Welcome to your whirlwind tour of RSpec, a Behavior Driven Development framework for Ruby and Ruby on Rails. I debated with myself on how best to start this series of tutorials, and eventually decided to take a breadth-first approach, i.e. dump it all in your lap and break it down from there. So this first post we’ll cover just what RSpec is and what it can do for you and your code.

Since RSpec is simply an implementation of Behavior Driven Development, you’d be best served to read my previous post An Introduction to Behavior Driven Development first, if you don’t know what that is.

Getting back to RSpec. RSpec, in addition to being an implementation of BDD, is more specifically, a DSL, or Domain Specific Language. Which, itself, is a fancy way of saying that it is a programming language designed for a specific purpose or task: namely, the task of specifying the behavior of an application. The programming language part may be a bit obtuse in meaning; it’s not another C or Java or VisualBasic. However, it does introduce a new ‘language’ in Ruby that is specific to defining application behavior.

Now that you know what it is, let’s get to the fun stuff and see what it can do.

I’ve already stated that RSpec’s purpose is to specify the behavior of an application. More to the point, RSpec provides a way for us to set down in stone exactly what our application should do and how it should behave. Notice the emphasis on ’should’. ‘Should’ is a crucial focal point of BDD and it’s how RSpec makes its assertions.

For example, if I wanted to specify that a post should have a title, I would write something a little like this:

describe Post do
before(:each) do
@post = Post.new
end

it “should have a title” do
@post.title.should_not be_blank
end
end

There’s actually quite alot going on there, so let’s break it down.

We start with creating a describe block, which encapsulates our specification. The part right after describe is the name of the class we are describing, in this case: Post.

Then, we have a before(:each) block, which acts as a setup method or initializer for the specification. The :each specifies that we want the following instructions performed for every example. Inside this block, we store a new instance of the Post class in the instance variable, @post.

Next, we add an it block, which tells RSpec we’re starting an example. The example, itself, is everything between the do and end. The string after it, “should have a title”, is purely informational. You could even leave it out. In which case, RSpec would automatically generate a description of the example based on what is inside. In this case, that would end up being, “title should not be blank”.

Inside the it block, we have the real meat of our example. We access the title attribute and specify that it should_not be_blank.

should_not is a method RSpec extends the superclass Object with; should_not and it’s positive version should will both return true or false, resulting in either a pass or fail, respectively, for our example.

be_blank is bit of a different beast. It is not a method itself, but rather signals to RSpec to call the blank? method on our title attribute. blank?, by the way, is an innate method (exists out of the box) that returns true if the variable in question is either an empty string or nil.

Every example you code in RSpec will have at least one statement with should or should_not. The be_whatever part is just one of many different possible arguments (matchers) for these two methods. Let’s look at the full list:

Eql and Equal

RSpec has two levels of equality checks. First, you can use eql or the standard equality operator ==. For example:

"this string".should eql "this string" or "this string".should == "this string"

Second, you can check for equality at the object level with equal or the “three equals” operator ===. For example:

25.should equal 25 or 25.should === 25

However, note:

"this string".should equal "this string" and "this string".should === "this string"

Both of these will actually evaluate to false. To understand why you could run script/console and try the following:

$ ruby script/console
Loading development environment.
>> "this string".object_id
=> 106148390
>> "this string".object_id
=> 106145680

Even though it’s the same string, each instance has a unique object id. The example using 25 works because of the following:

$ ruby script/console
Loading development environment.
>> 25.object_id
=> 51
>> 25.object_id
=> 51

The technical explanation is that 25 is instantiated as a Fixnum, so every instance of 25 afterwards is actually a reference to the first instance of 25. However, strings and most other objects in Ruby receive unique ids for every instance.

Have

Quite often, you’ll want to ensure that a collection has at least a certain number of items: ensuring there are no validation errors on a particular field in a form, for example. RSpec provides an easy way to specify the behavior you want with have. For example:

day.should have(24).hours

It should be noted that in order for this to work, day would have to own a collection, hours, with 24 items. This is really just shorthand for the following:

day.hours.should have(24).items

RSpec provides some “sugar” with have so that both of the following will work without any further implementation:

[1, 2, 3].should have(3).items and "fun".should have(3).characters

Additionally, some things in RSpec exist simply for the purpose of readability. One example of this is have_exactly, which is just an alias for have. So, the code above could be be rewritten as:

day.should have_exactly(24).hours

Either way works; it’s simply a matter of preference.

Often, you won’t be entirely sure about how many items you should have, but you will know a minimum or maximum. Once again, RSpec comes through with have_at_least and have_at_most. For example:

blog.should have_at_least(1).post or question.should have_at_most(4).answer_choices

Include

Closely related to have, we have include. Whereas, have concerns itself with the number of items in a collection, include concerns itself with the collection’s values. For example:

{ :str1 => 'first string', :str2 => 'second string' }.should include('second string')

The above would pass because the value ’second string’ exists in the the collection. You can even specify multiple values as such:

[1, 2, 3, 4, 5].should include(1, 3, 5)

However, when you specify multiple values for the include all of those values must be present in order for the example to pass. The following would fail, since 6 is not present in the array:

[1, 2, 3, 4, 5].should include(2, 4, 6)

Match

RSpec provides the ability to match based on regular expressions through the match matcher. Like eql and equal before, there’s you can also the use the operator equivalent, =~. For example:

"sample string".should match(/sample/) or "sample string".should =~ /sample/

Predicates

The previous matchers have all been methods specific to RSpec. The true power of RSpec comes from letting you apply its behavior-specific language to your own methods. It does this via various prefixes. We encountered one of these earlier with be_blank. As we saw, the actual method being called is blank?, but by prefixing it with be_ we can not only instruct RSpec to call this method, but also maintain nicer readability. Here are some other common uses of the be_ prefix:

be_true
be_false
be_nil
be_blank
be_empty
be_an_instance_of(Class)
be_a_kind_of(Class)
be_close(expected, delta)

Each of the above rely on built in Ruby methods, but you can also apply this to any other predicate. What is a predicate? Predicates are methods that end with ?’s and return true or false. It could be one built into Ruby or Ruby on Rails, or it could be one of your own creation. Consider the following:

# method defined in User class
def admin?
self.role == ‘admin’
end

# example from User spec
@user.should be_admin # will pass if @user.role == ‘admin’

Also, notice the two matchers above, be_a_kind_of and be_an_instance_of. These respectively call the methods kind_of? and instance_of?. The prefixes be_a_ and be_an_ are aliases of be_, provided for better readability.

In addition to the be_ prefix, RSpec also provides the have_ prefix. Note, however, that this is not the same as the have matcher mentioned above. It’s also not a prefix in the truest since, but the best way to explain is with an example:

{:fun => 1, :times => 2 }.should have_key(:fun)

In this example have_key signals RSpec to call the predicate has_key? built into Ruby. This will work with any predicate starting with has_ as well. For example:

# defined inside a Chicken class
def has_feathers?
self.feathers > 0
end

# example inside the Chicken spec
@plucked_chicken.should_not have_feathers # passes if @plucked_chicken.feathers == 0

Is that it?

There’s a few other matchers that I have intentionally not mentioned yet: only because they are a little more abstract in nature. We’ll eventually get to all those as we continue through this series.

The next article up will detail the process of spec’ing a model. I haven’t completely decided on an example application yet, but I have a couple ideas.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati

A Fresh Coat of Paint

Well, after… umm… months… of running this blog without a template, things are starting to look up. I wanted to be ever so uber unique and design my own custom template, but frankly I never could seem to find the time. More appropriately, the time I did have, I wanted to spend on things that we simply more important, such as say posting to this silly thing.

So, I finally broke down and decided to use a ready-made template, and I was thankfully able to find one that I really liked. I hope you will too. It’s simple and usable, but still has a touch of style. I’ve customized it a little already, and I’ll likely continue to do so.

The important thing is that my blog doesn’t look so God-forsakenly ugly anymore.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati

Ruby on Rails Development in Windows via Cygwin

Such a love/hate relationship I have with Linux. It has everything but a great editor (Please no flames from the vi and emacs crowd… those are great editors if you know how to use them properly, but I’d prefer to spend my time learning Ruby and Rails rather learning how to use a text editor).

Windows, on the other hand, lacks much in the Rails development arena, but has been graced with a really great text editor: e-Text Editor, a TextMate clone for Windows. That’s just enough motivation to keep me hacking away at Windows (at least until I get a Mac… then you’re all on your own).

So on to the actual point of this article. Via Cygwin, I have been able to setup up an acceptable Rails development environment for myself in Windows, but since Cygwin can be a little tricky to setup properly, I decided to get some community service hours in by providing a tutorial.

Without further ado (cue drum-roll and general fan-fare)…

Preparation

I had various things such as Ruby and MySQL already set up on my computer before installing Cygwin. The Windows version of Ruby will have to go the way of the dinosaurs once we bring in Cygwin, but it does play well with the Windows version of MySQL. However, I’m not sure if that would still be the case if setup after Cygwin (it probably would, but why take any chances?), so our first step will be to setup MySQL.

Install MySQL for Windows

There’s a few million tutorials on how to do this, so I’m going to cover the bare minimum. If you run into any problems, go make friends with Google.

First, go download the current MySQL binary. At the time of this writing, it’s 5.0.45. You can download either the Essentials or the regular setup executable. I normally go with the regular setup since space is not an issue for me, but I’ll leave the choice to you. Run the installer, and follow the on screen prompts. The install process is pretty self-explanatory, but I’ll cover a bit of minutiae.

You can pretty much use the default settings throughout the install. I normally like to keep all my server apps (apache, mysql, etc) in a common directory for ease. If you’d like to do the same, you can change the install directory when you have the option. After the install finishes, you’ll be asked if you’d like to go ahead and configure MySQL. Yes you do, so proceed with that. Choose the development options throughout (the explanatory paragraphs will mention that this setting or that setting is better for either production or development). When you’re asked if you’d like MySQL to run as a Windows service, tell it yes. When you’re prompted to setup accounts, make sure you disable the anonymous account. You can leave the root password blank, as long as you also turn off remote access. The default Rails database config has blank root passwords, so it’ll save you from having to customize the config every time you start a new app, and it’s just easier to not have to type in a password every time you want to do something with MySQL. The rest of this tutorial will assume the password is blank, though I’ll provide little pointers here and there in case you did set a password.

Install Cygwin

With that out of the way, we can move on to Cygwin. You can grab the setup at the Cygwin website. Look for the “Install or Update Now!” link around the center of the home page. The setup file is a small download, but go ahead and get a pot of coffee ready for brewing, because the rest will be downloaded during install.

Run the setup program, and click next. You’re going to want to stick with the default here (Install from Internet), so click next again. The root directory should default to ‘C:\cygwin’. If not, it’ll make your life a little easier if you change it to that. Leave the two recommended settings checked, and click next again. Now, you’re going to be prompted for a Local Package Directory. I forget what this defaults to, but I like to set it to ‘C:\cygwin\install’ just to keep everything together. Click next again, and you’ll be prompted for your connection settings. For most purposes you should be fine with the default of “Direct Connection”. If that doesn’t work, and you’re unsure of what your settings should be, you can try “Use IE5 Settings”. If you know you’re connecting through a proxy, what are you bothering me for? Just enter your information there.

Time for a new paragraph for this rather tedious install process, but we’re getting close to the end. After clicking next, you’ll be prompted to choose a download site. I always feel a little bit like I’m in Vegas at this point in the install, because it’s basically just a gamble as to which one to pick. FTP is more efficient for file transfer than HTTP, so that weeds it down a bit. Other than that, you can either pick one at random or try to discern one that might be close to you. There’s alot of college servers there, so if you recognize a college that close to your area, go ahead and pick that one.

Okay, I devoted way more attention than was necessary to picking a mirror. Once you’ve rolled the dice, click next. The installer is now going to download a list of available packages and then it’ll present you with a very cryptic screen. Fortunately, we’re going to stick with the defaults for most of these, but we will have to make one small change. Expand the “Devel” category, and then scroll down in the list until you come to the “ruby” package. Click where it says “Skip” to set it to install. And with that, you can click next again and go have a cup of coffee.

When the install completes. You’ll be asked if you’d like to create a Desktop icon or Program Group, give one or both a check, just to simplify your life, and you’re done.

Installing RubyGems

The process from here ought to be familiar for awhile if you’ve ever done any Rails development before. However, we do have a few gotchas to take a look at.

First, download the rubygems archive, which is at version 0.9.4 at the time of this writing. Save it to your desktop to make things easy on yourself. Now, we need to open up a Cygwin command prompt, using one of our handy, dandy shortcuts (either on your desktop or in your start menu… you did remember to do that right?). In the command prompt, you’ll already be in your home directory (i.e. C:\Documents and Settings\[your name]\) which is short-handed as ‘~’ (Tip: you can run ‘cd ~’ at any point to return to your home directory). We need to get to the RubyGems archive we downloaded, so if you followed instructions that’ll mean running ‘cd Desktop’. Now, run the following command (remembering to change the version to whatever is appropriate):

$ tar -pxzf rubygems-0.9.4.tgz

After that finishes it’s work change into the directory that was created:

$ cd rubygems-0.9.4

And run the setup.rb program:

$ ruby setup.rb

Note:

At some point either by now or in the next few steps, you might come across a cryptic error resembling:

ruby: no such file to load -- ubygems (LoadError)

If or when this occurs, you can simply run the following command, and you’ll be good to proceed:

$ unset RUBYOPT

Now back to our regularly scheduled tutorial…

Install Rails

Normally, this is a easy as:

$ gem install rails --include-dependencies

But I have recently noticed, both in Linux and Cygwin that this will return a NoSuchGem error. (Confirmation?). Go ahead and try it the tried and true way first, but if that doesn’t work, continue on.

Go ahead now and download the rails gem, which is at 1.2.3 at the time of this writing. Save it to your desktop, like before. Back in your Cygwin command prompt change back to your desktop (’cd ..’), and run the following command to take care of the dependencies:

$ gem install rake activerecord actionpack actionmailer actionwebservice

You’ll be prompted at points to confirm the download of additional dependencies. Of course, you’ll want to allow those. Grab another cup of coffee, and when it finishes up, run:

$ gem install rails-1.2.3.gem

With that, we now have Rails up and running.

Getting Autotest

Autotest is a very nice feature that will run both your tests and specs automatically based on file changes. It’s actually just a part of a larger suite of testing tools, though, available through the ZenTest gem. Let’s go ahead and get that:

$ gem install zentest

Creating a Rails App

Now that we’ve got all the boring stuff out of the way, let’s get to the interesting part, setting up a Rails app and bootstrapping it for Behavior Driven Development via the RSpec framework. First, change to whatever directory you want to store your Rails apps in (I like to simply use my home directory) and then run:

$ rails myapp

(Where ‘myapp’ is whatever you want to name your app). Then change into the new app’s directory, via:

$ cd myapp

This is where all the fun will happen. But I’ve gotten a little ahead of myself. Before we continue, we need to take care of a few little things. First, we’re going to need both a test and development database for our new app. We can take care of that easily with:

$ mysqladmin -uroot create myapp_development

and

$ mysqladmin -uroot create myapp_test

Now we need to make a slight change to the database.yml config file for our app, due to some Cygwin/Windows compatibility issues. Open the database.yml file (found in the config folder of your app’s directory) in your favorite text editor or wordpad (notepad would not be a good choice due to the Unix format line-endings). Once there, replace every occurrence of ‘localhost’ with ‘127.0.0.1′ (fixes a socket problem with MySQL).

Install the RSpec and Spec:Rails Plugins

There, that’s taken care of. Let’s bootstrap our app with RSpec. (Oddly enough though, we can’t seem to do this in Cygwin. I ran into a very weird issue trying. The plugins appear as if they are installing normally, but afterwards, nothing shows up in the vendors/plugins directory of the app. Odder still, if you try to install the plugins again, it will actually error out, saying that the directories already exist. The only way I could get the plugins installed was to backdoor it through a standard Windows command prompt, but that requires keeping a separate version of Ruby on the Windows side. (Confirmation?) Unfortunately, I have not been able to find another way, so for the meantime, I will go ahead and still put the process here. However, be advised that it may not work.)

$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec

and when that finishes:

$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails

Note:

If you’re feeling adventurous, you can download the trunk versions of these plugins instead. As of this writing, this would give you access to the new Story Runner functionality of RSpec, that has not yet been released. Instead of the above commands run:

$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec

and then:

$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails

Now back to our tutorial, already in progress…

Whichever route you choose above, the next step is to generate the standard RSpec folders and files:

$ ruby script/generate rspec

Generating Some Stuff to Play With

And that’s all there is to it. But for the sake of instruction let’s generate a sample controller and model. This will let us run autotest and see how the whole process went. I’ll be pretending that this app is going to be a blog, but you can go ahead and create something more meaningful here if you want.

The model:

$ ruby script/generate rspec_model post

The controller:

$ ruby script/generate rspec_controller blog

After these two complete, open the 001_create_posts.rb migration file that was created in the apps db/migrate directory. It will initially look like this:

class CreatePosts < ActiveRecord::Migration
def self.up
create_table :posts do |t|
end
end

def self.down
drop_table :posts
end
end

Modify it to look like this:

class CreatePosts < ActiveRecord::Migration
def self.up
create_table :posts do |t|
t.column :title, :string
t.column :content, :string
t.column :created_at, :datetime
end
end

def self.down
drop_table :posts
end
end

Save and close. Then go back to your Cygwin command prompt and run:

$ rake db:migrate

followed by:

$ rake db:test:clone

With that done, we can run autotest and get a glimpse of the rest of our lives in development

$ autotest
loading autotest/rails_rspec
/usr/bin/ruby -S script/spec -O spec/spec.opts  spec/helpers/blog_helper_spec.rb
 spec/controllers/blog_controller_spec.rb spec/models/post_spec.rb
...

Finished in 0.389 seconds

3 examples, 0 failures

Those three examples are default examples generated for us by RSpec.

Finally…

Take a breather now. You’ve done alot of work, and accomplished quite alot too. I hope this helps those of you who are stuck programming in a Windows environment.

As always, if something is unclear, feel free to ask for further explanation. I do my best to try and write to the lowest common denominator, but I don’t always succeed. Thanks for reading. Now get out there and do some coding.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati

Quantity vs Quality: RSS Spam from Popular Blogs

That ought to be a controversial enough title. So just what am I talking about?

Well, I got tied up this week with some things and neglected to check in on my subscribed feeds for a few days. I finally got around to doing that today and was greeted with 1000+ new items (Thanks Google for the grace of vagueness). As I started going through the list, I started to realize that alot of it was, for lack of a more graceful term, crap.

There were lots… LOTS… of repeat stories, each trying to get first (or at least a) bite at the apple of some popular topic. Of course, there were usual smattering of Facebook/iPhone themed posts (pause to puke). What was left, I found either boring or otherwise uninteresting. In the end, I think I went through about 200 or so, reading a whole five of those, and eventually just marked everything as read.

Now, complaining aside, I subscribed to all these blogs/news sources. I have in fact, weeded quite a few out that I had initially subscribed to, so the feeds I’m currently subscribed to are blogs that I like or sites that give me interesting information, mostly at least.

Nevertheless, I wonder sometimes if the vast quanity of posts coming from some of these sites, especially when very few ever truly get read on my side, doesn’t constitute a form of spam. Many times, I do end up feeling as I oft did back in the stone ages of email when spam was prevalent but spam filtering no so much.

For kicks and giggles I decided to utilize one of Google Reader’s interesting little features, Trends. Trends give you an at a glance look at not only your own reading habits but also your most frequently updated subscriptions and the percentage of posts from those feeds that you actually read. There’s a definite trend in mine, and I’d be willing to bet that it’s hold true for others.

First let’s take a look at some of the most frequently updated feeds I subscribe to:

Subscription Items/Day % Read
Engadget 39.9 0%
Mashable! 24.5 1%
Slashdot 18.2 0%
Lifehacker 16.5 1%
Wired Top Stories 10.0 0%
TechCrunch 9.2 0%
Read/WriteWeb 4.8 2%

It should be noted that most of the 0%’s are not actually zero posts read. Rather, the sheer volume of incoming posts versus what I read rounds to 0%.

Now, let’s look at some of my less frequently updated feeds:

Subscription Items/Day % Read
Copyblogger 0.7 5%
Ruby Inside 0.7 5%
Smashing Magazine 0.6 11%
Web 2.0 with Ruby on Rails 0.2 33%
Nuby on Rails 0.1 25%
Dan Manges 0.1 33%
Rails Envy 0.1 67%

The percentage really goes up there. Granted, these feeds are updated less frequently, so I like read as much if not more from the more frequently updated feeds. However, the point is in the percentages. Which site is better in the long run: one that posts hundreds of items but only five get read, or one that posts ten and five get read. In my opinion, the choice is simple: the latter.

I think somewhere in the race to be number one on Technorati or to get some Google love, many bloggers have lost sight of the point of blogging in the first place: providing information to the community at large. The time spent on writing a hundred mediocre posts could be spent in coming up with a handful of really great posts, and everyone wins with that.

But I’m just the new kid on the block, so maybe I’m wrong. But it’s my hope that what I lack in frequency at my blog here, I’ll make up for in quality. That’s my goal anyways.

  • Del.icio.us
  • Digg
  • Facebook
  • Google Bookmark
  • StumbleUpon
  • Technorati