Monday, March 30, 2009

Aimless Surfing Gadget - Still Waiting

I am still waiting for approval from Google for my gadget (or rejection or any response at this point). Today, I learned about an link lengthening service. That will make any url much longer. It got me to thinking though, you could probably encrypt a bunch of good data into a meaningless string of characters and let them hang out on a visible URL. Your data is "safe" because the string can't be decrypted and it becomes difficult for the user of the url to try to modify the variables he is passing to our web service....what a great idea....I bet someone has already thought of it and has already made their millions.

Monday, March 23, 2009

Aimless Surfing Gadget Update

I'm still waiting for Google to review my Aimless Surfing submission. In the mean time I'm making small tweaks and finding interesting results. I decided that having a default of 4 characters in the string was giving links that are too old. I switched the default to 5 in the code I have stored via the GGE widget. I was interested to see that my gadget didn't update automatically. However, the next day, the default was 5 and not 4. Clearly there is some caching going on. I need to see if there is a published update schedule somewhere.

This can make for interesting coding updates. You make your bug fix/update and users get the fix on their machine at some unknown future date.

Sunday, March 22, 2009

Vendor Relations

About 2 years ago I moved for a company who always chose "build" in our build v. buy discussions to one that always chooses "buy". Part of this is a byproduct of the respective sizes of the two companies and the two IT departments. Needless to say, I've learned a lot about vendor/outsourcing relationships. Maybe I can help you with a few rules I've invented.

Rule #1: Find out what the outsourcer is good at. If you ask your vendor to do something they don't know how to do well, they may try to do it anyway (the customer is always right). Also, always ask about the SOP for the vendor and try to work within it. The risk for them to mess up is high if you are making them do something out of the ordinary for them. I've run into good vendors who will say "no" or who will suggest a way to meet my need via another means. However, this revelation will only come about if you take time to talk about your needs and keep an open dialogue. This takes some time, be patient.

Rule #2: Know the SLA. Nothing causes more tension than expectations mismatches. If a service defenciecy is within the SLA and you blow your top, you can gain a reputation as being unreasonable. On the other hand, if you approach a vendor who has not met their SLA and cite the SLA and give data about how far they missed it, they are likely to be willing to make it up to you. During these discussions, I always try to be prepared with a short list of actions they might take to patch the relationship.

Rule #3: Let the vendor make money. There are times to negotiate a price and there are times to let the vendor charge what they need to. Pay attention to hourly rates and equipment costs in the SOW's that a vendor gives you. When they change, have a discussion about what is going on. Also, do your best to pay attention to the business of the vendor, who are the other customers (can you meet them?), how is business going in general (are there going to be capacity issues). Are there any HR or market issues that may impact the vendor's ability to meet their obligations to you.

Rule #4: Get to know the workers. With most outsource relationships, you are assigned a customer advocate or something similar. It can be really helpful to also meet and know some of the people who work on your projects. All of the skills you have for managing your own employees can be applied here to build loyalty. Over time, you can even get the better employees at the outsourcer to be assigned to your projects, especially if you're asking for them by name.

Rule #5: Don't surprise them. Keep your outsource vendor up to date on the other big projects and thing on the horizon even if you are unlikely to use that vendor for the project. They are more likely to be able to support you or engage you if they know what you are doing.

Rule #6: If it's a crisis, ask for help. If you are truly in a bind and have a good relationship with the outsource vendor, they will work with you. It's in their best interest, and the good ones know this.

The best distillation I can offer for these rules is to treate these people like they work for you and are part of your team. Let them be partners with you. Recognize when they are the experts but don't hesitate to be the expert in your field either.

I think that not all of my vendor relationships follow these rules. Some vendor relationships are full of distrust on our side (and likely for them as well). If you cannot become a partner with your vendor, you should probably try to figure out how you can do without them. Sometimes this can be hard (like if your company uses a proprietary piece of software). However, if only one or two of your vendor relationships are difficult you will have a lot more energy to devote. If all of the relationships are contentious, you will be very tired.

Wednesday, March 18, 2009

Aimless Surfing Google Gadget Part 2

Twitestract: Getting my Google Gadget prepared to put into the Google Directory and more on how it's constructed.

This is part 2 of a 3 part series on my Aimless Surfing gadget. Part 1 can be found here.

