Sunday, June 10, 2007
by Nik Kalyani
Sunday, June 10, 2007 11:52:44 AM (Pacific Standard Time, UTC-08:00)

Last week was a big one for DotNetNuke with two major announcements:

Visual Studio Magazine Editor's Choice Award for 2007

This was a pleasant surprise, especially considering that last year's winner was SharePoint and this year's other winners are Microsoft Expression Blend and Microsoft Expression Silverlight. You can read all about it here.

OpenForce '07 Conference

I am very excited about the DotNetNuke OpenForce '07 Conference for three reasons:

  • It's the first major mainstream event for DotNetNuke, highlighting how far the project has come and how much it has grown;
  • It's co-located with the DevConnections conference which is one of the premier conferences for Microsoft technology professionals; and
  • It's in Vegas!!!!

I will be presenting one session and participating in one panel discussion. My session is:

DotNetNuke Modules: Beyond the Browser
DotNetNuke modules are generally designed to function with a web browser as a client. In this session you will learn how to extend your module beyond the browser and onto the desktop. We will review how to use the “Widget Toolkit” to create Vista Sidebar Gadgets and widgets for various other platforms that act as clients for DotNetNuke modules. You will learn how these same techniques can be used to quickly extend DotNetNuke to mobile clients.

The panel I will participate in is:

DotNetNuke – The Road Ahead
In this panel discussion, the four co-founders of DotNetNuke Corporation will share their vision for the company and the DotNetNuke Open Source project. The resources, approach and business model required to manage and grow a large Open Source project such as DotNetNuke are substantially different than those required for a commercial software company. Get an inside look at how DotNetNuke Corp. is addressing today’s challenges while preparing for the future.

I hope to meet many from the DotNetNuke community at the conference.

by Nik Kalyani
Sunday, June 10, 2007 11:25:34 AM (Pacific Standard Time, UTC-08:00)

When importing photos from a digital camera or phone, the Windows import wizard allows me to give all the files a more descriptive name than "DSC10011.jpg." The problem I run into all the time is that I don't import photos more than once a week and this makes a common filename prefix pretty useless since the imported sets may contain multiple events.

Although it has bugged me to no end, until today I left this at the default and organized files manually into more descriptive folder names. Today I decided to fix this annoyance. I briefly checked out BatchPhoto and a couple of other utilities and concluded that they were all overkill. So I wrote a quick console app to take care of this problem.

FileNamer (not feeling very creative today, hence the lame name) is a very simple app that will accept one parameter -- a local or UNC path. It will then recurse every folder at that path and rename most photo and movie files (*.jpg;*.jpeg;*.mpg;*.mpeg;*.avi;*.wmv;*.mov) with the same name as the parent folder followed by a numeric serial number. If your photos are in C:\Docs\Picnic, the photos in this folder would be renamed to Picnic 0000.jpg, Picnic 0001.jpg etc.

The program has very limited error handling and I have no idea what happens when there are more than 10,000 files present (you should not have that many files in the same folder anyway). You will need .Net 2.0 to run the app. No installation is needed -- just copy FileNamer.exe to a location of your choice, fire up a command window and type:

FileNamer <path to rename>

The zip has the source which you can ignore if you don't intend to modify. Use the program at your own risk and be sure to test it with some junk files first.

 

FileNamer Source.zip (5.43 KB)
#    Comments [0] - Trackback    

 Tuesday, June 05, 2007
by Nik Kalyani
Tuesday, June 05, 2007 8:52:46 AM (Pacific Standard Time, UTC-08:00)

When opening an HTML file that sits on your desktop, IE will throw a security warning which you must click before the page is rendered. This is annoying, especially when the file is your own creation and there is no security risk. You can suppress the security warning by adding the "Mark Of The Web" (MOTW) to the top of your HTML document:

<!-- saved from url=(0014)about:internet -->

After adding this, you can launch the HTML file locally without any annoying warnings.

 Thursday, February 08, 2007
by Nik Kalyani
Thursday, February 08, 2007 6:49:51 PM (Pacific Standard Time, UTC-08:00)

As AJAX and Javascript widgets get more popular, it is not unusual to see Javascript from multiple parties running on the same page. This greatly increases the chances of collisions in variable and function names. For instance, two unrelated scripts might define the function “modifySomething()”. In this case, the last definition of “modifySomething()” on the page will be the one called. This is an invitation to disaster.

One way to prevent this is to practice defensive Javascript coding through the use of namespaces. In .Net and Java, the use of namespaces clearly delineates classes and prevents collisions. While Javascript does not have a built-in mechanism for using namespaces, it is relatively easy to implement them. In fact, just about every library such as Dojo Toolkit, Yahoo UI and ASP.Net AJAX provides a mechanism for registering and using namespaces in Javascript. This is fine if you are using one of the libraries, but if you are not, then how do you go about creating namespaces in your Javascript code. Read on.

Let’s create a simple “Cube” class with properties of Width, Height, Depth and methods grow() and shrink(). This class must reside in the “Speerio.Web.Solids” namespace.

If we try something like this: 

Speerio.Web.Solids.Cube = function(width, height, depth)
{
      this.width = width;
      this.height = height;
      this.depth = depth;
}

…we get an error. This is because Javascript expects to find an object “Speerio”, with a child object “Web”, which has a child object “Solids”. To make this work, we will first need to define a way to tell Javascript that the “Speerio.Web.Solids” hierarchy exists. We can do this by creating a function to create the hierarchy like this:

function $register(ns)
{
    var segs = ns.split(".");
    var namespace = window;
    for(var s = 0; s < segs.length; s++)
    {
        var seg = segs[s];
        if (typeof(namespace[seg]) == "undefined")
            namespace[seg] = new Object();
            
        namespace = namespace[seg];
    }
}

This function adds our namespace as a hierarchy of objects that are children of the top-level “window” object. It only works if the object has not already been defined, so it’s OK to register the same or similar namespaces multiple times. Now, it’s a simple matter of calling the function:

$register(“Speerio.Web.Solids”);

Once the namespace is registered, we can use it in our code as we would any other object. Since we are talking about defensive coding, let’s go further and define the “Cube” class.

Speerio.Web.Solids.Cube = function(width, height, depth)
{
       this.__width = width;
       this.__height = height;
       this.__depth = depth;
}
 
Speerio.Web.Solids.Cube.prototype =
{
       shrink : $Speerio_Web_Solids_Cube_Shrink,
       grow : $Speerio_Web_Solids_Cube_Grow,
       getWidth : $Speerio_Web_Solids_Cube_GetWidth,
       setWidth : $Speerio_Web_Solids_Cube_SetWidth
}

We start by defining the Cube class whose constructor takes three parameters — width, height and depth. In the definition of the class, these parameters are used to initialize properties __width, __height and __depth respectively. Why the underscores you ask? Mainly to discourage them from being directly modified. Javascript does not provide a set/get mechanism so to protect properties from being set directly, a small layer of obfuscation is necessary. It is not fool-proof…anyone studying your code will see this right away. However, it should be obvious that the intent is to protect the integrity of the data and prevent it from being modified directly.

Next, we define the various methods for the Cube class. For each method, the “public” method name is clear and simple. The actual method that does the work has a longer name. I used the following convention:

  • prefix all class methods with $
  • append the namespace and class name, replacing periods with underscores
  • append the name of the method, prefixed with “Get” or “Set” if the method is intended to be a property getter/setter

Now, we can define the actual methods:

function $Speerio_Web_Solids_Cube_Shrink()
{
    if ((this.__width > 1) && (this.__height > 1) && (this.__depth > 1))
    {
        this.__width--;
        this.__height--;
        this.__depth--;
    }
}
 
function $Speerio_Web_Solids_Cube_Grow()
{
    this.__width++;
    this.__height++;
    this.__depth++;
}
 
function $Speerio_Web_Solids_Cube_GetWidth()
{
    return(this.__width);
}
 
function $Speerio_Web_Solids_Cube_SetWidth(w)
{
    if (w > 0)
       this.__width = w;
}

And finally, some code to test the class:

var cube = new Speerio.Web.Solids.Cube(10, 10, 10);
cube.grow();
cube.grow();
cube.shrink();
alert("The cube width should be 11; the actual value is " + cube.getWidth());
cube.setWidth(100);
alert("The cube width should be 100; the actual value is " + cube.getWidth());

The above namespace-based class definition protects your code when it is running on a page where code from other parties is also executing. In addition the code is readable and likely easy to manage, even if months have elapsed since you last took a look at it. There may be a small performance hit the first time the script file is downloaded to the user’s browser due to the verbosity, but I’ll take verbose code that works over concise code that breaks the page any day.

#    Comments [2] - Trackback    

 Tuesday, February 06, 2007
by Nik Kalyani
Tuesday, February 06, 2007 7:56:25 PM (Pacific Standard Time, UTC-08:00)

