Canonical URLs are all the rage on the Internet nowadays. All one has to do is do a Twitter search for canonical to see the conversations going on.

The problem is this, micro-blogging services such as Twitter only allow a certain number of characters, so a URL like this http://eddorre.com/posts/buildin-the-blog-part-5-refactoring-part-2, is too long. This is where URL shorteners like tinyurl.com come in.

They take a long, but perfectly fine URL, and make it something like this: http://tinyurl.com/Hukjfd (this is an example – not a real link). This is much more useful on Twitter where character space is at a premium. However this has its own problems, one is trust. How can you trust tinyurl.com to actually be delivering you to a URL that you would even want to visit? Short answer, you don’t. Also, what happens if tinyurl.com goes away one day? Any search on Twitter that uses these links immediately becomes less valuable. It’s the opinion of some on the Internet, that a site should take care of its own short urls.

For example, the link http://eddorre.com/posts/buildin-the-blog-part-5-refactoring-part-2, could become http://eddorre.com/s/SQ2BAs. Notice that the domain remains the same and short url is under my control. If the link goes away it’s MY fault not someone else’s. I have a vested interest in making sure that the link doesn’t go away. It doesn’t solve the trust issue, but at least you know that it’s a link coming from eddorre.com instead of anywhere on the Internet.

Enter the debate about canonical URLs and rev=canonical. The theory behind rev=canonical is simple. When I include a link like this: http://eddorre.com/posts/buildin-the-blog-part-5-refactoring-part-2 in Twitter or a similar website, they will then load up the original link and look inside the HTML for markup that looks like this:

<link rev="canonical" href="http://eddorre.com/s/SQ2BAs" />

When Twitter or a similar service finds this tag, they should then replace the long link with the short one. It makes sense but this does have one drawback that will most likely kill its adoption. It’s expensive. Twitter, for every link that is posted, has to connect to the URL, parse the HTML and then return a new link if it supports canonical URLs.

With that in mind, there is a proposed new HTTP header for canonical URLs that a web server could return to a service like Twitter. Something like “X-Rev-Canonical: href=”http://eddorre.com/s/SQ2BAs". This way, Twitter or other services just have to do a GET request to the original URL and it would just return them the short URL. No downloading and parsing the HTML. Whether either of these methods becomes widely adopted remains to be seen.

This past Saturday, after reading comments in Twitter and blogs about short urls, I decided to try coding up my own system for my blog. Turns out it only took me about 15 minutes to code something in Ruby/Rails.

Here is how I did it.

• I created a migration to my posts table to include a short_url column
• Created a before_create callback method in my post model to create a short_url.
• The creation of the short_url is done by randomly mixing 6 characters from the characters available in Base 62 encoding (meaning: 0-9, A-Z and a-z).
• To create short_urls for all of my older blog posts, I just created a migration that looped through all of the blog posts and generated this random token string for all of those and saved them.

I create a named route similar to the following:

map.short_url "/s/:short_url", :controller => 'posts', :action => 'show'                                   

Next, in my controller I did something similar to this:

    if params[:short_url]
      @post = Post.find_by_short_url(params[:short_url])
      redirect_to post_path(@post), :status => :moved_permanently and return
    else
      @post = Post.find_by_permalink(params[:id])
    end

There you have it. Something quick and dirty in about 15 minutes. Now if I want to post links to my blog on Twitter, I can use my own short url instead of using a service like tinyurl.

I should note that this probably isn’t the best way of doing things and it’s most certainly not the only way, but for a quick hack project on a Saturday afternoon, it fit the bill.

I forgot to mention that the inspiration for this post was Duncan Davidson’s post Everybody Wants Short Links.

In my last Buildin’ the Blog article, I wrote about how I cleaned up my comments controller by moving all of the processing to the model. In this follow-up article, I’m going to write about how to access properties that aren’t part of your model object (aka table).

Take for example, a simple comments database table. It might look like this:

id

full_name

email_address

url

body

As you can see this is pretty straightforward, a single comment is comprised of a full_name, email_address, and the body. These attributes can easily be checked and processed in our comment model. Here comes the tricky part.

Take for instance my comment form below:

Name, email address, URL, and the body of the comment can all be mapped to database table fields. Unfortunately, Remember Me and Subscribe Via Email cannot and should not.

A beginner in Rails might write something like the following in their controller code:

if params[:subscribe]
#create a subscription record here
end

This code works but it leaves a lot of logic in the controller. The controller should be fairly lightweight, “I accept input from the user pass it to the model and then I pass it back to the browser/user.”

In order to get non-database bound fields to the model we use Ruby’s attr_accessor declaration (we could use attr_writer too to only write attributes and not read them).

For example:

class Comment < ActiveRecord::Base
  attr_accessor :subscribe
end

This allows me to create a form like the following:

  <% form_for @comment do |f| %>
  <%= f.text_field :full_name %>
  ...snip...
 <%= f.check_box :subscribe %>
 <%= f.submit %>

Once this is done, I can check what the value of the checkbox was set to in the model in a callback (let’s say either a before_save or an after_save):

  def before_save
    if self.subscribe == 1
      #create a subscription record here
    end
  end

It’s that simple. Now all of my logic can be done in the model.

With that out of the way, here is something to watch out for. Let’s say that you have a comments table that looks like this:

id

full_name

email_address

url

body

is_admin

Obviously, the is_admin attribute should be set by the application and not by the user but unless you protect your model, the user can set any attribute he wants. Let’s say that you have a simple comments form with full_name, email_address, url, and body. The is_admin attribute is not displayed as a form field.

A malicious user could come by and change the form by adding the following or by submitting to the comment form using cURL. Here is an example:

  <input type="checkbox" name="comment[is_admin] checked="checked" />

By crafting this form and sending it, the user automatically becomes an admin!

One way to protect your application from this type of malicious activity is by protecting fields that should never be set by the user behind the attr_protected declaration. For example:

class Comment < ActiveRecord::Base
  attr_protected :is_admin
end

This will stop malicious users from trying to set attributes that should never be set by the user.

It’s been a long time since I posted something in this series, almost 3 years to be exact, and it’s about due.

One of the things that developers do when they are new to the MVC paradigm/Rails is to litter their controllers with all sorts of business rules code. This isn’t a fault really. For beginners it’s a way to get your app and running quickly.

As a developer matures with the MVC paradigm, they begin to see that there is a better way to do things (think Fat Model/Skinny Controller). That certainly was the case with me.

For instance, the create action of my blog’s comment controller (the heaviest action by far) weighed in at a hefty 61 lines of code. After doing a bit of refactoring, my controller has dropped to 25 lines of code. Still not perfect, but all of the comment processing code has been moved into the model.

Let’s take a look at how and why I made the changes.

First thing is first. Since I’m using the Akismet web service to check for comment spam, I need to track the referrer, the IP address of the client, and the User Agent.

I used to have a line of code in the create action that got this information by calling a method in the Application Controller.

options = get_browser_info

That method was defined as:

def get_browser_info
  options = { :ip_address => request.env["REMOTE_ADDR"], 
                :user_agent => request.env["HTTP_USER_AGENT"], :referer => request.env["HTTP_REFERER"] }
end

This worked, but it lacked a little sophistication.

The new method in the Application Controller:

def fetch_browser_info
 @browser_info = { :ip_address => request.env["REMOTE_ADDR"], 
  :user_agent => request.env["HTTP_USER_AGENT"], :referer => request.env["HTTP_REFERER"] }
end

Now in the Comments controller, I can run a before filter on the actions that need this:

before_filter :fetch_browser_info, :only => :create

Unfortunately, the old Akismet plugin that I was using, ror_akismet, enforced the use of extra methods in the controller. I changed this up, by copying the akismet.rb file to my lib directory and removing its dependence on the controller. And yes, I know that ror_akismet is the old library file and rakismet is the replacement. At the time, I didn’t want to install and futz with the new plugin.

That allowed me to pull this entire code block:

if is_spam?(:comment_content => @comment.body, :comment_author => @comment.name, 
                :comment_author_email => @comment.email, :user_ip => @comment.ip_address, 
                :referrer => @comment.referer, :user_agent => @comment.user_agent)

That now goes into the model. With a code block that looks like this:

if is_spam?( { :comment_content => self.body, :comment_author => self.name, :comment_author_email => self.email, :user_ip => self.ip_address, :referrer => self.referer, :user_agent => self.user_agent }.merge(self.akismet_attributes))

That’s it for this edition of Buildin’ the Blog, but I’m not done rebuilding my Comments create action. In the next part of the series, I’ll cover how to access variables that aren’t part of your Model’s attributes (table columns) and a quick note about security.

Having the ability to allow users to subscribe to a post (and therefore getting email updates when someone adds a follow-up comment) is something that I’ve been wanting to implement ever since I rolled out the first version with Ruby on Rails.

I think I first started the initial implementation of a subscription engine a few months back but it was extremely buggy and I was not satisfied with the underlying code. A couple of weeks ago, I dove in again and hacked a working version.

The implementation worked, but I was unhappy with the underlying code as it was based on code that I had written years ago. Now that my skill set has improved, I decided to rip out most of what was there and code up a cleaner version of the workable code.

After some rigorous testing, I’m finally happy with the implementation and the underlying code.

So how does it all work? Well, it’s simple really. If you want to be notified (by email) of follow-up comments to a post, click the Subscribe via email checkbox and post your comment. You’ll receive an email confirmation that let’s you know which post you’ve subscribed to. If someone posts a follow-up comment, you’ll get an email notification.

If you don’t want to be notified anymore, there is an opt-out/unsubscribe link on the emails that are sent out. Follow that link and the subscription to that specific post is terminated.

I think the last new feature was Gravatar support way back in September of 2008. Now I’ve finally gotten enough free time to release a couple of new features. The first is linkable tags on post pages. I’ve had the ability to add tag for a while when creating a new post and they can be seen on the homepage and on post specific pages but they haven’t been linkable until now. Click on a tag and see what other posts have been marked with that tag.

Eventually I’ll add some sort of tag cloud so that one can see the most popular tags but that’s an update for another day.

One of the things that I’ve had in mind when I started coding this blog in Rails was to eventually support Gravatars otherwise known as Globally Recognized Avatars.

Before rolling out this feature, comments had a little astronaut next to the speech bubble for each and every individual comment. If you have registered your email and uploaded a photo with the Gravatar service, it will no longer display the astronaut icon and it will load the registered image. If you haven’t registered, your comment gets a default kanji image.

Making this change in Rails was actually pretty trivial especially since Michael Mayo posted a very nice tutorial not long ago on his blog.

I did make some modifications from the code that he posted.

One of the more prominent changes that I made was to split out the image creation from the just generating the URL.

For example, I have this first method in my application_helper.rb file:

def gravatar_url_for(email, options = {})
      url_for({ :gravatar_id => Digest.MD5.hexdigest(email.downcase), :host => 'www.gravatar.com',
                   :protocol => 'http://', :only_path => false, :controller => 'avatar.php',
                   :default => 'http://eddorre.com/images/visitor.png',
                   :rating => 'G'}.merge(options))
end

I convert the email address to lowercase letters with the downcase method because an MD5 of noemail@eddorre.com and NOEMAIL@eddorre.com are actually two different things. This way, there can be no error. One of the other settings that I’m passing in is a “default” flag. If you haven’t registered with the Gravatar service, I’ll just use the astronaut image that I have and finally I don’t want goatse photos or worse showing up on my blog so I make the rating a mandatory “G”.

Notice that the above method doesn’t actually generate an image tag, it will only generate a URL.

For that, I have a second helper method defined simply as:

def gravatar_image(email, options = {})
      image_tag(gravatar_url_for(email, options), :alt => "Author Image")
end

This is the code that actually creates the Gravatar image.

Now in my view code, I can do the following (where @comment.email represents a variable with the user’s email address):

<%= gravatar_image(@comment.email, { :size => 40 }) %>

And it will display the image correctly. I should note that Michael’s example lists a size in height and width and you’ll notice that I’m passing the size as just an integer. I believe that the height and width options have been deprecated in favor of the more succinct size option.

I’ve recently become a Twitter user and I’m starting to use the service on a more regular basis. Considering how much I’m using the service now, I wanted to integrate some of the messages posted there onto my blog.

