Weblog Development
A couple of minor bug fixes:
- If you clicked on the word “tags:” at the bottom of each post you were taken to a page listing all of the tags used in this weblog. If you clicked on any of the tags, you were then taken to a page for editing the tags! So now, when you click on a tag from the list of all tags, you will be taken to a page listing all of the entries that have that tag. Still no “tag cloud” but getting closer!
- The “updated” problem! When I was making new posts, they were all being listed as “updated”, until I went in to the database and physically changed the “updated_on” date to equal the “created_on” date. This was an error in my original logic, I was under the impression that “updated_on” would stay null until the post was actually updated. It turns out that “updated_on” is set whenever a change is made to the database, even when a new post is created. The fix for this problem was the addition of a column (field) in the posts table that would allow me to flag a post as being updated or not. This is actually more functional than my original approach. Before, if I were to make a minor edit to a post, the post would have considered itself to have been updated. While this wasn’t wholly inaccurate, it was misleading in that most people assume that an updated post has a moe substantive update than the correction of a grammatical error or a simple HTML tweak that doesn’t add anything new to the post. Now, when I edit a post I have to implicity set the “updated” column to display to the user that the post has been updated.
In case anyone is wondering, the second of the two fixes was accomplished easily using Ruby On Rails migration feature. The steps are outlined below
- At the command line, enter: (I probably should have called it something like AddUpdatedColumnToPosts!)
ruby script/generate migration AddUpdatedFieldToPosts
- Edit the new migration as follows: (Note that MySQL does not support Boolean columns, but Ruby On Rails know this and handles it for you!)
class AddUpdatedFieldToPosts < ActiveRecord::Migration def self.up add_column :posts, :updated, :boolean, :default => false end def self.down remove_column :posts, :updated end end - At the command line enter:
rake migrate
- Make the neccesary changes in the post controller, in my case I had to change to the logic that determined if the post had been edited or not.:
<% if updated_on > created_on %>
to:
<% if params[:updated] == true %>
- Once everything is good on the development side, commit the changes to the Subversion repository:
svn add * --forcesvn commit -m "fix updated_on problem"
- Now it is time to migrate the “Production” database! Log in to the server via the Secure Shell client of your choosing, navigate to your application’s directory and enter:
rake migrate RAILS_ENV=production -t
- If this all goes off without a hitch (it won’t, trust me!), then your final step is to “deploy” your updated application code:
rake deploy
The beauty of all of this is that I am doing completely disconnected development on my computer at home, once everything works the way I want it to I simply upload my changes to the server, make the neccesary database changes and deploy. If it fails at any point, I can very easily revert to the previous state! I love Ruby On Rails!
This post has been updated to show what an updated post looks like.
