Thursday, 18 September 2008

Extreme Programming - Getting Started

Just a few words about the theory. There are a couple of concepts I want to introduce and a few Rights and Responsibilities I wish to present. I will try to keep the theory to a minimum in this blog, only explaining enough to keep non-experienced readers up to speed. I will introduce each as it impinges on that part of the project and they may not be in the order that they are presented in the texts I am reading.


In the background I have selected the project, I have briefed the client on the approach taken and have assembled the team. The client, who I’ll keep under wraps for now, is somewhat keen to experiment with this method.


Firstly a few basic concepts.


Customer Centric Development and the Circle of Life


XP puts the customer firmly at the centre of the projects in terms of defining requirements (user stories), getting involved in the testing and choosing project priorities. The programmer is equally important and in refining the scope, diagrammatically the interaction is meant to look like this..



There are four variables we can control in the project: cost, time, quality and scope. They are interdependent. Take a minute to look at these variables and play around with increasing or decreasing each one. What happens?

Getting the customer involved as in the circle of life above allows honest decisions to be made about what can be achieve in the limits of the four variables. Cost, in most of our experience, is the limiting constraint. The other variables adjust to suit.


Ideally XP insists on the customer being on-site and available. This is an ideal we shall have to work around. One rule we must adhere to is that “communication is king”. There will be misunderstandings, we must plan for them. Email communication is error prone, verbal communication (meetings, telephone conversations etc.) is ideal. Communication shortens project timescales!


User Stories and the Beginning of the Project Scope


User Stories are customer requirements. Customers define User Stories, programmers, however tempting it is, don’t. XP suggests that the customer defines the stories on cards, with each card representing a piece of functionality that the system will need to accomplish. Stories should encompass one or two weeks of work. All the stories don’t need to be defined at the beginning. XP “embraces change” and have ideas in place to meet them. User stories will grow, shrink, change and split over the lifetime of a project.

User stories will be picked up by a programmer and developed. More on that later!

Testing, Testing


XP demand that testing is carried out strategically, continuously by developers and customers. Customers define tests as well as programmers. Programmers should aim to automate the testing as much as possible.

Testing should be done all of the time to keep the development on track and the quality of code to a maximum.

Oh, and it might be an idea to consider parallel testing, stress testing and monkey testing (idiot users and nonsensical input etc.) as well.

Releasing


XP plans for frequent releases. Frequent releases to the customer allow them to check functionality, see progress, refine stories and choose priorities. Releasing at the end of a project runs the risk of delivering something the customer did not want. XP is the antidote to this.

Each release should be as small as possible and should contain the most valuable business requirements.

Thoughts and Progress


We are all in agreement with the concepts and have begun to implement the process. I have had a look at some of the software packages available to manage the process but for now we have opted for a purist, pen and paper approach.

Do I agree with everything?



I’m not sure. Some of the terminology isn’t sitting right with me. I have something against the word “stories”.

The testing and releasing concepts hold no problems for me and the team.
The customer centric approach is great but I envisage a time when we drift away from the ideal and the customer gets detached from the development cycle.

Measurement of success is on our minds at present, both for this project and for XP as a whole. I shall have to delve into the theory more.

So we are off… We have our project, team, customer room, whiteboards, cards and coffee. We have defined our first user stories and have are at the beginnings of implementing some of the features.

The next blog will present a more developer focused view of XP.


References:
Extreme Programming - Explained

Extreme Programming - Installed

Labels:

Wednesday, 17 September 2008

Extreme Methods - Are They Right For Us?

Like a lot of people in the world of software, I had heard of extreme programming (XP) and knew enough of the concepts to be interested. I had even bought the book for some of my customers to attempt to define a more rational way of working in an environment of rapid change and limited appetite for long scoping phases.


Some of the concepts of extreme programming, such as pair programming, customer-centric development, openness and frequent refactoring are core to my beliefs. The healthiest projects I have worked in have embraced these philosophies and have produced well finished, working systems with happy clients and happy developers. It sounds like that should happen every time but we’ve all been around long enough to no it is not a “given”.


