The day has finally come. I've put up the 1.0 release of my very own, lovingly hand-made, spanking new blog. It doesn't do much of the stuff this one does, and it certainly hasn't got the ammount of posts this blog has, but that's my new home, and a work in progress. Keep an eye out for new posts there.

This is my very last post here. I'll keep this one up for as long as the server is paid for (it will expire soonish, though). I won't try to move the posts to the new blog. It's a fresh start, and I think I'd like to let this thing die. I'll rewrite some of the older articles that I find useful, though.

In most online resources on CSS, you see a recurring theme: "Don't bloat your HTML with DIVs." For those of you who may not be familiar with the concept (please don't tell me you're still using tables!), DIVs are generic block elements which can be used to create hooks for styling your HTML document. So what is wrong with DIVs?

Yeah, yeah, I know this topic's kinda corny. But this is just a reminder for myself, and you reading this is simply incidental. :P

Anyway, I've used only FireBug for a long while, and I've started looking around for other useful addons to enrich my web development experience. So, here's my list of must-haves.

I've skimmed over some hundreds of pages of various books in order to define a good starting point in this little undertaking of mine. The Tanenbaum book is really great, but it's very theoretical, and painfully detailed. It's definitely not something I want to touch yet. Not coming from IT background has its own drawbacks, especially in more technical areas such as networks.

Oh, well, you can't always use the best tool, simply because best is kind of relative these days. There are so many of them (tools) and all have a valid reason for existence, so it becomes hard to define why something should be called "the best". Anyway, as far as web application (or site) frameworks go, Django, for me, is the best (relatively) tool for what I do. But, it is still not the best because I cannot purchase a decent hosting plan (don't ask, it's my weird last name that's giving me a lot of trouble), and therefore am stuck with shared hosting...

Short answer: you will be hard pressed to find better docs.

I've read one of the typical flame bait blog posts about Rails vs Django back when I was very enthusiastic about Rails development (I won't even post the link here, because it has no educational value, whatsoever), and one of the points the author was making was lack of documentation for Django. Well, that person couldn't have been further from the truth.

Python's IDLE displaying the license text: A call to license() in the IDLE's shell prompt give you not only the text of the actual license, but also a bit of Python's history.

As a Django newbie, I am always a bit at loss when I need to find out what is going on with my app. Sure the error page is quite informative (other frameworks could learn a thing or two about newbie friendly error pages from Django), but if you need a more powerful solution IPython Shell is the perfect answer.

Thanks to my mentor, Dusty, for sharing the secret with me. ;)

So, I've coded in Ruby on Rails for a while, and to tell you the truth, I thought it couldn't be better. But what do you know! Django is the framework I'm using right now. Just like that. I've swtched and I'm quite happy about it.

When you are begging with Ruby on Rails, you usually resort to scaffolding. Scaffolds are a quick way to boost your productivity, especially in Rails 2.0, which makes it possible to specify most details for scaffolding a RESTful resource.

A default "New post" form with a "Preview" button.

Using the default scaffold, you get a single "Create" (or "Update") button in your new post (or whatever resource you re working on) and edit post forms. In this post, I'll tell you how to add another button for previewing the post before saving it to the database.

As you might have noticed, has_and_belongs_to_many (HABTM) relationship in Ruby on Rails does not support the counter_cache.

Counter caching is a good way of improving performance by caching the number of child records associated with the parent in a parent table's column as opposed to querying the database each time you need that information. In a 1 to many (has_many) relationship, you can use the :counter_cache option on the belongs_to side of the matter to have counter cache updated automatically. With HABTM relationship, you need to do it a little bit differently.

One reason for this is that, of course, HABTM method doesn't support :counter_cache. Another reson is that with HABTM, you can do mass-associations so incrementing and decrementing counters by 1 simply does not make any sense.