Archive for October, 2009

Connect to a MySQL database

A simple little function allowing you to connect to a MySQL database.


 *
 * You can then do your database queries
 */
// Edit your database settings
$db_host = "localhost";
$db_user = "username";
$db_pass = "password";
$db_name = "databasename";

function db_connect() {
    global $db_host;
    global $db_user;
    global $db_pass;
    global $db_name;

    $connection = mysql_connect($db_host,$db_user,$db_pass);

    if (!(mysql_select_db($db_name,$connection))) {
        echo "Could not connect to the database";
    }
    return $connection;
}
?>

Switching stories mid sprint

Introduction

I blogged about this some time ago and then posted the blog on various agile forums to judge peoples responses.

Most of the responses were well reasoned, however, one of the responses I received shocked me somewhat and so I feel that it's worth blogging about this particular situation once more.

The response I received was "You're not serious you're going to ignore the PO" and "You can't be a slave to the process"

In all fairness, there are many situations under which the need to switch stories arise. And the specifics were not really provided. For example:

How long are the sprints?
How far into the current sprint are you?
Are there stories that have yet to start that is of similar size that you can switch it out with?
Is this a critical issue that needs to be fixed ASAP as customers are complaining and may negatively impact revenues?

Those are some of the questions that need to be asked when making that decision.

In response to being a slave to the process...

Well you're either a slave to the process or the team is a slave to any chicken in the company who shouts the loudest. Lets go back to basics and why the Sprint is there in the first place. It's designed to provide stability for the team to get stuff done. Hopefully you're doing short sprints so it's not a lot of time before the team pops it's head up again and asks for more direction.

If the team listens to whatever the next flavor of the month is, then we're back to square one where there's just chaos and nothing gets done. Seriously, smart people figured out why we need to do it this way. There is strong evidence to support that this makes a difference, a really positive difference. So lets not willy nilly and go changing plans whenever someone in the organization feels like there's something more important to do.

Moreover, in this situation, I think it's important the team asks some serious questions as to why suddenly there's a story that's so super urgent that it calls for a change in plan. Lets say you're doing 2 weeks sprints and lets say you're midway. This means in reality that 5 days ago, nothing was more important (top priority items get selected to go into the sprint). Why all of sudden is their a need to change direction so soon after. Additionally can't it wait another 5 days?

Now I am sure there are times where such a situation arises and that's fine. I would never be so hard-line to suggest that the team doesn't collaborate over this and decide what are the best options. And in such a case, it's important that the team does this.

But lets be very careful how we deal with this. Because once you do this once, it's a slippery slope after that.

So what would I do. As already mentioned above, I would sit down with the team. Have the PO explain the dilemma. Thereafter, it's up to the team to decide if there is an easy swap out that doesn't impact the Sprint goals and productivity. Ultimately if it is possible, I am sure most teams would do it any ways. Level heads should prevail.


Syndicated via RSS From: http://agilesoftwaredevelopment.com

Dynamic in C# 4.0: Creating Wrappers with DynamicObject

In the previous post I showed how you can use the new dynamic feature and the ExpandoObject class to add and remove properties at run time, and how this can make your code more readable and flexible than code written with LINQ to XML syntax.

But there were some obvious flaws in that example: While ExpandoObject provided better syntax, LINQ to XML provided a lot of useful library methods that helped you to work with XML files. So, is it possible to combine those two advantages, to have better syntax and still get all those methods? The answer is yes, but you need another type from the System.Dynamic namespace: DynamicObject.

The DynamicObject class enables you to override operations like getting or setting a member, calling a method, or performing any binary, unary, or type conversion operation. To illustrate the issue, let’s create a very simple object that overrides the “get property” operation, so that whenever you access a property it returns the property’s name as a string. This example has no practical value.

public class SampleObject : DynamicObject
{
    public override bool TryGetMember(
        GetMemberBinder binder, out object result)
    {
        result = binder.Name;
        return true;
    }
}

As with ExpandoObject, we must use the dynamic keyword to create an instance of this class.

dynamic obj = new SampleObject();
Console.WriteLine(obj.SampleProperty);
//Prints "SampleProperty".