The folks at Twitter have 3 badges for use with custom made blogging engines. The first two are Flash based and I ruled those out quickly. The third was based on HTML and Javascript. This option gives me the most flexibility as far as configuration was concerned so I chose to go that route.

The process of getting the Twitter badge/updates to render on my site is fairly simple. Include some HTML and the following Javascript files:

<script type="text/javascript" src="http://twitter.com/javascripts/blogger.js"></script>
<script type="text/javascript" 
src="http://twitter.com/statuses/user_timeline/eddorre.json?callback=twitterCallback2&amp;count=5">
</script>

Usually Javascript files are loaded from the HEAD section of an HTML file, but the Twitter page specifically suggests to move the Javascript lines to the bottom of the page. The rationale behind this is simple; if Twitter is down and the their Javascript files are in the HEAD section then your page won’t load! In theory, by moving the Javascript lines to the bottom of the page they will be activated last after your page has already loaded.

Unfortunately, different browsers render Javascript and the DOM differently and there is no guarantee that a failure of the Twitter service will result in your page loading. The solution is to wait until the DOM is fully loaded before including or calling those Javascript files.

With any modern Javascript library such as Prototype (it’s what I use), jQuery, YUI, etc., it’s simple to interrogate the DOM to find out if it’s been loaded or not. The solution that I wanted was to display a “loading” graphic while the Twitter updates were loading and once they were finished, then the “loading” graphic would disappear; a standard ajax-y interface.

My solution was to render the “loading” graphic, wait until the DOM was loaded and then append the Javascript to the end of the BODY element.

Here is my implementation:

//Wait for DOM to fully load
Event.observe(window, 'load', function () {
	loadTwitterJSFiles("http://twitter.com/javascripts/blogger.js");
        	loadTwitterJSFiles("http://twitter.com/statuses/user_timeline/eddorre.json?callback=twitterCallback2&count=5");

//Hide twitter_spinner div
$('twitter_spinner').hide();
});

function loadTwitterJSFiles(url) {
      var urlRef = document.createElement('script');
      urlRef.type = "text/javascript";
      urlRef.src = url;

      if (typeof urlRef != "undefined")
          document.body.appendChild(urlRef);
};

There were a couple of adjustments that I had to make in order for it to work right. First off, notice the second Javascript line that Twitter gives you. In it, it refers to & where my code just has the & symbol. I had to make this change because I noticed when using the appendChild method it would insert a double & and therefore breaking the URL.

The second thing that I had to modify was the original DOM checking mechanism. In the Prototype documentation it says that you can observe the DOM loading by the following:

document.observe("dom:loaded", function () {
Your code here
});

This never worked out for me as it would never display the “loading” graphic even while getting the updates from Twitter was slow. I’m not sure if it hid it immediately or not, but I changed it to the code above that waits for the “window” to load and it’s worked out for me.

So that’s it. This works in IE7, Safari 3, and Firefox 3.

Over the past few days, I fell in love with updating my blog engine again. I go through these cycles where after an update, I won’t touch it for a while. Then something comes along that I need to fix and I’ll update a whole bunch of stuff all at once.

This time I went in and added some new features, updates old pages, and fixed some bugs. One of the pages that had been published, but was not publicly accessible, is the changelog. A changelog is a simple log of changes that have occurred during a project that includes new features and bug fixes. This is the first time that it’s been publicly linked. I’ll keep updating this as I add features and continue doing bug fixes.

You can access the changelog from the updated About page which contains updated information about the blog URL name (eddorre) as well as information about the tools that I use. Someday there will be information about me but I haven’t figured out if I’m going to write (hard to write about yourself) or have someone that I know do it.

As my changelog mentions, I’ve added Twitter updates. This just simply lists out the last 5 updates that I’ve made in Twitter via a JSON call. If you’re curious there are full updates available.

I’ve also fixed a nasty bug (that I thought that I had fixed before) where the order of the comments were listed in the wrong order (latest comment first in the list instead of last).

All of those changes are visible to everyone but there are changes that aren’t available for everyone to see. The mostly involve the back end publishing part of the site. Those updates include shoring my Models by using Rails’ new named_scope options as well as including several helper methods here and there.

