While I was updating iTunes, I figured I may as well install Safari for Windows, just to take a cursory look at my websites.

So all those problems with Japanese text and sans-serif fonts I've been laying down at Google Chrome's feet? Well, it's not Chrome's fault entirely -- it's Webkit's fault.

Chrome runs on the Webkit engine, which also powers Safari. Viewing this site in Safari produces the same result -- no font substitution when a sans-serif Japanese font is required. A visit to Bounce.com on Safari confirms it -- the site looks borked on Safari as well.

Just to be thorough, I checked Opera as well. It can handle sans-serif Japanese font substitution fine, although it looks a bit ugly.

Nothing strange so far, right?

Here's the same sentence in a <span/> tag with a style attribute specifying Helvetica, Verdana and Arial fonts: このセンテンスは日本語で書いた。

If you're using Google Chrome, you may not even see the sentence at all. It will, however, render when you view the source code.

Curious to know why some parts of my sites render Japanese text and others do not, I started inspecting elements with Japanese text in Chrome, enabling and disabling rules. When I disabled font-family rules specifying sans-serif fonts, the Japanese text re-appeared. Enabling the sans-serif rule made them disappear again.

It looks like Chrome is pretty literal about how it renders fonts -- if it encounters a character the font doesn't support, it's not going to render it. In fact, it won't even bother trying to render an analogous sans-serif Japanese font.

Here's our same example sentence with a style attribute specifying a sans-serif font-family: このセンテンスを書いた。

Firefox and Internet Explorer look like they substitute fonts to render sans-serif Japanese text, probably falling back on MS PGothic.

If you want a mix of English and Japanese text to render with a sans-serif font in Google Chrome, it looks like you have to specify those sans-serif fonts in your CSS.

Example: This sentence mixes 日本語 and 英語 with Arial MS Unicode and MS PGothic specified in the font-family.

Of course, this means your English text is also rendered in Arial Unicode MS or MS PGothic, which pales next Helvetica. And Mac users? Well, that's an entire cross-platform can of worms I haven't even tested.

UPDATE, 06/01/2010, 0917: Of course, this site uses UTF-8 for character encoding. If a site uses Shift-JIS or EUC-JP, these problems may not be an issue.

Also, the examples may not adequately demonstrate the sans-serif issue, so here are more examples using <h1/>.

Sans-serif specified in font-family:

日本語

Helvetica and sans-serif specified in font-family:

日本語

MS PGothic specified in font-family:

日本語

Arial Unicode MS specified in font-family:

日本語

Firefox falls back on MS PGothic in the Helvetica example. Internet Explorer falls back on a serif Japanese font. Chrome does not render it.

I signed up with Twitter a good six months before it took off at SXSW in 2007, and one of the first things I did was tweet in Japanese. Success! I signed up with Grooveshark around the same time and tried to share some upload some music tagged in Japanese. I saw question marks where there should have been text. Failure.

Google Chrome is gaining market share, and even I have to admit I like its speed. But one thing prevents me from adopting it -- it can't handle the Japanese characters on my site.

That's not to say it can't handle Japanese -- I can visit HMV with no problems, but Bounce looks totally messed up.

If you're viewing this site on Google Chrome, you already see a number of these inconsistencies. First, the header of my site, which is named 「作譜」, is completely missing, although the <h1/> space for it is allocated. But "About this blog" renders the blog name just fine.

The side bar ought to have links to this site and my "creative scrapbook", 「名作記」, but they are gone. Trying to reproduce the errors is proving elusive. Here's how the side bar is supposed to look like under the "Links" section labeled "personal":

作譜
名作記
austin stories

It renders fine in this entry, doesn't it?

I've coded this site on the back end to do a bit of string processing to account for paragraph and line breaks, so while it's a syntactic replica of the problem text, it's not rendered the same way. But I suspect even if I do replicate the markup, encoding and response headers, I won't get the same results.

I've already sent bug reports through Chrome about this issue, and it's been a persistent problem since the browser launched.

It would probably help if I didn't make such weird demands on browsers with all this mixed language content. Why must I be so difficult?

Part of me would like to visualize Hula's Bar and Lei Stand as the scene of that moment, but Hula's has been around for 35 years, according to its web site. That would put it around 1975. The American Psychiatric Association revised the entry in 1973, then removed it entirely in 1987. Maybe it's plausible?

A semantic argument ensued, which usually happens when definitions of adjectives are up for debate, but in this case, both authors are correct. Passion, professionalism -- they're not mutually exclusive in the realm of programming. But both writers managed to talk around the one point on which they agreed.

The Carnegie Hall web site makes a coy reference to that age-old joke, "How do you get to Carnegie Hall?" The reply: practice.

If you want to improve a skill -- be it C# or C-Sharp -- you need to practice. To become a master at that particular skill, you need to practice for 10,000 hours.

Malcolm Gladwell seems to get all the press regarding this figure, but Daniel J. Levitan mentioned it first in his book, This Is Your Brain on Music. Levitan says it's a well-researched figure, and I haven't scoured the footnotes of the book to verify. Intuitively, it makes sense.

So, yes, there's a reason employers seek at least five years of experience for their positions -- consciously or not, they're looking for masters.

The quality of the practice matters. I had a piano teacher in college who advocated a method of "perfect practice" -- he taught that if you played a passage of music perfectly during rehearsal, your performance will be likewise perfect. (Classical music is all about fidelity to the score.) If you spent five years doing something incorrectly, you'll be a master of doing it incorrectly.

So here's where passion and professionalism affect the picture. Passion is needed to make those 10,000 hours feel engaging. If you're an accountant who hates being an accountant, five years is going to feel like a lifetime. Professionalism, as defined by Mark, is actually the same thing Soon describes without the hyperbolic language. Whatever it's called, you're going to need it to reach that mastery.

And really ... if you spend that much time being engaged (and not getting burned out), then yes, it may seem like passion/professionalism should take all the credit. It doesn't.

I've been building web sites from the ground up since 2000. Numerically, I ought to be a master at it, and by some accounts, I am. I like what I do, and on the days I don't, I take solace knowing it doesn't annoy me as much as, say, working at a newspaper would. (I've done that.) But I have interests beyond programming, some dating back further than when I became a programmer.

Do I lack passion, then? Probably not. But I've got something that has kept me going for the last 10 years, and even if I never set out to master my programming skills, it doesn't mean I may not end up doing so.

Note: I had intended to write a series of tutorials while I dealt with some menial task for a video project, but those tasks turned out to be easier than expected. So I'm not sure how many more of these entries I'll write.

There are a lot of places on the Interwebs where you can find out about video resolutions and the first two links provided by Google are good places to start.

Assuming you can get through all the jargon that gets thrown around.

Here's the thing you should come away with in learning about video resolution: there are many ways to describe the same thing.

Let's begin with aspect ratio, the width of an image divided by its height. Long ago and far away when televisions started inching their way into American homes, film studios combated the perceived threat of the medium by expanding the size of the theater screen. As a result, films have an aspect ratio of 16:9, while TV has an aspect ratio of 4:3. That's the simple history of aspect ratios.

Now comes the hard part.

It has to do, in part, with scan lines.

The About.com article describes it best:

A television or recorded video image is basically made up of scan lines. Unlike film, in which the whole image is projected on a screen at once, a video image is composed of rapidly scanning lines across a screen starting at the top of the screen and moving to bottom.

Even though the image you see on the screen may be 4:3, the video resolution expresses the degree of granularity within that 4:3 aspect ratio. A 640x480 resolution has a 4:3 aspect ratio. 640 / 480 = 1.333. A 720x480 resolution also has a 4:3 aspect ratio. 720 / 480 = 1.5.

What? 1.333 is not the same as 1.5.

All right, let's talk about standards. Different regions of the world have set specifications by which video makers and manufactures must abide. In North America, there's NTSC. In Europe and Asia, there's PAL. And there's also SECAM, wherever that's used. Each specification states how many scan lines can be used in video equipment.

That explains why the 480 doesn't change between 640 and 720 -- the specification deems it so.

What's the deal with the 640 and 720, then?