Let’s see what’s going on in this example. When you call obj.SampleProperty, the dynamic language runtime (DLR) uses the language binder to look for a static definition of this property in the SampleObject class. If there is no such property, the DLR calls the TryGetMember method. This method gets information about what property it was called for through the binder parameter. As you can see, the binder.Name contains the actual name of the property.

The TryGetMember method returns true if the operation is successful. But the actual result of the operation must be assigned to the out parameter result. In this example, TryGetMember returns true, but obj.SampleProperty returns "SampleProperty".

Now let’s move to a more complex example and create a wrapper for the XElement object. Once again, I’ll try to provide better syntax for the following LINQ to XML sample.

XElement contactXML =
    new XElement("Contact",
    new XElement("Name", "Patrick Hines"),
    new XElement("Phone", "206-555-0144"),
    new XElement("Address",
        new XElement("Street1", "123 Main St"),
        new XElement("City", "Mercer Island"),
        new XElement("State", "WA"),
        new XElement("Postal", "68042")
    )
);

First of all, I need to create an analog of ExpandoObject. I still want to be able to dynamically add and remove properties. But since I am essentially creating a wrapper for the XElement type, I’ll use XElement instead of the dictionary to maintain the properties.

public class DynamicXMLNode : DynamicObject
{
    XElement node;
    public DynamicXMLNode(XElement node)
    {
        this.node = node;
    }
    public DynamicXMLNode()
    {
    }
    public DynamicXMLNode(String name)
    {
        node = new XElement(name);
    }
    public override bool TrySetMember(
        SetMemberBinder binder, object value)
    {
        XElement setNode = node.Element(binder.Name);
        if (setNode != null)
            setNode.SetValue(value);
        else
        {
            if (value.GetType() == typeof(DynamicXMLNode))
                node.Add(new XElement(binder.Name));
            else
                node.Add(new XElement(binder.Name, value));
        }
        return true;
    }
    public override bool TryGetMember(
GetMemberBinder binder, out object result) { XElement getNode = node.Element(binder.Name); if (getNode != null) { result = new DynamicXMLNode(getNode); return true; } else { result = null; return false; } } }

And here is how you can use this class.

dynamic contact = new DynamicXMLNode("Contacts");
contact.Name = "Patrick Hines";
contact.Phone = "206-555-0144";
contact.Address = new DynamicXMLNode();
contact.Address.Street = "123 Main St";
contact.Address.City = "Mercer Island";
contact.Address.State = "WA";
contact.Address.Postal = "68402";

Let’s look at the contact object. When this object is created, it initializes its inner XElement. If you set a property value, like in contact.Phone = "206-555-0144", the TrySetMember method checks whether an element with the name Phone exists in its XElement. If it does not exist, the method creates the element.

The next interesting line is contact.Address = new DynamicXMLNode(). Basically, in this particular example this line means that I want to create a node that has subnodes. For this property, the TrySetMember method creates an XElement without a value.

The most complex case here is a line such as contact.Address.State = "WA". First, the TryGetMember method is called for contact.Address and returns a new DynamicXMLNode object, which is initialized by the XElement with the name Address. (Theoretically, I could have returned the XElement itself, but that would make the example more complicated.) Then the TrySetMember method is called. The method looks for the State element in contact.Address. If it doesn’t find one, it creates it.

So I have successfully created the required XML structure. But TryGetMember always returns an instance of DynamicXMLNode. How do I get the actual value of the XML node? For example, I want the following line to work, but now it throws an exception.

String state = contact.Address.State;

I have several options here. I can modify the TryGetMember method to return actual values for leaf nodes, for example. But let’s explore another option: override type conversion. Just add the following method to the DynamicXMLNode class.

public override bool TryConvert(
    ConvertBinder binder, out object result)
{
    if (binder.Type == typeof(String))
    {
        result = node.Value;
        return true;
    }
    else
    {
        result = null;
        return false;
    }
}

Now whenever I have an explicit or implicit type conversion of the DynamicXMLNode type, the TryConvert method is called. The method checks what type the object is converted to and, if this type is String, the method returns the value of the inner XElement. Otherwise, it returns false, which means that the language should determine what to do next (in most cases it means that you’re going to get a run-time exception).