I’m proud of what I’ve accomplished considering that I work on this in my spare time.

I’ve come up for air after doing the upgrade. Remind me not to drastically change my database schema next time.

There are a few bugs that I see here and there will be addressed at a later date. For now, I’m going to bed.

I’m re-doing my blog engine. I’m focusing on refactoring old crufty code as well as expanding my knowledge of Ruby on Rails.

So far everything is on track and I should be done with it soon. One of the things that I wanted to focus on was the use of modules and plugins. Last time, I was using my own code for accessing the Akismet web service. This time around, I downloaded the ror-akismet plugin and I’m extending my comments class using the built in downloaded methods.

However there seemed to be a bug in the works. Every time that I included the declaration “include Akismet” into my comments controller, all of the other methods would break.

I started tearing out bits of my code and then the modules’ code and no matter what I did, everything would go to hell when I added the include declaration.

It turns out that Rails (1.2.3) seemed to be freaking out because the plugin directory that was downloaded was called ror-akismet.

Once I changed it to ror_akismet, everything worked fine.

I’m really close to deploying my new blog on Ruby on Rails. While I’ll be working to do some mod_redirect work, you’re better off at pointing your feed reader to http://eddorre.com/rss.

I expect that the change will be live on Wednesday (October 4th).

Read part 1, part 2, and part 3.

Building a user interface is hard. This is especially true for programmers that do not have a lot of experience or background in design, usability, human-computer interaction. Linux is a perfect example of this; solid in function, poor design in the user interface.

On the web, design and usability critically important. A recent article suggests that web users judge the quality of a web page within seconds of viewing it.

Some teams might comprise of programmers and designers, but some teams are small enough that the programmer is the designer. If this is the case then you’ll want to employ some techniques that designers use. One of those is sketching.

One of the hardest things to start with is a blank piece of paper. The blank piece of paper can lead to procrastination and even worse, it can cause people to just give up entirely.

This is where sketching comes into play. Sketches are rough drafts. They don’t have to be (and shouldn’t be) perfect. Just get some stuff on paper and work from there. Whip out a couple of sketches and start defining the details from your favorite ones.

I’ve whipped up some small, quick and rough sketches on what my new blog might look like. Since these are just sketches, it’s easy to throw away ones that I don’t like or to erase and start over.

• Sketch 1
• Sketch 2
• Sketch 3
• Sketch 4

I would suggest getting a sketch pad and sketching out any ideas that come to mind even if it doesn’t have anything to do with a project that you are currently working on. Inspiration can come at any time.

Here is a perfect example of a sketch book from Jason Santa Maria’s site.

The guys at 37Signals have a great article on sketching screen and how it can evolve into the final design.

Read part 1 and part 2.

This probably should have been part 1, but oh well.

I should make a disclaimer. Although I know some about requirements, I’m no PMP (Project Management Professional) nor do I play one on TV (although I do know a real one – hopefully I won’t do her a disservice with this). This article isn’t meant to be the be-all, end-all of the requirements gathering process. The process is quite detailed and whole books can and have been written on the subject. More information on requirements can be found at the bottom of this article.

In general, requirements define the what the software project does and doesn’t do. All software projects should have some form of requirements to define what it is that you are building.

In a situation where you have been contracted by someone else to build them software, the user or group of users should be involved in the requirements process. They probably have an idea of what they want built for them and using this idea(s), you’ll help them define the requirements of their project (although it’s really not as easy as that since sometimes they don’t even know what they want).

In my case, the requirements gathering process was simple. With the exception of the public interface (reading posts and making comments), I’m going to be the only user.

If I’m the only user, why couldn’t I just start designing and coding? Well, if I had starting working right away, I would have been making myself susceptible to “feature creep.” Feature creep can be defined as features which tend to be requested for inclusion into a project when it’s already in motion. This can stall and delay the project or worse, it cause the project to fail outright. In a case where someone has contracted you, this can cost them real money.

Even a single developer working on a project can fall prey to feature creep and it can actually deter you from finishing the project.

Requirements can be complicated or they can be simple. Complicated requirements can contain interviews, use cases, prototypes and more. The 37Signals guys write a one page story about what the application can do. I chose to just list, in a summary form what the application can do. Using these simple requirements, I can easily build onto them by defining Use Cases for each action.

