Saturday, November 01, 2008
by Nik Kalyani
Saturday, November 01, 2008 1:37:21 PM (Pacific Standard Time, UTC-08:00)

In trying to use an existing VS2008 Project as a WebRole in a Windows Azure Solution, I discovered that the project did not appear as a candidate for selection from the Roles > Add > Web Role Project in solution menu. All the Azure documentation indicates that there is no special requirement for a web project to be a candidate for Azure, so I found this to be odd. The solution, as it turns out, is pretty simple:

1) Open the existing project's .csproj file in a text editor.

2) Add the following two lines of code anywhere within the first <PropertyGroup> element:

    <RoleType>Web</RoleType>
    <ServiceHostingSDKInstallDir Condition=" '$(ServiceHostingSDKInstallDir)' == '' ">$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\ServiceHosting\v1.0@InstallPath)</ServiceHostingSDKInstallDir>

Reload the project and it now becomes available as a WebRole.

 Saturday, August 30, 2008
by Nik Kalyani
Saturday, August 30, 2008 7:54:35 AM (Pacific Standard Time, UTC-08:00)
The only thing missing from my BlackBerry Curve 8310 (service with AT&T) has been video. It did not make much sense since there is a 2MP camera on the device. Posts on the CrackBerry forums pointed to availability of this feature in v4.3.1 of the device OS (now called v4.5.0). Here is a list of all the new features in BB OS 4.5.

Since AT&T takes an ungodly amount of time to release new software through its site, and I wanted the video feature, I decided to find the software and do the upgrade without AT&T's blessing. My upgrade went smoothly and my BlackBerry now has some shiny new features. I have documented the procedure here. It worked for me but may not work for you. In fact the likelihood is high that you will have a BlackBrick on your hands when you are done. Proceed with caution. Think carefully before doing this. Did I mention you could brick your BlackBerry? You have been warned.

IMPORTANT NOTE: If you are reading this after Sept. 2008, there is a good chance that the software is now supported and available with U.S. carriers. Check your carrier's site and if they have the update, ignore these instructions.

The upgrade process itself is very simple:

1) Make a complete backup of your BlackBerry with the existing version of your BlackBerry Desktop software.

2) Download and install the latest version of the BlackBerry Desktop which is Version 4.6

Download the software here: BlackBerry Desktop v4.6 (from BlackBerry site)

Quit the BlackBerry desktop software if it is running on your PC and untether your phone if it is connected to your PC. Install the software.

3) Download and install the BlackBerry OS v4.5 to your PC

Download the software here: BlackBerry OS v4.5 (from Vodafone Germany site)

Note the difference -- step 2 is to install the "Desktop" software to the PC. This step is to install the "OS" software to your PC. When you perform this install, you will not find any new app icons.

REBOOT the PC.

4) Remove Vendor.xml

If the file C:\Program Files\Common Files\Research In Motion\AppLoader\Vendor.xml is present, move it to some other folder. I did not perform this step because I got distracted in the middle of the upgrade but there seem to be no harmful consequences. Your mileage may vary.

5) Perform the upgrade

Turn off the Radio and Bluetooth on your BlackBerry Curve 8310. Tether the phone to the PC with USB and start the BlackBerry Desktop software. The software will recognize that the phone needs to be upgraded and will start the process. Some things to remember:

- Choose Advanced... so you can customize what gets installed. I de-selected all the languages and added "Documents to Go"
- The process can take from 30-60 mins and there is no progress indicator
- When the upgrade is done you will have to go through the Setup Wizard, but all your settings, apps and data will be preserved.

Overall, I am very happy with this upgrade. I now have video (albeit at a maximum resolution of 240 x 180), a much snappier photo app with geo-tagging and enhanced browser navigation. I am sure there are other things which I will discover as I use the phone and I'll update if there's anything interesting.
 Friday, August 22, 2008
by Nik Kalyani
Friday, August 22, 2008 5:09:46 PM (Pacific Standard Time, UTC-08:00)
Joe Brinkman posted a technique to pass parameters to Javascript script files. The approach is simple -- append a standard querystring to the script URL and obtain the parameters by locating the script element using the ID attribute, and parsing the key-value pairs from the "src" attribute. A sample usage is like this:

<script type="text/javascript" id="MyScript" src="http://www.foo.com/myscript.js?obj1=ABC&obj2=XYZ"></script>

This is a great approach and works well for most scenarios, except in those situations where HTML 4.01 Strict markup is desired. In this case there are two problems that would cause validation to fail:

1) The HTML "script" element does not support an ID attribute. Yes, this is true. Verify it for yourself here.

2) The ampersand ("&") character is a predefined entity and must be expressed as an entity reference "&amp;"

So, is there a simple way to work around this issue. Of course, otherwise the title of this post would be totally false advertising.

Here is the revised code snippet I propose in lieu of the one above:

<script type="text/javascript" src="http://www.foo.com/myscript.js#obj1/ABC/obj2/XYZ"></script>

Let's break it down.

1) The ID attribute has been removed. Even without the ID attribute there is still a simple way to reference the script element. The trick is to take advantage of the fact that as the browser is rendering the page, it executes JS code immediately when encountered. As a result, if the code in your JS file queries the DOM, the last script element in the DOM is a self-reference (i.e. a reference to the script element that loaded the code being executed). Thus, using document.getElementsByTagName("script") and referencing the last element in the array, provides an easy way to get the current script reference.