A Google Gadget is simply an XML file that contains the code needed to run the Gadget. The simplest files have some header information and then one Module node. Within the Module node is the metadata for the gadget (user prefs, the title, url for screen shots, the author's contact information, etc.) and the code itself in the Content subnode. More complex gadgets will add UserPrefs section to store end user preferences and other state data. The most basic "Hello World" gadget looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<ModulePrefs title="hello world example" />
<Content type="html"><![CDATA[
Hello, world!

Pulling this apart, we have the first line which just proclaims that this is a piece of XML. In XML files, you tend to see every object encapsulated between an open and close tag. The main object in the Google gadget model is enclosed between a <Module> at the beginning and a </Module> at the end. The Content node is where you place your javascript and html code that will render your gadget. If you've ever created an RSS feed or disected an iTunes feed you will have seen the CDATA tag before. CDATA is used when you have a big chunk of unstructured stuff that you want to put inside your XML document. Unlike everything else in XML is gets wrapped in square brackets. Once you are working in the CDATA part of the gadget, it's the same as building any other web page. You can add <script> tags for your javascript and HTML forms and image tags and whatever else you want.

Google provides a wonky little gadget to help you write basic gadgets and preview them. The Google Gadgets Editor(GGE) always loads itself with the little "Hello World!" code above. It is part of Google's extensive documentation pages on gadget writing. One thing to note, Google is in the midst of migrating from this simple gadget interface to a more complex (and more full featured) instruction set. So, you will see reference in the Google documentation to "Legacy" gadgets. The Aimless Surfing gadget and any gadget you create via the Google Gadgets Editor are Legacy gadgets.

I call the gadgets editor wonky because more than once, it overwrote my changes or my changes wouldn't save. I don't know if it's a byproduct of using Firefox/Mac but if you start writing serious gadgets, you may want to go a different route. By the end of the Aimless Surfing project, I was writing everything in Text Wrangler and then just uploading the files to the GGE for testing. I continued to use the GGE for previewing and because you can publish your code to the Google world and the Internet from the GGE directly. I can see from the documentation, that as you write more complex things, Google expects you to set up a Subversion system (code control). However, they are happy to host the code. When I write my "real" gadgets, I will likely either go this route or host the code at my work domain.

Publishing the code was surprisingly easy. Google asks that you add in some extra meta fields into the beginning of your XML document and they even have a nice set of tricks to keep the act of inserting your email to a published file from increasing your flood of inbound spam. After adding the requested fields to the <Module Prefs> section of my file, I was able to publish via the menu in the GGE. Publishing was simply reading an agreement and supplying the url where my XML file lives.

Once I get confirmation that the gadget is accepted to the directory, I'll post the last in this series and discect the code.

Sunday, March 15, 2009

Open Source Business Model Thoughts

Twittestract: Sunday Musing is about using open source software in a business setting. It's not really free, but it has its place.

For anyone who is trying to maximize the value of their IT expenditures, the notion of free software is attractive. As Microsoft and some of the other vendors like to point out, "free" does not really mean free. In many cases, the licensing costs (the free part of open source) are only a small part of the total cost of a project. The consulting fees, infrastructure and labor costs to implement the software can dwarf the licensing, even when working with a traditional vendor.

The message here is that we still have to look at the total cost of the projects. There will be times when paying the licensing fees for the comfortable, well known software is the best and safest way to get our organization back to its "real" work.

In particular situations, though, going with open source is still attractive:
  • If you truly have no cash money: the trade off with open source has always been time. Red Hat and other early pioneers in the field discovered that consulting and paid support for free software was a valid business model. There is a large population of people for whom technology is still a hobby. They are more than willing to test software, to improve that software and to tinker. These people are not going to pay for support, but the will invest large chunks of time to get things working. And they are likely to publish their findings in a public place. If you or your organization have no cash but can find time to invest, you can have stable, world class systems for "free"
  • If you are anti-big business: some organizations need to be open source because it supports a philosopical part of the mission. It gives your organization credibility with those who believe that the big business software companies are evil. Be careful here though: IBM, Microsoft and Novell spend money to support open source initatives. Any message you craft around your open source usage can sound hypocritical to those who know about this relationship.
  • If you control the whole organization or are starting from scratch. By control, we are speaking of the computers and the software that runs on them. Many organizations who want to explore open source find that they have one or two pieces of software that do not have open source equivalents. This makes an open source implementation more difficult or at least less comprehensive (e.g. just replacing the email software instead of the whole operating system).
  • If the hardware is old: which is especially true of operating systems. In general, though, open source software packages run at an acceptible speed on older/less powerful hardware. Hardware does have a finite life, though and will fail at some point. Take proper precautions to protect data.
  • If you're collaborating using main stream standards: email, html, pdf, etc. An early development when open source software became a viable alternative was that it could read and write the documents produced by proprietary software systems.
Hopefully some ideas to help you think about this issue. For most organizations, a mixture of open source and paid license software is probably best. As IT matures as a business function we need to focus on business problems. The tools we use to solve those problems are unimportant to the organization. By considering all alternatives, though we can be sure that we are presenting the best solutions.

Tuesday, March 10, 2009

The Aimless Surfing Google Gadget

I think this will be probably a multi-part series on this gadget and how I went about writing it.

Twittestract: A Google gadget that creates random url's and then provides a link to their destination. This should help people surf the web more aimlessly.

As I was completing my recent discussion of link shortening, I became curious about what would happen if you entered a random set of characters after the url. Sure enough when I did that, I was sent to a random site. This gave me an idea for a Google Gadget. I need to create some Google gadgets anyway for work, so I thought this would be a great way to learn how to do them. The idea was to create a random string of characters between 1 and 5 characters in length and then redirect the user to that site. I was wondering how many times I would encounter a dead link when I stumbled upon this site about tinyurl whacking which answered a lot of my questions about how the strings are formed. The tinyurl whacking site was doing what I wanted the Google Gadget to do but manually. So, my idea wasn't original at all, but I am improving something. The author of that site cautioned that you never know what is on the other side of a link. After a few missteps of my own, I realized that you don't really want to be tinyurl whacking with your mom watching over your shoulder.

The gadget itself has two controls, a drop down list for the number of characters in the random string and a button to generate a new random string. TinyUrl allocated all of the one character strings and then the two character strings and is now populating 5 and 6 digit strings. Since there are 62 possible characters per place I think that means that TinyUrl is referencing over nine hundred million links. Hopefully, that is enough to give you a truly random experience.

So, as often happens with software, the Gadget got a little more complicated when I added the preview function. I now wanted to not only create the url for tinyurl but preview the url it points to out in the big wide Internet. Thankfully, someone has already done some work here as well, so using Embiggen and dissecting that to get to Dapper , I was able to utilize a web service that would grab the tinyurl preview link and let me display it. So, that's what I've done. If you are just interested in grabbing the Gadget and don't care about how I created it, you can grab it from the link below. A big warning, though. Big warning: there is some nasty/offensive/virus-laden content on the other side of tinyurl links sometimes. If a proposed link looks suspicious, then use the "Make Another" button to generate a new link. Here is the screenshot (I've also added the gadget itself to the sidebar for the time being).

This is a link to the "Add this Gadget to my Webpage" and one to "Add the Gadget to my iGoogle page"

If you're interested in how I created this or want to follow my progress of adding this gadget to the Google Directory, check back in a few days and I will explain the code and some of the issues I faced writing the gadget. This little toy aside, I think I have the basics down now for creating some useful Gadgets to use on my website or to distribute.

Thursday, March 5, 2009

Link Shortening and Traffic Monitoring

Twittstract: How to use link shortening to track traffic to your site and to track who clicks on all of those links you've been posting to other sites.

Link shortning services are starting to become pretty important to sharing. With the advent of twitter, (perhaps the original) seems to be a waste of characters when services like and save those last few characters so that you can make your witty point or to get your message out to your members/followers.

In normal person terms, a link shortener is just a redirect to your site. Instead of some long, crazy link such as you can present your twitter followers or your email blast recipients with a nice or even a nice which can fit better into your blog post or email blast or twitter update (see my caution about "readable string" below). When someone clicks on your link, they are taken first to the redirecting site and then off to the link you want them to see. If you are fortunate to work for an organization with a short domain name, you can even create your own link shortening service for use by your staff or customers. I mean, which would you rather look at:


Technology wise, a link shortening service is just a webpage, a database and a random character generator.

It used to be that you could embed javascript into a tinyurl which was handy for tracking codes or other intersting tricks. But, over time I guess that "feature" was abused so, now it's url's only. However, there are still ways to use link shorteners to derrive some information about who clicks your links. For shortened links that you want to direct back to your Google Analytics based site, it is pretty easy. Google makes a link building tool, that will embed information that shows up in your analytics reports to help you know where a click-through originated. Using that tool, I made a link that looks like this:

Disecting the link (the interesting stuff is after the ?) I have told Google that I want the link to appear as if it came from twitter, that the campaign name is Test and that the medium is web. After I put this link through the website it becomes and it goes to the homepage of this blog (apologies if you are reading this in a few months and you get redirected to a more current post). However, the underlying tracking data is retained. This becomes really powerful if you want to test different marketing media. For instance, no one will type this long url:

if I have printed it in the March magazine but they might be willing to type (use the "Optional Custom name" feature) which will not only take them to the blog, but will record that they came from the ad in the March magazine. Note well, the link shorteners work on the principle that 6 character long strings of 60 combinations per character is a gigantic number of combinations (I think there's a factorial involved). However, now that I've taken the character string of "MarchMag" over at, you cannot use it. So, pretty soon, this feature may become worthless for this purpose. Go ahead, click on the links, and then I will post what the Campaigns section of the Traffic Sources reports looks like.

The other way to use link shorteners is to find a way to track the traffic that you send to other sites. Remember that each click will first go to the link shortening site and then off to its destination. If you want to measure the effectiveness of various campaigns or word phrases to get people to click a link then measuring traffic at the shortening site can be valuable. However, unlike the previous example, you aren't getting any traffic on a site you own, so you cannot see the traffic. Fortunately, people smarter than I have decided this is important and already offer the ability to track the redirects. The site we've used in the examples, does it. Other sites that offer similar tracking features are,, and (I'm sure there are more, why not leave a comment with your favorites). Notice something about and that they don't end in .com or one of the familiar 3 character endings. Turns out that each country has been granted a 2 character extension for URL's. In America, we have .us but it is overshadowed by .com, .org and .net. The .ly code that uses is the country code for Lybia and the .im code is for the Isle of Man. Using two character country codes to make intersting url's is probably a whole blog post in itself.

Note to early readers of this post: go ahead, click on the links. It will help use create some pretty graphs to insert into the post so that people can see how all of this works.