By defining a loose set of requirements, I was able to see what I
wanted to do and what I could release in the first iteration and what
could wait for further iterations. I solidified my vision for my application and reduced my susceptibility to feature creep.

Further reading:

• Requirements Gathering Essentials
• Gathering Requirements: The Crux of the Matter
  
• Recommended Requirements Gathering Process
• Software Requirements, Second Edition
  
• Mastering the Requirements Process
• Writing Effective Use Cases
• Managing Software Requirements: A Use Case Approach, Second Edition
• Software Requirements: Styles and Techniques
• The Requirements Engineering Handbook
• Project Management Institute
  

Part 1 of this series is here.

I originally was going to have this part come later in this series, but I wanted to install Ruby on Rails a bit before I started writing my blog application so that I could become more familiar with the programming language and the web framework. Add to that, the fact that I installed it last night makes it fresh in my head.

I picked Kubuntu to be my development platform for a few reasons. I’d really like to use a Mac along with TextMate, but I don’t have the capital for a new Mac. Oh sweet, MacBook, I will have you one day…

But I digress, it’s probably best to use Kubuntu at first anyway. One of the reasons why I chose this distribution of Linux is because, well, I wanted to learn Linux. I chose this specific distribution because I plan on using Debian as my production platform and since Kubuntu is based on Debian it seemed to make sense. I should note that I don’t use Ubuntu because it comes with the terrible GUI, GNOME (although I’m perfectly aware that I can switch to KDE using Ubuntu, I just wanted it all in one package).

Anyway, it’s time to get to the good stuff.

With modern Linux distributions, you can install software using a package manager and Kubuntu (and Debian) is no different. I could have easily downloaded Ruby with the apt program and then installed Rails on top of it but the latest version avaliable to the apt program is Ruby 1.8.3 while the latest version of Ruby is 1.8.4. I should note that Ruby 1.8.3 is not recommended for use with Rails.

So I had two choices, install an old (and incompatible) version with apt or install from source.

I decided on installing from source. First thing is first, I gotta install Firefox in order to browse the web (I don’t really like Konqueror – the web browser that comes with KDE) and download the source.

I run this command to get Firefox:

This installs Firefox 1.0.7 and displays a warning message when loading, but that’s fine for now – it’s not critical. It’s time to get Ruby and then Rails. The Ruby on Rails site has very simplistic instructions on how to install both Ruby and Rails. They are deceptively simple and as I’ve found with all things Linux, it’s actually much harder than adverstised.

I created a directory in /home/carlos called work where I could download packages and compile the programs. I download both Ruby 1.8.4 and Ruby gems into these folders.

You have to install Ruby first, so I run this command in the directory where I’ve download Ruby:


This creates a directory called ruby-1.8.4. Moving into that directory, I attempt to run this command:


And it gives and error stating that “no acceptable C compile was found in $PATH.”

I guess I have to install a C compiler so I run this command:


It does its thing and I try the ./configure command again. This time it’s another error. C compiler cannot create executables. Hrrm, it’s turning out that it’s not as easy as “download and go” after all.

After doing some Google searches, I found out that I need to install some development packages first, so I run the following commands (the second command is used for later when attempting to get RubyGems working):



BAM. That got it working. It does it’s thing and makes a make file. I go to make the…uh…make file and when typing in the command “make”, I get the error: bash: make: command not found. Unbelievable. I then run the following commands (which run without error):


I’m not sure why a base install of Kubuntu doesn’t have gcc, make, libc6-dev, and zlib1g-dev but I’ll leave that to smarter people to figure out.

I first have to unpack Ruby Gems. The command (to be run where I downloaded Ruby Gems) is


That creates a rubygems-0.8.11 directory. The following commands are to be run in that directory:


Note if you get an error here that reads: The error is no such file to load - zlib (LoadError), it means that you have to install zlib1g-dev first. Unfortunately you also have to go back and run the .configure, make, make install commands in the Ruby directory again.

In theory, Ruby and Rails should now be installed. Let’s test it out by running the commands:


You should see WEBrick 1.3.1 startup and at this time, I’m satisfied that Ruby on Rails has successfully been installed.

All in all, it was way more complicated than it needed to be and if I wasn’t so determined to get it working I would have quit and just double-clicked the installer for Visual Studio.NET 2005.

I’ve been working on updating this site to what I call “version 3” for a while. “Version 3” has been set to include a whole new look and design as well as some programming additions to make it…well, better.

At first I was committed to using ASP.NET as my programming platform of choice (this site currently runs under ASP.NET 1.1), but somewhere along the line, I lost enthusiasm for using it.

Along the way, I’ve discovered Ruby on Rails and I’ve become determined to use it for the new site. Unfortunately, using Ruby on Rails on the preferred platform (Linux or Mac OS X) makes the learning curve quite steep.

As I thought more and more about what I’ve learned and what I’ve still yet to learn, I decided to make a set of articles that went from the first step of building a blog to the final steps of deployment and rolling it out live.

It’s helpful for me to document my progress and it might be helpful for other people out there as well.

Some people might say that I’m re-inventing the wheel considering the amount of great blogging packages out there (Typo, Das Blog, .Text, Wordpress, Movable Type, etc). I don’t see it like that at all. Since my goal is to learn Ruby on Rails on an Open Source platform, I see as “figuring out how the wheel works; by itself and in conjunction with other systems.”

The technologies that I’m going to be using will help me build my skills by learning basic skills in Ruby on Rails like CRUD (Create, Retrieve, Update and Delete), as well as more advanced skills like XML-RPC and AJAX.

Hopefully, whoever reads these can pull something useful out of them.

Next up: Buildin’ the Blog: Part 1 – Design Web Standards and Design Inspiration.

I’ve been neglecting the RSS feeds on my site. Apparently when I coded the URL rewriting stuff, I broke the comments RSS system and therefore comments were unreadable using an aggregator such as SharpReader. I’ve now fixed that so that comments get properly enumerated again.

There were also errors that stopped my main feed from validating. I’ve fixed those and now it validates (with warnings).

To top off all the RSS coding that I’ve been doing today, I’ve created a new RSS feed for those readers that never actually visit the web site using a browser.

If you visit the site using a web browser, you’ll notice “media” sections on the right side of the page. Those sections are labeled “read”, “listen”, “watch”, and “play.” In those sections, I have links to what I’m currently reading, listening to, watching, and playing.

Until now, the “media” content was only accessible by viewing the site through a web browser. I’ve not made those into a separate RSS feed so that you can subscribe to it in your favorite aggregator. The URL for the feed is http://eddorre.com/mediarss.aspx

.

I’ve been busy the last few days making some [more] modifications to the site.

The first is a URL Rewriting engine so that instead of getting
unfriendly URLs like this one eddorre.com/comments.aspx?post_id=5,
you’ll see this: eddorre.com/posts/5.aspx. Makes it easier for
people to read and supposedly makes it easier for search engines to
spider. Some of the site still uses the unfriendly URLs but I’ll
transition that over soon. Although I would like to take credit for
writing the engine myself, I can’t. I used Scott Mitchell‘s engine that he posted on MSDN.

The second is a simple thing really. It’s a “remember me” checkbox on
the comments page. If you have the box checked (checked is the default
value on page load) and post a comment, I’ll save your name and url to a cookie. Next time you visit the comments page, I’ll
load those values in again so you don’t have to type them in all over
again. I don’t store anything else besides these values. If you don’t want cookies written to your machine, uncheck the
box before posting the comment.

I should note that while I do write and read cookies in this manner, I
don’t store any user information for personal use or distribution. The
only information that I log is what the web server normally logs.

Thanks to my friend Rod for pointing this out. Apparently, my RSS feed
was incorrectly displaying the wrong time format for posts and comments.

The
RSS specifications require that this time format be in GMT/UTC.
Although it was saying that it was in GMT/UTC format, it really wasn’t.

I’ve fixed that bug so it should appear correctly now.

The monkeys and I
have been busy. They must have had a lot of the Jack because they’ve
had me working overtime. I’ve added a bunch of new features, some on
the front end, some on the back end. In addition to that, I’ve done a lot of, and I hate to
use this trendy buzz word…refactoring.

