Tuesday, June 09, 2009
My graduation speech for my alma mater
Over the weekend, I put together a draft of the graduation speech I'm giving to my alma mater next monday, 20 years after I started high school. It took me three sittings to bang this out...I can write 3,000 words about sports in a hearbeat, churn out a business plan in a flash or whip together a lengthy anecdotal blog post so fast it'll make your head spin - but being emotionally neutral, the more sappy stuff take a lot out of me. so i took my time and let this evolve.
I did it as a series of vignettes that can be modularly added/removed for time purposes. I've been told I have 5 minutes to fill, but I plugged the speech into our teleprompter and it comes out to about 6:12.
Let me know what you think...criticism welcome! And if you're one of my classmates from SSHS '92, then print this out or share it with our classmates. It's as much for you as it is for the kids.
Appreciating Who You Are
Hello, Hafa Adai and good evening...my fellow Sharks.
It is truly an honor for me stand before you AND beside you, on this, your proudest moment. It doesn't matter that I'm twice your age, because tonight, and for all time, we now stand as equals. In a very short time, you'll officially be able to call yourselves "alumni of Simon Sanchez High School", a wonderful achievement to be sure.
I'd like to talk to you tonight not about where you're going, not the unique paths you've all certainly come from that got you here, but who you all have become. Many of you probably may not realize the truth that's been hiding in plain sight for the past four years, since you first set foot at Sanchez High. That you are - and will always be - Sharks.
When I was asked to speak to the Class of '09, I was incredibly moved. I was humbled at being given the chance to not only honor my alma mater and bring some laughter and inspiration to the great young minds of tomorrow...but to also be able to represent MY classmates; and pass down our experience, our knowledge and our motivations to you. You see...that's truly what it means to be a Shark. Let me explain.
In a competitive context, the personification of our school spirit is naturally often characterized as being predatory, aggressive, keenly-sensed, and second-to-none in our ability to dominate our environment. That certainly works for sports and extra-curricular activities, because as anyone clearly knows, it's quite frankly a completely moronic argument to challenge that Sanchez has hands-down THE BEST MASCOT ON GUAM!
But there's another, more critical dimension about these majestic creatures that perfectly describes how we take care of business in the classroom and how we conduct ourselves in society - Sharks survive. Sharks adapt. Sharks are highly respected. Sharks finish what they start. Sharks stand their ground. Sharks are among the most highly-intelligent members of the animal kingdom. Sharks are everywhere.
And that is how we, your predecessors, carry ourselves everyday as members of the prestigious fraternity you're all about to join. It's a legacy we're proud to uphold - and this is the legacy I'm now extremely honored, on behalf of my fellow alumni, to pass onto you.
And make no mistake, my Sharks: your ability to earn the right to sit here before your friends, family and the community is proof positive that you can do anything in this world. And no one, ever, can take this moment away from you.
<><><><><><><><><>
The burden of an alumnus is the unspoken promise that you'll be the best member of the community you possibly can. Demonstrate good character. Always put others before yourself. Be confident, but humble. Don't back down from any challenge, no matter how daunting. Honor your family and your faith. Respect those who came before you and appreciate the lessons they have to teach. Help the next generation. Give back to Guam, and always do your very best to make the island the very best it can be. That's the mark of a Sanchez graduate. It's not easy, and it's a commitment that's lifelong.
But it's a true honor...and this is the honor that you've worked for all your life. And tonight, that honor is finally yours.
<><><><><><><><><>
I represent a graduating class that two decades ago this fall started out our high school journey, both collectively and individually. The Mighty Class of 1992. 17 years ago, my classmates and I, some 202 strong (which at the time was a Sanchez record), sat in our caps and gowns as you do now - some anxious, some nervous, some relieved, some fidgety, some hungry, some bored, some unable to wait for it to be over, some scared out of our minds.
But like true Sharks, we all persevered.
Now, I won't gloss over the truth. While most of my classmates have happily raised families, found success in business, defend our nation's liberties on the battlefield, serve in government, keep our streets safe, and fight to rid the world of disease...some forgot who they were and lost their way. Some right now are sitting in jail, tormented by regret. Some are in deep battles with drug and alcohol addictions. Some lie in mainland medical facilities enduring indescribable pain. And some are no longer with us at all.
That's the brutal reality of life, my friends. And that's how society seeks to categorize each and every one of us: not as a Shark, but merely a number. A statistic. A figure.
So I challenge you tonight and for the rest of your time on Earth to rise above such expectations. Realize who you have become AND the responsibility you now carry. Be the best always, and in everything you do. Walk tall. Be a strong Guamanian. Be a Shark.
<><><><><><><><><>
So even though you've most assuredly got plans with friends and family, I would humbly ask you, my fellow Sharks, to do something tonight. Do this one simple thing, not for your families, ot for your classmates, not for the alumni...do this exclusively for yourselves: before you embark on your celebrations tonight, go somewhere quiet and alone. Spend a few moments in silence and just look at your diploma. Reflect on the last four years of you life, recognizing all the dedication, sacrifice, commitment, self-discipline and devotion to your education and the hard work you've put in.
Think about your first steps on the Yigo campus, remember how big the buildings seemed, how lost you were, how you only knew a few people. And then think about the class activities you got involved in, the friendships you've forged, the teachers that mentored you, how underclassmen went to you for your expertise, how you knew everyone in your class and everyone knew you.
I ask that you do this because I did this the night I graduated, and it made all the difference in the world. It helped remind me that my school years may have ended, but more importantly that a new chapter in my life was just beginning. And it galvanized who I had become.
And I believe it'll have the same effect for you.
<><><><><><><><><>
So while a very demanding, very competitive and at times very cruel world lay ahead, let me leave you with this: don't ever stop believing in yourselves. By completing your high school education, you've now proven to the entire world - but most importantly, to yourselves - that you're capable of doing anything. Don't stop learning, working, or questioning. Be not nobody.
Go into whatever walk of life you take interest in and do it with pride. Wear your school colors proudly, and never forget who you are. You are a graduate of Simon Sanchez High. You are a Shark.
<><><><><><><><><>
So on behalf of the thousands of Sharks throughout the world, I say welcome to our ranks. We're extremely proud of you, we celebrate your achievement, we love you, we stand ready to help you as fellow graduates of this wonderful school, and we expect you to do the same for future Sanchez High classes.
So congratulations, my friends! This night is yours. And always, always conduct yourselves as Sharks.
Thank you.
Monday, June 01, 2009
My commencement speech intro (aka, The Old Testament)
I mentioned on Twitter several weeks ago how I was hoping to involve crowdsourcing feedback into the commencement speech I've been asked to give at my alma mater's graduation ceremony on the 15th. I've since been asked to whittle it down to five minutes, but to also do a lengthy intro (that's public school for you).
Have at it...comments/criticism welcome. Rather than be stuffy, I'd prefer to do something to make the kids laugh.
Delivering tonight's keynote address is a proud alumnus of Sanchez High, Mr. Jason Salas.
Jason is best known in the Guam community for his work at KUAM, where he works as interactive media manager, overseeing all aspects of the company's digital content delivery efforts. Over the last decade he's co-anchored the nightly 6pm news with Sabrina Salas Matanane, done play-by-play for local sports broadcasts, and hosted numerous shows and programs on television, on the radio and online.
He also continues his life's work of helping Guamanians improve their lives through technology, having launched several spinoff projects to this end.
Having grown up in Dededo in Ypaopao Estates as the eldest child of two educators, Jason graduated from the Home of the Sharks in 1992. He was a four-year cadet in the Shark JROTC battalion, serving as color guard commander and battalion commander his senior year. He played middle blocker for our boys volleyball team (although a broken wrist kept him from seeing any on-court action his last season). He was heavily involved in class activities, extra-curricular events, and was an avid high school sports fan. He even came back after graduating to help coach the volleyball teams.
Jason was an honors student and graduated near the top of his class of 202 students, excelling at math and English; despite this, he was absolutely horrendous at science and often fell asleep in government class. He was voted duke of his senior prom, and his yearbook lists his senior superlative as "Worst Jokes", a well-deserved moniker he remains proud of to this day.
He wore his letterman's jacket to school as often as he could. He also doesn't hesitate to give Sanchez High a shameless on-air plug whenever he calls a game.
After high school, he earned a marketing degree from the University of Guam and also studied music theory. He later put himself through graduate school and holds an MBA with emphasis in technology management. He's a self-taught software developer and a passionate part-time musician.
Despite the various paths his career has taken him, he always remained true to his alma mater. He credits the tightness and camaraderie between his classmates as a major driving factor towards his success, and he and his fellow alumni remain lifelong friends. He kept his graduation tassel hanging from his car's rear-view mirror for three years, even after Guam's searing heat faded its proud silver & black colors.
He very happily returns to his alma mater to speak to tonight's graduates on the topic of "Appreciating Where You Came From". Ladies and gentlemen, please join me in welcoming Class of '92 graduate...Jason Salas.
(...and the crowd, assuming they're still awake by this point, goes wild.)
Friday, May 22, 2009
Hacking @guamtweetbot: writing a Twitter Search service
While sitting at home last night I had an idea about creating a localized service that archives all posts on Twitter having to do
with Guam. Like most other markets, Twitter's really taken off on Guam, and the number of posts about our little island, from locals and other people alike, is surging tremendously. So the need existed to perpetuate the thoughts of those taking an interest in my hometown, and give the micromessages a little more press and some extra time in the limelight.
I set out to achieve four main goals, building-out a little autonomous service that would:
- Troll for new tweets having to do with Guam
- Harvest and retweet all found posts
- Set this to run at a scheduled interval so to mirror the posts as they're appearing in the statusphere in near-realtime
- Follow the user that posted a new entry
So last night, inspired after a pretty healthy hot fudge sundae, I wrote a bot in PHP that makes calls against the
Twitter Search API, extracting tweets containing the string "
guam" and re-posting them to the
@guamtweetbot timeline. A variation of the RESTful URL called
is here.
I setup the process to run as a CRON job on my Ubuntu Linux server, using wget to execute the script (since PHP's compiled for Apache, not as a CGI module):
*/20 * * * * wget -O /dev/null <path to PHP script>
This is actually a prototype for a much larger platform I'm building for KUAM, which we're going to use with our news broadcasts. But it certainly has
generated some nice feedback from the community.
Plan your code, code your plan. Creating value for others - not a bad way to spend a Thursday evening, huh?
Tuesday, April 21, 2009
TwitterNeni's a go!
Hey Guammies! I'm very pleased to report that
Will and I got our new SMS gateway up and online so local Twitter users can post tweets via text messaging. We're currently in beta testing, so give it a spin and see if it works for you.
This is a perfect way for Guamanians that still have 2G non-smartphones to get with the social networking revolution. It's completely free, so
let us know what you think.
Tuesday, April 14, 2009
One-night gig: set-list
My friend
Andy was
nice enough to offer to let me sit-in with one of the many bands he plays bass with for
a birthday wish I had to play lead one more (and probably last) time. I'm looking over the set list he sent me, and while it's decidely more 90's than the 80's cheese I was shooting for, there are several pieces I know and could probably pull off without giving myself
CTS in the process.
In my naive quest to reclaim my youth and do the Fretboard Olympics, I'm reminded that there's nothing wrong with some 3-chord singalongs. Can't go wrong with RHCP or 311...it'll be fun no matter what.
What do you think?
3 DOORS DOWN – KRYPTONITE
3 DOORS DOWN – LOSER
3 DOORS DOWN – WHEN I’M GONE
311 – ALL MIXED UP
311 – AMBER
311 – BEAUTIFUL DISASTER
311 – COME ORIGINAL
311 – DOWN
311 – FIRST STRAW
311 – FLOWING
311 – I’LL BE HERE A WHILE
311 – PRISONER
311 – PURPOSE
311 – YWB
311/THE CURE – LOVE SONG
AUDIOSLAVE – LIKE A STONE
BLINK 182 – ALL THE SMALL THINGS
BLINK 182 – MUTT
BLINK 182 – WHATS MY AGE AGAIN
BUSH – COME DOWN
BUSH – MACHINEHEAD
CAKE – I WILL SURVIVE
CREED – ARMS WIDE OPEN
CREED – MY SACRIFICE
CUSTOM – HEY MISTER
DAVE MATHEWS – SATELLITE
FOO FIGHTERS – EVERLONG
FOO FIGHTERS – HERO
FOO FIGHTERS – LEARN TO FLY
FUEL – BAD DAY
GODSMACK – WHATEVER
GREEN DAY – BASKET CASE
GREEN DAY – LONGVIEW
GREEN DAY – SHE
GREEN DAY – WELCOME TO PARADISE
HOMEGROWN – SURFER GIRL
HOUSE OF PAIN – JUMP AROUND
INCUBUS – DRIVE
INCUBUS – NICE TO KNOW YOU
INCUBUS – TALK SHOW ON MUTE
JIMMY EAT WORLD – THE MIDDLE
JIMMYS CHICKEN SHACK – DO RIGHT
LIFEHOUSE – HANGIN BY A MOMENT
LIMP BIZ – BREAK STUFF
LIMP BIZ – FAITH
LIMP BIZ – ROLLIN
LIT – MISERABLE
MARCY PLAYGROUND – SEX & CANDY
MODERN ENGLISH – ILL STOP THE WORLD
MODEST MOUSE – FLOAT ON
NIRVANA – IN BLOOM
OASIS – CHAMPAGNE SUPERNOVA
OASIS – WONDERWALL
PEARL JAM – ALIVE
PEARL JAM – BETTERMAN
PEARL JAM – BLACK
PEARL JAM – YELLOW LEDBETTER
POISON – EVERY ROSE
PRES OF US – LUMP
PUDDLE OF MUD – SHE HATES ME
RADIOHEAD – CREEP
RAGE – KILLING
RAMONES – SEDATED
RANCID – RUBY SOHO
RANCID – TIME BOMB
RHCP – AROUND THE WORLD
RHCP – BY THE WAY
RHCP – CAN’T STOP
RHCP – OTHERSIDE
RHCP – ROLLING SLY STONE
RHCP – SOUL 2 SQUEEZE
RHCP – UNDER THE BRIDGE
RHCP – ZEPHYR SONG
SEVEN MARY THREE – CUMBERSOME
SIFL & OLLY – WHATEVA
SOAD – AERIALS
STAIND – FOR YOU
STAIND – IT’S BEEN A WHILE
STAIND – OUTSIDE
STP – INTERSTATE LOVE SONG
STP – PLUSH
STROKE 9 – LITTLE BLACK BACKPACK
SUBLIME – BADFISH
SUBLIME – CARESS ME DOWN
SUBLIME – SANTERIA
SUBLIME – SMOKE 2 JOINTS
SUBLIME – WHAT I GOT
SUBLIME – WRONG WAY
THE CALLING – WHEREVER YOU WILL GO
THE CURE – JUST LIKE HEAVEN
THE FLYS – GOT YOU
THE STROKES – LAST NIGHT
THIRD EYE BLINE – SEMICHARMED
UNWRITTEN LAW – SEEIN RED
VIOLENT FEMMES – BLISTER
WEEZER – BEVERLY HILLS
WEEZER – ISLAND IN THE SUN
WEEZER – PERFECT SITUATION
WEEZER – SAY IT AIN’T SO
WEEZER – SWEATER
WHITE STRIPES – 7 NATION ARMY
Wednesday, April 01, 2009
One night gig - my birthday playlist
So I've got a birthday coming up at the end of the month. And while I'm not normally all about celebrating the occasion personally (I've always found it odd how my parents do things for me instead of the other way around, considering they gave me life), I'm hoping to ring in my 35th year of existence by gigging with someone. Anyone. As long as they can play.
So while I dust off my dexterity and try to get my chops back up to their proper shredding form, here's my tentative working setlist of what I'd like to perform:
- Rush - Tom Sawyer
- Metallica - Master of Puppets
- Still Got the Blues for You - Gary Moore
- Ozzy Osbourne - Bark at the Moon
- Dokken - In My Dreams
- Kiss - Hide Your Heart
- Kajagoogoo - Too Shy Shy
- Asia - Heat of the Moment
- Nelson - Only Time Will Tell
- Queensryche - Eyes of A Stranger
- Yngwie Malmsteen - You Don't Remember, I'll Never Forget
- Lynryd Skynyrd - Gimme Three Steps
I'm still fortunate to have a few cats in the music scene who call me friend, so we'll see about who's daring enough to give me a shot. I'd consider it a great birthday gift to just share the stage with talented players who enjoy this stuff as much as I do.
If you can make it out that night, do try - I may rock, I may fall flat on my face. But it'll be fun...for all of us.
Saturday, March 14, 2009
Introducing...Twitter Tactics!
I had a conversation recently with a local friend on Guam who's a fairweather 'netizen, and as such a modest user of social apps. She's happily on Facebook, so when I asked her why I couldn't find her on Twitter, "Oh, I can't do that one...it's way too hard!" was her shocking reply. This galvanized my motivation to start work on a tiered series of services for locals to use the platform.
I want to interactively show people how to REALLY use Twitter. Like in ways you've probably never heard of. Like in ways that would blow your mind. Like in ways that can streamline your operations. Like in ways that can make you money. (Yes, Twitter.)
So
Will and I have cobbled together and refined a framework of ideas that we're collectively calling
Twitter Tactics. The capstone is an interactive 1-day workshop with distinct tracks for beginners and advanced users, showing you how to get the most out of micromessaging. Here's the premise of our objectives:
- Make Twitter-via-texting work for Guam users. Because Guam's SMS infrastructure and carrier interoperability with web-based services nearly never work as designed (Twitter included), we've taken it upon ourselves to develop a custom gateway to facilitate users posting tweets to their account via text messaging. This would work exactly the same as other international users.
- Offer a downloadable topic track bot for BlackBerry. Because of legal limitations, the iPhone hasn't officially dropped on Guam yet. So with RIM's BlackBerry being the dominant smartphone locally, we're going to hack a mobile service that watches Twitter's stream of messages on your behalf and tracking topics you specify. When matching messages are posted by any other Twitter user - even those you're not following - you get the tweet pushed to your handset...in real-time! It's a really cool way to stay informed of the things that interest you, discover new people and make friends based on shared interests. And because we're open source advocates, the app's free to download with the source code being totally extensible. And despite the fact that these high-end mobile phones are admittedly in pretty small deployment (several hundred at the moment, at best), users with iPod Touches, Internet-aware applicances and/or legacy cellular devices can still interact via SMS, as noted above.
- Host a two-phase workshop. Why would anyone want to attend a training session in informing people of their status? That's precisely the point: the Twitter ecosystem goes way deeper than just telling people what you're doind, and we want to show you. The Beginning Course deals with all activities from signup-to-signin, customizing the UI, Twitter etiquette, growing your followerbase and more. The Advanced Course is for power users who want to take their game to the next level, integrate platforms, build custom micromessaging clients, and really explore the platform. We'll also show businesses, government and organizations how to use micromessaging productively for their operations. The whole session will be 100% interactive, with the facility having totally free Wi-Fi and liveblogging, shooting/streaming video, sharing, texting and crowdsourcing all highly encouraged throughout the event. Because again, that's the nature of social networking.
So that's it. My muse saw fit to slap me upside the head with this gem earlier in the week, and it all came together in about an hour over McNuggets. Building the whole thing out's going to be fun...but not as fun as helping connect people with technology and seeing how they use it for themselves.
We'll both be posting our progress through the phases of the project. Here we go!
Wednesday, March 04, 2009
The curious case of the Real-Time Web
eConsultancy's got a really intriguing article denouncing the need for a real-time web.
I very much enjoyed it and the author's stance is certainly valid, undoubtedly
shared by many.
It's led to several
passionate responses within the blogosphere.
Ever the contrarian, I'd like to speak in defense of real-time online experiences (to be understood as those involving the Web, desktop applications, mobile devices, e-mail, RIAs, texting, instant messaging, Internet-aware appliances and otherwise), shedding light on why the direction we all know the delivery of content and information is inevitably heading is so critical. I'm speaking specifically from the perspective of the broadcast news industry, as ours is a perfect case study to prove the worth of such systems such that other lines of work might follow suit with their own respective implementations.
Very necessary
I'm highly in support of ushering-in push-based methods of delivering content to user at a near-real-time pulse. I'll admit my selfishness: working in a multiplatform/multimedia/multidevice business that's more and more these days predicated on responsiveness over authoritativeness, credibility has taken a backseat to time-to-market. So if someone else out there has stuff to tell people - a direct rival news source, a citizen journalist with a devout following, or simply a (micro)blogger - they're taking away eyeballs that I could have. They're cutting into my attentionspace.
If I've got content to distribute, it's not enough anymore for me to update my site and expect people to manually browse to it, or to send out news alerts and only after people check their messaging accounts expect them to flock, or wait for their feedreaders to modify their subscriptions. I've got stuff and I need to let you know as quickly as I can, lest you find out from someone else.
Such is the sense of urgency with which we in the news game have to operate, because it's better for competition, better for the user and better for the technological landscape overall.
Why the lag?
To date there's always been an acceptable disconnect in communicating online, so much so that such latency has sadly become accepted as the norm. This was largely because of a lack of supporting infrastructure over which to send/receive data - available bandwidth, affordable consumer technology, meager public awareness, and the Internet being a medium confined to desktop-only access - in addition to the event-dependent request/response nature of HTTP.
Even the traditional mechanism of "evolving platforms" like notifications via SMS and e-mail are still subject to a lag that the unwashed masses tolerate. Think about the Answering Machine Analogy: how inconvenient and difficult would it be if every phone conversation you engaged in saw you and your distant-end party exchange messages exclusively over voicemail? The staggered nature of such communications is ridiculous, and yet we're happy with doing just that via e-mail.
Today we're getting close - very close - to mirroring the experience of actual human conversation. And this needs to be seen by society as (1) an augmenting option to the static retrieval process of information we're used to, and (2) a good and positive thing.
The game's a-changin'
As a user, if I can be informed about a developing event the source matters less to me than in years past. I don't put so much value anymore on whether whoever authored a report or posted a thought that's 140 characters or less has won an Emmy or Pulitzer Prize. It's the nature of being informed that I'm after. If I want the full details about a report, I'll seek out the offering from an established leader.
CNN no longer holds a monopoly on controlling what people know about the world. And more importantly, when they know it.
To the ad hominem challenge of user-generated content: there's always going to be a market for well-produced information products...assuming the mainstream media gets its act together and stays proactive to compete with grassroots applications while leveraging the quality composition and credibility its known for. To date, that's not largely been the case. Corporate media powerhouses, newspapers in particular, have traditionally displayed a hubris towards emerging technologies that's let them fall several lengths behind the rest of the field.
! GEEK ALERT !
Asynchronously pushing content to subscribed users, an evolved method of the traditional interval-based polling technique used across online properties, is THE pattern developers are salivating over these days. XMPP is a well-defined, established, flexible technology stack that avoids the inefficiencies of making unnecessary repeat system roundtrips that are at best highly wasteful of network resources and at worst an emulated DDoS attack. Expect a lot of mainstream traction in this space.
Granted, filtering posts through the Twitter Search API via a client-side track bot is a technical process that's not exactly easy for the layman to grasp, much less setup. So there's much work ahead in terms of making the tools easy to use to achieve this experience. We faced the same challenges five years ago when podcasting really took off in the technical substrate, with a solution needed to make single-click subscription to RSS feeds a reality to open up the platform to the greater worldwide community.
But the groundwork's been laid and the technology exists to make it possible.
I also see people retrofitting real-time delivery models within existing platforms beyond the World Wide Web. The perfect candidate for such migration is e-mail, that tried-and-true killer app. Once you've drank from the real-time well, waiting around for messages to be aggregated and downloaded is a nuisance, as you're now cognizant of the fact that you're not truly reading notes as they're being sent to you. I've spoken to a developer who's planning to embed the open source Jabber engine within a custom SMTP transport for delivery of electronic mail, sans delay.
The demand for real-time mail clients, in addition to a call for XMPP support within browsers, is going to thrive.
How about the Mothership?
Another perspective to consider is that of Google, the bastion of all things Internet-related. Their main search index has been chastised for not being "real-time friendly", only listing stored documents in the historical Web. But consider what the company did years ago when launching Google News.
The pilot project crawled a distinct subset of networks, affiliates and news services so rapidly it was able to provide results mere minutes after its network of publishers updated their sites with new content. The trend we're now seeing is that the company is starting to leverage that innovation towards the Web at-large, timestamping new pages it crawls not too long after they've been added online.
Google could also conceivably incorporate real-time notifications into Gmail, building out an XMPP architecture supporting pushed alerts triggered by the presence of newly-arrived messages. And a new Firefox add-on is all the rage at the moment, displaying tweets related to Google search queries in quasi-real-time. So the demand for real-time information is certainly there.
Each of these concepts, applied at Google's scale, has huge implications.
And my point is...?
In short, the Web is becoming what it's never been before - a helluva lot faster. This is meaningful because it could be the first major form of media to achieve multi-format interactivity at a near-synchronized rate. This is a larger achievement than most realize and are willing to accept.
So here's the long and the short of it all: if real-time experiences aren't your cup of tea, that's fine. Such will function as a valuable extension of the current method of disseminating information. There's work ahead that we in the development community have cut out for ourselves in building tools to filter data coming across the wire so that people can only get what they want, or people not interested in such processes at all won't be bothered. The World Wide Web will continue to exist as society's largest repository of historical data, replete with tools to search, filter, discover and create content.
The Web's IP-based cousins will continue to support their own methods of managing the data you crave so desperately, with IM getting a particular share of the limelight. It's nabbing items coming down the pike and doing neat things with them that's the impetus of so much interest here. Moving towards delivering content in near-real-time is a natural evolution of the Web as we know it.
We all knew it was heading this way. So integrate it, love it, oppose it, ignore it, or fall head over heels for it - just don't deny it a place at the table.
**UPDATE**
Just mere hours after posting this article, Facebook announced their low-latency web updates capabilities, and big revelations were made at DrupalCon in regards to XMPP support. Now with major players behind them, more people will hopefully be exposed to the benefits of instantaneous data, and begin to get it.
7 Questions for Tourneytopia
Tourneytopia, a company out of Grand Rapids, Michigan, produces an ASP.NET control and a hosted application that manages and provides alerts for sports tournaments and other types of bracket-based data. The service is incredibly flexible and customizable, providing numerous options in letting developers and users track their teams in applications like the NCAA College Basketball March Madness tournament, poker, battles of the bands, Wimbledon, and more.
Lead developer
Joel Ross talked with me about how his idea has progressed over the years.
1. Early versions of your custom server control leveraged a ton of JavaScript to manage the progression of teams advancing or eliminated from a tournament. What steps have you made to ease the top-heavy payload on the client, or is this even an issue? We've had exactly 0 complaints about the heavy usage of Javascript with the
Tourney Bracket Control. The biggest complaint we got early on was that it was slow. We alleviated a lot of that when we moved to a div-based layout in Version 2. The Javascript was also moved to an external resource, so it gets cached now. Surprisingly, the Javascript hasn't had a significant change since we first wrote it. We've considered revamping it with jQuery, but it's tough to justify a huge change like that when the current method works so well.
2. From personal experience, mapping out an abstract programmatic framework for sports applications is tough, given the variations in rules, formats, scoring, etc. How did you take a generic approach to developing a control that's applicable in so many different venues? Can Tourneytopia tackle the headaches of double-round-robin formats?
Our biggest task early on with the Tourney Bracket Control was to figure out how brackets can be built based solely from the number of teams involved. Building in that flexibility was time-consuming and painful, but doing it right up-front has paid dividends - without it, we would never have been able to handle the tournaments that The Tennis Channel runs - they have brackets with 48, 64, 96, and 128 players. So far, we haven't ventured away from bracket-based contests, so the round robin formats are out right now. There hasn't been a lot of demand for us to deviate, so we haven't. That's not to say we're against branching out - a confidence pool is something we're strongly considering adding over the summer.
3. One of your first high-profile clients was Playboy.com. What did the exposure do for your business, and what's been the most-requested feature from customers and users to this point?
Actually, Playboy.com was our very first paying customer. Being able to prominently highlight them on our website immediately established us as a reputable company. Regardless of your thoughts about what Playboy produces, they are a well-known brand and if they're willing to put their name on something, it gives people confidence in that service.
4. What version of the .NET Framework is Tourneytopia running as its codebase now, and what were the most dramatic and/or challenging aspects of migrating through the various phases of Microsoft's platforms?
Tourneytopia runs on .NET 3.5 with a SQL Server 2005 back-end. It actually started as a classic ASP application written to manage the office pool where
Brian, my business partner, and I both worked. Before launching Tourney Logic, we ported it to ASP.NET. At one point, it was a redistributable application that anyone could install on their own servers. Publishing a software package turned out to be a major challenge, and after a couple of years, we turned it into a hosted service. Switching from a system that was meant to run a single pool to one that could handle thousands of pools was a pretty big change for us. We learned a lot about scaling applications - we're still learning, actually!
5. Conventional logic (or just blind assumption) leads me to believe that you're heading towards implementing Web 2.0 principles and make your service applicable to mobile users with a serious social slant. Your thoughts?
Thanks to
you pointing out Web Hooks to us, we're looking at what it will take to let our users use our services in their own applications. We've eyed a Facebook application for Tourneytopia for a while, and adding a mobile interface has been on our roadmap for a long time. For both Brian and I, this is an evening and weekend gig, so our biggest issue is finding the time and prioritizing what we want to get done.
6. Aside from the primary target audience, have your customers retrofitted your control in other industries or applications, like political events, family trees, etc.?
We actually were contacted this week about using Tourneytopia for a gubenatorial election contest, and we've had a few radio stations run "Battle of the Bands" contests. Someone used myPlayoffs.com to run a "Best Movie" bracket, as well.
7. With the UI being historically rendered HTML, have you considered evolving the UI for Tourneytopia to be a richer client, say, one based on Silverlight or Flash?
Given that we're both primarily .NET developers, Silverlight would be the natural progression for us. I'd love to see a much more interactive bracket with a Silverlight UI, but at this point, the penetration is a bit low, and again, time is our enemy.
Thanks Joel, and good luck!
Past interviews:
Saturday, February 28, 2009
Web Hooks & XMPP - right tool for the right job
Software developers and system architects, whether they know it or not, are approaching a rather intriguing crossroads of possibilities in terms of achieving efficient data exchange and creating compelling user real-time experiences. Two established platforms - the event-driven callbacks method of the aptly-named Web Hooks and the bandwidth-friendly federated communications of the eXtensible Messaging and Presence Protocol (XMPP) - are rapidly emerging as major players for managing proper communications across the Internet.
It's important to know the strengths and benefits of each technology and recognize which technique is best suited to achieve your objectives. So let's consider each platform's effectiveness.
Scalability
Anytime a Web Hooks and XMPP discussion arises, scalability is typically the first criterion challenged. Politics notwithstanding, the general consensus seems to favor XMPP for rapid-fire, high-volume, push-based traffic. Web Hooks on the other hand stake a strong claim in scenarios seeing smaller, less frequent calls to public APIs. The time-tested web growth strategy to create server farms, server gardens, utilize edge computing or to go the cloud route all exist and are applicable for callbacks.
Yet opinions still vary on exactly how scalable XMPP-based stacks might truly be, noting performance and latency concerns in cases where servers have to manage massively large rosters in IM applications - Twitter's May 2008 removal of its XMPP firehose data stream being the canonical example. MetaJack suggests such cases as being candidate for componentized or S2S bot design, as opposed to the bot-as-client method so often used.
Load Balancing
Not many, if any, case studies or formal patterns are in existence to guide us in designing well-tuned networks in cases of XMPP applications. Again, the decision tree on whether to scale up or scale out in Web Hooks scenarios, based on the number of requests against a server, is well documented. The most important thing to remember when comparing XMPP and HTTP stacks is that the traffic levels are different - the former being low-bandwidth push of XML fragments to users based on availability, the latter being the traditional request/response method.
Cost
With Web Hooks relying on a URL registering a server script to an event on a remote application, a web server with appropriate platform support/permissions is all that's needed to get up and running. Most people can put their own development web servers online, and free services like AppJet and GitHub exist for no-cost script authoring/storage, but are subject to downtime and other inconveniences common to third-party hosting. Conversely, free open source Jabber servers and clients are legion but are arguably more difficult to setup than Apache or IIS. And hosted services for instant messaging like Jabber.org and Google Talk have historically throttled clients incurring heavy loads (i.e., Gnip's main gripe). The Pownce team postulated that clients running their own web servers will greatly outnumber those maintaining XMPP servers.
Speed/Efficiency
XMPP's redeeming quality is its efficient use of network resources, sending small messages only to those clients who are capable of receiving them at that moment, as well as supporting out-of-band communications for larger payloads like voice and video. But the feature is largely limited to messaging. Callbacks can perform whatever functionality you program them to do, with the tradeoff being variable consumption levels of bandwidth, memory and processing cycles. So there's the rub.
Reliability
Yahoo! has stated that a major architectural dealbreaker in choosing pure XMPP PubSub over Web Hooks for its Fire Eagle real-time geolocation service was a concern about a lack of presence data, not wanting to unnecessarily send messages to hosts that may be offline, as well as the taxation of enforcing SSL for each and every endpoint. (Comparatively, Google Latitude provides such geolocation via triangulation of Wi-Fi access points and radio towers.)
Security
XMPP features a secure environment through enforced server dialbacks and inherent support for SSL and SASL. However, XMPP Standards Foundation executive director Peter St. Andre begrudgingly admitted that after a decade of using the protocol, the community hasn't been able to implement an official encryption format. From the Web Hooks perspective, SSL, authorization and other traditional security measures can be leveraged over existing HTTP techniques, as any of the major web frameworks supports their own cryptography libraries.
Network Access
Generally speaking, web API calls can directly move through Port 80 without additional configuration. The XMPP community has made some very impressive strides with NAT traversal, facilitating messages seamlessly passing through the corporate firewall.
Standards Compliance
Google developers Brad Fitzpatrick and Bret Slatkin expressed their frustration at how XMPP development has fragmented due to the fact that XEP-0060 (the PubSub extension) is more convoluted than the Core spec, coupled with architects not following the protocol extension as written. (This clutter gave rise to the development of the Personal Eventing Protocol, a greatly reduced subset of PubSub.) Conversely, the web services model, operating over standards such as SOAP, HTTP, WSDL and other structures, is widely understood and adhered to in client apps. Web Hooks, being a software pattern not bound to a formal spec, also has a little bit more leeway than the rigidity of a full protocol.
XMPP over HTTP
During that same presentation, the Googlers also noted how a simple framework can be built on XMPP using JavaScript techniques via their pubsubhubbub sample app. This evoked an immediate reaction from supporters of BOSH and Web Hooks, citing how web services can leverage keep-alive HTTP sessions and asynchronous calls. Let's face it - AJAX Comet hasn't really taken off the way many had hoped. (Comet vs. BOSH merits its own discussion altogether.) A major area of development for achieving near-real-time notifications of web data is Atom feeds over XMPP PubSub, which may prove to bridge the two schools of thought.
Public Perception
While each technology hasn't quite hit the development mainstream just yet, cursory views on it vary. The big knock against XMPP today is twofold: people see XMPP merely as IM and not a flexible messaging framework, and that it's not HTTP. Pundits quickly point out HTTP's many shortcomings in cross-network communications, while others remind us not to forget its simplicity. The appropriately named "Web Hooks" has more of a natural grokability to it.
Development Model
Any modern-day developer knows server-side coding in some language, so adopting Web Hooks makes for a very smooth transition. XMPP's use of long-lived TCP connections to stream XML fragments between servers might mean web devs have to delve into the unfamiliar world of socket programming; and perhaps going even deeper, having to get into GUIs, servers, and possibly bots. This makes for a sizable learning curve not everyone is going to want to undertake.
Platform Accessibility
One area where Web Hooks have a distinct advantage over XMPP is their accessibility across developmental platforms. A handful of XMPP clients, libraries and SDKs exist for .NET and Mono, but they're still vastly outnumbered by those for Ruby, Python, Erlang, PHP, Java, Perl and the like. Ironically, the Jabber project, the IM platform driving XMPP, has been around nearly as long as server-side web development, but has really only seen a large interest uptake in recent history.
Conclusion
While advocates of both Web Hooks and XMPP passionately defend their preferred system of data exchange, friendly and at times pragmatically aggressive challenges are being lobbed across forums, blogs and IRC channels about HTTP's survivability as we move toward delivering real-time experiences. Some have even proposed abandoning the moniker "web services" altogether, suggesting we using "online services" by virtue of political correctness.
There's little argument against the fact that XMPP scales better. But the low barrier to entry of the Web Hooks model of registering callbacks is orders of magnitude more achievable than setting up a back-end architecture that to many IT shops will be foreign territory. The learning curve, supported platforms, infrastructural requirements, security issues and ease of deployment make this a very compelling discussion.
Thursday, February 26, 2009
7 Questions for Jeff Lindsay on Web Hooks
I asked Jeff about his thoughts on the emergence of a platform that's not really new at all.
1. You've certainly been asked this a thousand times and will be asked to do it a million more, but explain the concept behind web hooks and its implementation in today's web services.
Web hooks are user-defined callbacks over HTTP. They're intended to, in a sense, "jailbreak" our web applications to become more extensible, customizable, and ultimately more useful. I think of web hooks as the STDOUT of web applications, where the STDIN are web APIs. Together they create a simple input/output model for the web, similar to what was needed for Unix command pipelining. Pipes allowed users to compose and orchestrate new functionality by chaining together commands. Web hooks will achieve something similar by bringing a new level of event-based programmability to the web.
Like web APIs, vendors have to opt-in on providing this kind of infrastructure. Fortunately, web hooks are not hard to implement at the core. They're just making inline HTTP requests on the backend at significant events to a URL specified by the user. In most programming environments, this can be implemented with a single line of code, without needing a special library or external dependency. There are obvious scalability issues with making a blocking request to the greater web, so most implementations will be more complex than that. However, conceptually, they really are that simple.
2. Since callbacks aren't an original technology concept, as was the case for AJAX, how does the community build momentum for its use, adoption and evolution so it can achieve critical mass, as was the case for AJAX?
I think AJAX achieved critical mass from two things: having a very well-known and obvious example use-case (Gmail and Google Maps), and having a name to reference the design pattern. Those two things are all you need to seed a new technology like that. From there, word spreads, more examples show up, people talk about it online and at conferences, and libraries pop up to make it even easier to accomplish. The adoption of AJAX happened very quickly.
The AJAX story provides a nice template for web hook adoption, but unfortunately, AJAX is a much more user-facing technology. You can see it very clearly when it's used. Web hooks are not only less obvious, but they conceptually require you to step back and think of how they affect the web as an ecosystem, not just a particular website you love to use.
Perhaps another technology to compare the adoption of web hooks to is REST. You've always been able to do REST APIs, just like you've always been able to do web hooks or HTTP callbacks. Whereas AJAX required functionality to finally be exposed in all the popular browsers. Unlike AJAX, after REST was coined and explained, it a while for it to become the dominant way to implement web APIs. This might have been because it was such a developer-facing technology.
However, both REST and AJAX grew from having a name to talk about them in discourse, and examples to inspire and instruct others how they can be used. Web hooks are a name, and over the past three years since they got a name, a number of examples have shown up. I think the best way to build momentum is to keep talking about them and thinking about the issues and implications, but more importantly, building out the infrastructure by actually implementing them.
3. What are some misconceptions about the process of registering callbacks? Have there been inappropriate applications of the concept?
Some of the original cases of web hooks were framed as notification mechanisms. While notification is a major use-case of web hooks and describes how they were being used in those cases, it doesn't describe why they were being used. The PayPal Instant Payment Notification mechanism, maybe one of the oldest instances of a web hook, was described as a notification, but the purpose was really about integration. If all you wanted was notification, you could get an email to tell you a payment was made. But IPN was useful for integrating the rest of your software system with PayPal's payment processing.
I don't think there have been inappropriate applications, although one requirement people sometimes forget is that web hooks are user-defined. This can be a hard distinction to make, but is why I don't consider linkbacks to really be web hooks. And again, a lot of people are thinking of web hooks for just notifications and push, which I don't think is entirely counter productive, but it falls short of the bigger picture.
4. XMPP is the darling of the media right now, gaining lots of traction within the development community and a decent amount of attention from the mainstream press. Web hooks has a slight advantage in being a clever off-the-cuff branding idea not being bound to a formal spec. How can we ensure development with web hooks isn't swept under the rug by people's fascination with following the Pied Piper of Hamelin, as it were, and lose focus on using the right tool for the right job?
Definitely XMPP is a strong contender for real-time message passing. It was designed for that. It only just so happens that web hooks can be used as an alternative to XMPP for server-to-server communication. XMPP comes with a lot more out of the box that makes it better suited for many cases, and web hooks requires more work to compete with some of those features. To me, though, it's a little bit like comparing apples to oranges.
I used to compare web hooks to XMPP to bootstrap the existing conceptual model there. I also used to describe web hooks as push over HTTP. I've since realized that could easily pigeonhole web hooks. Now I try and emphasize the functional extensibility it provides more than the push aspect. After all, that's why I fell in love with web hooks in the first place. Can you build a plugin framework in your web app with XMPP?
I think the strength behind web hooks, at least in relation to the grander vision, is that it's not only simpler, but you're already using its protocol. To play the role of STDOUT for the web, it would be silly for every web application to have an XMPP stack alongside their HTTP stack. If we're going to have a common "output infrastructure" on the web, web hooks make too much sense.
That said, I think XMPP and web hooks will coexist and even work together in the future of the programmable web.
5. The evolution of distributed computing has gone from complex binary remoting to crude screen scraping, to structured web APIs, to object-oriented JavaScript and cross-domain access, to now extensible triggered execution. How survivable is this iteration in The Programmable Web?
That's an interesting question, although it seems all those forms of "distributed computing" are still around and used in some way today. The common property of all the previous technologies, including the many not mentioned, seem to be that they're request-oriented. While web hooks are based on making a request, they're not invoked by making a request, but by a relevant event. In this way, they bring event-driven programming to distributed computing.
Off the top of my head, I can't think of existing technology at the application level for event-driven distributed programming. At least in the context of the web, I see web hooks being the foundation for more specific standards and technologies that promote this paradigm. When technology is a platform like that, like the web itself, it can sometimes be more survivable than people want! For example, I'm still surprised email hasn't been replaced with a better system. :)
6. There are certainly going to be cases where web programmers are going to want to tap existing apps that don't have publish formal APIs. Without reverting to the hacky days of using mammoth regular expressions or feigning server-side event frameworks, what ecosystem exists in these cases?
Honestly, I don't see anything wrong with hacky solutions sometimes. Either they lead to a more formal solution (like screen scraping to web APIs), or they remain the best solution for a particular problem (like CGI handling the proper use of POST instead of the web server itself).
Sometimes you can package up hacky solutions as a nice library (the way AJAX is used now), or even as a service. For example, although screen scraping is outdated, not everybody has a web API, making it the only viable solution in some cases.
Dapper's Dapp Factory lets you easily create a scrape-based feed of any site, automating the need for tedious regular expressions.
These kinds of transformer services seem like a great thing to have in our programmable web ecosystem. I can only imagine that web hooks will encourage more of them, allowing web programmers to easily interact with other systems, like even XMPP for example.
Gnip lets you consume XMPP data streams using web hook callbacks. I'd just as much like to see a web service that gives you an HTTP endpoint for posting into XMPP.
7. You've become the de facto champion of this movement. What are some of the barriers - technological, political, social, etc. - you can see going forward with this means of data access?
It seemed like the biggest hurdle originally was getting people to wrap their heads around this idea. I would always talk about it in the abstract and go on about all the implications of what was essentially one line of code. I think there are enough fairly well-known examples now that it's easier for people to join the party. Even then, the general perception of what's possible is going to be limited by the examples.
Like AJAX, you can't just build a popular example of AJAX without it being a useful tool itself. I can build all the web hook prototypes I want, but it's not until the Googles and Facebooks implement them in a useful way that people will really see the value. Until then, we get incremental boosts by the smaller companies like Gnip, GitHub, and others. I've started working or talking with these guys to get them involved in a collective conversation around web hooks, so we can work out issues standing in front of adoption.
The issues people come up with are usually security and scalability related. As it turns out, some of these issues have been solved by these guys already doing it. So I'm trying to get more of them to share best practices and publicize their use of web hooks. This way people can start seeing the different ways they can be used. For example, the Facebook Platform, although pretty complicated and full of their own technology, is still at the core based on web hooks. They call out to a user-defined external web application and integrate that with their application. That's quite a radically different use of web hooks compared to the way people think of them in relation to XMPP.
Moving forward, I think we're going to see more libraries and tools that have solutions to scalability and security built-in. I've started one project called Hookah that I'm hoping to get released soon. It provides basic callback request queuing and management of callback URLs so you really can implement web hooks with a single line of code for each event. We're also starting to see similar helper libraries for frameworks like Django and Rails.
Eventually we'll be seeing specs for doing specific things on top of web hooks. One of the first things on my list of standards to look into is the way in which you register and manage callbacks in a programmatic way. Many web hook providers use a web interface to manage your callback URLs. We'll see some neat things happen when you can manage them via APIs so that tools can set callbacks with services on your behalf.
Anyway, one of the reasons I'm so attached to the idea of web hooks is that I see a lot of long-term potential. Especially when you integrate them into other visions of the future, like the Web of Things. When you combine the Programmable Web with the Web of Things, you get a world of Programmable Things.
That's where I'd like to see this end up.
Thanks, Jeff! :-)
Sunday, February 22, 2009
Movie Review: Friday the 13th
I've spent the weekend doing
a lot of creative writing...but with a twist: I'm syndicating my content out to other sources. Rather than bloat my own blog,
I'm trying to find new audiences by branching out and writing about the things that interest me in other venues. It's been fun...and flattering to be a guest!
Saturday, February 14, 2009
Tutorial: Twitter alerts for your Qik live mobile streams
While encoding
tonight's newscast, I was messing with a feature in
Qik that lets you automate alerts about the fact that you're streaming mobile video to one of several social platforms, so I wanted to enable such notifications for the users that
follow me on Twitter. After some initial difficulty and discovering syntax snafus, I got it working.
Hope it helps you, too!
**UPDATE**
The hit "55" to send out twitter notifications only apply to Nokia phones, on iPhone, there is a "send alert" button. Twitter alert is not yet available on Windows Mobile and BlackBerry, users have to set "Tweet all videos" under edit profile on their profile page.
Friday, February 13, 2009
7 Questions for Notifixious
Over the next few weeks, I'll be profiling several up-and-coming startups whose services I think are really clever and innovative and whose leaders are really making some waves with social apps. Up first:
Julien Genestoux from
Notifixious.
ABOUT NOTIFIXIOUS
Notifixious is a company that produces
Superfeeder, a multiplatform reader service that attempts to harvest any type of content stream
at a near-realtime rate. The service acts as a relay for feeds you subscribe to, pushing notification alerts to you via text messaging, e-mail or instant messaging in mere seconds after the source is published.
1. What led you to come up with the concept for Superfeeder?
Notifixious actually needs to notify people as fast as possible when new content is available, so we needed a feed parser. However, parsing feeds is not "smart" enough in most cases since many services exists to detect stories faster. We have then built the superfeeder as an improved feed parser, where we also detect new stories through pusheds streams, ping services, or SUP services.
2. The fact that you're encouraging content creators to release their material via XMPP streams over which you would sending alert notifications via e-mail, SMS and IM is remarkable - but more impressive is that you're also supporting feeds via SUP and traditional Atom/RSS polling. Can you explain your ecosystem for harvesting content?
We actually have a "core" composed of 2 elements: a fetcher that is in charge of fecthing the feeds and the parser, which is in charge of fetching them. Each feed as a fetch "frequency" determined by its frenquency of udpates and other factors. Around this, we have services that "listen" to pushed sources. When they detect a feed that we're already monitoring, they will either take the content (of available), or go and fetch the feed immediately (instead of waiting its frequency). It is actually pretty simple, as you can see.
3. Without giving anything too secretive away, detail your system architecture and back-end infrastructure.
The different components I described above are running on various EC2 instances, which makes it easy to "scale", as we only have to start more instances with more fetchers and parsers.
4. What's Notifixous' business plan?
Ads will definetely be a short-term revenue stream. We are currently looking for the right partners to do so. We have various options for them: a "wait" page, before accessing the link you clicked, or ads pushed to you and that corresonds to your subscriptions. We have other options, but they're not clear enough for me to get into details ;)
5. Obviously, the success of Superfeeder is going to be contingent on data providers evolving their feeds. How do you get sites to go the XMPP route?
We have to admit this is quite difficult right now...however, it is also clear that, at some point, if these services 'push' their content, it starts to become very easy for them to 'scale'. Also, it is a fact that real-time is increasing visitors loyalty and improving the "conversation" factor.
6. What's your short- and long-term vision for Notifixious as a platform? How will the service evolve?
Our goal is to be a notification paltform and basically allow any webservice to notify their users through our service. We also want to be the "single" subscription point for all your subscriptions online.
7. What have some of the challenges been supporting so many different kinds of content in so many different formats and over so many different platforms?
You nailed it : the challenge is to be able to find the smallest common denominator and build around it. Almost every service on the web provides RSS/Atom feeds, and they probably are the simplest API for information consumption. However, the lack of unity and the abundance of protocols, added to the fact that most of them are not valid makes it difficult to extarct the information. Another difficulty is that services tend to not build their feeds with care by putting insignificant titles or worse, by not respecting a few basic rules that makes it easy to understand what the information is about.
Please see this post about it.
Thanks Julien! Good luck with your service!
Do you have a cool product, service or platform you think should be featured in this series? Shoot me an
e-mail or
IM and let's talk.
Thursday, February 12, 2009
The arrows in my Twitter quill
A friend to one and all,
Leo Babauta, made a general inquiry about
which Twitter client(s) his followers use. I'll admit...a guilty pleasure of mine lately has been trying to post micromessages across as many platforms as I can, and voyeuristically noting which user agents my social network uses. SMS still doesn't work for us out here in Guam, which sucks, but thankfully we've got tons of other options.
I'm therefore taking stock of my armory, listed in order of how I came upon them:
Subscribe to Posts [Atom]