The last thing I’m going to show is how to get access to the XElement methods. Let’s override the TryInvokeMember method so that it will redirect all the method calls to its XElement object. Of course, I’m using the System.Reflection namespace here.

public override bool TryInvokeMember(
    InvokeMemberBinder binder, 
object[] args,
out object result) { Type xmlType = typeof(XElement); try { result = xmlType.InvokeMember( binder.Name, BindingFlags.InvokeMethod | BindingFlags.Public | BindingFlags.Instance, null, node, args); return true; } catch { result = null; return false; } }

This method enables you to call XElement methods on any node of the DynamicXMLNode object. The most obvious drawback here is absence of IntelliSense.

I’m not even going to pretend that this example is a ready-to-use wrapper for the LINQ to XML library. It doesn’t support attributes, doesn’t allow you to create a collection of nodes (for example, multiple contacts), and it is probably missing other features. Creating a library is a difficult task, and creating a good wrapper is too. But I hope that after reading this blog post you can create a fully functioning wrapper with DynamicObject yourself.

So, if you routinely use a library with complicated syntax that crawls XML files or works with script objects, or if you are creating such a library yourself, you should probably consider writing a wrapper. Doing this might make you more productive and the syntax of your library much better.

All the examples provided in this blog post work in the just released Visual Studio 2010 Beta 2. If you have any comments or suggestions, you are welcome to post them here or contact the DLR team at http://www.codeplex.com/dlr. You can also send an e-mail to the DLR team at dlr@microsoft.com.

Documentation for DynamicObject is also available on MSDN (check out our new MSDN design and don’t forget to take a look at the lightweight view.) In documentation, you can read about other useful methods of this class, such as TryBinaryOperation, TryUnaryOperation, TrySetIndex, and TryGetIndex.

Syndicated via RSS From: http://blogs.msdn.com/b/csharpfaq/

Functions in C++

Functions are pieces of code, that can be executed by calling from another function. You know that a common C++ application, must have one function, that functions is int main().

So there is a statement of a function

return_type function_name(parameter1, parameter2,…)

{

// Statements

}

  • return_type, is the type that the function returns as a result (eg. int, float, string,…). It can be void, if the function doesn’t return anything.
  • function_name, is the identifier of the function, we can call the function using that identifier
  • parameters, values that we give to the function to make some operations with them
  • statements, the code in the function, it is surrounded by braces

Example:

#include 

using namespace std;

int sum(int a, int b)
{
return a+b;
}

int main()
{
int x=5;
int y=6;
int z=sum(x, y);
cout << z << endl;
}

The function expects two arguments, the first will be the value of x, the second will be the value of y. And it will return their sum.

So, we initialize two variables, x and y. And the variable z will get the value of the sum of x and y. That operation is performed by the function.

State of Agile

Introduction

Seems like there's lots going on in the agile world right now. Lots of talk about Lean and it's impact on Agile. Lots of attacks going on at the CSM certification. Kanban is all over the news these days. And just last week, I read about a new Agile methodology called Stride.

So how do we make sense of this all?