2) The standard querystring separator "?" has been replaced by "#". This is not necessary, but something I did for semantic reasons. To overcome the "&" entity issue, I used a slash ("/") character for separating not only key-value pairs, but keys and values too. The reason for this will become evident in a bit, but since I modified the querystring to something non-standard, I felt it was important to also remove the "?" separator which is a prefix for querystring. Instead, I used a hash ("#") character which is a pointer to a document fragment and does not have any semantic value in the context of a JS script URL. (In fact the JS URL hash technique is a common way to pass data in cross-domain XMLHttp requests for this reason and also because it does not cause a page re-load.)

3) Key-Value pairs. The last change I made is to use a path-based approach to key-value pairs instead of Key=Value format. I did this because it is a common technique in RESTful URL's, is easier to read and much simpler to parse. In fact, using a single "for..." loop, it becomes a trivial task to create an associative array of all the parameters for ready reference.

Here's the code wrapped into a function with a sample call:
var myParams = getScriptUrlParams();
alert(myParams["obj1"]);
alert(myParams["obj2"]);

function getScriptUrlParams()
{
var scriptTags = document.getElementsByTagName("script");

// This code is assumed to be in a file so the "src" attribute
// is guaranteed to be present...no error-checking is needed
var urlFrags = scriptTags[scriptTags.length-1].src.split("#");

var urlParams=[];
var urlParamRaw = [];
if (urlFrags.length > 1)
{
urlParamRaw = urlFrags[1].split("/");
if (urlParamRaw.length >= 2)
{
for(var param=0;param<urlParamRaw.length;param+=2)
urlParams[urlParamRaw[param]] = (urlParamRaw.length >= param + 1 ? unescape(urlParamRaw[param+1]) : null);
}
}

return(urlParams);
}


What do you think? Is this a simpler approach or is it more complicated? Are there other techniques for working around the XHTML validation issue.

 Monday, August 18, 2008
by Nik Kalyani
Monday, August 18, 2008 1:51:10 PM (Pacific Standard Time, UTC-08:00)
Om Malik posted about the NSF website chronicling the birth of the Internet. What a cool site. I skimmed it briefly and found this entry for 1980s:

In the mid-1980s, NSF decided the time was right to try to link its regional university networks and its supercomputer centers together. This initial effort was called NSFNET. By 1987, participation in the new NSFNET project grew so rapidly that NSF knew it had to expand the capacity of this new network. In November of that year, it awarded a grant to a consortium of IBM, MCI, and a center at the University of Michigan called Merit to create a network or networks--or internet--capable of carrying data at speeds up to 56 kilobits a second. By July 1987, this new system was up and running. The modern Internet was born.

I came to the U.S. on Sept. 3, 1987 from India to begin my Bachelor's degree at Western Michigan University. I remember logging on to the Merit network that same month from the campus computer lab. Since, at the time, everything about computers was totally new to me (other than the Sinclair ZX Spectrum+, my home computer), I had no idea until today that this was a brand new network and more importantly, the first "network of networks."


 Sunday, August 17, 2008
by Nik Kalyani
Sunday, August 17, 2008 5:36:18 PM (Pacific Standard Time, UTC-08:00)

I have been thinking on and off about Posterous since I first used it and decided to put my thoughts down in a post. Nischal asked the question "Would you stick to Posterous?" My answer today is "No" for the simple reason that it's difficult to make the commitment to use Posterous as my primary blog until custom domains are supported. Redirects just don't cut it.

Also, the brutally honest truth is that Posterous is on borrowed time. If the service does not start innovating rapidly, get huge user adoption and then create a significant reason for users to stay, it will soon become irrelevant. Its primary feature -- email to blog -- is not enough of a differentiator because technically it is not very difficult to implement and other blog engines will be quick to offer it to their users (some already do).

I think Posterous should be thinking about ways in which they can continue to stay relevant and even attractive to bloggers by doing the exact opposite of what they are doing right now. Instead of trying to be a blogging platform, they ought to focus on being an email publishing utility very much like FaceBook is positioned as a social utility. The AutoPosting capabilities available on the service are a great way to start, but they could be so much more. Instead of just supporting vanilla posts with title and body and hosting the photos/media here, they should go all out and implement email to MetaWebLog and other API's. Being able to use email to make a complete, detailed post to WordPress, DasBlog and other blogging engines would be great. Add template, tagging and categorization and it starts to get really interesting.

And while they are at it, they should do it for not just 10, but 100's of other services. Basically, email enable every ProgrammableWeb.com API for which email posting makes sense and that has any kind of traction. That would be killer and greatly increase the barriers for competition as users don't like changing habits unless there is a very good reason. Imagine "posterous" becoming a verb for "posting something to any web service using email." I think this would be a bigger opportunity for the company and allow it to become truly indispensable compared to where it is now -- a "me too" blogging platform which re-posts to other services.

Bottom line, forget the blogging and focus on the email.

RSS feed
Search and Links
Bling

View Nik Kalyani's profile on LinkedIn

Contact me: nik*kalyani.com (replace "*")

TechBubble
www.flickr.com
This is a Flickr badge showing public photos from techbubble. Make your own badge here.
Statistics
Total Posts: 217
This Year: 0
This Month: 0
This Week: 0
Comments: 247
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2009
Nik Kalyani
Sign In
All Content © 2009, Nik Kalyani