I’ve been meaning to mention this useful post— 10 Firefox Add-ons for Web Designers—for some time now but never seem to get around to it. Anyway, it’s a short, efficient read, well worth your time. The features added by installing some of these plug-ins more than makes up for the bloated Firefox you’ll end up with (Firefox is almost always my biggest memory hog these days). Of the add-ons mentioned, the following are in my must have list:

• Firebug, which does, well, just about everything. This is a must-have.
• Firecookie, for debugging cookies.
• Codeburner, which provides a reference for HTML and CSS elements.
• Web Developer Toolbar, which does some things that Firebug does not and is also a must-have.
• Firefox Accessibility Extension, for testing the accessibility support of your page.

Not mentioned in that post are these add-ons, which I rely upon as well:

• Console, an improved JavaScript error console.
• YSlow, for analyzing a Web page’s speed (also see \[intlink id="128" type="post"\]my posts on this\[/intlink\], if you want).

Plus, unrelated to Web development, but add-ons I use daily:

Adobe announced last week details for the forthcoming 2.0 version of their Adobe AIR (of which I’m a big fan). It’ll be released in beta format by the end of 2009, with the official release in the first half of 2010 (theoretically). The updated AIR 2.0 will be able to make use of mounted mass storage devices, like flash drives and cameras, will be able to communicate with native applications running on the computer, should have improved performance, and more.

For more on Adobe AIR, you can check the official Adobe AIR Web site, read this review (of AIR 1.5), or see my book on developing AIR applications using HTML and JavaScript.

, I layout some common conventions of MVC frameworks. Both of those posts lead up to this one, in which I want to talk about actual code. In my opinion, it’s not too hard to understand what MVC means, in theory, or to follow a framework’s naming rules, but then you start developing a project and can quickly become confused as to where you actually put your code.

If you haven’t heard about NoSQL before, it’s worth looking into. It’s an interesting development in the world of databases, or an interesting label given to a long-running approach to non-databases, depending upon how you want to think about it. The short description of NoSQL is that, instead of turning to existing relational databases, from MySQL to the powerful Oracle, many high-demand applications are using their own storage system. This includes the biggies, like Facebook, Amazon, and Google. By writing a specific storage system for an application, you can greatly improve the amount of data that can be managed and, more importantly, the performance. In other words, instead of using something that’s been designed to work for every situation, create something that’s perfect for your situation. This level of effort certainly isn’t for everyone or every situation, but for those that use databases a lot, and have potentially demanding applications, it’s worth thinking about.

, I introduce the MVC design pattern, commonly used in frameworks and other programming situations. In that post, I wrote about the Model, View, and Controller parts: their specific roles and how they relate to one another. Those are the fundamental pieces of MVC, but I personally found that knowing what this means in terms of code is a whole different subject. I want to eventually focus on that, but first I have to discuss some of the conventions that frameworks use and how they might differ from one framework to the next.

In this post, I’ll use a hypothetical employees-departments example, giving examples using the Yii framework, the Zend Framework, and Ruby on Rails (these are the three frameworks with which I’m most familiar). If you’re using a different framework, let alone a different language, some of the syntax and particulars will change but the basic principles will still apply, and that’s the important thing I’m trying to get across here. In my next post on this subject, I’ll provide some representative code (I was hoping to do that here, but this subject became too expansive, as commonly happens for me).

I’m planning on writing several posts on the Yii framework (for PHP 5), which I’ve been using for the past several months. Before getting into that, though, I thought it’d be worth while to write about the MVC—Model-View-Controller—architecture first. MVC (first defined 30 years ago!) has become a standard approach for frameworks and many other types of application development, where the emphasis is on separating presentation from logic. By taking this route, you can more easily tweak individual parts without (hopefully) breaking the whole.

The basic concept is relatively simple to understand, but I found that the actual implementation of the pattern can be tricky. In other words, it can take some time to master where you put your actual code. In this post, I write about the individual pieces and how the relate to each other. In a follow-up post, I’ll write about how to communicate between them, and what in the world $this means at any particular point!