Changing Shoes For A Redesign

The best way to rethink things is to be in the shoes of your users. Use your app how they use your app. Try to take a fresh look at your application like you’ve never seen it before. Would you change the location of the menu/navigation? Would you change the actual menus/navigation? Would you add a shortcut search box where there wasn’t one before? Maybe you remove the advertising or move the place that the ads are located so that they are less intrusive…

The idea is that every so often you need to take a step back. Looking at your application from your users perspective may well change how your entire application works. I’m not saying this from a statistical analysis of the way people click and heatmaps and all that good stuff (though they do have their applications), I’m saying just a pure usability test from another perspective. Where do the new users look? Where do they click? What’s the first thing they want to go to? Are you putting them through information overload?

So take a step back, change shoes and take a fresh look at your app. No statistics, no heatmaps, no preconceived notions about the problem you are trying to solve (I know this is easier said than done). Just remember why you wrote your app in the first place. Try the passion on for size again and see if that doesn’t stir things up a bit.

Speeding Up Your Selects and Sorts

When you are using a framework, they typically set your VARCHAR size automatically to 255. This is normally fine since you are letting the framework abstract you away from most of the SQL. But if you interact with your SQL, there is a way to get a decent speed increase on your SELECTs and ORDER BYs when you are working with VARCHARs.

The VARCHAR data type is only variable character size for storage, not for sorting and buffering. In fact, since the MySQL optimizer doesn’t know how big the data in that column can be, it has to allocate the maximum size possible for that column. So for sorting and buffering of the name and email columns below would take up 310 bytes per row.
Read the rest of this entry »

Database Read/Write Splitting in Frameworks/ORMs

Although one of the primary ideas behind frameworks is to keep things as simple as possible, sometimes they create issues in the long run. What I am about to discuss is something of a luxury problem (as scaling usually is), but it is a problem nonetheless.

When initially starting a project, whether you are using Ruby on Rails (Ruby), Django (Python), CakePHP (PHP), Catalyst (Perl), or any of the other 100s of frameworks in any of the languages out there, the first and most important thing to do is to get it out the door. Once you have done that, it’s time to get users, fix bugs, and add features. After you have done all that and you have a great web app, its time to think scaling. (Yes I realize that I have trivialized this process immensely, but its for a point, I promise).
Read the rest of this entry »

Textmate Minimap Plugin

My editor of choice for most of what I do on the Mac (when I’m not in the shell using Vim) is Textmate. I recently came across a neat plugin called the Textmate Minimap. Essentially this plugin opens a map across the side of your Textmate window (like another drawer on the other side) and allows you to scroll full screens. You can move the editing window screen by screen in the minimap. This is equivalent to a visual page down.
Read the rest of this entry »