We've been doing a lot recently supporting teams in deploying and / or upgrading to Team Foundation Server 2008. It's been a very interesting and enlightening period of our work at Luminous because it is field testing and reinforcing some of the fundamental ideas we have held about the underlying patterns of thought people experience when adopting software.

Software adoption is a complex cultural process that is often relegated to a functional discipline that is ill-equipped to address the organizational and cultural requirements that support successful adoption. Adoption is not simply putting someone new in front of someone. Optimally it addresses the notion of enhancing the capability of the individual, which inherently is about changing the way people think about the world and their relationship to it. Software adoption always occurs as some substep to a larger process, namely change management within an organization. Executed properly, it is always motivated by strategic goals. There is an excellent paper on this topic written by John Kotter from the Harvard Business Review entitled "Leading Change: Why Transformation Efforts Fail". 

It's funny how we can sometimes generate certain ideas and then lay them aside only to later realize how important and central those ideas are to what we do. A case in point here has to do with the ideas I presented in my 2003 CPSR paper entitled "Patterns of Thought:  An alternative approach to technology design".

In this paper, I argued that regardless of the type of technology, people tend to respond in the same, predictable ways to the introduction of a new technology. These responses can be categorized as:

• Masking: New technologies emerge in the guise of (or are used as if they were) old technologies;
• Convergence: Technologies evolve by converging with other technologies;
• Specificity: Different people use technologies differently;
• Ramifications: The adoption of technologies by a society always causes fundamental changes in that society;
• Evolution: Changes may take time yet they do occur;
• Entropy: People resist change.

Knowing this, I argue that when deploying new technologies (or designing new ones) that it is of great value to consider these cultural responses as part of the process. In this fashion, focus is  tightened around the strategic goals of the technology for the target group so that clear steps to achieve the objectives can remain at the fore and be fully realized.

At Luminous, this is a core aspect of our practice. We have deep knowledge about specific technologies, but it is our understanding of organizational dynamics, culture, and human behavior that enable us to support organizations to consider how these critical factors play into the process of deployment so that these are considered and addressed in practical terms.

What we have found is that there is a profound difference between the results acheived by those organizations who take the time to fully explore the strategic, organizational, and cultural aspects of deploying a new technology and those who simply take a functional approach to the same process.

Results and benefits of employing our suggested approach include:

• Greater alignment about the strategic vision;
• Tangible ways to track and measure progress;
• Accelerated progress;
• Greater ease in execution as technology becomes perceived as supportive rather than  hindering;
• Technology investments are fully aligned with business goals;
• End-users have a sense of ownership about "their" process and tools;
• Enthusiasm for change process and an environment where innovation is possible;
• Work environment moves toward proactive initiatives;

These are results we can get really excited about. (read more)

To continue with my topic on things you can do in VB9 that you cannot (yet) do in any other .NET language, I wanted to write a bit about XML Schema Support and intellisense support for XML properties in VB9.

First, I highly recommend reading Eric Meijer and Brian Beckman’s research paper XLINQ: XML Programming Refactored (The Return Of The Monoids), which provides background as to the motivation and implementation of XLINQ technology. The Monads referred to in the paper remind us that the constructs being integrated into the .NET framework are enabling a more functional programming paradigm. This and the concurrent development of the dynamic language runtime promise to further expand the capabilities of the .NET platform to languages and programming approaches so that any programmer with any approach can make use of the platform in a fashion they are comfortable with.

The LINQ project, as many of you are aware, brings to all .NET languages capabilities languages like LISP and Scheme have long enjoyed, based on the notion of the Lambda-function. There are many examples for LINQ available so I will not bore you with that topic, however, what I do think is very interesting are the extensions to LINQ which support XML (XLINQ) as well as a number of other VB9-specific capabilities such as XML Literals that make working with and programming against XML infinitely easier.

This blog post explores the way in which Visual Studio 2008 and VB9 work together to enable programmers working with XML to:

Ready? Here we go!

 

Setup

First, make sure you have downloaded and installed Visual Studio 2008 Beta 2.

Then, in order to make inferring the XML Schema easier, download and install this XML to Schema Inference Wizard, which is an add-on to Visual Studio and makes the process of inferring a schema from XML very easy.