Scan lines deal with vertical resolution, but each line contains a number of dots -- that is, pixels -- that get fired up anytime that scanning beam of light hits it. The more lines and the more dots you have, the sharper the picture becomes.

Throwing all these numbers around won't mean a thing without seeing just how messing with them affects your picture. Ever hear of letterboxing? It's those black bars that show up on the top and bottom of your screen if you try to watch a 16:9 film image on a 4:3 TV set. If you tried to watch a 4:3 image on a 16:9 screen, the black bars would show up on sides.

Try to fill the entire space with the image, and it gets distorted. The narrow picture on a widescreen gets stretched, while a wide image on a narrow screen gets squished. Take out the distortion, and the image gets clipped.

In the audio world, it's best to cut than to boost, and that still applies to video as well. Analog images look terrible on high definition screens because of the differences in scan lines -- the 480 vertical lines of an analog signal can't possible fill all 720 lines of a hi-def screen. It's like transcoding a 128kbps MP3 to 192kbps -- it's still going to sound like a 128kbps MP3.

So if you want to watch a video shot at 320x480 on a DVD player, you cannot help but have a fuzzy picture. And if you transcode a high definition video to standard definition -- no, I'm not even going to get into what those terms mean -- then try to upload to a site that supports high definition, you get a letterboxing double whammy.

Combine these concepts with the lesson about codecs, and ... well crap, my brain just shut down trying to keep all of it together.

And there's still much more to learn.

"Rock star developer" used to mean one thing but now is meaning something else. I sometimes look at those job postings and wonder if these employers would prefer a "classical developer" instead.

I am a classically-trained musician, although you wouldn't know it if you heard me try to bang through the Tocatta by Aram Khachaturian. When I was learning the first movement of Ludwig Van Beethoven's Moonlight Sonata, I wasn't concentrating on the individual notes so much as I was listening for the overall harmonic rhythm. I could sense when one diminished seventh would fake out a resolution to another diminished seventh, till it finally reached the tonic, which was not necessarily in the root key established at the start of the piece.

But some musicians don't need to speak that language. In fact, most musicians never speak that language. They just develop an instinct for what sounds "right". U2 prided themselves on the fact their earliest songs were nothing more than music exercises jumbled up to become songs. (On some level, though, that's how it's supposed to work.)

U2 are rock stars. They probably still don't read music. And honestly, they're wealthy enough not to need to.

By that token, I could probably be a "rock star developer". I don't necessarily know what design patterns are. I may not be able to tell you what "cardinality" and "polymorphism" are off the top of my head. I write database queries with joins and outer joins all the time, but if you asked me to explain how they work, I'd probably mumble and stammer.

Makes you wonder how I make a living as a web developer.

I've been building web applications since 2000, so at this point, you'd think I'd pick something up. And I have. I'm just not necessarily cognizant of what. I know I have holes in my knowledge, but I don't know exactly where they are. My coding style could probably best be described as "instinctive".

