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
Web Hooks is an emerging concept in the web services community whereby developers register callback scripts to events on remote applications for asynchronous execution. Jeff Lindsay, since coining the moniker, serves as the driving force behind helping people understand how to best use it. His slide presentation on the "Programmable World of Tomorrow" has motivated scores of people to incorporate the technology into their own projects.
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!
I posted a whimsical review of Michael Bay's remake of "Friday the 13th" for the popular local site 7MilesDown.com. Enjoy! More to come.
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**
Clarification from the Qik team:
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.
Superfeeder supports content produced via eXtensible Messaging and Presence Protocol (XMPP), as well as FriendFeed's Simple Update Protocol (SUP), in addition to custom demand-based polling for RSS data.
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!
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:
- Twitter.com
- Mobile Web
- TwitterBerry
- TwitterFeed, tapping KUAM's RSS feed
- Twhirl
- TwitPic
- Via FriendFeed
- TweetDeck (user agent: "XMPP Gateway")
- tweet.IM
What are yours?
Tuesday, February 10, 2009
An open letter to RIM about IM interop for BlackBerries
An open hypertext letter to Research in Motion
RE: Federation between BlackBerry Messenger and XMPP networks
Dear Sir(s) or Madam(es):
Good day! I hope this finds you well. I represent, in de facto fashion, all software developers, system architects and instant messaging users who have expressed frustration at not being able to federate their IM networks with the BlackBerry Messenger platform. I can only blindly assume that my humble request today isn't the first time your company has heard a cry for open interoperability, but I hope it reinforces the importance of such a feature in forthcoming versions of your product.
I'm aware of the existing ecosystem of third-party ISV client applications for BlackBerry (e.g., Vayusphere, Beejive, et al.) for connecting to and communicating with remote networks such as AIM, ICQ, MSN, Yahoo!, Google Talk, Jabber variants, etc. via the eXtensible Messaging and Presence Protocol (XMPP). This is an easy, albeit costly, solution from a consumer standpoint; however, the fact that such an environment inherently is unable to deliver messages to BlackBerry users without the use of additional external software, coupled with the fact that nearly every major IM vendor is doing so already, is a major weakness from a developer's perspective.
It's impractical to have to operate within such a silo. At the enterprise level it's costly to have to purchase/maintain scores of licenses for my staffers' BlackBerries, and even more unreasonable for me as a maintainer of a public XMPP-based web updates notification service to force my audience to have to purchase a separate product just to get my free content. The community can't be held hostage to such vendor lock-in.
I therefore strongly stress the need for enabling future versions of BlackBerry Messenger to support cross-system communications via XMPP.
Thank you for listening to my suggestion and congratulations if such a feature is already in the works. If my meager understanding of how the communications between disparate systems works is in error, please point it out and I'll gladly do a retraction. RIM's constant expansion for capabilities, such as having the Clock application natively include Timer and Stopwatch functions in BlackBerry OS v.4.6.0+, previously available as externally-developed freeware, is a noteworthy testament to your consideration of the community's ideas.
I would be more than happy to discuss this matter more with you at your convenience. Please e-mail me at jason@kuam.com - or better yet, leave me an instant message at my Jabber ID (jas@www.ymesei.com) and I'll get back to you, seeing as how I can't proactively contact you via IM...which is my point entirely. :-)
**UPDATE** If you feel as strongly, please sign your name/e-mail/JID/URL below and we'll consider this a living petition. Thanks!
Sunday, February 08, 2009
25 Random Things About Me
Evidently there's a meme making its way around the Facebook community having users list random quirky things about themselves, so I thought for a moment about mine. Here 'tis:
- I'm distantly related to abolitionist author Harriet Beecher Stowe on my mom's side.
- I've never done any drugs. Ever. Not a one.
- Anything I've ever enjoyed success in, I've always failed miserably at the first time out.
- Although I've played in volleyball tournaments half my life, I never played a second in high school. Two weeks before the first game of my senior year, the only year I made the team, I broke my wrist and was out for the season.
- I'm really good with kids...I'm totally willing to embarrass myself publicly for their amusement.
- I've worn my Schwimmeresque hairstyle since 1998.
- I'm very subversive and non-conformist. Peer pressure's never really had an affect on me.
- Joe Montana is still my hero.
- The thing most people don't realize about my photographic memory is I can't control it. Some things just stick.
- I didn't drink my first beer until I was 20.
- At 22 I changed religions.
- My sense of humor is very referential, upbeat, observational, perverted, narcissistic and self-deprecating.
- I'm a total mama's boy. As an infant if you tried to carry me and you weren't either of my parents, I'd throw a major tantrum. And by that I mean I'd pee all over you.
- The only places I've ever lived have been Guam and Connecticut.
- I've been working every single day of my life since I was 19. Seriously, Monday through Sunday I'm doing something productive.
- I was the first kid in my neighborhood to flip Super Mario Bros.
- I'm lactose intolerant, which means I can't enjoy dairy like most of you...but I can drop 15 lbs. in two days if I wanted to. Hehehe.
- My lucky number is 4.
- I believe that staying home and enriching the mind can be as fulfilling as going out and killing brain cells.
- I used to have a pretty intense sleepwalking problem. I'd leave the house, go all the way up the street, turn around, and get back in bed.
- Everything I know about software development has been self-taught.
- The only thing I've been doing longer than playing guitar is breathing. I picked up the instrument at age 5.
- My father was president of the university I attended. I later put myself through graduate school online, cranking out my MBA while working full-time as a web developer/newscaster.
- I'd pick EPCOT Center over Disneyland in a heartbeat.
- The movies "Big" and "Wall Street" served as the motivating factors for me majoring in marketing.
Keep it going!
Friday, February 06, 2009
Google Latitude - the first 48 hours
I've always loved toys, and over the years I've developed quite an affinity for figuring out how things work. The unveiling of Google Latitude is the ultimate for me...an amazing gizmo to play with, take apart and marvel at.
GPS is better than cell towers. If you're offered a choice between being tracked by Global Positioning System, the Wi-Fi access points or the cell tower triangulation schema that Google uses to pinpoint your place in the world at any given moment, opt for GPS. A co-worker who used the cell tower method was accurate to within 200 feet of where she actually was. When using GPS, my geoposition was dead-on accurate to within 20 feet...at most. That's crazy!
Google Latitude is a battery killer. Because you're constantly sending data back and forth to determine your geolocation in real-time and also because the screen can be backlit for long periods of time as you track yourself and others in your social network, your phone WILL heat up because of all the data communication passing back and forth and redrawing of the screen graphics. Depending on your data plan with your wireless provider, this could also get pretty expensive. So while a neat app to play with, realize this will eat away at your battery's life.
OK, enough blabber. Get with the program! If you know me, add me and let's have some fun.
To say Google Latitude is cool is a gross understatement. This is tremendously awesome. I've tested the app exhaustively with users from GTA TeleGuam's and DOCOMO Pacific's networks, over a wide range of phones. I'm also lucky I've got several friends who know way more about computers than I ever will that have helped me figure this stuff out.
When I caught word Wednesday night (Guam time) that Google had released a real-time geolocation service for mobile/desktop, my jaw hit the floor. I've Twittered about it incessantly over the past couple of days as I've hacked away at it, trying to get it to work after it didn't immediately take. So here are some notes from the field when you get the geolocation bug.
Understand the Google Latitude operating environment. The one criticism I've got about Latitude is how surprisingly weak the initial documentation is about it. There's one YouTube clip, a couple of Google Blog posts and that's it for now. As such, a lot of people don't get it immediately. Here's the skinny: your phone is the base unit that allows your geolocation to be dynamically updated. As you move around, your phone reports these changes. You could do this with a laptop with a persistent Internet connection of some sort, but that would be cumbersome and annoying...not to mention the fact that at some point your computer would die. You can track your own progress and that of your GMail contacts over your phone after downloading/installing Google Maps 3.0.0, or on your desktop by way of an iGoogle portal web widget. That's it in a nutshell.
Don't just 'accept'. If you get an invite from a GMail user, merely accepting won't get it done...you've got a bit of work still to do. I've invited several of my social network friends to join in the fun, most of whom just merely accepted without properly setting up their profile. So I see them listed as having confirmed, but they're not reporting their geolocation.
Real-time works on your mobile, not your desktop. Many people I've introduced the app to who use it over the Web don't see me moving about as I do it get frustrated. On phones, you can see yourself moving in real-time (insanely cool!), but that's a feature that works on phones only. The desktop component refreshes itself every couple of minutes and redraws each user's updated geolocation with their avatar. It's not real-time and isn't intended to be.
Don't fear Google Gears. When you setup the desktop component to Google Latitude (enabling the widget within your personalized iGoogle portal), you'll be prompted to download a small plugin, Google Gears, and to allow Google Latitude access to your computer. This lets the service run certain operations in the background to update your position. Don't worry...it's harmless and sounds worse than it is.
Go outside and play. I'll admit I've never worked with GPS devices before, so getting over that learning curve helped greatly in understanding how Latitude works. After about a day of frustration in not getting my geolocation to be shown - I sometimes jump back and forth between Guam, South Dakota, Macedonia, Honduras and Vietnam - a buddy at DOCOMO suggested I re-synch my GPS settings with satellites. I told him I did, to which he replied, "No - stand OUTSIDE and synch it." I'll be damned, it worked. As such, I've also noticed dramatically more consistent GPS coverage and responsiveness by the app when I'm not within a building. So this might be an incentive to take a stroll and watch yourself move on your mobile.
When I caught word Wednesday night (Guam time) that Google had released a real-time geolocation service for mobile/desktop, my jaw hit the floor. I've Twittered about it incessantly over the past couple of days as I've hacked away at it, trying to get it to work after it didn't immediately take. So here are some notes from the field when you get the geolocation bug.
Understand the Google Latitude operating environment. The one criticism I've got about Latitude is how surprisingly weak the initial documentation is about it. There's one YouTube clip, a couple of Google Blog posts and that's it for now. As such, a lot of people don't get it immediately. Here's the skinny: your phone is the base unit that allows your geolocation to be dynamically updated. As you move around, your phone reports these changes. You could do this with a laptop with a persistent Internet connection of some sort, but that would be cumbersome and annoying...not to mention the fact that at some point your computer would die. You can track your own progress and that of your GMail contacts over your phone after downloading/installing Google Maps 3.0.0, or on your desktop by way of an iGoogle portal web widget. That's it in a nutshell.
Don't just 'accept'. If you get an invite from a GMail user, merely accepting won't get it done...you've got a bit of work still to do. I've invited several of my social network friends to join in the fun, most of whom just merely accepted without properly setting up their profile. So I see them listed as having confirmed, but they're not reporting their geolocation.
Real-time works on your mobile, not your desktop. Many people I've introduced the app to who use it over the Web don't see me moving about as I do it get frustrated. On phones, you can see yourself moving in real-time (insanely cool!), but that's a feature that works on phones only. The desktop component refreshes itself every couple of minutes and redraws each user's updated geolocation with their avatar. It's not real-time and isn't intended to be.
Don't fear Google Gears. When you setup the desktop component to Google Latitude (enabling the widget within your personalized iGoogle portal), you'll be prompted to download a small plugin, Google Gears, and to allow Google Latitude access to your computer. This lets the service run certain operations in the background to update your position. Don't worry...it's harmless and sounds worse than it is.
Go outside and play. I'll admit I've never worked with GPS devices before, so getting over that learning curve helped greatly in understanding how Latitude works. After about a day of frustration in not getting my geolocation to be shown - I sometimes jump back and forth between Guam, South Dakota, Macedonia, Honduras and Vietnam - a buddy at DOCOMO suggested I re-synch my GPS settings with satellites. I told him I did, to which he replied, "No - stand OUTSIDE and synch it." I'll be damned, it worked. As such, I've also noticed dramatically more consistent GPS coverage and responsiveness by the app when I'm not within a building. So this might be an incentive to take a stroll and watch yourself move on your mobile.
Spotty coverage may require a bit of elbow grease on your part. Cool as it is, the one thing you won't be able to get around is poor radio and/or GPS coverage and/or telecommunications infrastructure if you live in a non-metro area (see CNET's coverage). So riding on the coattails of my last point, if when you head inside you're noticing that Latitude constantly jumps your position around the planet or dramatically skews your true position, you may need to toggle between manually setting your location when you're at work or at home, and then letting it auto-detect and track you when you're on the move. That's what I'm forced to do - I'm currently seen by 5 satellites here in Guam (is that good?).
GPS is better than cell towers. If you're offered a choice between being tracked by Global Positioning System, the Wi-Fi access points or the cell tower triangulation schema that Google uses to pinpoint your place in the world at any given moment, opt for GPS. A co-worker who used the cell tower method was accurate to within 200 feet of where she actually was. When using GPS, my geoposition was dead-on accurate to within 20 feet...at most. That's crazy!
Google Latitude is a battery killer. Because you're constantly sending data back and forth to determine your geolocation in real-time and also because the screen can be backlit for long periods of time as you track yourself and others in your social network, your phone WILL heat up because of all the data communication passing back and forth and redrawing of the screen graphics. Depending on your data plan with your wireless provider, this could also get pretty expensive. So while a neat app to play with, realize this will eat away at your battery's life.
OK, enough blabber. Get with the program! If you know me, add me and let's have some fun.
Thursday, February 05, 2009
Google Latitude on Guam
I was supposed to have spent a quiet night at home last night reading and researching. Google Latitude ruined all that. I was messing with the company's new real-time geolocation social network tracking service for awhile, and made it work for Guam...sort of.
Here's my video review:
I've used three different ISPs and at least one wireless provider, but the cell tower triangulation, which not surprisingly doesn't accurately cover Guam, keeps placing me in Honduras. If anyone can figure out how to get us out here to be tracked in real-time, shoot me a note.
Thanks...and enjoy!
DON'T ride the waves
We've been reporting how huge waves of late have caused massive waves to pound Guam over the past couple of days, and the safety advisories that have been declared by the National Weather Service. Clynt Ridgell took some great mobile video of some of the more extremely flooded places on island, including this clip, which got him caught in the act.
Check it out on KUAM's Qik channel!
Book Review: What Would Google Do?
This is the latest seminal work about doing business in the Digital Age, following in the footsteps of seminal work like Being Digital, The Cluetrain Manifesto and The Long Tail.
I greatly enjoyed this book for the intelligence and wit of Jeff's writing, broad scope and reach within the Web 2.0 community, and loose application of the theory of following in Google's footsteps. The book's not specifically about Google per se, but more about profiling the generation of entrepreneurs who weren't necessarily non-conformist in bringing their ideas to life. These are those men and women who ignore convention and tradition, do their own thing, and, to badly coin a phrase, think different.
However, there's the rub: the main point of the work isn't to teach people to photocopy Google's business strategies - but more to ignore traditional marketing and economics and buck the syste, thinking way outside the box in developing a new way to do business. Google got to be where it is today by being distinct and doing what they do better than anyone else on the planet, in their own unique way. To merely copycat their approach would be missing the point. Have your own ideas, your own motivations and your own theories about building a business.
Start with that and enjoy Jeff's offering.
Tuesday, February 03, 2009
Disruptive technology: delivering real-time web experiences
Will and I discussed last Friday night my fascination of late with XMPP. So while in the midst of our talk about the true potential for the protocol that drives instant messaging, he finally broke rank and asked me what exactly it is about XMPP that I enjoy so much.
IM, he pointed out, has been around for years. And while cool, it isn't exactly anything new and never really uprooted other communication means like e-mail, chat, and streaming media. Duly noted.
I've been known to take casual interest in many emerging concepts every year, with one or two ideas sticking in my craw every once in a blue moon when I really see how big they can be at a mainstream level. This is one such case. The potential for us content creators to leverage the protocol as a means of delivering real-time online experiences has me mentally salivating.
Bottom line? The last time my spider-sense tingled this loudly for the prospects of a new platform was when I first discovered podcasting in its infancy. (And for those of you who can remember that far back, I was kinda into it.)
Yesterday during Super Bowl XLIII I was engaged in a really neat user experience. I had Twhirl, my desktop Twitter client, pulsing my batches of people's thoughts every few minutes on my laptop, and Spark, my IM app, open on my desktop. The latter was hooked up to my FriendFeed social network, which alerted me to synchronized posts and comments by those users in real-time.
During an absolutely insane 4th quarter of an otherwise pedestrian contest, both platforms went NUTS, facilitating the community's responses to a series of jaw-dropping plays. Following Larry Fitzgerald's touchdown catch-and-run that put Arizona ahead, I was getting a surge of IMs and micromessages. A tidal wave of similar messages came seconds after the safety called in the end zone due to offensive holding on the Steelers. And naturally, a slew of updates arrived immediately after Santonio Holmes made the game-winning TD reception before the officials could confirm the play.
The experience was truly amazing. And I believe, the future of things to come for the web in general.
The one thing I've been preaching to people about XMPP's massive potential for content delivery is its ability to most closely mirror actual human conversation, which we haven't quite been able to do yet technologically. Everything's had an uncomfortable disconnect. In recent years I would have had to wait until after the game to read feedback from the blogosphere. Over the last 18 months liveblogging made the experience a little more tolerable but still gimmicky, and certainly laborious for those on both sides of the post - content creator and content consumer.
New services like Notifixious and its SuperFeeder aim to deliver a real-time web, which as a guy working in online news I'm totally in favor of. Letting people interested in my stuff know aboutits presence the second I post new information is a massive sea change in how we've been able to access information to date. Whereas browsing has historically been a static, manual process and the evolution of RSS automated content delivery, there's still a lag.
My point is that the applications that XMPP can and will drive, along with its ilk such as SUP, are going to change the way you and I get information. Accessible across devices and platforms (web, desktop, mobile, e-mail, SMS, RIA, API) and coupled with the natural progression for any type of content to incorporate multimedia through out-of-band conversations, delivering instantaneous experiences about your favorite web destinations is going to be huge.
Personally, I've wanted to feed out the multimedia/multiplatform news content my company produces to the IM market and do things like geolocation, topic-specific web updates (essentially PubSub), interactive TV, and other types of specific functionality that fall outside the boundaries of HTTP, but there was never really the glue that could tie it all together. I'm confident XMPP can be the driving force towards this and other ends.
Now, I'm not fool enough to think that XMPP will be the saving grace for the entire web. Like podcasting, it'll be complementary to the total process of getting information, not supplanting it. Most people aren't going to want real-time updates of their favorite online data, and fewer still will glom onto the concept immediately. Despite the convinience of getting IM'ed when your roster of sites publishes new information, that's a pretty advanced process. And the development model isn't exactly easy.
Notifixious is encouraging content owners to develop their own XMPP streams, but that's not going to be easy. SUP is making some great strides, but there's admittedly inaccuracies in missing updates, and slight latency still exists. But both will evolve, get more accessible and easier to build into your apps.
And those shortcomings aside, mark my words, friends: this is the Next Big Thing. So my objective as a journalist/technoligist is to help spread the word - talking to people, getting the right people to ask the right questions, propose solutions, start writing code, and coming up with ideas.
Hold onto your hats...here we go.
Monday, February 02, 2009
No fiction. No drama.
Taking a break from reading Jeff Jarvis' latest gem, What Would Google Do?, I gave a quick glance at my bookshelf (shown aside), and then I paused to notice its composition, more specifically what it lacks. With the exception of my Stephen King bookends - hardcover versions of the classics It and The Stand - my modest collection's completely devoid of fiction, suspense and drama.It's all reality, all stuff that's actually happened or applications of things that really exist in the world.
So online services aside, here's a snapshot at how I get my media fix.
I've always been an avid reader, having consumed great works, but largely within a specific silo - humanities, academic essays, sportswriting, biographies, technology, accounts of the music industry, business tomes. I've always had an affinity for knowledge and at a very young age embraced literature, discovering the marks people have made in history and also the projections great thinkers have put forth about the future. I don't largely crossover into imagined stories.
That said, contrast my movie viewing habits. While I appreciate the classics, the theater's my wind-down time. I largely prefer my Silver Screen experience to be one that entertains, not teaches. So I normally frequent action, horror, sports and comedy. Typical guy stuff.
So now we arrive at my mid-range: the boob tube. Television for me has always been the great panacea as far as delivering content. I turn to TV for education, entertain and enlightenment, so I'll watch anything you put in front of me. On any given night you can find me taking in a cartoon reeking of post-modernism, a dumbass b-comedy, a documentary on Hitler, science fiction, a cooking show, and a Baroque production - all in the same session. Heck, I've been known to sit through infomercials, marveling at their deliberate scripting as a means of low-level mind control.
As someone who's been profoundly influence by mass media his entire life, the disparity in how I separate my information across platforms is interesting, upon review.
So if you ever see me around and want to have a chat about the finer points of Hamlet, feel free...I prefer Mel Gibson's version. :-)
Sunday, February 01, 2009
My magazine interview on Guam web tech
Dashing into the gas station this afternoon I noticed the latest copy of Guam Business Magazine, which featured an interview a reporter did with me about local web technology trends. I'd almost forgotten I did this...good thing I archived my Q&A responses.
Here's the piece quoting me (PDF). Good job on the write-up, Jessica. Thanks for letting me participate. :-)
Subscribe to Posts [Atom]