The partners at Red River Software set up the business with an ethos which has proved very successful. It encompasses many of the aspects of openness and partnership we will discuss in this thread. But more of the business later for now my aim is to test out extreme programming and its suitability for the projects we come across in our business.
What will this take?


Firstly, I will have to brush up on the theory and practice of Extreme programming. I am starting with the two of the most commonly read texts on the subject “Extreme Programming Explained” and “Extreme Programming Installed.


Secondly, I will pick a project and document our journey through the project.


Finally, I intend to have a wash-up discussion at the end with the aim of refining or shaping extreme programming to suit the shape of our business.


I intend to highlight the theories of extreme programming in the coming weeks and show where the theory works well in practice and where we are struggling with it. I would welcome feedback on anything written and if needed, other people’s experiences and wisdom on this subject.


I am in the process of setting up an “extreme methods group” in my local enterprise area which will explore the implementation of the extreme ideas in businesses other than software. That’s another story (those that know extreme methods-please excuse the pun).


The next blog entry will be the start…


References:
Extreme Programming - Explained

Extreme Programming - Installed

Labels:

Tuesday, 16 September 2008

Creating SQL Server tables automatically - from Visual Studio Datasets or XSD Schemas

This article tackles one of the more frustrating features (or lack thereof) in Microsoft Visual Studio. While Microsoft have furnished it with Server Explorer (which lets you manage database tables directly in SQL Server) and a DataSet designer (which lets you manage code objects for wrapping up tables and relationships), it’s only possible to create a DataSet based on database tables as a one-way manual process, which regenerates DataSet code.


I’ve long found it far more comfortable and better practise to define a schema in one place – usually, the DataSet designer in VS: it’s quick, its easy to define many tables and their relationships at once and the results go into source control. Historically, I would use Visual Studio to create an XSD in this manner then propagate changes to SQL Server manually.


I’m definitely not alone in this requirement – you can find lots of posts on forums and newsgroups. It’s always worth posting these solutions so that future frustratees can share the solution. That said:


The solution


There exists an ActiveX library – “Microsoft XML BulkLoad for SQL Server 3.0 Type Library”, also known as SQLXMLBULKLOADLib. The SQLXMLBULKLOAD3Class component within it can be used from a .NET environment very easily, using interop, and is designed to create (or update) database tables in SQL Server, based on an XML schema. The library is installed along with SQL Server 2005 development tools.


I will present a basic overview of how to use the tool to update database tables from a Visual Studio DataSet object itself, at run-time, without even having to use XSD files.


The catch


The XML format that the SQLXMLBULKLOAD3Class object uses for creating the tables differs slightly from the XSD format that Microsoft use in Visual Studio. Things such as relationships (foreign keys), nullable column specification, and so on, are possible with a little modification of this method but aren’t covered here!


The code


First, take a quick look over this MSDN article - it describes a few important basics, like the fact the component won’t run in a multi-threaded environment (use STAThread). The article is written for SQLXML 4.0 but this still applies.


Remember to add an ActiveX reference to the library and a ‘using’ directive for the SQLXMLBULKLOADLib namespace.


I usually create a console application for initialising a database using this technique – simply create any dataset objects your application uses and pass them to the method below. Obviously, this would remove any data already in the database.


The usual disclaimers apply: take a backup of your database first, add salt to taste, lather, rinse and repeat.




/// <summary>
/// Creates tables in SQL Server, for all of the tables within the DataSet object.
/// Does not populate the tables with data. Optionally drops existing tables if
/// they exist.
/// </summary>
/// <param name="connectionString">Example:
/// "Provider=SQLOLEDB;Data Source=MyServer;Database=MyDatabase;Integrated Security=SSPI;"
/// </param>
/// <param name="schemaObject">Any DataSet object - for example </param>
/// <param name="dropTablesIfExist">Deletes tables if they alreday exist, before recreating
/// them</param>