Some of the new things include:

• A blogroll (if you scroll down on any page, you’ll see it)


• No more static mailto: tags on the front page, now it links to an email form


• I finally got my edit comments thing working on the back end just
  in case someone (namely myself) messes up and wants it corrected


• A lot of…sigh…refactoring to make things cleaner

I’ve got to get my friend Ken to make a caricature of the monkeys and I while we are hard at work.

Well, I’ve implemented a new search feature. You’ll see it on the right
side where the XML logo used to be (that’s down below under Syndication
now). I pushed the files and the database changes up from my dev site
but now that I see it working on the live site, I don’t quite like the
implementation. I was gonna take it down, but it works well enough, so
I’m going to leave it and just fix the bugs.

This is officially my 200th post. I also uploaded code today that gets rid of the static XML that was generated by a C# console application at midnight and have replaced it with aspx pages that render the XML dynamically (using XmlTextWriter in C#). Not only that, but I added in support for wfw:comments and wfw:commentRSS which allows RSS aggregators like SharpReader to enumerate comments without having to go to the site to read them. For those of you that are reading this through an RSS reader, re-point your feed location to http://eddorre.com/rss.aspx.

I also have to give props to this code snippit on CodeProject. Without it, starting the new XML generation process would have taken me a lot longer. I’ve heard CodeProject has bad and terrible code samples, but this one was right up my alley; it really put me on the right track.

Not bad for a non-programmer trying to learn C# and ASP.NET.

When I sat down to write the comments for version 2.0 I knew that I wanted the following:

• Stop people from posting HTML willy-nilly into the comments (this stops blog-spam and cross site scripting attacks)
• Automatically convert line feeds to break tags
• Allow people to include links to web sites, SSL sites and ftp sites without having them type in and HTML

I got #1 and #2 easy enough but it was the inclusion of #3 that gave me a really hard time. I had a vague idea of what I wanted to do, but I didn’t know how to go about doing it. I scoured Google for what seemed like an eternity and I was coming up with nothing helpful. Then I found Simon Willison’s blog. His example (in PHP) gave me the nudge that I was needing to complete the code. I did do a little modification as mine uses Regular Expressions to search out the strings, but I have to say without seeing his code it would have taken a lot longer to complete my code. Props to Simon.

I finally decided to update the site to version 2.0. A lot of changes occured on the backend of the site but there are obvious changes even on the main pages. Of course your RSS reader will see nothing new. :) I’ll have some photos up soon of what the backend used to look like that what it looks like now.

Last but not least, I re-did the comments section from the ground up. Hope that there are no bugs in it (I did all the testing that I could).

There are some other features that I want to add but I will wait until version 2.5 to make those changes.

I’ve been working on what I call Version 2 of this site for a little while and I’m really getting excited to deploy the changes that I have made. In fact there are so many changes, that I can’t keep track of them. Some of them are minor tweaks some of them are major rebuilds. I’m targeting a month before the new version will be out but hopefully it will be sooner than that. There are still several things that I need work on including a full rebuild of the comments section (I remember throwing that up without much though put into it – as long as it got the job done it worked for me).

Just finished making some changes here. I limited the front page to 15 posts and added a monthly archive on the right side. I also updated the code on the RSSGenerator and now my RSS XML feed is compliant (therefore the cool little button)! After a mad night of hacking, it’s time for bed.

I went to validate my RSS feed today at this site and it didn’t validate! Arrrghgghh! Luckily, I found the problem quite easily. It’s off by one tag.

I’m in the design phase for version 2.0 of this site. Currently, it’s at version 1.0. Behind the scenes there will be a lot of work done on the admin interfaces (something that you have to login for) and some tweaks to the front page, including limiting the number of posts that show up and side navigation for archvies. I’ll also start on putting some of my source code on (projectsourcecode.com — there is nothing there right now) including my RSS Generator and images from the admin portion of this site.

It might take a while but, I’ll get there.

I added a new feature to the site. Just in case someone wants to link directly to a post and not just the main site, I added an archive feature. Right after comments, you will see a link that says “Archive”. Just copy that URL and you can use it where ever you want. I am going to add a calendar view system so that you can see when I posted but that’s later.