This is the greatest music video ever. Hooray for the intertubes.
Category Archives: Web
Locker Room
June 1, 2008
Just as soon as we started describing Twitter as a micro-blogging/text-messaging tool, a well-oiled jealousy engine, and a scalable narcissism platform, it seems to have evolved into something beyond all that. Judging by my list of favorites, as well as those of others, Twitter has become a venue for sharing your profanity-laden sexual innuendo with a willing, self-selecting audience.
Not that I’m complaining. I’m just saying. I mean seriously, listen to the art that Twitter has made possible.
Wait, did I say innuendo? I meant penis.
Quantum Entanglement – Part II
May 11, 2008
This is Part II. Read Part I.
As I mentioned earlier, Siskiwit and Rosco were unintentional BFF. When I launched Rosco I wanted to preserve the link structure of Siskiwit, because people were still way into searchin’ for and diggin’ on that stuff.
Siskiwit had a long and colorful history of publishing platforms, but a number of years ago it settled on Movable Type, where it has remained ever since. Recently I tried upgrading its circa-2005 installation to the latest and freshest version, Movable Type 4.1, and I nearly fell out of my chair because it executed so flawlessly. Seriously, nothing went wrong. This made me realize that Siskiwit was far more portable than I gave it credit for, and I began strategizing on how to move it away from brainsideout.com/weblog and onto its own subdomain.
Up until recently, I have done all of my development on my server at DreamHost, hosting them at super-secret subdomains. The majority of my development cycle would involve launching Transmit, opening a file on the server in TextMate (or BBEdit if I need to do some heavy-duty regex), editing that file, saving it, and refreshing my browser window. I don’t know how many web designers work this way, but I’m willing to bet a fair amount of them.
If I’m installing a package of software (say, Movable Type or WordPress) I’ll often FTP into my server to upload the tarball or .zip file, SSH into my server to expand the file, and then return to Transmit to move the expanded folders and files to their proper locations. Ditto for large image directories, or other cases where I have multiple files to upload at once. All the goddamn handshaking that goes on with an FTP transfer makes it a horrible tool for uploading multiple files, and if your connection drops halfway through a transfer, it’s difficult to figure out what got copied successfully and what didn’t. I don’t know how many times I’ve been hosed by a file that appears to have transferred successfully, but turns out later to have been only a 0 KB placeholder.
This, this development process is dumb. I never realized how dumb until I started working with Jason, and we did all of our development in Subversion.
Subversion: Time Machine for Your Project
If you’ve never used a version control system you may have no idea what all the fuss is about. Once you’ve used one, though… no, once you’ve lived in one for a few weeks, you’ll wonder why everything in the world isn’t done this way. Seriously, everywhere I look now I see opportunities for version control. I wish I could rollback the street in front of my house, so I could drive on it at a moderate speed without bottoming out on this year’s crop of potholes. I wish I could form a branch for this day, which has been kind of cloudy and crummy but altogether windy, and see what would have happened if I chose to go kiteboarding instead of writing all afternoon. The planet? Sheesh, talk about something that needs to be loaded into Subversion, like, yesterday.
Subversion is a popular open-source version control system, which stores and tracks every change made to every folder and file that you load into it. Well, not every change, as it only tracks changes that you “commit” to it. Anywho, it’s like Time Machine for code. Your entire Time Machine drive would be called a “repository” in Subversion parlance, and every snapshot of your computer (or project) at a particular moment in time would be considered a “revision”.
Phew! Being a noob myself I’m in no place to teach you everything you need to know about version control with Subversion, but fortunately there’s an excellent book on that very subject. If nothing else you should read chapter one, which covers the fundamental concepts of version control, and shows some examples of Subversion in action.
If you’re used to developing on a web server, applying version control to your development requires a fundamental shift in practice. Fortunately, this shift is one that turns out to be rewarding in many ways, including speed of development, robustness of your code, and ease of deployability. Your Subversion repository lives in the cloud, so to speak, and you download, or “checkout”, the most recent revision to a folder on your local machine to do your work.
OS X Leopard has just about everything you could ever want in a web server already installed on it, including Subversion, Apache 2, mod_rewrite, PHP 5, Ruby, Ruby on Rails, and MySQL, so creating a local web development environment is a pretty straightforward deal. That said, a lot of these fixin’s aren’t enabled out of the box, and they will take a bit of mucking around to get running. You need to turn on mod_rewrite and PHP, you might want to upgrade Rails and other preinstalled Gems, and installing the MySQL preference pane might make your life easier. At a later date I’ll try to outline my experience of getting my own OS X development environment running. For now, just trust me.
A step-by-step manual for setting up your local machine for version-controlled development is outside the scope of this article, but at the very least I want to give you a cursory glance of what my current setup looks like. This all came into being within the last few weeks, but already it hands-down beats the knickers off Ghetto-Ass Subdomain Remote Web Server FTP Development.
Non-Ghetto-Ass Local Development
First off, if you need a Subversion repository look no further than Beanstalk, who definitely put the sexy in version control. Honestly, if my first time had been with anyone but Beanstalk, I would have sworn off the whole thing entirely, given the craptastic nature of most Subversion applications. Most host and client setups assume prior knowledge of Subversion, incredible technical aptitude, and hella-tolerance for lousiness. Beanstalk makes it really easy to import your initial project into Subversion, and offers a free account with up to 20 MB of space, which will be fine out of the gate unless you’re planning on working with tons of images. Or, perhaps, if you’re planning on using the SQL on Rails framework.
The cool thing with Subversion is that every time you commit a revision to your project, it doesn’t need to make new copies of all the files. It hardly even makes a copy of the updated files. Nay, it just tracks and records the changes within the files. Thus, a 2 MB project with 10 revisions will not weigh 20 MB. For instance, I have a current project where my working copy weighs 11.5 MB, but the repository (with 69 revisions already) only weighs 3.4 MB. Wow, that’s a surprise. I have no idea how that works, in that my working copy weighs more than the entire repository. Perhaps there’s some voodoo magic going on, but I’m not gonna argue!
Once you have a repository, you’ll probably want to install a Subversion client on your local machine to make it easier to interact with the repository. Subversion is built with the command-line in mind, but a lot of us don’t think that way. I’ve been using the svnX client for a number of months now, and while it’s incredibly goofy I believe it’s the best one available for OS X. You can configure it to connect to a repository, and then checkout a revision to make a working copy on your local machine.
Managing, hosting and testing multiple web design projects can be a pain, however, especially if you don’t want to muck around inside Apache’s httd.conf file. I use Headdress, a tiny application that helps you manage virtual hosts in OS X, to handle all of my local development websites. The free version of Headdress lets you host two sites simultaneously, and if you want to run more it’s a lousy $14.99.
Ahem. Welcome to your new workflow, where you edit your local working copy while testing it in a browser window. When you feel like you’ve reached a comfortable point in your development, or if you’re about to try something risky, go ahead and commit the changes you’ve made to your working copy to the repository. This is how I do it now. Edit locally, refresh locally. Edit locally, refresh locally. Time to fix another cup of tea? Commit all local changes to the repository as a new revision.
“What about launching? What about deploying? What good is all this work if no one can see it?” I’m glad you asked! I still maintain a number of super-secret subdomains, where I can test my development work directly on the web server that will ultimately host its production version. Remember, the working copy of your website on your local machine is just that: a copy from the repository. So long as you’ve committed all your changes, the exact same site exists inside the repository as the most recent revision of your project.
Deploying your site, whether it’s deploying on a testing domain or deploying for realz realz, is just a matter of “checking out” a fresh copy from the repository. This is pretty easy, so long as you have Subversion installed on your web server. I’ve found the easiest way to do this is to SSH into my server, navigate to the parent directory that holds the folder in which I would like to expand the copy, and using the svn checkout command to checkout the most recent revision from the repository into that folder. After I’ve done that, I can continue to freely edit my working copy on my local machine, and commit those changes to the repository, without worrying about messing up the copy on my web server.
Once I’m happy with some new changes I’ve made, however, it’s easy to bring the version on my web server up to speed. All I do is SSH into my server, navigate to the child directory into which I originally checked out the copy, and type svn update. Bam! Everything that was out-of-date is now up-to-date! It can certainly be a lot more complicated than this, which is why there are services like Capistrano that automate the deployment and updating process, but at its most basic this is what’s going on.
“Dammit, Dane!” you’re saying. “What about my database? What about my needs?” Indeed, to make this work well you need to have a database that your local working copy can connect to. Sometimes you can use a remote server, which is what I did until I found a better solution. Currently I run a few MySQL databases on my local OS X machine, which I connect to via localhost and manage through CocoaMySQL. Getting WordPress to connect to a local MySQL database took a bit of finagling, but a quick search revealed an easy solution.
Disentangling Siskiwit
So. I wanted to move Siskiwit, and each and every part of it, out of Brainside Out and onto its own domain. The fact that I was able to upgrade Movable Type made me realize that Siskiwit was likely more flexible and portable that I had thought. To test this theory, I created a new project on my local machine, did a fresh install of Movable Type on it, and imported its current MySQL database onto my local MySQL server.
After changing a few configuration files to reference the new local database, I told Movable Type to rebuild all the weblogs, which it did flawlessly after only a few initial hiccups. I had a few stray layout, design and container files that I had to bring down from the live server, but the amount of customization necessary to get the site working was minimal.
At this point, the old skool way of doing things would have been to wrap up my local copy of the site in a zip file, FTP it to its corresponding subdomain on the server, and SSH in and expand the file. As if! Instead I created a new Subversion project at Beanstalk and imported my local copy of Siskiwit as a starting revision. From there I SSH’d into my server and ran svn checkout to put a copy at its new subdomain. I changed a few configuration options to make the site reference its live MySQL server, had it rebuild all the weblog files, and it all worked like gravy.
It’s worth noting that I left all the “rebuilt” weblog files out of the Subversion repository, and I left out the actual Movable Type install as well. With the former, Movable Type creates the static rebuilt files based on the content in the database, so they’re completely unnecessary so long as Movable Type has a database to work with and rebuild from. With the latter, since I’m never going to edit the Movable Type system files there’s no need to keep them under version control, so I just uploaded the .zip to the server and expanded it.
Likewise, since my images directory for Siskiwit is pretty huge, and since I don’t plan on making any changes to it, I left it out of the repository as well. This can be some fairly subtle and complicated stuff, and I mention it just to be clear that it doesn’t make sense, nor is it necessarily advantageous, to store everything in version control. Your own mileage may vary.
Before nuking every last trace of Siskiwit from Brainside Out, I wanted to make sure that visitors accessing pages at their old locations (either through search engines or through a crazy-good memory) would be seamlessly redirected to the page’s new location at the site’s new subdomain. I did this by adding the following rule to my .htaccess file in the root of brainsideout.com:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(www\.)?brainsideout\.com$
RewriteCond %{REQUEST_URI} ^(/weblog|/photolog|/sundries|/classics|/av)
RewriteRule (.*) http://siskiwit.brainsideout.com/$1 [R=Permanent]I have a few more rules besides this one, but they relate to CodeIgniter and aren’t relevant here. Also, if you want to monkey with .htaccess files on your locally hosted OS X websites you’re going to have to turn on mod_rewrite. It’s a bit of a thing, but you probably won’t die trying to do it. Headdress does have a bad habit of occasionally overwriting changes that you’ve manually implemented in your httpd.conf, especially when you add or remove a site from within Headdress. Yeah. Good luck with that.
With Siskiwit under version control and relocated to its new subdomain, and Rosco versioned and backed up as well for some inexplicable reason, I was finally ready to nuke everything at brainsideout.com and deploy the new, CodeIgnited version. I SSH’d into the server, navigated to the corresponding directory, and with cautious fingers typed rm -Rv --preserve-root *.
I then left my computer and fixed myself a drink. Upon returning I checked, double-checked and triple-checked my work, and pressed return. Then, with a haste matched only by the files scurrying up my screen, I deployed the new edition of Brainside Out from the repository.
Spring is here, and comments are open.
That’s right, comments. It’s gonna be that kind of spring.
End Part II. Read Part I.
Quantum Entanglement – Part I
May 11, 2008
This is Part I. Read Part II.
Over the last few weeks I’ve been working diligently on a few personal web projects, and what you have in front of you now is the most recent incarnation of Daneomatic, which was launched last night. There’s also a new version of Brainside Out, which has already been puttering about the neighborhood for the last week or so.
The original plan was simply to rebuild Brainside Out, but I was so fancied with the results from that project that I felt compelled to bring it over to Daneomatic. The act of “porting” the design and integrating it into the slapdash theming engine of WordPress took more effort than I expected, but I still figure a three-day turnaround from naked idea to launch isn’t that bad a churn.
The Problem With Supermodels
While it was definitely a fun challenge to piece together, in the end I was never too fond of the previous redesign of Brainside Out, launched in 2006 and codenamed Rosco. It always felt too heavy, confining and noisy. I was aiming for a funky private jet with shag carpeting and a rotating bed, and I feel like I hit a threadbare middle seat in coach. What’s more, the previous site was built to drum up work for an independent business that has since been pushed mostly aside to make room for a full-time job. This particular event happened more than a year ago, and if there’s one thing that supermodels, pets and websites don’t thrive on, it’s neglect. Unless they’re sea monkeys. sea monkeys dig that neglect shit. Kate and I are so gonna get some sea monkeys when we move into our new place.
More insidiously, the files that drove the Rosco edition of Brainside Out were intertwined with those for Siskiwit, the previous-previous version that was a weblog of sorts, a culmination of all the writing and web design I had done since 2001. The two sites existed side-by-side, confusingly wrapped around each other in a suffocating embrace, one stiff and businesslike, and the other bent low with a millstone of archives around its neck.
With the repositioning of Brainside Out as a business it didn’t really make sense, nor would it have been worth the effort, to bring Siskiwit and its thousands of archives forward into the Rosco design. Daneomatic would carry forth the Brainside Out weblogging tradition, but with five years’ worth of blood, sweat and tears put toward its name (or rather names, for those with ancient memories) I wasn’t about to nuke Siskiwit’s archives.
And so it came to be that I erected a crude scaffold around Siskiwit, allowing me to leave it fully intact while supplanting its front-facing views with Rosco. This worked. This worked just fine, and it very well would have continued to work if I hadn’t been born such a wild and restless child.
Bootstrapping in Flip-Flops
For years, up until just recently, all the sites I’ve built have been propped up with a laughably crude, but impossibly handy, PHP bootstrapper of my own devising. Calling it a bootstrapper may be too generous, as it’s nothing more than a glorified include file. Despite its inelegance it filled that void between “static website” and “dynamic template engine” with remarkable effectiveness, to the point that there was never really any incentive to improve upon it.
I’m a control freak when it comes to file structures and resource hierarchies, and as a code snob I am loathe to subject myself to the default outputs (or, gasp, the default layouts) of anyone’s content management system. With my simple bootstrapper I could build and deploy a site extremely quickly, all the while putting everything precisely where I wanted it to be. I wasn’t about to adopt another convention until I discovered something that was remarkably better.
And then I discovered something remarkably better.
Something Remarkably Better
During SXSW I shared my experience with building Bixby Heart Dot Com (that’s B-I-X-B-Y Heart Dot Com) with the EllisLab folk, but unless you were one of the twenty people attending their open panel, this anecdote likely bears repeating.
Jake and I had limited time to work on the Bixby Heart project and we wanted to get it out the door in time for SXSW, so throughout our development process the focus was always on “light is right”. Jake is one of the most talented designers I know, and I’m a great front-end (and lousy back-end) developer. Thus, perhaps inevitably, Jake did all of the design and much of the front-end development, and it somehow fell to me to write the back-end code. Yikes.
I wrote all of Bixby Heart in PHP, and I felt I did a fairly decent job at it. I compartmentalized all my functions and fine-tuned them for robustness. In the interest of simplifying the development process, one of my earliest decisions was to use flat files, rather than a database, to store incoming data. Databases are one of the most fickle, insecure, time-consuming and misunderstood subjects of web design, and I wanted nothing to do with any of it. I figured if I sidestepped the issue it would just go away.
Boy was I wrong.
I set up a buffer flat file that intercepted incoming data, and rotated every few minutes on a cron to dump its contents into the primary flat file. At first it recorded boolean values for “bacon” or “juice”, and soon it recorded timestamps along with them. Then it recorded IDs to prevent writing the same entry multiple times. I’d parse the flat file with string compares, searching for tabs or newlines or what-have-you. I even set it up to increment through the contents of the flat file, in case it became so huge that the entire file couldn’t be held in memory at once.
It was when we actually wanted to do something with the data that it all fell apart. Display the number of bacons? How about the number of juices? Oh dude, how awesome would it be if we could graph the heart rate over time! Say, do we even know how to compute the current heart rate?
SXSW was in two days and I was at an absolute dead end. We were taking in test data but I couldn’t figure out how to work with it in any reasonable fashion. I tried tweaking the flat file setup. I tried setting up a database. I panicked, and even tried installing Pear DB. Before long the entire application was completely fucked up and I didn’t even have a working copy to roll back to. In a single night we went from having a semblance of an application to having an unmanageable rat’s nest of broken code. It could not be saved. I gave up. I gave the fuck up. I cried and screamed and pummeled at my pillow with tiny little fists.
And then I found CodeIgniter.
CodeIgniter is a lightweight MVC framework, brought to you live in PHP by the same guys who gave you ExpressionEngine. I had installed and tinkered with CodeIgniter before, and of all the application frameworks I had experimented with (CakePHP, Symfony, Django, Rails, etc.) it was by far the most clearly documented and easiest to install. It’s worth noting that the upcoming version of ExpressionEngine is written entirely in CodeIgniter, and it’s so hot it will make you cry. With less than 24 hours between us and SXSW, I realized that this was our best, and perhaps only, chance of finding a database class that would suit even our meager purposes.
I decided I would give it a shot, and eight hours later I had completely rewritten Bixby Heart in CodeIgniter. We had a fully-functional application to bring to SXSW. I built all the necessary database hooks, and Jake thusly grabbed them and wrote the front-end hotness. Before long we were soaked in whiskey and vodka, presenting Bixby Heart Dot Com to a private audience as we struggled to keep our balance in an RV lumbering through downtown Austin.
After that experience I decided any application, nay any website, that I built from thenceforth would be written in CodeIgniter or a suitable equivalent. I make a lousy zealot and thus am open to other options, but as an individual I have by far made the most progress working in CodeIgniter. When rebuilding the Big Winds website in Ruby on Rails I worked with Jason Ives, a talented local developer, but without his canny knowledge of server configurations, database schemas and all-around Ruby l33tness, I am but a lost little puppy.
And so it came to pass that the new version of Brainside Out is written in CodeIgniter. In its current state it’s skimpy as far as content goes, and I’m still debating how best to go about resolving that. The site still suffers from a modest identity crisis, especially since the majority of my web activity has moved offsite, but now it is far less confused than it was during the “is a business, is not a business” phase. More than anything, I needed to shrug off the yoke of all its legacy innards, and figure out an elegant way to store that stuff elsewhere.
And that, my friends, is our next story.
End Part I. Read Part II.
Travelog
March 23, 2008
After two weeks of leading a jet-setter lifestyle, crisscrossing the country in economy class, and enjoying only the finest plastic cups of Canada Dry, I have returned home. Ahh, Hood River, where all the postal clerks know my name, I have the EDGE network all to myself, and there are no more than two places to eat in town.
Having flown on no less than eight flights and two different air carriers over the last couple weeks, I feel I am in a position to accurately report on the current state of air travel in our nation. Here’s the gist of it: Fewer flights, packed flights, longer flights. It’s a totally awesome combination, considering that you are free now even from the in-flight burden of consuming a bag of three broken pretzels. As far as I can tell, air carriers are running fewer flights to most destinations, and packing all of their remaining flights to maximum capacity. Every one of my eight flights was completely full, with additional travelers on standby in case of no-shows.
Now, a completely full flight takes a ridiculously long time to plane and deplane, so one would think that this, combined with a record number of delayed flights, would result in a cascading disaster of lateness. Not so! It seems the air carriers have taken into account the additional time it takes to load up all that extra meat, and have padded their schedules accordingly. If the flight before yours takes an abnormally long time to deplane, and your flight takes an abnormally long time to board, you’ll still likely arrive at your destination “on time”, as the travel times between cities have been arbitrarily increased to allow for these delays.
If your flight happens to board quickly, however, it just means more time sitting on the tarmac, waiting for your takeoff window. The good news is, this allows you all sorts of extra time to peruse Sky Mall, which currently features such awesome products as a colon-shaped brownie tray, litter boxes for one-legged cats, and Taylor Fay.
So where, you ask, did I travel during all this? Two weeks ago I had an incredibly early flight out of Portland, so I spent the previous night at the La Quinta near the airport to take advantage of their “Park and Sleep and Fly and Sleep and Park and Fly and Park” program. Thanks to an utterly bizarre celestial alignment I drove to Portland State University that night, and caught up with a Hopkins friend who I hadn’t seen in over ten years.
The following morning I flew from Portland to Dallas, met up with my cohort Jake Ingman, and flew to Austin for the SXSW Interactive design conference. For the next five days we drank obscene amounts of liquor, fed Mark Bixby obscene amounts of bacon, and occasionally talked about interactive design. We also cruised around in RVs and ice cream trucks, got kicked out of bars, rode giant wooden unicorns, and established Awesometown, USA (population: You).
After all that (there is a whole lot more to “that” than mentioned so far) I flew from Austin to Dallas, where I had a five-hour layover until my flight back to Portland. After reaching Portland I didn’t even bother driving back to Hood River, because the following morning I had to catch a flight to Minneapolis. Instead I once again spent the night in a king-sized Tempur-Pedic bed at La Quinta Portland, still confused, drunk and disoriented from SXSW.
I met up with Kate at the Minneapolis airport and we flew to Detroit, an airport that is so utterly dominated by Northwest Airlines that in the baggage claim they have a sign that says, “Lost or damaged baggage? Then fuck you!” We took a shuttle to Enterprise Rent-A-Wreck, who sent us away with a Grand Caravan and five children who needed a ride to soccer practice, and we then drove to Ann Arbor to visit the University of Michigan.
We spent the next four days in Ann Arbor, meeting with our graduate programs and eating Silvio’s Organic Pizza and wandering through cemeteries, until deciding that we just weren’t far enough south and needed to travel to Indiana. We headed back to Detroit and traded in the Grand Caravan for a Chevy Rollerskate, a deathtrap of a car that gets 32 mpg and would likely get lodged under an SUV in a crash, and drove to Bloomington to see what Indiana University is all about.
Indiana University is all about rain and “hoosiers”. We know what rain is, and there is apparently a lot of it. As for the hoosier, no one seems quite sure what to make of that. Fortunately Bloomington is wrought with delicious Thai and Indian food, which is simultaneously foreign and familiar for both Kate and I. Bloomington is also far enough south that McDonald’s has sweet tea on the menu, the student union has a Chick-Fil-A in the basement, and Kate swears that she will pick up a drawl if we happen to go to school there.
The sun shown beautifully on the Red Lobster the day we left Bloomington. Bound for Detroit to catch our evening flight back to Minneapolis, we stopped in Ypsilanti just so we could say we had been there (it’s called the Sufjan effect). From Minneapolis my flight to Portland was delayed, but by that time it was already so late and I had flown so much, that you could have told me our plane was infested with flaming poisonous snakes and tiny clones of Samuel L. Jackson and it still wouldn’t have fazed me.
Upon reaching Portland I took a shuttle to the hotel, thought wistfully of a giant Swedish mattress, but resolved to collect my Subaru and make the dark drive back to Hood River. Eight flights and two weeks later, I stumbled through my front door at two o’clock in the morning.
Tamagotchi
December 18, 2007
I realize now that this whole writing thing brings with it an alarming clarity of thought, something I’ve sorely missed since I stopped doing it on a regular basis. I make no promises, but indeed this would be a good habit to cultivate again.
Part of the problem is that while I have been writing, recently it has been reduced to short impulsive bursts of ill consequence. Despite my best efforts, my online identity has been scattered to the four great corners of the web, each one a series of fragmented imagery and slacker poetry completely lacking in depth and cohesion. This I hope to resolve at some point, with a dangerous and whirring brass contraption, spherical in shape and bisected by an angry equator of spinning gears.
It may be a time until I am able to realize that vision. Perchance I will soon settle on a reasonable equivalent, all stitched together with web-based APIs and a custom Ruby on Rails application. The end result for you, dear reader, would be a centralized place to keep tabs on yours truly, as endearing a proposal as that may be. For the time being, however, it would behoove you to consult the following locales. Note that if you find this old news, please count yourself among the savvy and move along. My readership regularly spans seven decades, so there’s a broad range of experiences that must be properly accomodated.
Daneomatic – Yes, you are here. This is probably the last place on earth where I think about what I’m going to say before I say it. Even then, I still don’t ponder long enough that it would actually interfere with anything.
Flickr – I used to maintain my own photo galleries, until I realized that such an activity could be much more fun if I farmed it out to a third party. I still take photos (more than ever, actually) and the better ones end up here.
Twitter – This is where I (among others) sputter about what I’m doing with such a diarrhetic frequency. Rather than encouraging a Hemingway-esque efficiency of language, I believe Twitter has done more to ruin my motivation to write than anything else. Why write an intelligent, well-reasoned article when I can just complain about it in 140 characters or less? All told, the idea of an indexed and publicly searchable database of my daily business kinda creeps me out, and thus my updates are protected.
Tumblr – Quite recently I began noticing a gloomy fog settling over the Twittersphere, with everyone constantly complaining about everything. I certainly was not exempt from this characterization, so I started sliding more of my knee-jerk kvetches over to Tumblr in an effort to boost morale on Twitter.
I’ve since realized Tumblr’s near-limitless potential for immortalizing the flaws of others, and so I’ve been capturing software bugs and interface gaffes as I encounter them. It’s a project similar to that pursued by my woodwind professor while he was in college, when he made a tape consisting of every chipped note and flubbed rhythm in every professional classical recording he could find.
Brainside Out – This is my business, which is currently in sleep mode. I wrote here for years, but this ain’t where the action is these days.
Vimeo – If I shot more video in my life, this is where it would be.
Facebook – My irrational animosity towards this site becomes more rational with each passing headline. I have disabled all email notifications and so I go for weeks without reading my wall or responding to friends, and I’ve earned myself a special seat of unpopularity by refusing to install any number of asinine applications. I do not categorically disapprove of Facebook applications, however, as My Flickr does a reasonable job getting my photos listed, and TwitterSync posts my Twitter messages to Facebook with some predictability.
That said, Facebook is like a digital pet that constantly needs to be fed, entertained and scolded. My only reward for this labor is that every so often, it shits itself in fury.
