Entries tagged with “Content Management System”
- All (4)
- Entries (3)
- Links (1)
- Photos (0)
A Fresh Start
I never thought I’d actually get to this point, but, today, I am releasing a complete ground-up reworking of my site. With Ruby on Rails as a starting point, I was able to develop my very own content management system, and it is now powering everything here (with the help of a few plugins). I’m also excited to have a brand new design up, and it’s one I really have grown to enjoy. Read on for more details on the specifics of the new site.
The Design
Ever since I started using Twitter, I always used a stunning picture of the Crab Nebula as my background. When I started redesigning my site, I used the photo as a placeholder, but after a while it stopped being a placeholder and started driving the rest of the design, so I decided to keep it. The colors in the layout were directly influenced by the image: nearly every color comes directly from the Crab Nebula photo.
One thing I attempted with this was to not hold myself to the notion that there has to be a sidebar on every page. If you take a look at my About and Work pages, you can see where I switched things up. Personally, I think this helps to make it feel a little less like a blog, something I was definitely aiming for.
Even though I’m launching the new design today, there’s still quite a bit of refining for me to do. For one, the notebook page is pretty cluttered, so I really need to go through and organize that a lot better. In addition, several people I’ve shown the site to have mentioned that the header is a bit awkward; having the navigation attached and the title detached throws them off. I’m definitely going to need to find a better way to have that set up.
The Development
Developing the site is something I really enjoyed, and it allowed me to try a bunch of things I’ve been thinking of for a while. The site is built using Ruby on Rails, several plugins, and a whole lot of my own code.
One thing I’m proud of on the site is that every single page is cached. This way, things stay speedy, and the load on the server is lessened. Adding caching in Rails is really easy, and if you’re looking to do it yourself, you’ll probably want to check out this Rails Envy tutorial as well some Railscasts episodes.
For the server setup, I originally was planning to use Dreamhost and Phusion Passenger, but after using it for a bit, I felt like I needed a little more freedom, so I ended up buying a VPS from Slicehost. So far, I’ve been thrilled with Slicehost’s service and performance, and I’m definitely considering moving more projects over to them. As far as the technical side of things, I’m still using Passenger to run the site, though I might test out using Mongrel to see if that’s any faster.
Next Steps
I’m really excited about the new site, but I’m not done yet. Like I mentioned before, I still have some design tweaking to do, but I also have a lot I want to implement under the hood. There are bound to be issues that come up, and I’ll be hopefully fixing them as fast as possible, but if you run into something, please let me know.
I would love to hear any feedback (negative or positive) you have about the new site, so please leave a comment below!
Building a CMS: Simplifying Posts with Single Table Inheritance
“Posts” will make up the majority of my site’s content, and there will be a few different types: articles, reviews, links, and comments. While I could create separate tables in the database for each, I’ve decided to utilize Rails’ single table inheritance, whereby multiple models share the same table and some common behavior. However, STI is not limited to Rails; it’s a general design pattern where one table is used for multiple objects or models.
Rails and Single Table Inheritance
In Rails, every table in the database is represented as a “Model” (which follows the model-view-controller design). So, for instance, a standard Post might look something like this:
class Post < ActiveRecord::Base
# model methods go here
end
This model will store its data in the “posts” table in your database. Now, to implement STI in Rails, all I have to do is create models, but instead of inheriting from ActiveRecord::Base, I inherit from Post, like below:
class ArticlePost < Post
# model methods go here
end
Now all that’s left is to add a “type” column to the “posts” table in the database, and Rails automatically figures out the rest. I’ll go into more detail about this in a future post.
Why STI is Awesome
The basic reason I wanted to go with STI is it makes it very easy to pull different types of data from the database at once and display them. Instead of making a query for each type of post, I can just do @posts = Post.find(:all), and Rails pulls every type of Post and even makes each the right object type (e.g. if the table row has a type of “ArticlePost,” Rails returns an ArticlePost object, not just a Post object).
Single Table Inheritance also makes it very easy to share behaviors between different types of posts, especially the way it’s implemented in Rails. Since each object is a child of the Post model, I only have to write standard behavior once, such as post status and commenting.
Potential Pitfalls
One of the main problems with STI is that it can lead to cumbersome database tables with many columns, since each child model might require different fields. When the database table gets very large, this could potentially cause issues and slowdowns. However, in my case, since each post has the same basic fields (title, body, author, etc.) with only a few specific fields (product name for reviews, link urls for link posts, etc.), I don’t see this becoming an issue. Also, since I’m never expecting the database table to reach, say, 100,000 rows, it’s doubtful there will be much of a performance loss.
Comments as Posts?
While it was a simple decision to handle articles, reviews, and links as subclasses of “Post,” I had a little trouble coming up with how to best handle comments. I had two choices, either I make comments just another type of Post (i.e. CommentPost), or I create a new table and model just for comments. In the end decided on STI, because, once again, I can take advantage of shared behaviors to cut down on code. Also, since a comment is just a “Post,” it will make it easy to “comment on a comment” to create a threaded discussion.
More to come
Since this was more of an overview of STI, in a future post, I’ll try to explore more of Rails’ implementation of single table inheritance and how to best use it.
Building a Content Management System on Rails
In my first post, I mentioned building a content management system from scratch. To introduce the project, I figured I should go through my reasons for it, and what I want to accomplish.
Why write my own?
Sure, there are loads of systems out there for running a web site, and it’d be really easy to take something like the incredible ExpressionEngine and get it to do what I want. However, using existing software means I don’t get the experience of writing one myself.
Also, by writing it myself, I don’t have to try and work around an existing structure to get my site to operate the way I want. If I want a feature, I can just dive into the code and add it, rather than reading through plugin documentation and existing code.
What’s it going to do?
A few of the features I want to implement:
- Blog Posts
- Link Posts (i.e. my own del.icio.us)
- Review Posts
- Portfolio Management (to replace my current portfolio)
- Comments
- Static Page Management
- RSS Feeds for everything
- Caching System
- User Management
This is a pretty general list, but as I start working on it, I’ll go into detail about each of the site’s features.
Why Ruby on Rails?
Simply put, I love Ruby, and I love Rails. If you’ve never used either, however, don’t despair! Although I’ll have a lot of Ruby and Rails specific material, my focus will be more on designing the structure of the application, rather than going through the underlying code.
Stay tuned!
I’m going to try to post pretty regular updates on my progress, so make sure to check back often if you want to see how it’s going!