Today is a big day for me for two reasons:

1) One year ago today, I moved with my family to Silicon Valley from Washington, DC, a city we love and miss very much.

2) Also today, DotNetNuke Corp., the company I co-founded, announced that we have closed on our Series A round of venture funding.

Adjusting to Silicon Valley has had its challenges. Having to drive everywhere after getting around mostly on DC’s Metro was the hardest adjustment. Our friends, DC’s breathtakingly beautiful monuments, abundance of fantastic (and free) museums and overall character of the city are all missed. That my daughters were both born at George Washington University hospital in DC means that my family has an unbreakable bond with the city and we expect to live there again in the future (perhaps when I run for Congress, a dream of mine).

The past year in Mountain View has been a year of discovering California, rekindling old friendships, making new ones, enjoying great weather and the many playgrounds in this area. We are slowly adapting and beginning to enjoy what Silicon Valley has to offer. I’ll be candid, reaching the funding milestone is certainly going to make a difference in terms of quality of life.

All startup entrepreneurs make sacrifices to see their dreams come true. In this business, it’s called “skin in the game.” I can say unequivocally that my co-founders (Shaun Walker, Joe Brinkman and Scott Willhite) and I have a lot of skin (and probably additional layers) in this game. Building a company based on a free, Open Source product is challenging, to say the very least. But we had a vision and continued to persist despite the challenges we encountered. Raising growth capital was one of them.

In the summer of 2007, Shaun and I made several trips to Silicon Valley to meet with VC‘s. Everything that followed was textbook venture fundraising. We had many positive meetings but no takers. Our team quickly realized that we were missing three things:

  1. Feet on the ground. It is expensive to travel to Silicon Valley every couple of weeks for meetings (Note: Most VC’s that fund Open Source companies are located in Silicon Valley). It is also a huge disadvantage that you cannot meet with an interested investor at short notice. And finally, missing out on the powerful network effect of Silicon Valley is a serious impediment to raising capital here.
     
  2. Solid Business Model. While we had achieved tremendous success as the #1 Open Source web project on the Microsoft stack, the business model we articulated to VC’s was not polished enough to merit their serious interest.
     
  3. Experienced Advisors and Management. VC’s invest first and foremost in people. Having a solid management team in place is critical for the success of any company, and more so for venture-funded companies. While our team is very strong technically, we did not have the depth and breadth of business experience needed to take the company to the next level. (While DotNetNuke Corp. is the fourth company I have founded/co-founded and the third of my companies to receive investment capital, I still have much to learn.)

We decided to address these three issues as best and as quickly as we could.

Since I had the lead role in the fundraising process and did not have significant constraints on where my family lived, moving here was a no-brainer for me. While it was a major move, I was determined to do what needed to be done to ensure the success and longevity of our business. I did not see any way we could be successful at raising capital without having a local presence in Silicon Valley. Savi, my wife was supportive as ever in this decision. The other co-founders and I agreed on a course of action. I took on the role of CEO with a charge of focusing on raising capital and prepared for the move.

But there were more challenges. Savi was pregnant with our second child due in late October. Gia, our first daughter, was three years old at the time and we had to find a Montessori in Silicon Valley that met the standards for teaching and cultural diversity that we had become accustomed to in DC. Also, since we paid our own health insurance, we could not make the move until after the baby was born, otherwise we would have to assume the full cost of the delivery — totally impossible for us (and most people, I would imagine). We decided to wait until January 2008 to move.

We made a couple of trips to the Bay Area, checked out schools and settled on a Montessori in Mountain View. With that done, it was now time to find housing. We did not find anything suitable during our visits. It was extremely challenging trying to find housing in Silicon Valley that met our requirements remotely from DC. A couple of these requirements greatly restricted our options and I remember checking CraigsList every 20 mins., all day, hoping to find a place we could call home. We were getting very frustrated and then things took a turn for the worse.

On the evening of Sept. 5, I accompanied Savi for a routine pre-natal check-up, while my parents who were visiting from India at the time, watched Gia. The news we got from the doctor was scary. We were told that we had to go straight to the hospital as our baby was going to arrive five weeks ahead of schedule. With a great sense of fear, we got Savi admitted and began a very long night. In the morning, the chief resident told us that the baby was in distress and they had to deliver. Kaamya was born on Sept. 6. I got to hold her for one minute and then she was taken to the NICU (Neo-natal Intensive Care Unit). The next 12 days were a blur. Savi and I took turns keeping her company in the NICU hoping and praying that she would be OK. Our prayers were answered. Today, Kaamya is a healthy, happy and active one-year-old.

