Remember a few years back before we knew what Twitter was? People had things called "Blogs" where they wrote "articles" about their field, their friends, and more importantly, their cats.

Well. It turns out that I have one of these things. I should use it more.

I have some fun stuff coming up that I'll blog about soon since it won't quite fit into 140 characters. However, in the meantime follow me on Twitter so you know how funny I am.

Don't worry, I promise there will still be pictures of cats.

See that lil' radio button that says "Structure and data"? Well. If you're backing up a database table using SQLyog, make sure you check that if you plan on dropping the original table.

Oops. Sorry JC

He insists on standing in my way whenever I'm using the computer. Jerk.

Hopefully by now you know what Subversion, aka SVN is. It's a version control system that keeps track of changes made to files like source code and documentation. It's similar to CVS, but with some major advantages. We've been using it at work for awhile, and I really like it. Changes don't get lost, we can easily keep track of released versions, and once we get around to implementing it SVN will tie into our bug tracking system.

We usually have two servers for a project, one as the development server, and the other a production server. We all have a working copy checked out on the development server. Using virtual hosts with Apache we all have our own sub domain. So for example on our dev server we'd have:

• dan.ourproject.com
• mike.ourproject.com
• jc.ourproject.com

With each pointing to that developers working copy. We make our changes on the dev server as we're making the site, when we finish a task we check it in, and everyone does an update often to avoid conflicts.

When we are getting ready to push a release out to the production server we have to be careful since a lot of the time there are people using the site. We don't want to have errors pop up on the production server. To make sure it runs on that server as well as it did in our working copies, we have a staging area. It's on the same server as the production copy, but only we have access to it.

So we do an export to the staging area, click through the site and run through a checklist of things to check for and once we're sure it's running ok we copy that to the production area and it's live.

Since we want to keep track of the versions we push out to the production server, we give that release a version number, tag it in our Subversion repo, and update our project wiki.

This workflow has worked well for us and if we have a problem we can always roll back to a previous release. We can also use the Change Report feature of SmartSVN to do a kind of code review when others commit code. If we see something a little strange we can fix it, or if's completely crazy we can roll back quickly.

This is just how we do it, if you do it differently I'd love to hear about it so just leave a comment. In the future I'd also like to look into using Git in a similar way.

I never get comments, or requests, so this is for Peter.

Here's a sample controller for CodeIgniter. This is pretty much the structure and it doesn't do much. When you go to yoursite.com/blog, anything in the index function will run.

If you added a function called edit, and went to yoursite.com/blog/edit, then that would run.

All this controller does is load the links from the links table, get the page content for the current page ID, and then passes that to the views. In your views folder you would have 2 files, sidebar.php and content.php. Those would be your template files.

$links would be a variable available in the sidebar view that just contains the result of the database query from _load_links().

And then the view for the sidebar can be anything, like: