Antares Trader Blog

Tomorrow's project is redeploying these blogs. I always get nervous when I do a big deployment. I'm not a sysadmin, and I do not have a lot of practice at it. Switching from WordPress over to this blog went pretty smoothly thanks to a good deal of forethought and planning. I'm hoping that the same thing will hold true this time.

After a long day of coding yesterday, I've gotten to the point where I think I can add a few new feature to the blog. Here is my list:

Stats

What kind of a person gives themselves the e-mail user name emperor (-at-) antarestrater.org? One with a surprisingly large ego that's who. I love to know how many people are reading my blog, what they are reading, when and how. Which post gets the most hits. That kind of thing. I'm getting really tired of greping through my access log for this kind of thing

This is going to require a bit of work to store the data and some way to track cached pages. Webbugs anyone?

Series, Categories, and Subjects

Categories will work once the database is upgraded. You can see them in the right hand column, and they actually do lead to the old posts they are associated with, but changing them or adding new posts is broken until I unshared my database.

Subjects are what I'm calling tags. I hope hey will be quick and easy with dm-tags. We'll see.

Series are what I am most excited about. I can write a bout a page (500 words) without getting bored. Some things take more then a page to write. I want to be able to break these long thoughts up into multiple posts and have them link to each other automatically. If I add another post, I want all the previously published ones in the series to link to it.

Page Caching

It's harder then you may think when I serve multiple blogs from the same application. I have to put the cache in the right public folder, and expire the right file later. I think I'm going to write a custom cache strategy using Merb's clean Cache API. The other trick is going to be expiring the cache when a new post goes live. At the moment nothing really happens. If the wall clock is greater then the publication time the post shows up in the query. With a cache there is no query to run so no new post. I'm thinking the whenever gem may be an option here.

Backups are only as good as your ability to restore them. This is one of the axioms that I learned working tech support for a county government office. I also majored in Physics, which meant collect data now and analyze it later. I bring this up because todays job was adding the restore feature that would read the backup feature I implemented a couple of weeks ago. Now that I have data that is actually worth keeping (and keeping in the same place) backup and restore suddenly is not just another feature, its important.

Todays lesson is a corollary to that lesson of so long ago: Restore is always trickier then Backup.

For my backup solution, I am generating and XML file of all my posts and burning them to CD with my regular backups on my local machine. I wrote an action and a Haml view to take care of generating this, but when I hit that URL, Firefox would display the XML on screen instead of offering to save it.

It took me too long to solve this ever to waant to do so again. The solution is to add a header with a key of 'Content-Disposition' and a value of 'attachement; filename=backup.xml' I'm not sure that everyone will agree that it is the correct place for it, but I added this to my view as:

#!/xml
- headers['Content-Disposition'] = 'attachment; filename=backup.xml'
!!! xml
...

This lets me keep my backup action serving both an HTML form and the XML backup file with no extra logic needed.

Outdated URLs from the days of WordPress are still floating around in in collective memory of the web. The way I had WordPress configured everything was accessed through a query string to the root document. (I think this may be true of any WordPress configuration but I'm not sure)

The point is that hitting the root of this blog with almost any query string now just renders the home page. The query string is ignored. I was careful tp preserve links to posts (/?p=123) and the rss feed (/?feed=rss2) but other things like tags and categories were simply not handled, and will not be any time it the future.

Instead of rendering the main index page these query strings should return a 406 error. doing so would clue in the search engine spiders that what they were looking up no longer existed. I have plans to change the router to make this happen, and if I everything goes right urls like /?tag=ruby will return 406 by the time this post goes live.

On the other hand, this is just one of many good reasons why using the query string for routing is just a bad idea in the long run. It also made it very difficult to write a robots.txt that would keep the bots out of things like tags or categories. These are just different groupings of the same content, but they often ranked higher then an individual post on a subject. In my opinion landing on such pages from a search presents the user with too much irrelevant information.

When subjects (was tags) and Categories make their reappearance they will have pretty URLs and not show up on anyones search results.

Drop Caps have made me a better blogger. The large initial letter you see at the front of each post in this blog are called Drop Caps. They are one of the CSS style choices that I like on this site. The big serve to quickly directly the eye to the start of the first line of text, but having drop caps on the sight has encouraged me to think about what the first word of the first paragraph will be. A capital "I" is not a very pretty letter (in my opinion anyway), and I did not like how the page looked when it was filled with lots of large I's all over the place. I had to think about a different way to start a sentence then with "I am" or "I was."

TrackBack is a loosely defined way for one blog to let another blog know that it was linked to. This is done with a quick post request to a specially designated URL found on the original blog post.

I like the concept of trackbacks instead of. Most blog comments are not well though out and rarely have enough content. Further, they live exclusively on the site they are posted to and their survival is at the whim of that web master. Trackback content on the other hand live on their own site, establish a relation to other content by that author, and most posts are well thought out and relevant. People rarely write "Me too" or "First Post!" into their own blogs.

When I set up the Post class for this blog I quickly went through and added a bunch of needed columns:

#!/ruby
class Post
  include DataMapper::Resource

  property :id, Serial
  property :title, String, :not_null=>true
  property :text, Text, :not_null=>true
  property :allow_comments, Boolean, :default=>true
  property :format, Enum['Markdown','HTML','Textile'], :default=>'Markdown'
  property :guid, String, :lazy=>true

  property :published_at, DateTime
  property :updated_at, DateTime
  property :created_at, DateTime

  has n, :categories, :through=> Resource

  # ...

end

All was good until I tried to write a post with a title longer the 50 characters. For some this will be one of those gotcha type bugs, but I have read through the property rdoc so many times, I think I could probably quote it from memory. String columns default to 50 characters.

The following is a reposting of a question I asked on StackOverflow. I'm putting it here in hopes of generating a bit more buzz for it:

I'm using DataMapper, an open source ORM for ruby, and I have in itch I would like to scratch. At the moment, DataMapper can use Strategic Eager Loading(SEL) for one-to-many relationships, but not many-to-many, where N+1 queries occur. I would like to hack around with making this work correctly, but I cannot find where to do it. So two part question:

1. How to I run the test suite so it will show this to be failing (nb. right now all the specs that should be failing are marked as pending)?
2. Where and how is SEL implemented for one-to-many relationships?

Long ago, when I was just learning Rails, I read somewhere using your primary key in a way that allowed users to see or use it was a bad idea. The source explained that any data that is seen or used by humans may need to change format, and/or, it will become relied upon to be consistent when the database needs it to change. I read this and thought, "Maybe that is true in a big corporation full of PHB's, but I won't ever want to change my data." Wrong!

As I wrote in a previous post I am merging two databases with identical schemes into one, and guess what: the primary keys conflict. Ok, so I need to change the primary keys, but those keys since the days of WordPress have formed the URL's of my posts. These posts are linked to from all over the web (or so my Ego tells me), and I spent a lot of time ensuring that they did not change when I upgraded.