I happened to read a RWW article on Tweeting in Color today.  I can’t say I was thrilled at the entire concept of Twitter Style Sheets (TSS), the Twitter version of CSS for HTML.  The entire concept of having people able to colorize and change the font characteristics of their tweets is a bit disturbing to me.  To quote the last section of the article:

For now, come check out our demo (if you have a preview access account), or at least read the code (at http://xent.com/tss.js ) and stay tuned for what comes next. Though, like @ev himself, we’re not quite sure about the Promethean curse of giving users Tweets in any color they’d like – we’re afraid it’s only a matter of time before we see animated, blinking Tweets in 3-D!

I can’t say I’m hopeful at the ability of at least some of Twitter user base to restrain from posting loud and obnoxious tweets, or louder and more obnoxious, anyway.  What I do like about that post is the mention of annotations and that people are thinking about how to link between tweet subjects and other social network accounts using the annotation functions.  It is indeed difficult to reference a Facebook user in a Tweet in a useful manner while keeping the message under 140 chars.

What interested me more about the article was the thoughts that it prompted about the usefulness of the Internet.  The concepts of “Content is King” and “keeping presentation out of the way of your message” seem to come to mind when being reminded of the old “blink” HTML tag and it’s possible use (or abuse) in the future of Twitter.  It is a very good reminder that new functionality can be misused just as easily as it can be used to improve experience.  That’s something every UI designer and software engineer needs to be reminded of on a regular basis.

I was forwarded an article today that talked about the benefits of SSDs (solid-state-disks) on the performance of MySQL databases.  It sounds both amazing and almost unbelievable.  There has to be a catch, right?

Well, there probably is, but I’d love to see the technical scenarios behind which the 4 companies referenced in the article claim that much of a benefit.  None of my projects are yet to the point of scale where it would be likely, but I hope they will be soon.  I could probably learn a LOT from setting up informal interviews with the engineers behind those architectures.

Then I got to thinking about MySQL database server architecture and some consulting I’ve been doing for a friend of mine.  He’s running a fairly popular web forum based on raising chickens in your backyard.  Go ahead and pop over to www.backyardchickens.com if you’re interested in the topic.  He’s been facing some load problems with his database and his server environment he’s using.  He has some architectural decisions to make soon that have been heavily weighing on him lately, not the least of which deal with the size and structure of his MySQL database.

My thinking in his scenario where his load has gotten high enough to warrant fairly advanced performance tuning of his database, leaned me to thinking about one tunes a MySQL database, specifically when running the InnoDB or in-memory table engines.  Basically, the more memory you can throw at the system (and assign to MySQL for in-memory caching), the better it’s going to perform.  (Tuning gets much more advanced than that, but that’s the main portion of it).  It’s imperative these days that you use a 64-bit processor and matching OS and software if you have any sort of size on your database, lest you run into the 2GB process memory limit of 32-bit systems.

However, the reason that caching mechanism works so well is that it reduces the number of reads from disk that need to be executed.  It stands to reason, thinking logically anyway, that if you can get the read to write ratio down far enough, the disk subsystem will be spending most of it’s time writing.  If SSDs are supposed to perform much better than their standard disk counterparts, than the little time MySQL spends reading from the disks would be even faster, and the write performance would be even less, leaving much more time to spend answering queries from memory cache.

Of course, this is all hypothesis on my part since I am not deeply skilled in the arts of MySQL performance tuning.  Nor do I know a significant amount about SSDs, definitely not enough to say for certain whether their performance attributes would definitely be of benefit to specific MySQL architectures and design use cases.