iTunes software piracy incentives

People steal software for many reasons. Of course it's generally easier to copy and share your mp3 collection than it is to walk out of HMV without paying for a bagful of CDs. Mailing application serial numbers around is certainly convenient for the morally corruptible amongst us and sharing account details for online systems is a well established practise.

So where does iTunes fit into this battle for moral righteousness? It only takes a casual browse around the iTunes store to see how many people think their pricing structure may help to promote piracy. Let's look at an example:

Lost series 1 Pay £32.99 on iTunes for video quality that is inferior to standard DVD (PAL resolution)

Pay £34.98 on Amazon for the full DVD boxed set

So for £1.99 extra you get a nicely boxed DVD set for your bookshelf that you can watch on a PC, Mac, TV or even projector with no scaling problems whatsoever. Additionally, there is lots of free software that will convert your Lost episodes to a format that can be viewed on any video capable iPod.

There is, of course, convenience to consider. With a few button clicks and a decent broadband connection you can download episodes of Lost directly to your computer and quickly switch them across to your iPod via firewire or USB2. It still seems a ridiculously high price to pay in my opinion when I can get next day delivery from Amazon for a 'real' product. This seems to be the general concensus of the general public too according to the comments that accompany many of the downloads that iTunes offer.

And there's more! Video downloads to the UK from iTunes cost considerably more than from the US. Alarmingly, in the US this same download costs $34.99 - meaning us poor souls in the UK pay almost double for an identical product. Come on Apple, be fair!

It's also bizarre that you are not able to make legitimate backups of your downloaded video to DVD. It seems that the very steps that iTunes are making to try and prevent piracy are alienating many of their potential customers.

Whilst these issues will not convert me to a life of piracy, I will certainly not be using the iTunes service unless some serious changes are made.

Part 4: Implicit types

With C#2, a variable's type must be explicitly declared, some simple examples are:

int clientAge; string clientName = "Matthew"; DateTime currentDate = DateTime.Now;

Notice that we do not have to specify a value for the variable at the point at which it is declared, in the example, clientAge will be assigned a value of zero by the compiler. In C#3, variables may be declared with the var keyword in which case the compiler infers the variable type from the value it has been assigned...but it does this at compile time!

So var is not a variant (it's just a keyword that's not named particularly well) and it's not an object type either.

The following constraints apply to the use of the var keyword:

• var can only be used within a method and not at the class level
  
• Any variable created with var must have a value assigned as part of the declaration

Please see the following code for examples:

class VarSamples {     //This will not compile, the following error will be reported:     //The contextual keyword 'var' may only     //appear within a local variable declaration     var invalidDeclaration;     public void ImplicitTypes()     {         //The compiler will create postCode as a string variable         var postCode = "B12 5HP";         //The compiler will create postCode as an integer variable         var houseNumber = 8;         //This will not compile, the following error will be reported         //Implicitly-typed local variables must be initialized         var streetName;         //Perform operations with var variables.         int nextHouseNumber = houseNumber++;         string formattedCode = "Postcode: " + postCode;     } }

The invalidDeclaration variable will not compile because it has been declared at the class level. This is not allowed for variables declared as var.

The streetName variable will not compile because any variable declared with var must be initialised when it is declared. Otherwise, the compiler is not able to determine an actual type for the variable when it is compiled.

So why do we need var at all?

The var keyword was introduced to support anonymous types that are also a feature of C#3. Anonymous types are described in the next article.

Part 3: Initialising objects

Consider the following simple class definition:

//Simple client class used to demonstate //C#3 object initialisation class Client {     //Read-write property for the client's name     public string Name { get; set; }     //Read-write property for the client's age     public int Age { get; set; }     //Read-write property for the client's height     public double Height { get; set; }     //Read only property that is True for existing     //clients and False for new clients     public bool IsCurrent { get; private set; } }

A constructor has not been explicitly created for this class so the compiler will generate a default, parameterless one for us. This means that an object can be created and properties assigned inthe way that we are currently used to with C#2

//Create a client object using the default constructor Client firstClient = new Client(); //Assign values to the class properties that have public set methods firstClient.Name = "David"; firstClient.Age = 32; firstClient.Height = 124;

However, with C#3, we are now able to create an object using any of the following methods:

//Construct the object by supplying the client Name Client secondClient =     new Client { Name = "Matthew" }; //Construct the object by supplying //the client Name & Age Client thirdClient =      new Client { Name = "Sarah", Age = 21 }; //Construct the object by supplying //the client Name & Height Client fourthClient =     new Client { Name = "Daniel", Height = 131 }; //Construct the object by supplying //the client Height only Client fifthClient = new Client { Height = 108 };

This is essentially identical to creating a client object with the default constructor and then calling each property set method as appropriate. Looking at the disassembled code shows us what isactually happening for these client objects.

Client <>g__initLocal0 = new Client(); <>g__initLocal0.Name = "Matthew"; Client secondClient = <>g__initLocal0; Client <>g__initLocal1 = new Client(); <>g__initLocal1.Name = "Sarah"; <>g__initLocal1.Age = 0x15; Client thirdClient =<>g__initLocal1; Client <>g__initLocal2 = new Client(); <>g__initLocal2.Name = "Daniel"; <>g__initLocal2.Height = 131.0; Client fourthClient = <>g__initLocal2; Client <>g__initLocal3 = new Client(); <>g__initLocal3.Height = 108.0; Client fifthClient = <>g__initLocal3;

As the code above shows, each client is constructed using the default constructor and then the property set methods are called as necessary. Of course, we cannot specify a value for IsCurrent when creating a client object because the set property is marked private (as shown in the first code snippet). Trying to do so will generate a compile time error of something like: The property orindexer ‘Blog.Client.IsCurrent’ cannot be used in this context because the set accessor is inaccessible.

Part 4: Implicit types

Part 2: Automatically implemented properties

C#2 provides the ability to create properties that encapsulate class member variables; the following code provides a simple example:

//Private member variable to store the client name private string name; //Read-write property for the client?s name public string Name {     get     {         return name;     }     set     {         name = value;     } }

The idea here is that the property prevents the class variable from being accessed directly. A property can be made read only as follows; this is simply a property that does not have a set statement.

// Read only property that returns the client?s name public string Name {     get     {         return name;     } }

C#3 provides a shortcut syntax for creating class variables and associated properties; the first code example can be shortened to:

// Shortcut syntax for creating properties //and underlying member variables public string Name { get; set; }

And of course, the principle of read only (or write only for that matter) properties is also supported using this new syntax:

// Shortcut syntax for creating properties and underlying //member variables (this time ClientName is read-only) public string Name { get; private set; }

For this shortened syntax, the compiler actually generates all of the required code behind the scenes. So in effect, you end up with exactly the same code that you would have got if you had written it using the available syntax of C#2. The code below shows the MSIL that is generated from the source code; note the use of the [CompilerGenerated] attribute that decorates the code.

[CompilerGenerated] private string k__BackingField; public string Name {      [CompilerGenerated]      get      {          return this.k__BackingField;      }     [CompilerGenerated]     set     {         this.k__BackingField = value;     } }

Automatically implemented properties provide a way to quickly expose class member variables; we will examine this feature more in the next article.

Part 3: Initialising objects

The newbie guide to C#3, Part 1: Overview

This short series of articles gives you an overview of the new features provided by C#3. The articles are peppered with simple code examples that you can copy directly into a C#3 editor to try them out for yourself. At the end of each article, a link is provided to a standalone class that contains fully commented examples of the features that have been discussed.

The information presented here won't make you a C# guru but they will give you an appetite for the new features that have been added to the language.

Part 2: Automatically implemented properties
Part 3: Initialising objects
Part 4: Implicit types

It takes time to make a decision

Some people describe software development as a manufacturing process. Basically you take a recipe, try it out a few times and once you are happy with the ingredients and the cooking process you write it down and pass it on to your eager coders. Over time you collect a whole book of recipes that can be easily followed, producing code that is both repeatable and reusable. Software restaurants announce ticker tape openings around the globe to serve up cheap and reliable cookie cutter software solutions. Recipe for success? Actually, past experience tells us that more often than not it is a recipe for disaster.

The manufacturing process needs to guarantee repeatable results and this is very difficult given the amount of human intervention that programming typically involves. Of course, there are now many utilities that generate, parse, check, analyse and generally prettify source code but it's still essentially a solo practise between the developer and the IDE (apologies to all you XP pair programmers out there). There is also the issue of code maintenance to consider, generated code is not the prettiest of creations and, whilst it's fine when it works, any subtle imperfections are often very difficult to isolate and rectify.

Some people describe software development as an artform. Each contributor adds their own creative interpretation of requirements, applies keyboard brushstrokes to their electronic canvas and steps back to admire yet another unique creation. No two pixel paintings are the same; programmers the world over write different code to achieve the same objective. Even individual coders write the same routines differently, with or without varying degrees of standards and procedures, many times during their illustrious careers. An artistic masterclass? Very often this approach generates code that may be inventive but is seldom practical and rarely maintainable.

The problem here is consistency; code is produced that can be difficult to maintain where the layout of each class looks very different to its neighbours. There are a number of architectural decisions and considerations that a developer has to make that exist outside of what is generally perceived as the 'system design'. Does a particular piece of logic sit in the database layer or the business layer? How are exceptions handled? Should a method be instanced or static? Do you choose an interface or an abstract base class? In reality your code is simply a string of statements, loops and conditions but the potential number of combinations are astronomical even within a relatively small code base. Coding standards and recommended practises can help to reduce the confusion, code generation can produce generic classes and components and design patterns provide some level of guidance but dividing a limitless number of possibilities by any given factor still leaves a limitless number of possibilities.

So should we strive for a repeatable and consistent, painting by numbers development process where creativity and initiative are completely removed from the programming equation? Or do we promote flexibility and encourage our development teams to express their creativity and inventiveness in new and inspiring ways? Is there some magical, middle ground that satisfies the developer's creative aspirations whilst still adhering to repeatable templates, design patterns and agreed best practises?

This blog is littered with questions but unfortunately devoid of answers; each question corresponds to at least one, and often very many decisions. It is ironic that the decision making process is a key factor in making programming an interesting practise. It is also a subtantial contributor to the problems and complexities that lurk beneath the surface of even the most trivial of solutions.

Decisions take time ... so less choice, less freedom and fewer choices must surely facilitate a better programming environment...or do they?