Very much like a rock star. Or at my level, a rock musician. (I don't have the ego or the blow to be a "star".) Knowing the difference between an augmented fourth and a diminished fifth won't effect whether you can shred through a guitar solo, but even a little music theory could go a long way in enriching your harmonic language.

What I should really be doing -- and what I aim to do in the next several months -- is become a "classical developer", someone who can map those nebulous concepts with an actual vocabulary, someone who knows why best practices became the "best", someone who can actually explain what "cardinality" and "polymorphism" mean.

Of course, the hazard of having classical training is being shackled by it, and no world is more inflexible than classical music. What's on the page is what should be coming out of your instrument. That is the rule of law, and audiences will let you know when you break it.

The trick, then, is to lean on that training without being beholden to it. When I work on my own material, I'll keep in mind what the common chord progressions are -- then try to find ways around them.

I'm at a point professionally as a developer where I want to do something and know what I'm doing. And, uh, it's kind of long overdue.

Have you heard the story of how Paul McCartney "composed" his classical piece, Liverpool Oratorio? He had someone with music training transcribe what he was humming.

I don't want to be like Paul McCartney.

Any explanation of digital video begins with an understanding coders and decoders. The proper parlance for this concept is codec. This word is important to learn. Take it to heart.

Digital video takes up a lot of space, much, much more than audio. An uncompressed audio file can be dozens of megabytes. An uncompressed video file can be dozens, even hundreds, of gigabytes. Back in the late '90s, when I made my first tip-toe into the depths of digital audio, 6GB hard drives felt voluminous, but they were no match for the demands of space-hogging WAV files.

Today's late-aught hard drives make those 6GB drives look puny, so a 100MB WAV file doesn't seem so greedy. But even a 1.5-terabyte drive is no match for hours of uncompressed video files. Till such a day comes when drive space approaches infinity, codecs are a fact of life.

And damn are there a lot of them.

Lossy codecs discard information during encoding, similar to how a WAV file loses part of its frequency range when being converted to MP3. Lossless codecs do not discard information during encoding, similar to how a FLAC file compresses a WAV file without loss of sound quality.

Between the rock of hard drive space and the hard place of video file size, lossy codecs are pretty much de rigeur when working with digital video. To the home studio enthusiast, that's like recording a song with nothing but MP3s and MP4s. Oh, it could be done, but the basic tenet of any media editing is that you want to cut more than boost.

Actually, keep that idea in mind throughout your exploration of any creative endeavor: cut before boost.

So in terms of digital video, you'll be working with source that's pretty much cut to begin with. I did not realize this fact during my first steps in dealing with video, so I ended up transcoding a lot of video. But similar to how coding and re-encoding a sound file will eventually screw up the sound quality, the effects on digital video are compounded moreso.

Transcoding is a necessity when working with video, but smart transcoding saves time and space.

Let's make this personal.

My first music video was shot on a Canon Powershot S500 point-and-shoot camera from 2003. It could record 30 seconds of video at 640x480 or 3 minutes at 320x240. Translation: It could record 30 seconds of video viewable on an old television set or 3 minutes viewable on 2005 state-of-the-art YouTube.

I opted to go for the smaller file size.

I eventually wanted to view this video on a DVD, despite its resolution. The concept of resolution requires another tutorial entirely, but for now let's map some of these numbers being thrown around with real-life environments:

• A 320x240 video can be viewed, as mentioned before, on YouTube at its lowest settings. It won't look any good bigger than that.
• A 640x480 video can be viewed in iTunes or other desktop computer media players such as Windows Media Player and Winamp. You might even watch it on a television, but it won't have the same picture quality as ...
• A 720x480 video, which is DVD quality and no better. It is certainly not hi-def, which is ...
• A 1920x1280 video, right now the best picture quality around, with 1280x1040 still being pretty damned decent.

My video, being capped at 320x240, has no chance of looking good at a DVD level, but in order to be burned on a DVD, it has to be transcoded to that resolution regardless.

Fine. I figured I may as well transcode the source material to the destination resolution, edit it and export at that resolution. So I transcoded those files without paying attention to which codec I was using and ended up with 10 files each nearly 1GB. The original files combined took up 230MB of space. But I have a big drive, so what's the deal?

First, the codec mattered. I could have saved a lot of hard drive space by choosing the right codec for the job, and I didn't. I don't even know how I chose what I chose -- probably some default setting -- but if I used one designed specifically for DVDs, I could have shaved a few hundred megabytes from those encoded files.

But in reality, I didn't need to transcode those file at all. In fact, I could have just worked with the files on hand and let the settings in Sony Vegas Movie Studio take care of the transcoding during export. The picture quality looked the same both ways, but one method saved hard drive space.

So what codec do you use? That's a question that comes up numerous times, but for beginners, read the manual for your camera. My Canon Powershot S500 stored video in AVI files with the MJPEG codec. My newer camera, a Canon Powershot SD780IS bought to replace the now-dead S500, stores video in MOV files with the H.264 codec.

Your camera will be different.

If you use a paid software video editor such as Vegas Movie Studio (the one I use) or iMovie, it should come with its own set of codecs to create whatever video you want to produce -- DVD, Blu Ray, YouTube. If you use freeware such as VirtualDub, you'll have to hunt for your own codecs.

I'm at the point where my workflow is pretty solid -- get the MIDI parts down, record those MIDI parts to audio, lay some vocals over those tracks, apply effects processing to all that audio, mix it down, do some quick mastering and pow -- ready to hear.

It took a few years before I really got how effects, particularly equialization, work, and I had to redo a lot of stuff multiple times just to get the sound I have today.

That shot of confidence in my achievements made me think video would be just as surmountable.

What an idiot.

And boy am I never going to get any of those hours back.

Right now, I'm going through a tedious process of accommodating my lack of processing power to edit some hi-def video. It will take me a few days to reach a point where I can start editing, which will take another few days. And once the editing is done, another few hours will be spent rendering the finished product to various formats.

It takes only a few seconds, maybe a minute, to turn a WAV file into an MP3. No such luxuries await with video.

So I'm hoping to spend the next few days jotting down -- mostly for myself -- things I've learned in working with video. I'm still light years away from attaining a beginner's fraction of knowledge, but I hope what I know prevents me from going down any more wrong-headed paths.

Hyperlinks, punditry and meta were pretty essential to the success of early blogs. Not so much online journals -- meta, yes, punditry, perhaps, links, optional. Blog topics could cover any number of subjects. Journal topics focus primarily on the events of the writer's life.

I come from the journal tradition. I'm not much of a blogger because I'm not combing the web for things on which to comment. Well, I do for Musicwhore.org, but for this site? This site which was intended to be my dumping ground for commentary? This site which was supposed to deal with subjects other than myself? Not so much.

I'm just not suited to write a blog -- which hasn't stopped me from launching about seven of them -- because I'm just not a link collector.

Or so I thought.

For months, I've felt self-conscious for letting this site -- and others -- go neglected. Where can I find that cool content which would make me gaze intently at my navel?

That's when I looked at the links I post to Facebook and realized all of them were fodder for blog posts. If I had the inclination to ponder and to elucidate, I could have contributed my two yen about, say, Patrick Stewart's mom, Nathan Gunn's workout or the correlation between secular societies and prosperity.

Or would I?

Actually, I probably would have just made a link and wrote little more than "Hey, this is cool" -- a format at which Facebook excels.

Paste a URL in a box, type some text, press a button -- viola! Instant link log.

Sure, I could do something like that with Tumblr, but Facebook has an advantage this site does not -- I know my audience.

The Facebook audience are people I have met at some point in my life, a few virtually. I know exactly who is reading what I have to say about some link I posted. I can find out IP addresses of visitors for this site.

This site isn't indexed by search engines because, well, I have family members on the Internet. So whatever potential audience I have is seriously curtailed by a robot.txt file. In short, the people who would read this blog are people with whom I'm already networked.

(My personal sites are really for them, anyway.)

So yes, Facebook killed this blog. Or rather, injured it significantly. Things I could have posted here, ended up there.

I don't really intend to shut this site down, but I can't picture an avalanche of content coming soon either.

I could see where Dzuiba is coming from, although I wouldn't word it as strongly. I've seen a lot of posts pop up on DZone extolling the virtues of being a "passionate programmer", someone who always strives to learn, devotes free time to improving, living and breathing code ... all the usual self-back-patting by overachievers.

I used to code in my free time. But that's because I was learning from scratch. I spent my college years learning such esoteric topics as orchestration, music theory, Associated Press style, defamation of character, points and picas. Control structures, variable types and design patterns were not part of that curriculum.

I can tell you when I started coding at home less -- early 2005. That's when my interest started being diverted to home studio recording. I wanted to figure out how compressors, limiters and equalization worked. I wanted to create a Red Book-standard compact disc that I could eventually send to a pressing plant. I wanted to learn how I could create a make-shift isolation booth in my walk-in closet to record vocals.

It's possible I could have learned home recording and continued my exploration of code, but honestly? How many times do I want to relearn how to use an if statement? When you know the basic grammar of programming languages, all that's left is to learn vocabulary and syntax. I would like to learn Ruby and Python at some point, but I prefer to learn how to use effects processors instead.

I still code in my free time, but it's not all I do. In fact, coding is my escape from recording. When my ears are fatigued, I'll fire up Netbeans and scrub a few more bugs I've been putting off.

All that to say, I chose balance. I've benefited from coding in my free time. I wouldn't be nowhere near qualified if I didn't. But I've benefited just as much -- my instinct tells me even more so -- from leaving code in the office. When I'm done with models, views and controllers, I can go home and think about chord progressions and melodies. Or nothing at all.

Dzuiba is right to question a mindset that blurs boundaries between the personal and the professional. I don't find it healthy. The rebuttals are also correct. Extra-curricular coding is necessary to improve, let alone keep up.

So code in your free time, if you want. And if hiring managers find fault that you don't, their lack of balance is not your responsibility. In fact, just nod and walk slowly away.

After considerable uproar from users, the forced compression was removed. So I begrudgingly uploaded my videos again.

This past summer, I put new audio tracks on my videos, and I wanted to update them on all the sites to which I uploaded. The difference in user experience between then and now was drastic, and it forced me to update the 2008 shootout. High definition is now the norm, and each site handles it differently, some better than others.

This time around, I stuck with uploading MPEG-2 files, forgoing the comparison with MP4.

Here's how each site performed.

YouTube has really stepped up. I was expecting my videos to look like total ass -- and yes, the upload process does create low-quality versions for users with low bandwidth -- but I was nicely surprised to see very little to no loss in picture quality. The audio also remained in stereo.

Back in 2008, the multiple video upload interface was marred by JavaScript errors. Google now forces users to install Google Gears to upload multiple videos, which I guess gets around the JavaScript issues.

The best part of the user experience was not having to hack my videos to accommodate YouTube's processes. My opinion has pretty much changed 180 degrees.

Myspace

Myspace, on the other hand, is worse for wear. Myspace Video also supports HD, but the post-upload process is too dumb to figure out whether something is really in HD. My 4:3 videos were stretched to fit the 16:9 view port, making the videos look odd.

The audio quality remained high, but the fact YouTube and Facebook can get aspect ratios correct pretty much reveals how far Myspace needs to go to catch up.

Facebook

In 2008, Facebook scored high on picture quality but low on audio quality. Now the audio quality has caught up with the video quality. Before, the audio was converted to mono, but now it's kept in stereo, with little or no degradation.

Last.fm

Bandwidth issues pretty much took Last.fm out of the running. My video uploads timed out after a few minutes, and with an upload transfer rate easily a fraction of the other sites, Last.fm cannot be considered a serious contender in online video. So the old videos from 2008 are just going to have to suffice.

Conclusion

As much as I was surprised to praise Myspace last year, I'm just as surprised to turn around my opinion about YouTube.

YouTube effectively addressed the issues that hampered my user experience a year ago, and I don't hate the site any more. (That's not to say I love it, either.) Myspace, however, lost out, and I'm not confident in its ability to catch up. Facebook also gave some impressive results, so I'm more inclined to post on Facebook than to Myspace. Last.fm? It has bigger issues with its artists services on the whole, something the site has never really managed to address satisfactorily.