We will be querying a XML file that contains data from a plant catalog. To obtain this file, go to http://www.w3schools.com/xml/xml_examples.asp and download the file plant_catalog.xml to your desktop.

Next, launch Visual Studio 2008 Beta 2 and create a Console Application using the Visual Basic language:

Add a XML namespace to the XML file

In the same way that the .NET framework organizes the massive API it encompasses into namespaces to establish an organization for the framework and minimize name collisions, when we use XML using these tools, it helps to add a XML namespace if the file does not already have one. This XML namespace is used by visual studio to map the schema to the actual file you are working with. The namespace must be in the form of a URI, which means it can be either a URL or a URN. In a production environment, you would agree with your development team or department what the namespace would be, but for our example, it could be anything. To add the namespace to the file you downloaded, open it in notepad and extend line 3 of the line to read as follows:

Think of this as analogous to the code you would write when importing a .NET namespace into your procedural code. Placing this namespace in the file provides a unique reference point for the schema we will infer.

Infer the Schema

This part is fun. Right-click on the project in the solution explorer and choose “Add new item”. Then from the dialog box (if you have installed the XML to Schema Inference Wizard), you will see at the bottom an item called “Xml to Schema”. Select that, and for the purposes of our demo, name it “PlantCatalog.xsd”.

 

The wizard will run and the following dialog box is displayed:

Note that you can infer the schema with this wizard from:

In our case, we will “Add from File”. When you click on the “Add from File” button, a dialog will appear, where you should navigate to the plant_catalog.xml file referred to earlier in this post:

The dialog will then list the file as an input to be processed by the wizard, as follows:

Click OK and you will see that a file, “PlantCatalog.xsd” is created in the solution explorer:

Open this file by double-clicking to review the contents:

The actual work of inferring and building the schema is done by a tool that has shipped with Visual Studio since VS.NET 2003, named xsd.exe, however, this is a command-line tool while the XML to Schema Inference Wizard we are using puts a nice UI over this step and also takes care of adding the output to the current project.

Note also that the “targetnamespace” property has been inferred from the xmlns property we added earlier.

Importing the Schema into Intellisense and writing code

Now that we have a schema ready to use, all we need to do is tell the VB9 compiler that we want to use it in our code. For this we use the standard “Imports” directive that you are familiar with when you want to import .NET namespaces.

Choose “” from the intellisense choices and then type a colon. This colon defines a separator where you define an alias you will use in your code to refer to as an alias for this namespace. We use “plants” as the alias. Finally, if you type “=”” you will see the intellisense suggest the namespace for the XML schema you have brought into your project:

I should note here that the steps we took in this example of adding the namespace and importing it are not required if you are working only with one XML document in your application that does not specify a namespace. However, many real-world cases will have more than one schema, so this is a good thing to know.

Accept this option and the close the statement with a closing quotation and greater-than sign. You are now ready to begin writing code. Let’s use the following example that shows XLINQ in action:

Note that in addition to the normal intellisense you have come to expect as part of your programming experience with Visual Studio that you also get intellisense in places where you are using XML literals in the code, for example:

And also here:

The “…” operator deserves a bit of explanation here, as it is new for VB9. Referring again to Meijer and Beckman’s paper, (in section 5.2, actually) this syntax is defined as representing the child axis of the current element. This is a form of syntactic sugar that returns all PLANT nodes in the plantsXML document, regardless of how deeply in the hierarchy they occur. It is another aspect unique to VB9 at this time that will save a lot of time for those of us reading XML in code.

Finally, what you will see, if you run your lovely application is the following output:

(read more)

While I am not an expert on the subject, in my tenure as a founder of the Bay Area .NET Users Group (Bay.NET), I am very much aware of cultural differences between programmers who work with the Visual Basic and C# languages. An excellent overview written by Nigel Shaw on these cultural differences can be found here.

Having lived in many places throughout the world I would consider myself as one who is most interested in culture and cultural differences. In my experiences, I have discovered in myself an inclination to find things I appreciate about other cultures (and people).

I think we all tend to look at differences, be they cultural, as in those who prefer Apple Computers to Windows or Linux and make some value judgments based on what camp we live in and what camp they live in.

My late friend Rich Gold put it beautifully in his biographical work The Plenitude when he said:

“During my life I put on and took off four hats of creativity: artist, scientist, designer and engineer. I think of each one as quite distinct with its own methods, world views, precedents, predecessors, style of dress, interior decorations, histories, vocabularies, alliances, likes, dislikes, prejudices, tools, techniques and demeanors. I can walk into an office and know immediately if it is a designer’s office or an engineer’s office. I instantaneously know if it is an artist’s loft or a scientist’s lab even if they are filled with the same digital tools. Actually it is only with great effort that I have begun thinking about them as hats; in some real way, for me, they are states of being as different as alligators and elephants.”

The one thing Rich made extremely clear about these cultures is that all of them are essential to create a great product.

What is true regarding Gold’s observations of the artist / scientist / designer / engineer cultures is also true of the Visual Basic and C# cultures (as well as those of all other programming languages): We need all of them to make truly great products.

Prior to and since its incorporation into the .NET framework, Visual Basic has been perceived by many as somewhat of an ugly stepchild by many programmers whose language of choice is not Visual Basic.

And that is why the new version of Visual Basic.NET – VB9, to be released as part of Visual Studio 2008 is so terribly exciting to me. It marks a powerful sea change in the Visual Basic language where the culture behind that language is bringing some exciting innovation to the .NET platform based through language-specific features.

I will be spending the next few blog posts, writing about, among other things, these new language features. They are features that are important for all .NET developers to know about so informed choices can be made regarding the approach used to build software applications.

XML Literals in VB9

The first VB9 feature I think it going to make me more productive as a programmer is the ability to work with XML literals directly in code. From a description, this may not seem like much, but it represents is a new paradigm of working with XML natively in a programming language. No longer do I need to learn an API to work with XML, but I can write XML in 2 lines of code, as follows:

That may not seem like much, but VB9 also supports embedded expressions that are evaluated at runtime within the XML literals, that, when combined with language integrated query (LINQ) to enable very powerful, yet simple constructions, such as:

 

The <%= ... > syntax above represents an embedded expression and you can nest these recursively as many levels as you need to represent the desired structure.

These are things you just cannot do in any other .NET language and will make a huge different in productivity for any job where the construction of XML is required.

 

 

(read more)

I recently got a new computer preloaded with Windows Vista. I must say that when I got the machine I was extremely surprised at how well it worked and how easy it was for me to transfer my data to the new machine (Lenovo T60p). With all of the comments I had been hearing which indicated that many people felt that the Vista operating system was problematic, I was rather surprised at how smooth my transition was.

Alas, this was not to last, and what is rather ironic is that I have been subject to a number of issues in the past month that have been rather disruptive and taken some time to remedy and yet are not related specifically to any flaw in the operating system.

The first sign of trouble was when I shut the computer down after doing some work and found it would not start the next morning. I believe a file was (or files were) corrupted somehow on shutdown (although I do not know for sure) and were only able to get back to an operable state by restoring the OS from a recent rescue and recovery backup, which I do regularly. One nice part about this option is that one can restore the OS to the state in the backup without touching the state of user files. In other words, fix only the OS and leave my files alone. This worked like a charm, so I was pleased to see that the recovery tools worked as they should. But I was not yet through my ordeal. This was only the beginning of a folly of further system errors.

The next thing that happened is that I started to receive visits from the Blue Screen of Death. Now, I am an intense computer user, so when this happened, I naturally assumed it was because I was doing too many things, i.e. playing music, compiling code, having too many files open, etc. Yet, when this continued to occur even at times of minimal activity and began to interfere with system backups. I knew at that point that I really needed to get to the bottom of this.

The next issue occurred, rather ironically, when I was trying to fix this problem and ran the Lenovo system update tool. When I ran the update, the tool informed me of a “critical BIOS update”. Upon reading about this update, I found it interesting that the language Lenovo used to describe what the update was addressing was “a possible processor marginality” and “a potential source of unpredictable system behavior”. Further research on the Microsoft site was more telling: “You may receive a Stop error, or you may experience unpredictable system behavior”. Oh yes, I thought I had found the issue and so proceeded to apply this update. But something odd happened when the update was complete. The computer would not start and the BIOS screen did not come up. I knew immediately that the BIOS was either erased or cor