After Kaamya’s birth, we were able to move to Silicon Valley a little sooner than planned. Housing was still an issue. On a whim, Savi looked at short-term rentals, and found a place in Mountain View that matched all our criteria, but was only available for 3-6 months. My brother-in-law who lives in San Jose checked out the place, we found it acceptable and signed the lease. We decided that we would move immediately after my Las Vegas trip for Open Force ’07.

Thus, on Nov. 25, 2007, we arrived in Silicon Valley.

I immediately began connecting with and setting-up meetings with people/firms to enable progress on the fundraising front and also to identify and work with business advisors and potential additions to our management team. Larry Augustin, founder of VA Linux and one of the most respected names in the Open Source world, was already our business advisor. He referred me to several exceptional people and firms, one of them being Navin Nagiah. At the time, Navin was CEO of Cignex, a company that specialized in services around Open Source CMS solutions.

I met Navin at a Starbucks in San Jose on Dec. 18, 2007. Almost immediately, Navin saw DotNetNuke’s tremendous potential. I too saw how Navin’s experience in the Open Source Enterprise CMS space would be valuable for DotNetNuke Corp. We started meeting regularly 2-3 evenings a week. Within a couple of months, Navin formally became our business advisor.

Working closely together, and with the support and input of the other co-founders, we developed a solid business model and investor pitch. We were a little slow off the blocks, but with all three of the missing items addressed, we were confident that getting funded was an inevitability. We made rapid progress through the summer culminating in today’s announcement. (I have been working on collecting my thoughts around what we learned in the process and will blog about it in the future.)

I am incredibly gratified to have reached this major milestone. There are many, many people who made it possible, many of them are behind the scenes. To all of them, I am grateful. A special thanks to my family and the families of my co-founders, who stood by us and supported us through thick and thin (mostly thin) as we made it to this point. And thanks to everyone in the DotNetNuke community who have time and again demonstrated support for DotNetNuke Corp. and confidence in our product — DotNetNuke.

This is the first step in a journey. We have a great team and I am looking forward to doing my part in building a very successful and profitable company while making DotNetNuke the platform of choice for .NET-based websites. I am very excited for the future.

Below is a link to Shaun’s keynote from the recent DotNetNuke OpenForce ’08 conference. It will shed some light on where we are and what our vision is for DotNetNuke Corporation.

 

DotNetNuke-OpenForce-KeyNote.pptx (1.45 MB)

This is a defining moment for America and I am proud that my country has chosen such a transformational figure as Obama to be its next President.

I was moved and inspired by his speech tonight and look forward to doing my part in moving the country forward. As a father of two little girls, I found his future-looking questions most inspiring:

“So tonight, let us ask
ourselves – if our children should live to see the next century; if my
daughters should be so lucky to live as long as Ann Nixon Cooper, what
change will they see? What progress will we have made?”

After eight years of failed leadership, I am very excited and hopeful for the future of this great nation that I love.

“This is our chance to
answer that call. This is our moment. This is our time – to put our
people back to work and open doors of opportunity for our kids; to
restore prosperity and promote the cause of peace; to reclaim the
American Dream and reaffirm that fundamental truth – that out of many,
we are one; that while we breathe, we hope, and where we are met with
cynicism, and doubt, and those who tell us that we can’t, we will
respond with that timeless creed that sums up the spirit of a people:

Yes We Can. Thank you, God bless you, and may God Bless the United States of America.”

Here’s an excellent analysis of the speech by Bert Decker:

Transformational Election – Transformational Speech!

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 element:

Web
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\ServiceHosting\v1.0@InstallPath)

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

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.

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 id="MyScript" src="http://www.foo.com/myscript.js?obj1=ABC&obj2=XYZ" type="text/javascript"></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 “&”

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 src="http://www.foo.com/myscript.js#obj1/ABC/obj2/XYZ" type="text/javascript">

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.

© 2012 TechBubble Suffusion theme by Sayontan Sinha