Steve Jobs' rather unassumingly titled Thoughts on Music packs quite a punch. In what is surely going to be one of the most linked-to URL’s on the Internet, Jobs openly advocates an end to DRM-crippled music. Reactions from bloggers such as Don Dodge and Fred Wilson are positive and commend Jobs on this move.

Until now, it has been generally accepted that Apple uses DRM on iTunes tracks to protect its control on online digital music distribution. Turns out that Apple’s research data shows the average iPod has only 22 songs or 3% of music that comes from the iTunes store. So while iTunes and iPod appear to have been mega successes, it’s only the tip of the iceberg. The music companies require Applie to DRM-protect iTunes music and this constrains the market to those willing to live with DRM, liberal as the iTunes DRM policy may seem.

Jobs does a great job of educating us on how completely unbalanced and illogical the music industry’s approach is to online music distribution:

Why would the big four music companies agree to let Apple and others distribute their music without using DRM systems to protect it? The simplest answer is because DRMs haven’t worked, and may never work, to halt music piracy. Though the big four music companies require that all their music sold online be protected with DRMs, these same music companies continue to sell billions of CDs a year which contain completely unprotected music. That’s right! No DRM system was ever developed for the CD, so all the music distributed on CDs can be easily uploaded to the Internet, then (illegally) downloaded and played on any computer or player.

He takes a jab at European countries such as France who have legislation requiring companies to make DRM-enabled music playable on any device: 

Much of the concern over DRM systems has arisen in European countries.  Perhaps those unhappy with the current situation should redirect their energies towards persuading the music companies to sell their music DRM-free.  For Europeans, two and a half of the big four music companies are located right in their backyard.  

Overall, this is an excellent P.R. tactic by Jobs. With this one post, adverse public opinion will shift away from Apple and on to the music industry. Of course, this will not make much of a difference since the dinosaurs running  industry are too fixated on the old to look at the huge opportunities that await a music industry that is free.

Under a free and fair system, there will be no incentive for most people to download sub-standard quality music from questionable sources with embedded junk in the files. The pace of innovation in the music player business will increase as the market size increases. Artists will be fairly compensated for their work and the music industry will get fairly compensated for its marketing efforts. To make this happen, all the industry has to do is build on Apple’s successful 99 cent model and either remove DRM completely, or include DRM in such a way that from the perspective of the purchaser, the DRM does not exist. Another way to look at it is to change the positioning altogether — instead of Digital Rights Management, which serves to limit and take away rights, it should be DRG – Digital Rights Grant. By purchasing a piece of content, you are effectively granted the right to play it on any device that you have in your control.

This is not a very difficult technical problem. Most digital devices today have a configuration function which can be used by the consumer to customize various aspects of its operation. Why not allow the consumer to enter in a “key” of their choice. (Something akin to a password, but with limitations on the characters and the length allowed.) The consumer would enter the same key on every device or media playing software in her/his household. When purchasing digital content (the scheme can be applied to music, video, eBooks), the consumer provides the same key to the online store which locks the content with that key before allowing the consumer to download it. The content can then only be played on any device programmed with that key. This is the essence of DRG — the consumer is freely able to play the content he/she purchased on ANY device under her/his control. If he chooses to illegally share the content, he will also need to also share his key, and the other person(s) will need to configure his devices to use that key. It is certainly conceivable that those intent on stealing music will collude and share keys, but this can be mitigated by retiring keys that are known to be on illegal sharing sites. The music pirates are then left with a static collection of content. That should get boring very quickly.

I realize this is a gross over-simplification of the cryptographic controls that would be necessary to implement such content protection, but the main point I’m trying to make is that a simple and elegant system is possible if all the players cooperate. Device manufacturers and digital content distributors need to agree on a system that is easy for consumers to use. By focusing on “granting” rights for those who want to have legal content, instead of “restricting” rights for those bent on abusing the system, the industry can gradually change the game. If it has the will, there are plenty of super-smart people out there that can create a system that really works.

I truly believe that consumers will be quick to vote with their wallets for any system that makes content available under a fair pricing scheme and without limitations on playback on their devices. Jobs knows this and although it’s an uphill task, this open letter is a great first step in getting the music industry to wake-up to the realities of content distribution in a digital world. Whether the outcome is totally DRM-free music or music with real “fair play” rights, anything is better than the status quo.

#    Comments [0] - Trackback    

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: 204
This Year: 22
This Month: 0
This Week: 0
Comments: 233
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 2008
Nik Kalyani
Sign In
All Content © 2008, Nik Kalyani