At some point, I may try other video sharing sites, but for my current needs, YouTube and Facebook suffice.

When I tried out the early incarnation of the site, my mixes were pretty novice. (Now, they're safely amateur.) I think the results I got were softballs, and my second go at the site confirmed it.

In fact, I even dropped cash to get full access to the site's services. I uploaded a beta mix of Imprint, and the results were brutal. Of the 12 tracks on the album, only "Choices", "Take It Apart" and "Late Thaw" were considered having hit potential. Most tracks got an "Honorable Mention", and a few earned the rank of "Keep Trying". At least I didn't score so low as to be told to keep my day job.

It was night and day. "Your Gaze" first scored a 5.2 (Keep Trying), but the new mix scored an 8.9 (Platinum). "Silver Sting" first scored a 6.4 (Honorable Mention), but then scored 8.0 (Platinum) on the second try.

The final mix of the album earned five Platinum, two Gold and one Silver -- that is, eight of the 12 tracks have hit potential. (Not bad, eh?)

I uploaded most of Restraint, and it bears out my perception that the album is a sophomore slump -- three Platinum, two Gold and one Silver, a little less than half of the album.

The first time I used this site, all my songs seemed to hover around a score of six. I'm not sure what happened since the launch of uPlaya, but the analysis varied widely. My lowest scoring song is 4.0, while the highest scoring song is 8.9. I bet it's a combination of the mix and pitch correction. The 2007 mixes were really, really bad.

Of course, why should I put so much credence into a machine analysis of something as ephemeral as music? Isn't it about the song?

Well, I've got a solid analytical streak running through my creativity, and curiosity, more than anything, is reason enough for me to use uPlaya. (What a terrible name for a web site.) I wanted to see whether the machine could match my instinct.

As with most machines, garbage in, garbage out. In 2007, it told me the hit potential of my music, as it was back then. I got indignant when a song I felt would be a hit got a low score. Now that I've cleaned the mixes up, uPlaya got a better handle of my songs.

For the most part, it seems to pick out songs I had that "good feeling" about. It also surprises me a few times -- "All the Times I Remember" is really that good?

Of course, now I have to figure out how to leverage that information. High scores are nice ego boost, but they won't have much impact if I don't do more to get the songs out there.

Given my whole move to frameworks, I decided to try out a CSS framework, namely Blueprint. It was a paradigm shift for which I wasn't quite ready. I made the mistake of trying to use Blueprint to recreate an existing design. The final product looked ... odd. Rather, my eyes were so accustomed to how it has looked that I didn't see how else it could look.

I abandoned the idea and moved onto other projects.

When my sister asked me to build a web site for the daycare her son attends, I decided to use Blueprint rather than figure out all the minute details of the design myself. I whipped up something fairly decent in a couple of hours, and I was impressed -- Blueprint, like any good framework, sped up development time.

So I gave Blueprint another shot, this time in creating entirely new looks for my sites. I've spent the past two weeks moving everything to Blueprint. A few sites -- including this one -- did not undergo any redesign, but Blueprint does a nice job of cleaning up the layout. I did, however, make some very major changes to the Musicwhore.org family of sites.

(Speaking of color palettes, the Color Schemer desktop application rocks my world. When I'm less broke, I'm buying a license. In a pinch, I can always the Color Schemer Online.)

I've even gone so far as to incorporate white backgrounds into the sites. I dislike white backgrounds. They hurt my eyes. The majority of my sites -- including this one -- use dark backgrounds, but I think I use white backgrounds in the new designs sparingly enough to mitigate any discomfort.

I have to say, working with the grid layout has always been the one thing I missed about print page design. Back in my student newspaper editor days, I would be calculating points and picas, worrying about gutters and white space and text flow. The grid offered by Blueprint lets me space elements in a way that's consistent. I don't think I achieved that with my non-grid layouts.

Now I just have to use more semantic HTML, and I think my skill set will finally be up to date.

• I know you.
• I know of you.

Beyond that, I can't say I'm terribly interested. Yes, that flies in the face of the idea of "social media", but anyone who knows me can attest that my sociability has its limits.

I also have some very draconian criteria of whom I allow to follow me. I actually tend to block a lot of people, most of whom seem to gamble on the idea that if they follow me, I will follow them back. Here's what determines when I block Twitter followers:

• A following-to-follower ratio more than 2:1. Just now, I blocked a guy who was following more than 900 people but had only 169 followers himself. That rose a flag to me that he was trolling for another follower. I may let you slide if you have a manageable following count of fewer than 100.
• Following or follower counts in the thousands. I don't care if you think you can pay attention that many people. You can't. I'm doing you a favor by blocking you. I cannot in good conscience contribute to your attention deficit disorder. Also, I'm egoistical enough not to want to be lost in a stream of thousands of posts.
• SPAM. I do have to say Twitter has been very good at targeting mass followers.

Right now, I'm following 40 people, and I've got 50 people following me. I didn't block a few people because their profiles indicated some common interests, and maybe something I say will have some relevance to them. Only they could tell you.

But my stringent following and follower policies pretty much spares me from all the annoyances other Twitter users may experience. In the end, I use Twitter in a way it was probably intended -- as a means to communicate with a tight social circle. I like some of the ideas that have bootstrapped on to that premise, but I'm not a true believer.