My opinion is that there is value in each of the methodologies (for the purposes of this blog I'll refer to them all as methodologies even though some of you might not think of them as such). It's real important to read about them all so that you are armed with enough knowledge to know what's out there. I see this as a toolset from which you can choose for your specific situation.

In order to illustrate ....

Scrum is a methodology and process that provides the mechanisms for teams to learn and adapt. Scrum however doesn't say much about the meaning of DONE and how to accomplish that. That's where XP comes in. XP has great practices around engineering discipline. It teaches us all about craftsmanship and producing quality work. I personally cannot see anyone practicing Scrum without at least some elements of the XP toolset. Be it pair programming, TDD, ruthless refactoring, emergent architectures etc.

Lean on the other hand is way more philosophical, but they have great teachings. For example, recognizing that work-in-progress is a liability is huge. If you start to think like this, you're going to minimize work-in-progress and as a result you will improve overall cycle time. With Lean, people come first. What effect does this have on your organization? Well happy teams make happy customers, better quality software, improved work culture.

And Kanban? Well Kanban helps teams with flow (i.e. cycle time, throughput etc) and almost eliminates the need for traditional sprints which I won't get into here (subject for another discussion). So many teams are using kanban boards for controlling the workflow of tasks or stories, or both.

Scrum has also been said to have problems with scalability and cross site development shops. Well Stride in it's infancy (not even sure you can call it an accepted methodology yet) has adapted Scrum to provide capabilities for better handling these sort of situations.

So what do you do?

Well in my opinion Scrum provides the best overall process or mechanism to manage agile project. It's a good base to start with and I would definitely start with Scrum. But you can't go it alone with Scrum. You have to pick and pack from other methodologies till you get what works for you.

I think Agile is evolving and most likely wont stop. And why should it. I want us to get better at it. And there's so many smart people thinking about how to make software development better. I can't wait to see what it will be like in 5 years from now.


Syndicated via RSS From: http://agilesoftwaredevelopment.com

Poka Yoke, error handling for your process

Software engineering is still a very human endeavor. Its a complex process that requires our ability to create non-standard solutions for non-standard problems. But with this ability to creatively solve problems comes a tendency to introduce defects, one of the seven wastes lean production and lean programming try to eliminate. Jack Milunsky describes several ways to reduce the amount of defects in his article. I want to look at another idea from lean manufacturing for reducing the number of defects called Poka Yoke in Japanese and have a look at how we can apply this idea to software engineering.
<!--break-->
Poka yoke is a Japanese term that means something like fail-safing or as I like to call it fool-proofing. The idea is that instead of just telling people how to do things you design your process, your tools or your product in such a way that it becomes harder to make mistakes and easier to do things the right way.
USB cables are a good example from manufacturing. It's impossible to accidentally connect two USB printers together because of the way the plugs are designed. You can only connect a USB device to a USB host. Another well know example are microwave ovens that turn off the moment you open the door.

Poka yoke in software engineering takes a bit more creativity. Software is incredibly flexible so it's often harder to define right and wrong ways to fit parts together. First lets look at a couple of ways we already do poka yoke without knowing it to get some inspiration. Later we can look at how we can fit more of it in our process.
We have a lot of practices that make it more difficult to check in faulty code. Unit testing and regression testing together with a continuous integration system makes defects very visible very fast. A similar but older technique is coding by contract. Defining pre-, and post-conditions for every function in your code making it fail fast whenever it is called in the wrong context or with the wrong parameters.
Another concept in API design that is gaining popularity is 'convention over configuration'. Instead of letting consumers of your API configure every aspect before they can start to use it you give them a set of sensible defaults that 'just work'

Of course it's easy to go overboard with fool-proofing your process. We know that for every fool-proof system the universe just invents a bigger fool. The trick is to just fool proof the parts of your process that repeatedly cause defects. The best way to do this is to bring it up as part of your retrospective. Try to find the weak spots in your system and make them more robust by setting sensible defaults or adding tests. Sometimes even improving names in your code can improve things.


Syndicated via RSS From: http://agilesoftwaredevelopment.com

Object and Collection Initializers

Initializers introduce a concise syntax that combines object creation and initialization in a single step. It even allows for parentheses to be optional for paramaterless constructors as you’ll see in the first line of the example below.

Point p = new Point { a=3, b=99 };

Student myStudent = new Student() {
   Name   = "Alex",
   Clas  = "Senior",
   School = "Nekoe" };

This functionality is great for demos where you are building collections of objects to do things like LINQ queries against. However, I caution you to consider real life initialization of large sets of data and whether code over a database is the proper place to store such information.

Initializers work very well with constructors. The example below shows an instance where a parameterized constructor is called along with remaining properties initialized. The constructor should commonly take all of the parameters so it isn’t an ideal setup, but it illustrates the point well.

class Customer
{
   public Customer(string customerKey) { ... }
   public string CustomerKey { get { ... } }
   public string ContactName { get; set; }
   public string City { get; set; }
}

var c = new Customer("MARKS"){
   ContactName = "Paul Owen",
   City = "London"
}

Dynamic in C# 4.0: Introducing the ExpandoObject

You have probably already heard about the new dynamic feature in C# 4.0 and how it is used to support COM interop. If you haven't, I strongly recommend reading the following MSDN articles: Using Type dynamic and How to: Access Office Interop Objects by Using Visual C# 2010 Features.

Well, where else can you use this new feature? What are the use cases? Where does dynamic dispatch work better than static typing?

The quick answer is that whenever you see syntax like myobject.GetProperty("Address"), you have a use case for dynamic objects. First of all, the above syntax is difficult to read. Second, you don’t have any IntelliSense support for the property name, and if the “Address” property doesn’t exist you get a run-time exception. So why not create a dynamic object that calls the property as myobject.Address? You still get the run-time exception, and you still don't get IntelliSense, but at least the syntax is much better.

In fact, it’s not just better syntax. You also get flexibility. To demonstrate this flexibility, let’s move to ExpandoObject, which is a part of the new dynamic language runtime (DLR). ExpandoObject instances can add and remove members at run time. Where can you use such an object? XML is a good candidate here.

Here’s a code example that I took from MSDN. (Yes, I am an MSDN writer myself, so I use MSDN a lot.)

XElement contactXML =
    new XElement("Contact",
        new XElement("Name", "Patrick Hines"),
        new XElement("Phone", "206-555-0144"),
        new XElement("Address",
            new XElement("Street1", "123 Main St"),
            new XElement("City", "Mercer Island"),
            new XElement("State", "WA"),
            new XElement("Postal", "68042")
        )
    );

Although LINQ to XML is a good technology and I really love it, those new XElement parts look a little bit annoying. This is how I can rewrite it by using ExpandoObject.

dynamic contact = new ExpandoObject();
contact.Name = "Patrick Hines";
contact.Phone = "206-555-0144";
contact.Address = new ExpandoObject();
contact.Address.Street = "123 Main St";
contact.Address.City = "Mercer Island";
contact.Address.State = "WA";
contact.Address.Postal = "68402";

Just note a couple of things. First, look at the declaration of contact.

dynamic contact = new ExpandoObject();

I didn’t write ExpandoObject contact = new ExpandoObject(), because if I did contact would be a statically-typed object of the ExpandoObject type. And of course, statically-typed variables cannot add members at run time. So I used the new dynamic keyword instead of a type declaration, and since ExpandoObject supports dynamic operations, the code works.

Second, notice that every time I needed a node to have subnodes, I simply created a new instance of ExpandoObject as a member of the contact object.

It looks like the ExpandoObject example has more code, but it’s actually easier to read. You can clearly see what subnodes each node contains, and you don’t need to deal with the parentheses and indentation. But the best part is how you can access the elements now.

This is the code you need to print the State field in LINQ to XML.

Console.WriteLine((string)contactXML.Element("Address").Element("State"));

And this is how it looks with ExpandoObject.

Console.WriteLine(contact.Address.State);

But what if you want to have several Contact nodes? Like in the following LINQ to XML example.

XElement contactsXML =
    new XElement("Contacts",
        new XElement("Contact",
            new XElement("Name", "Patrick Hines"),
            new XElement("Phone", "206-555-0144")
        ),
        new XElement("Contact",
            new XElement("Name", "Ellen Adams"),
            new XElement("Phone", "206-555-0155")
        )
    );

Just use a collection of dynamic objects.

dynamic contacts = new List<dynamic>();

contacts.Add(new ExpandoObject());
contacts[0].Name = "Patrick Hines";
contacts[0].Phone = "206-555-0144";

contacts.Add(new ExpandoObject());
contacts[1].Name = "Ellen Adams";
contacts[1].Phone = "206-555-0155";

Technically speaking, I could write dynamic contacts = new List<ExpandoObject>() and the example would work. However, there are some situations where this could cause problems, because the actual type of the list elements should be dynamic and not ExpandoObject, and these are two different types. (Once again, references to the ExpandoObject objects are statically-typed and do not support dynamic operations.)

Now, if you want to find all the names in your contact list, just iterate over the collection.

foreach (var c in contacts)
    Console.WriteLine(c.Name);

Again, this syntax is better than LINQ to XML version.

foreach (var c in contactsXML.Descendants("Name"))
    Console.WriteLine((string)c);

So far, so good. But one of the main advantages of LINQ to XML is, well, LINQ. How would you query dynamic objects? Although there is still a lot to be done in this particular area, you can query dynamic objects. For example, let’s find all the phone numbers for the specified name.

var phones = from c in (contacts as List<dynamic>)
             where c.Name == "Patrick Hines"
             select c.Phone;

True, the cast here doesn’t look like something strictly necessary. Certainly the compiler could have determined at run-time that contacts is List<dynamic>. But as I said, there is still some work to be done in this area.

Another thing to note is that this trick works only for the LINQ to Objects provider. To use dynamic objects in LINQ to SQL or other LINQ providers, you need to modify the providers themselves, and that’s a completely different story.

However, even with the cast, syntax is still better than in a LINQ to XML query.

var phonesXML = from c in contactsXML.Elements("Contact")
                where c.Element("Name").Value == "Patrick Hines"
                select c.Element("Phone").Value;

Sure, there are some things that look better in LINQ to XML. For example, if you want to delete a phone number for all the contacts, you can write just one line of code in LINQ to XML.

contactsXML.Elements("Contact").Elements("Phone").Remove();

Since C# doesn’t have syntax for removing object members, you don’t have an elegant solution here. But ExpandoObject implements IDictionary<String, Object> to maintain its list of members, and you can delete a member by deleting a key-value pair.

foreach (var person in contacts)
    ((IDictionary<String, Object>)person).Remove("Phone");

There are other useful methods in LINQ to XML like Save() and Load(). For ExpandoObject you need to write such methods yourself, but probably only once. Here, casting to the IDictionary interface can help as well.

And although I’ve been comparing LINQ to XML and ExpandoObject in this post, these two approaches are not “rivals”. You can convert ExpandoObject to XElement and vice versa. For example, this is what the ExpandoObject to XElement conversion might look like.

private static XElement expandoToXML(dynamic node, String nodeName)
{
    XElement xmlNode = new XElement(nodeName);

    foreach (var property in (IDictionary<String, Object>)node)
    {

        if (property.Value.GetType() == typeof(ExpandoObject))
            xmlNode.Add(expandoToXML(property.Value, property.Key));

        else
            if (property.Value.GetType() == typeof(List<dynamic>))
                foreach (var element in (List<dynamic>)property.Value)
                    xmlNode.Add(expandoToXML(element, property.Key));
            else
                xmlNode.Add(new XElement(property.Key, property.Value));
    }
    return xmlNode;
}

This little trick might help you access all the LINQ to XML functions when you need them but at the same time use more convenient syntax when creating and modifying XML trees.

Of course, XML is not the only area where you can use ExpandoObject. If you heavily use reflection or work a lot with script objects, you can simplify your code with ExpandoObject. On the other hand, ExpandoObject is not the only useful class that the DLR provides. The DynamicObject class, for example, enables you to take more control over dynamic operations and define what actually happens when you access a member or invoke a method. But that’s a topic for another blog post.

One more thing to note is that libraries that look up members by name might someday adopt the DLR and implement the IDynamicMetaObjectProvider interface. (This interface actually provides all the “magic” – or dynamic dispatch – for ExpandoObject and the dynamic feature in general.) For example, if LINQ to XML implements this interface, you would be able to write dynamic contacts = new XmlElement() instead of dynamic contacts = new ExpandoObject() and perform the same operations that I have shown in the examples for the ExpandoObject type.

All the examples provided in this blog post work in Visual Studio 2010 Beta 1. If you have any comments or suggestions, you are welcome to post them here or contact the DLR team at http://www.codeplex.com/dlr. You can also write an e-mail to the DLR team at dlr@microsoft.com.

Update:

See how you can improve this example in my next post: Dynamic in C# 4.0: Creating Wrappers with DynamicObject.

Syndicated via RSS From: http://blogs.msdn.com/b/csharpfaq/