public void CreateSchema(string connectionString, DataSet schemaObject, bool dropTablesIfExist)
{
// instantiate the bulk load object
SQLXMLBulkLoad3Class bulkLoad = new SQLXMLBulkLoad3Class();
bulkLoad.BulkLoad = false;
bulkLoad.SchemaGen = true;
bulkLoad.SGDropTables = dropTablesIfExist;
bulkLoad.SGUseID = true;
bulkLoad.ConnectionString = connectionString;
bulkLoad.ErrorLogFile = "error_log.xml"; // used to log problems from the component

string temporarySchemaFilename = Path.GetTempFileName();
try
{
// write out the schema to disk
dataSet.WriteXmlSchema(temporarySchemaFilename);

// load the schema into a memory document - for processing!
XmlDocument doc = new XmlDocument();
doc.Load(temporarySchemaFilename);

// overview of the XML processing we will perform:

// doc root -> element -> complextype -> choice -> table elements
// remove this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

// loop through tables in the dataset, updating XML structure accordingly
XmlNamespaceManager mgr = new XmlNamespaceManager(doc.NameTable);
mgr.AddNamespace("xs", "http://www.w3.org/2001/XMLSchema");
XmlNode goodDataParent = doc.DocumentElement.ChildNodes[0].ChildNodes[0].ChildNodes[0];

foreach (XmlNode kid in goodDataParent.ChildNodes)
{
foreach (XmlNode field in kid.ChildNodes[0].ChildNodes[0].ChildNodes)
{
// FEATURE - correctly pick up on the MaxLength property for string columns here!
if (field.Attributes["type"] == null)
{
XmlNode max = field.SelectSingleNode("//xs:maxLength", mgr);
if (max != null)
{
XmlAttribute attrib =
doc.CreateAttribute("sql:datatype",
"urn:schemas-microsoft-com:mapping-schema");
attrib.InnerText = "nvarchar(" + max.Attributes["value"].InnerText + ")";
field.Attributes.Append(attrib);
}
}

// other things (nullable column specifications, etc) would need to be done here
}

doc.DocumentElement.AppendChild(kid.CloneNode(true));
}

doc.DocumentElement.RemoveChild(doc.DocumentElement.ChildNodes[0]);

doc.Save(temporarySchemaFilename);
bulkLoad.Execute(temporarySchemaFilename, null);
}
catch (Exception ex)
{
// rethrow the exception
throw new DataException("Problem creating schema in SQL Server: " + ex.Message, ex);
}
finally
{
// clean up temporary file
if (File.Exists(temporarySchemaFilename))
File.Delete(temporarySchemaFilename);
}
}

Labels:

Wednesday, 3 September 2008

Google Chrome - A new open-source browser

Yesterday, Google entered the browser market with their new open-source offering, Chrome.


A list of some new features unique to Chrome can be found here. Things that caught our eye immediately:


  • Multi-process application model - each tab / plugin runs not just in its own thread, but its own process. This has several juicy implications - for example if one site crashes, hangs, or hogs resources, it can be controlled and terminated without compromising the rest of the application

  • Task manager - hit Shift+Esc at any time to get a Task Manager, for monitoring, statistics and control of all processes. There's even a Stats for nerds link for detailed diagnostics

  • JavaScript: V8 - Google's new JIT-compiler for JavaScript. In Chrome, JavaScript is compiled to native code - very fast. What's more, Google have invented a new API for the next generation of web apps. Plus there's an extensive integrated JavaScript debugger and console.

  • 'Home' page - a feature already growing on me can be seen whenever you open the browser or a new tab page. A list of recent bookmarks, and sites you access frequently (along with little screenshot thumbnails!) is presented, along with a 'history search'.

  • WebKit engine (ala Safari) - the render engine borrows largely from WebKit. This means it generally renders web pages the same as Safari.


No doubt there will be much more to come very soon. Developers will be interested in reading through this very informative cartoon, and perhaps even compiling Chrome themselves.

Labels: , ,