Monday, April 27, 2009

    JavaScript: Callbacks in Loops

    I just finished a mashup that had to be blogged about. I suffered to find this solution, and I wanted to share what I learned with the world.

    In the mashup I took a twitter feed and plotted the tweets onto a map based on the location of the tweeter. Let me set the stage.

    The Google Map has already been set up and the list of tweets has been obtained. It is now time to plot the tweets onto the map. This will be done within a function called addMarkers. The HTTP Geocoder that Google provides will be doing our geocoding. For more information on this service, see this.

    Keep in mind that I'm doing all of this in a Presto Mashlet, and will be calling out to the HTTP Geocoder via a URLProxy call that is undocumented but available for use.

    At first blush, the following approach seems appropriate. Here is an excerpt from the addMarkers function:

    However, this suffers from a very serious drawback, and that drawback revolves around the scope of the function as it exists on the stack. Remember that you are calling out and receiving an asynchronous response via the callback. There's no telling where this loop will be when a callback returns, but the scope of the function is maintained on the stack until all of the callbacks have been completed.

    When a callback returns, the current value of i will be used to index into tweets! Since all of these calls take time, the most common result is that i will actually be out of bounds of tweets. Recall that updating the loop variable is the last operation done in any JavaScript for loop. Once you have looped through all of your indexes you, of necessity, must set i to be out of bounds of tweets. Therefor, i will be equal with tweets.length.

    The result is that you pass an undefined object into placeMarker in place of what should have been the tweet.

    The next logical step is that you should create a variable to hold the value of i, like this:

    var myTweet = i;
    this.placeMarker(point, tweets[myTweet]);

    However, this will fail as well!

    The problem here is that myTweet is still within the scope of our addMarkers function. addMarkers will therefor have only one copy of myTweet. Once again, you end up in a situation where the loop will probably finish before any of the callbacks return. The net result this time, however, is slightly different. You will pass in a valid tweet to placeMarkers, but it will be the last tweet in every instance. You'll have the same tweet attached to all of your markers on the map, the last tweet in the list.

    So, how do you remove the timing issues? This is where I suffered. I hunted and pecked out half-solutions for quite a while. Finally, I had to start thinking outside of the normal box to come up with a solution.

    The whole problem revolves around all of the callbacks returning to a shared scope in the stack, that being the scope of addMarkers. Once you consider it that way, it becomes obvious that providing each callback with its own scope on the stack is what is needed. The way to do that is to have a function fire off the HTTP Geocoder request. The function will get its own spot on the stack and will have its own scope. Let addMarkers maintain the loop and call this function whenever it wants to fire off a request. Pass in the tweets and the desired value of i to be remembered.

    Consider the following:

    This approach will result in the correct tweet being displayed with the correct marker on the map.

    Wednesday, April 15, 2009

    Como Se Llama?

    Originally, I created my twitter account with the handle @jitlife. Obviously, jitlife is my blog, so I thought it made sense. After all, I want people reading my blog, right? Twitter seemed like a good pointer to my blog.

    However, I started rethinking this mindset and eventually asked myself this question: Am I marketing my blog, or am I marketing me? By being @jitlife, I was marketing my blog. Therefor, I determined to change my twitter handle.

    In deciding on my new twitter handle, I came up with a few criteria:
    1. It has to be short
    2. It has to reference me as an individual
    I was going to add as 3 that it had to be clever, but the more that I thought about this, the more I realized that the first 2 are the most important, and in that order.

    It has to be short as twitter only allows 140 characters. If someone is @replying to me and they have to type in a 15 character handle, well, they'll be less inclined to do so (at least from a mobile device) and they'll also have less space to say what they want to say.

    That it must reference me is quite obvious once you realize that I'm marketing myself. The problem here is that all of the obvious references to me were taken! @rollins, @mrollins, @mikerollins, etc. All, gone. Most were taken and had only one or two posts, which is frustrating, but so is life.

    Barring the obvious, I decided to get clever. I chose @rollinsio. Briefly, it's a silly name I call myself when I'm talking in a fake Spanish accent but it's also clever in that it could stand for Rollins I/O: perfect for twitter! It's short and it references me (rollins is prominent).

    Monday, April 13, 2009

    More Effective View Management in Web Pages

    One of the research scientists I work for and I have been going 'round and around recently about web desktops. In a web desktop you translate the traditional desktop view into a browser. For examples see Ext's web desktop and this actual web desktop OS. In question was how do you navigate between views of various applications in an efficient manner?

    The good professor drew a distinction between how a traditional web application represents a set of views vs. how a desktop represents a set of views. In the traditional web application a set of views is often represented using tabs. You have a tab for each view of the application. Google has taken this idea to the extreme. Consider Google Docs. In Google Docs when you want to open a new document, you open a new tab. You can keep opening new documents (and consequently new tabs) until you have a bazilion of them, at which point navigation becomes a nightmare.

    On the other hand, you have how a traditional desktop represents views: new views are organized on the "start bar" (forgive the Windows-centric frame of references) with icons. Each icon may have some text and an image to represent it. When you mouse over a given icon you get a tooltip which provides you more information.

    The question then becomes how do you find a particular view when you have many views open?

    In the web application you may be lucky enough to have individual titles on each tab, but barring that, you have to click on each tab and work your way through potentially all of them before you find what you want.

    In a desktop, though, you often can pick out the view that you want simply by glancing at the images in the icons. At the very least, this will narrow your search down. You can then rely on the titles of the icons in question to further narrow the choices. If you're forced to, you can obtain the tooltips for each icon. Your ultimate last step is to look at each view individually. However, looking at each view individually isn't as bad as looking at each tab as you've already excluded some views out of hand because of the images, titles and tooltips. At the very least, you're certainly going to be looking through fewer views.

    Quite clearly the desktop way of searching through views is more effective.

    There are other factors to be considered as well. The start bar is static across all views. Being part of the default view of the OS it doesn't go away. You never (or rarely) lose your navigation between views. The same cant' be said with web applications.

    Further, the start bar only shows the views that are active. If a list of all possible views is desired, you can click on the actual start button to obtain it. A traditional link list shows all possible views, not just the ones that have been accessed during the current session.

    Clearly a more effective way of switching views in web applications is needed.

    I propose a tool that adheres to the following rules:

    1. Each view will be represented by an image, a title and a tooltext
    2. A space for all active views will be set aside on the page
    3. A list of all possible views can be called for but is not in available by default
    While I'm not a proponent of recreating the desktop environment in a web browser, the above idea would be truly powerful in a web application where many views can coexist.

    Thursday, April 9, 2009

    Building Your Professional Brand: Drink the Kool-aid

    Is what you have to say compelling, insightful, interesting or useful? Would you like to get this message out to others? Would you like to receive the acknowledgment of your peers for what you have to say?

    If you answer yes to all of the above then you need a professional brand. A professional brand is something that marks you as uniquely you, something that points directly at you in such a way that others recognize you. It's not quite a kind of fame, but it is a way of differentiating yourself from the masses.

    I've recently become interested in establishing my own professional brand and I've started looking around at ways to do that. Here are a few of the observations I've made.

    You need a soapbox

    You have to have some place where you can expound on your ideas to the fullest extent possible. Follow out every thought, every nuance of an argument and feel comfortable doing it. Speak your mind!

    This is where your blog comes in. It is your soapbox. You can discuss whatever you like there, but the more erudite and insightful your blogs are, the more folks will come back after the first dose.

    However, how do you bring people to your soapbox to partake of the Kool-aid you're doling out?

    You need a megaphone

    You need some forum wherein you can succinctly give out information that will draw others back to your soapbox. You need something that is light-weight and is easily consumable with a minimum of effort.

    You need twitter.

    140 characters is not (generally) painful to consume. You can read a tweet and in a split second decide if it's something that your interested in. Thus, if you can craft your tweets to be compelling enough for folks to be interested, then you can use twitter to announce your new blogs.

    Of course, this necessitates having a following on twitter, but this is a recursive process. Your first few followers will likely be your friends or those you capture by chance. Consider, though, the phenomenon of the re-tweet. If what you have to say is compelling enough then there is a good chance those that follow you will RT your tweet to those that follow them, and on and on.

    Shameless self-promotion is of value here. If you think what you have to say has value, then there's no harm in promoting it. Someone else may find it of value, too. Remember, if it's profound enough for you to blog about, then it's probably profound enough for someone else to read.

    But, don't just limit your tweets to self-promotion! Tweet about things that fall in line with your brand or RT information that is compelling in and of its own right. If others begin to see you as a fount of useful information they're likely to buy into your Kool-aid.

    Mark Drapeau (@cheeky_geeky) has a great blog about "Expanding Your Twitter Base". His rule of thumb is provide valuable information to others on a regular basis.

    Shepherd your following

    Once you have others interested in your Kool-aid, you have to take care of them. Shepherd your following by interacting with them and acknowledging them. You can do this by responding to comments on your blog or by RT'ing interesting things that your followers aim at you. The main point is that you have to be involved in as personal a way as possible. If you're involved personally then others will be more inclined to recommend you to those that they know.

    Also, don't just fall off the face of the Earth for any lengthy amount of time. You have to keep the Kool-aid flowing! The more often you present new ideas and information, the more likely folks are to come back and see what the latest is. If you only post a blog once every 2 months, well, you're not going to have an easy time building a following. If, however, you are prolific poster and always provide value, you're likely to garner a larger following faster.

    Wednesday, April 1, 2009

    It's a Transforming Process!

    So, right now I'm working on a gadget that takes in generic info and sends out Fusion Charts XML. It's a SOAP service and there will be many service endpoints, but right now there are only 2, one for a simple, single series bar chart, and one for a multi-series "drag node chart" (think network diagram with drag able nodes).

    I chose to go about it in a different manner than I've seen a lot of people use for Fusion Charts, though. The prevailing way that I've seen people create Fusion Charts XML is to take the data in on the JavaScript side and create the XML, in string format, in the JavaScript. For this approach, I have only one thing to say: Building XML in JavaScript is less than optimal (translation: it sucks).

    So, I decided to go about it in the web service itself. My web service is written in Java and once you get the question into Java a few, more palatable, alternatives suggest themselves. In my web service there are 3 distinct transformations: request object to traditional object; traditional object to simplified XML; simplified XML to Fusion Charts XML.

    The request object to traditional object transformation is really the beast. The inputs for the endpoints are comma-delimited strings. A lot of work goes into parsing those strings and putting them into the more traditional object. I have my inputs be comma-delimited strings so that the Presto JUMP requests can invoke them effectively. I could just as easily have one of my endpoints be a direct invocation of the more traditional object, but as I understand it, that's a bit of a bad practice.

    Once I have my traditional object the easiest step occurs. In this step I use XStream to serialize the traditional object into a simplified XML. If you've never used XStream, it's very simple, very powerful and I recommend it highly.

    The last step is where the real magic happens, though. Here is where I transform the simplified XML into Fusion Charts XML. I use the Saxonica XSLT engine to do the transformation and it's a matter of using the right tool for the right job (with regards to using XSLT to transform XML).

    XSLT is designed to transform XML, whether it be from XML to XML or XML to some other language. You write a transformation wherein you process the source XML and then create a document in the desired format. It's really not all that hard to take the simplified XML and transform it into the Fusion Charts XML.

    Once I have the Fusion Charts XML document I send it back out of the service in a special response that contains the document in string format and the name of the Fusion Chart swf file that will correctly process that document. When my response arrives at its destination all that needs to be done is input the Fusion Charts XML document into the Flash engine with the correct swf file pulled up and voila, it's all done.

    I like this approach in that it moves all of the heavy lifting out of the display side (the mashlet, in my case) and into a much more suitable environment, that being a Java web service. I don't have to do endless string concatenation that is hard to debug inside of the JavaScript presentation layer. As a matter of fact, I can write all of the pieces independently of each other and then put them all together in the end. It's a nice break up of all of the work.

    An acknowledgment needs to go to @angleofsight for his help in getting this whole process set up. Without his paving of the way I wouldn't be anywhere near as far along as I am right now.