Tuesday, October 20, 2009

My current approach to Context/Specification

One of my most popular posts from last year is an article on test naming guidelines, which was written to resemble the format used by the Framework Design Guidelines.  Despite the popularity of the article, I started to stray from those guidelines over the last year.  While I haven’t abandoned the philosophy of those guidelines, in fact most of the general advise still applies, I’ve begun to adopt a much different approach for structuring and organizing my tests, and as result, the naming has changed slightly too.

The syntax I’ve promoted and followed for years, let’s call it TDD or original-flavor, has a few known side-effects:

  • Unnecessary or complex Setup – You declare common setup logic in the Setup of your tests, but not all tests require this initialization logic.  In some cases, a test requires entirely different setup logic, so the initial “arrange” portion of the test must undo some of the work done in the setup.
  • Grouping related tests – When a complex component has a lot of tests that handle different scenarios, keeping dozens of tests organized can be difficult.  Naming conventions can help here, but are masking the underlying problem.

Over the last year, I’ve been experimenting with a Behavior-Driven-Development flavor of tests, often referred to as Context/Specification pattern.  While it addresses the side-effects outlined above, the goal of “true” BDD is to attempt to describe requirements in a common language for technical and non-technical members of an Agile project, often with a Given / When / Should syntax.  For example,

Given a bank account in good standing, when the customer requests cash, the bank account should be debited

The underlying concept is when tests are written using this syntax, they become executable specifications – and that’s really cool.  Unfortunately, I’ve always considered this syntax to be somewhat awkward, and how I’ve adopted this approach is a rather loose interpretation.  I’m also still experimenting, so your feedback is definitely welcome.

An Example

Rather than try to explain the concepts and the coding style in abstract terms, I think it’s best to let the code speak for itself first and then try reason my way out.

Note: I’ve borrowed and bended concepts from many different sources, some I can’t recall where.  This example borrows many concepts from Scott Bellware’s specunit-net.

public abstract class ContextSpecification
{
    [TestFixtureSetUp]
    public void SetupFixture()
    {
       BeforeAllSpecs();
    }
    
    [TestFixtureTearDown]
    public void TearDownFixture()
    {
       AfterAllSpecs();
    }

     [SetUp]
     public void Setup()
    {
       Context();
       Because();
    }

    [TearDown]
    public void TearDown()
    {
       CleanUp();
    }

    protected virtual void BeforeAllSpecs() { }
    protected virtual void Context() { }
    protected virtual void Because() { }
    protected virtual void CleanUp() { }
    protected virtual void AfterAllSpecs() { }   
}

public class ArgumentBuilderSpecs : ContextSpecification
{
    protected ArgumentBuilder builder;
    protected Dictionary<string,string> settings;
    protected string results;

    protected override void Context()
    {
       builder = new ArgumentBuilder();
       settings = new Dictionary<string,string>();
    }

    protected override void Because()
    { 
       results = builder.Parse(settings);
    }

    [TestFixture]
    public class WhenNoArgumentsAreSupplied : ArgumentBuilderSpecs
    {
       [Test]
       public void ResultsShouldBeEmpty()
       {
           results.ShouldBeEmpty();
       }
    }

    [TestFixture]
    public class WhenProxyServerSettingsAreSupplied : ArgumentBuilderSpecs
    {
       protected override void Because()
       {
           settings.Add("server", "proxyServer");
           settings.Add("port", "8080");

           base.Because();
       }

       [Test]
       public void ShouldContainProxyServerArgument()
       {
           results.ShouldContain("-DhttpProxy:proxyServer");
       }

       [Test]
       public void ShouldContainProxyPortArgument()
       {
           results.ShouldContain("-DhttpPort:8080");
       }
  }
}

Compared to my original flavor, this new bouquet has some considerable differences which may seem odd to an adjusted palate.  Let’s walk through those differences:

  • No longer using Fixture-per-Class structure, where all tests for a class reside within a single class.
  • Top level “specification” ArgumentBuilderSpecs is not decorated with a [TestFixture] attribute, nor does it contain any tests.
  • ArgumentBuilderSpecs derives from a base class ContextSpecification which controls the setup/teardown logic and the semantic structure of the BDD syntax.
  • ArgumentBuilderSpecs contains the variables that are common to all tests, but setup logic is kept to a minimum.
  • ArgumentBuilderSpecs contains two nested classes that derive from ArgumentBuilderSpecs.  Each nested class is a test-fixture for a scenario or context.
  • Each Test-Fixture focuses on a single action only and is responsible for its own setup.
  • Each Test represents a single specification, often only as a single Assert.
  • Asserts are made using Extension methods (not depicted in the code example)

Observations

Inheritance

I’ve never been a big fan of using inheritance, especially in test scenarios as it requires more effort on part of the future developer to understand the test structure.  In this example, inheritance plays a part in both the base class and nested classes, though you could argue the impact of inheritance is negated since the base class only provides structure, and the derived classes are clearly visible within the parent class.  It’s a bit unwieldy, but the payoff for using inheritance is found when viewing the tests in their hierarchy:

Context-Spec-Example

While technically you could achieve a similar effect by using namespaces to group tests, but you lose some of the benefits of encapsulation of test-helper methods and common variables.

Although we can extend our contexts by deriving from the parent class, this approach is limited to inheriting from the root specification container (ArgumentBuilderSpecs).  If you were to derive from WhenProxyServerSettingsAreSupplied for example, you would inherit the test cases from that class as well.  I have yet to find a scenario where I needed to do this.  While the concepts of DRY make sense, there’s a lot to be said about clear intent of test cases where duplication aids readability.

Extra Plumbing

There’s quite a bit of extra plumbing to be able to create our nested contexts, and it seems to take a bit longer to write tests.  This delay is either caused by grappling with new context/specification concepts, writing additional code for subclasses or more thought determining which contexts are required.  I’m anticipating that it gets easier with more practice, and some Visual Studio code snippets might simplify the authoring process.

One area where I can sense I’m slowing down is trying to determine if I should be overriding or extending Context versus Because.

Granular Tests

In this style of tests, where a class is created to represent a context, each context performs only one small piece of work and the tests serve as assertions against the outcome.  I found that the tests I wrote were concise and elegant, and the use of classes to structure the tests around the context helped to organize both the tests and the responsibility of the subject under test.  I also found that I wrote fewer tests with this approach – I write only a few principle contexts.  If a class starts to have too many contexts, it could mean that the class has too much responsibility and should be split into smaller parts.

Regarding the structure of the tests, if you’re used to fixture-per-class style of tests, it may take some time to get accustomed to the context performing only a single action.  Though as Steven Harman points out, visualizing the context setup as part of the fixture setup may help guide your transition to this style of testing.

Conclusion

I’m enjoying writing Context/Specification style tests as they read like a specification document and provide clear feedback of what the system does.  In addition, when a test fails, the context it belongs to provides additional meaning around the failure.

There appear to be many different formats for writing tests in this style, and my current format is a work in progress.  Let me know what you think.

Presently, I’m flip flopping between this format and my old habits.  I’ve caught myself a few times where I write a flat structure of tests without taking context into consideration – after a point, the number of tests becomes unmanageable, and it becomes difficult to identify if I should be tweaking existing tests or writing new ones.  If the tests were organized by context, the number of tests becomes irrelevant, and the focus is placed on the scenarios that are being tested.

submit to reddit

Monday, October 19, 2009

Configuring the Selenium Toolkit for Different Environments

Suppose you’ve written some selenium tests using Selenium IDE that target your local machine (http://localhost), but you’d like to repurpose the same tests for your QA, Staging or Production environment as part of your build process.  The Selenium Toolkit for .NET makes this really easy to change the target environment without having to touch your tests.

In this post, I’ll show you how to configure the Selenium Toolkit for the following scenarios:

  • Local Selenium RC / Local Web Server
  • Local Selenium RC / Remote Web Server
  • Remote Selenium RC / Remote Web Server

Running Locally

In this scenario, both the Selenium Remote Control Host (aka Selenium RC / Selenium Server) and the web site you want to test are running on your local machine.  This is perhaps the most common scenario for developers who develop against a local environment, though it also applies to your build server if the web server you want to test is also on that machine. 

Although this configuration is limited to running tests against the current operating system and installed browsers, it provides a few advantages to developers as they can watch the tests execute or set breakpoints on the server to assist in debugging.

This is the default configuration for the Selenium Toolkit for .NET – when the tests execute, the NUnit Addin will automatically start the Selenium RC process and shut it down when the tests complete.

Assuming you have installed the Selenium Toolkit for .NET, the only configuration setting you'll need to provide is the URL of the web site you want to test. In this example, we assume that http://mywebsite is running on the local web server.

<Selenium BrowserUrl="http://mywebsite" />

Running Tests against a Remote Web Server

In this scenario Selenium RC runs local, but web server is on a remote machine.  You’ll still see the browser executing the tests locally, but because the web-server is physically located elsewhere it’s not as easy to debug server-side issues.  From a configuration perspective, this scenario uses the same configuration settings as above, except the URL of the server is not local.

This scenario is typically used in a build server environment.  For example, the build server compiles and deploys the web application to a target machine using rsync and then uses Selenium to validate the deployment using a few functional tests.

Executing Tests in a Remote Environment / Selenium Grid

In this scenario your local test-engine executes your tests against a remote Selenium RC process.  While this could be a server where the selenium RC process is configured to run as a dedicated service, it’s more likely that you would use this configuration for executing your tests against a Selenium Grid.  The Selenium Grid server exposes the same API as the Selenium RC, but it acts as a broker between your tests and multiple operating systems and different browser configurations.

To configure the Selenium Toolkit to use a Selenium Grid, you’ll need to specify the location of the Grid Server and turn off the automatic start/stop feature:

<Selenium
     server="grid-server-name"
     port="4444"  
     BrowserUrl="http://mywebsite.com"
   />
   <runtime
        autoStart="false"
        />
</Selenium>

submit to reddit

Thursday, October 15, 2009

A Proposal for Functional Testing

When I’m writing code, my preference is to follow test-driven development techniques where I’m writing tests as I go.  Ideally, each test fixture focuses attention on one object at a time, isolating its behavior from its dependencies.

While unit tests provide us with immediate feedback about our progress, it would be foolish to deploy a system without performing some form of integration test to ensure that the systems’ components work as expected when pieced together.  Often, integration tests focus on a cohesive set of objects in a controlled environment, such as a restoring a database after the test.

Eventually, you’ll need to bring all the components together and test them in real-world scenarios.  The best place to bring all these components together is the live system or staged equivalent.  The best tool for the job is a human inspecting the system. Period.

Wait, I thought this was supposed to be about functional testing?  Don’t worry, it is.

Humans may be the best tool for the job, but if you consider the amount of effort associated with code-freezes, build-reports, packaging and deployment, verification, coordination with the client and waiting testing teams, it can be really expensive to use humans for testing.  This is especially true if you deliver a failed build to your testing team -- your testing team who’ve been queued up are now unable test, and must wait for the next build.  If you were to total up all the hours from the entire team, you’d be losing at least a day or more in scheduled cost.

Functional tests can help prevent this loss in production.

In addition, humans possess an understanding of what the system should do, as well as what previous versions did.  Humans are users of the system and can contribute greatly to the overall quality of the product.  However, once a human has tested and validated a feature, revisiting these tests in subsequent builds becomes more of a check than a test.  Having to go back and check these features becomes increasingly difficult to accomplish in short-timelines as the complexity of the system grows.  Invariably, shortcuts are taken, features are missed and subtle, aggravating bugs silently sneak into the system.  While separation of concerns and good unit tests can downplay the need for full regression tests, the value of system-wide integration tests for repetitive tasks shouldn’t be discounted.

Functional tests can help here too, but these are largely the fruits of labor of my first point about validating builds.  Most organizations can’t capitalize on this simply because they haven’t got the base to build up from.

Functional tests take a lot of criticism, however.  Let’s address some common (mis)beliefs.

Duplication of testing efforts / Diminishing returns.  Where teams have invested in test driven development, tests tend to focus on the backend code artifacts as these parts are the core logic of the application.  Using mocks and stubs, the core logic can be tested extremely well from the database layer and up, but as unit-tests cross the boundary from controller-logic into the user-interface layer, testing becomes harder to simulate: web-applications need to concern themselves with server requests; desktop applications have to worry about things like screen resolution, user input and modal dialogs.  In such team environments, testing the user-interface isn’t an attractive option since most bugs, if any, originate from the core logic that can be covered by more unit tests.  From this perspective, adding functional tests wouldn’t provide enough insight to outweigh the effort involved.

I’d agree with this perspective, if the functional tests were trying to aggressively interrogate the system at the same level of detail of their backend equivalents.  Unlike unit tests, functional tests are focused on emulating what the user does and sees, not on the technical aspects under the hood.  They operate in the live system, providing a comprehensive view of the system that is unit tests cannot.  In the majority of cases, a few simple tests that follow the happy path of the application may be all you need to validate the build.

More over, failures at this level point to problems in the build, packaging or deployment – something well beyond a typical unit test’s reach.

Functional tests are too much effort / No time for tests.  This is a common view that is applied to testing in general, which is based on a flawed assumption that testing should follow after development work is done.  In this argument, testing is seen as “double the effort”, which is an unfair position if you think about it.  If you treat testing as a separate task and wait until the components are fully written, then without a doubt the action of writing tests becomes an exercise in reverse-engineering and will always be more effort.

Functional tests, like unit tests, should be brought into the development process.  While there is some investment required to get your user-interface and its components into a test-harness, the effort to add new components and tests (should) become an incremental task.

Functional tests are too brittle / Too much maintenance.  Without doubt, the user-interface can be the most volatile part of your application, as it is subject to frequent cosmetic changes.  If you’re writing tests that depend on the contract of the user-interface, it shouldn’t be a surprise that they’re going to be impacted when that interface changes.  Claiming that your tests are the source of extra effort because of changes you introduced is an indication of a problem in your approach to testing.

Rather than reacting to changes, anticipate them: if you have a change to make, use the tests to introduce that change.  There are many techniques to accomplish this (and I may have to blog about that later), but here’s an example: to identify tests that are impacted by your change, try removing the part that needs to change and watch which tests fail.  Find a test that resembles your new requirement and augment it to reflect the new requirements. The tests will fail at first, but as you add the new requirements, they’ll slowly turn green.

As an added bonus, when you debug your code through the automated test, you won’t have to endure repetitive user-actions and keystrokes.  (Who has time for all the clicking??)

This approach works well in agile environments where stories are focused on adding or changing features for an interaction and changes to the user-interface are expected.

Adding Functional Testing to your Regime

Develop a test harness

The first step to adding functional testing into your project is the development of a test-harness that can launch the application and get it into a ready state for your tests.  Depending on the complexity of your application and the extent of how far you want to take your functional tests, this can seem like the largest part.  Fortunately most test automation products provide a “recorder” application that can generate code from user activity, which can jump start this process.  While these tools make it easy to get started, they are really only suitable for basic scenarios or for initial prototyping.  As your system evolves you quickly find that the duplication in these scripts becomes a maintenance nightmare.

To avoid this issue, you’ll want to model the screens and functional behavior of your application into modular, components that hide the implementation details of the recorder tools’ output.  This approach shields you from having to re-record your tests and makes it easier to apply changes to tests.  The downfall to this approach is that it may take some deep thinking on how to model your application, and it will seem as though you’re writing a lot of code to emulate what your backend code already does.  However, once this initial framework is in place, it becomes easier to add new components.  Eventually, you reach a happy place where you can write new tests without having to record anything.

The following example illustrates how the implementation details of a product editor are hidden from the test, but the user actions are clearly visible:

[Test]
public void CanOpenAnExistingProduct()
{
    using (var app = new App())
    {
        app.Login("user1", "p@ssw3rd");

        var product = new Product()
                            {
                                Id = 1,
                                Name = "Foo"
                            };

        // opens the product editor, 
        // fills it with my values
        // saves it, closes it.
        app.CreateNewProduct(product);

        // open the dialog, find the item
        ProductEditorComponent editor = app.OpenProductEditor("Foo");

        // retrieves the settings of the product from the screen
        Product actual = editor.GetEntity();

        Assert.AreEqual(product, actual);
    }
}

Write Functional Unit Tests for Screen Components

Once you’ve got a basic test-harness, you should consider developing simple functional tests for user-interface components as you add them to your application.   If you can demo it to the client, you're probably ready to start writing functional tests. A few notes to consider at this stage:

  • Be pragmatic!  Screen components that are required as part of base use cases will have more functional tests than non-essential components.
  • Consider pairing developers with testers.  As the developer builds the UI, the tester writes the automation tests that verify the UI’s functionality.  Testers may guide the development of the UI to include automation ids, which reduces the amount of reverse-engineering.
  • Write tests as new features or changes are introduced.  No need to get too granular, just verify that the essentials.

Verify Build Process with Functional Sanity Tests

While your functional unit tests concentrate on the behaviors of individual screen components, you’ll want to augment your build process with tests that demonstrate common user-stories that can be used to validate the build.  These tests mimic the minimum happy path.

If you’re already using a continuous integration server to run unit tests as part of each build, functional tests can be included at this stage but can be regulated to nightly builds or as part of the release process to your quality assurance team.

Augment QA Process

As noted above, humans are a critical part of the testing of our applications and that’s not likely to change.  However, the framework that we used to validate the build can be reused by your testing team to write automation tests for their test cases.  Ideally, humans verify the stories manually, then write automation tests to represent regression tests.

Tests that require repetitive or complex time consuming procedures are ideal candidates for automation.

Conclusion

Automated functional testing can add value to your project for build verification and regression testing.  Being pragmatic about the components you automate and vigilant in your development process to ensure the tests remain in sync are the keys to their success.

How does your organization use functional testing?  Where does it work work?  What’s your story?

submit to reddit

Wednesday, October 07, 2009

Use Windows 7 Libraries to organize your code

One of the new features that I’m really enjoying in Windows 7 is the ability to group common folders from different locations into a common organizational unit, known as a Library.  I work with a lot of different code bases and tend to generate a lot of mini-prototypes, and I’ve struggled with a good way to organize them.  The Library feature in Windows 7 offers a neat way to view and organize your files.  Here’s how I’ve organized mine.

Create your Library

  1. Open windows explorer
  2. Bring up the context-menu on the Libraries root folder and choose “New –> Library”
  3. Select folders to include in your library.

While your folders can be organized from anywhere, I’ve created a logical folder “C:\Projects” and four sub-folders:

  • C:\Projects\Infusion (my employer)
  • C:\Projects\lib (group of common libraries I reference a lot)
  • C:\Projects\Experiments (small proof of concept projects)
  • C:\Projects\Personal (my pet projects)

Note that you can easily add new folders to your library by clicking on the Includes: x locations hyperlink.  This dialog also lets you move folders up and down, which makes it easy to organize the folders based on your preference.

Here’s a screen capture of my library, arranged by folder with a List view.

CodeLibrary

By default, the included folders are arranged by “Folder” and behind the scenes they’re grouped by the “Folder Path” of the included folders, which gives us the headings above our included folders.  A word of caution: while you can change the “Arrange by” and “view” without issue, if you change the setting for Group-by (view-> group by) there doesn’t appear to be a way to easily revert the Group-by setting back to the default.  Thus, if your heading back you’ll have to manually add the “Folder Path” column and the set it to the group-by value, but the user-defined sort order of the Libraries won’t be used.

This dialog is available anywhere that uses a standard COM dialog.  From within Visual Studio, this view is really helpful when adding project references, opening files and creating projects.  Being able to search all of your code using in the top-right is awesome.

Add your Library to the Start Menu

There are a few hacks to put your library on to the start menu.  You can pin the item to the start menu, which puts it on the left-side of the start menu.  This technique requires a registry hack to allow Libraries to be pinned.

If you want to put your library into the right-hand side of the start menu, there is no native support for adding custom folders.  However, you can repurpose some of the existing folders.  I’ve added my library by repurposing the “Recorded TV” library, since my work PC doesn’t have any recorded TV.

Here’s how:

  1. Open the Control Panel
  2. Choose “Appearance and Personalization”
  3. Choose “Customize the Start Menu” under Taskbar and Start Menu.
  4. Turn on the “Recorded TV” option as “Display as a menu”

    Customize-StartMenu

  5. Next, on the Start Menu, right-click “Recorded-TV”, remove the default folder locations and then add your own.
  6. Rename the “Recorded TV” to whatever you want.

Here’s a screen capture of my start menu.

StartMenu

submit to reddit

Monday, October 05, 2009

Find differences between images C#

Suppose you had two nearly identical images and you wanted to locate and highlight the differences between them.  Here’s a fun snippet of C# code to do just that.

While the Bitmap class includes methods for manipulating individual pixels (GetPixel and SetPixel), they aren’t as efficient as manipulating the data directly.  Fortunately, we can access the low-level bitmap data using the BitmapData class, like so:

Bitmap image = new Bitmap("image1.jpg");

Rectangle rect = new Rectangle(0,0,image.Width,image.Height);
BitmapData data = image.LockBits(rect, ImageLockMode.ReadOnly, PixelFormat.Format24bppRgb);

Since we’re manipulating memory directly using pointers, we have to mark our method that locks and unlocks the bits with the unsafe keyword, which is not CLS compliant. This is only a problem if you expose this method as part of a public API and you want to share your library between C# and other .NET languages. If you want to maintain CLS compliant code, just make the unsafe method as a private member.

To find the differences between two images, we'll loop through and compare the low-level bytes of the image. Where the pixels match, we'll swap the pixel with a pre-defined colour and then later treat this colour as transparent, much like the green-screen technique used in movies. The end result is an image that contains the differences that can be transparently overlaid over top.

public class ImageTool
{
    public static unsafe Bitmap GetDifferenceImage(Bitmap image1, Bitmap image2, Color matchColor)
    {
        if (image1 == null | image2 == null)
            return null;

        if (image1.Height != image2.Height || image1.Width != image2.Width)
            return null;

        Bitmap diffImage = image2.Clone() as Bitmap;

        int height = image1.Height;
        int width = image1.Width;

        BitmapData data1 = image1.LockBits(new Rectangle(0, 0, width, height), 
                                           ImageLockMode.ReadOnly, PixelFormat.Format24bppRgb);
        BitmapData data2 = image2.LockBits(new Rectangle(0, 0, width, height), 
                                           ImageLockMode.ReadOnly, PixelFormat.Format24bppRgb);
        BitmapData diffData = diffImage.LockBits(new Rectangle(0, 0, width, height), 
                                               ImageLockMode.WriteOnly, PixelFormat.Format24bppRgb);

        byte* data1Ptr = (byte*)data1.Scan0;
        byte* data2Ptr = (byte*)data2.Scan0;
        byte* diffPtr = (byte*)diffData.Scan0;

        byte[] swapColor = new byte[3];
        swapColor[0] = matchColor.B;
        swapColor[1] = matchColor.G;
        swapColor[2] = matchColor.R;

        int rowPadding = data1.Stride - (image1.Width * 3);

        // iterate over height (rows)
        for (int i = 0; i < height; i++)
        {
            // iterate over width (columns)
            for (int j = 0; j < width; j++)
            {
                int same = 0;

                byte[] tmp = new byte[3];

                // compare pixels and copy new values into temporary array
                for (int x = 0; x < 3; x++)
                {
                    tmp[x] = data2Ptr[0];
                    if (data1Ptr[0] == data2Ptr[0])
                    {
                        same++;
                    }
                    data1Ptr++; // advance image1 ptr
                    data2Ptr++; // advance image2 ptr
                }

                // swap color or add new values
                for (int x = 0; x < 3; x++)
                {
                    diffPtr[0] = (same == 3) ? swapColor[x] : tmp[x];
                    diffPtr++; // advance diff image ptr
                }
            }

            // at the end of each column, skip extra padding
            if (rowPadding > 0)
            {
                data1Ptr += rowPadding;
                data2Ptr += rowPadding;
                diffPtr += rowPadding;
            }
        }

        image1.UnlockBits(data1);
        image2.UnlockBits(data2);
        diffImage.UnlockBits(diffData);

        return diffImage;
    }
}

An example that finds the difference between the images and then converts the matching colour to transparent.

class Program
{
    public static void Main()
    {
        Bitmap image1 = new Bitmap(400, 400);

        using (Graphics g = Graphics.FromImage(image1))
        {
            g.DrawRectangle(Pens.Blue, new Rectangle(0, 0, 50, 50));
            g.DrawRectangle(Pens.Red, new Rectangle(40, 40, 100, 100));
        }
        image1.Save("C:\\test-1.png",ImageFormat.Png);

        Bitmap image2 = (Bitmap)image1.Clone();

        using (Graphics g = Graphics.FromImage(image2))
        {
            g.DrawRectangle(Pens.Purple, new Rectangle(0, 0, 40, 40));
        }
        image2.Save("C:\\test-2.png",ImageFormat.Png);

        Bitmap diff = ImageTool.GetDifferenceImage(image1, image2, Color.Pink);
        diff.MakeTransparent(Color.Pink);
        diff.Save("C:\\test-diff.png",ImageFormat.Png);
    }
}

submit to reddit

Thursday, October 01, 2009

Reading Oracle Spatial data into .NET

Recently, I was tasked with pulling geo-spatial data from Oracle into an application.  While Microsoft provides support for SQL Server 2008’s SqlGeometry and SqlGeography data types in the Microsoft.SqlServer.Types namespace, there is no equivalent for Oracle’s SDO_Geometry data type.  We’ll need some custom code to pull this information out of Oracle.

What is Geospatial Data?

Both SQL Server and Oracle provide native data types, SqlGeometry and SDO_Geometry respectively to represent spatial data.  These special fields can be used to describe a single point, or collection of points to form a line, multi-line, polygon, etc. The database technology indexes this data to create a “spatial index”, and provides native SQL functions to query for intersecting and nearby points.  The result is an extremely powerful solution that serves as the basis for next-generation location-aware technologies.

Oracle stores spatial data as a Character Large Object (CLOB), and to read it, we’ll need to parse that data into a structure we can use.

User Defined types with Oracle Data Provider for .NET

Fortunately, parsing the CLOB is really quite easy as the Oracle Data Provider for .NET supports a plug-in architecture that let you define your own .NET user-defined types.  I found a great starter example in the oracle forums that included user-defined types for SDO_Geometry and SDO_Point.  A near identical example can be found as part of the Topology Framework .NET, which cites Dennis Jonio as the author.

Summarized, the classes appear as:

[OracleCustomTypeMappingAttribute("MDSYS.SDO_POINT_TYPE")]
public class SdoPoint : OracleCustomTypeBase<SdoPoint>
{
    public decimal? X { get; set; }
    public decimal? Y { get; set; }
    public decimal? Z { get; set; }

    /* ... details omitted for clarity  */
}

[OracleCustomTypeMappingAttribute("MDSYS.SDO_GEOMETRY")]
public class SdoGeometry : OracleCustomTypeBase<SdoGeometry>
{
    public decimal? Sdo_Gtype { get; set; }
    public decimal? Sdo_Srid { get; set; }
    public SdoPoint Point { get; set; }
    public decimal[] ElemAray { get; set; }
    public decimal[] OrdinatesArray { get; set; }
    
    /* ... details omitted for clarity  */
}

With these custom user-defined types, spatial data can be read from the database just like any other data type.

[Test]
public void CanFetchSdoGeometry()
{
    string oracleConnection = 
            "Data Source=" +
                "(DESCRIPTION=" +
                    "(ADDRESS_LIST=" +
                        "(ADDRESS=" + 
                            "(PROTOCOL=TCP)" + 
                            "(HOST=SERVER1)" + 
                            "(PORT=1600) +
                        ")" +
                    ")"
                    "(CONNECT_DATA=" + 
                        "(SERVER=DEDICATED)" +
                        "(SERVICE_NAME=INSTANCE1)"
                    ")" +
                ");" +
                "User Id=username;" +
                "Password=password;";

    using (OracleConnection cnn = new OracleConnection(oracleConnection))
    {
        cnn.Open();

        string sql = "SELECT * FROM TABLE1";

        OracleCommand cmd = new OracleCmd(sql, cnn);
        cmd.CommandType = System.Data.CommandType.Text;

        OracleDataReader reader = cmd.ExecuteReader();
        
        while(reader.Read())
        {
            if (!reader.IsDBNull(1))
            {
                SdoGeometry geometry = reader.GetValue(1) as SdoGeometry;
                Assert.IsNotNull(geometry);
            }
        }
    }
}

Using SdoGeometry in your Application

Now that we have our SdoGeometry type, how do we use it?  The oracle documentation provides us with some details which we can use to decipher the SDO_GEOMETRY object type.

Recall that our SdoGeometry object has five properties: Sdo_Gtype, Sdo_Srid, Point, ElemArray and OrdinatesArray.

In the most basic scenario when your geometry object refers to a single point, all the information you need is in the Point property.  In all other scenarios, Point will be null and you’ll have to parse the values out of the Ordinates array.

Although the Geometry Type (sdo_gtype) property is represented as an integer, it uses a numbering format to convey the shape-type and structure of the ordinates array.  The four digits of the sdo_gtype represent dltt, where:

  • First digit “d” represents how many dimensions are used to represent each point, and consequently, how many bytes in the ordinates array are used to describe a point. Possible values are 2, 3 or 4.
  • The second digit, “l” refers to the LRS measurement when there are more than 2 dimensions.  This is typically zero for the default.
  • The last two digits refer to the shape.

Since the algorithm to convert from UTM to Latitude/Longitude depends on your Projection and Datum, I don’t want to mislead anyone with the wrong algorithm.  A very detailed breakdown of the formulas are listed here, including an Excel Spreadsheet that breaks down the formula.  Here’s an example:

public Shape ToShape(SdoGeometry geometry)
{
    Shape shape = new Shape();

    if (geometry.Point != null)
    {
        LatLong point = ReadPoint(geometry.Point);
        shape.Add(point);
        shape.shapeType = Constants.ShapeType.Point;
    }
    else
    {

        // GTYPE is represented as dltt where:
        //      d  = number of dimensions to the data
        //      l  = LRS measure value (default is zero)
        //      tt = shape type 
        string gType = geometry.Sdo_Gtype.Value.ToString();
        int dimensions = Convert.ToInt32(gType.Substring(0, 1));
        int lrsMeasureValue = Convert.ToInt32(gType.Substring(1, 1));
        int shapeType = Convert.ToInt32(gType.Substring(3));

        // convert tt value to a custom enum
        shape.shapeType = GetShapeType(shapeType);

        LatLongs points = ReadPoints(geometry.OrdinatesArray, dimensions);
        shape.Points.Add(points);
    }

    return shape;
}

private LatLongs ReadPoints(decimal[] ordinates, int dimensions)
{
    LatLongs points = new LatLongs();
    for (int pIndex = 0; pIndex < ordinates.Length; pIndex += dimensions)
    {
        double lat = (double)ordinates[pIndex];
        double lng = (double)ordinates[pIndex + 1];

        LatLong latLong = ToLatLong(lat, lng);
        points.Add(latLong);
    }
    return points;
}

submit to reddit

Wednesday, September 23, 2009

Understanding SharePoint’s “ddwrt:DataBind” syntax

SharePoint takes a lot of criticism from developers but it is really impressive what you can do without writing backend code. In my last large SharePoint implementation, I was customizing some input fields for a form using SharePoint Designer.  I found myself looking at the XSLT for a DataFormWebPart wondering how to decipher the auto-generated _designer:bind attribute.

<SharePoint:FormField runat="server" id="ff1{$Pos}" 
    ControlMode="Edit" FieldName="Field1"
    __designer:bind="{
        ddwrt:DataBind(
            'u', 
            concat('ff1',$Pos), 'Value', 'ValueChanged'
            'ID', ddwrt:EscapeDelims(@ID), '@Field1'
        )}"
    />

Strangely, the method ddwrt:DataBind is absent from what is probably the best online overview of the ddwrt XSLT extension object.  So I threw the question onto Stack Overflow to see if any bright people could shed light on the mysterious method.  Not surprisingly, no one could answer the question.  So I decided to do some spelunking in Reflector to see what I could find.
I opened reflector, added a reference to Microsoft.SharePoint then opened the search window.  Using the “Member Search” (tip: CTRL+M) I searched for "DataBind" and found the internal class, Microsoft.SharePoint.WebPartPages.DataFormDdwRuntime.  Some parts of this assembly are obfuscated, but by guestimation this is likely the extension object that is available to us in the XSLT under the namespace "ddwrt".

Oddly enough, the DataFormDdwRuntime.DataBind method returns an empty string, so it’s likely that the “__designer:bind” attribute is just a dummy attribute for SharePoint Designer, if at all.  Remember that curly braces inside an attribute is an XSLT expression, so the computed result is actually __designer:bind=””.  The real magic is that what the DataBind method actually does.

Behind the DataBind Method

Turns out that the DataBind method is basically a wrapper to the DataFormWebPart method, AddDataBinding.  This method has the following signature:

public override void AddDataBinding(string op,
                                    string controlId,
                                    string propertyName,
                                    string eventName,
                                    string keyField,
                                    string keyValue,
                                    string dataField
                                    ) 

As the name implies, it creates a data binding and associates it with the hosted WebPart, but the msdn documentation leaves us guessing as to what values should be used.  Reflector provides us some guidance.

Note:  keyField, keyValue and dataField all refer to methods that are obfuscated.  The detail below for these fields is my best guess, so take it AS-IS with no warranty.  As always, your comments, suggestions and feedback are welcome.

Operation Type (“op”)

This is the type of operation that will be used when the form is submitted. There are three possible values:  "i” (Insert), “u” (Update") and “d” (Delete).  The logic falls back to “update” if it doesn’t recognize the value passed in.

Bound Control (“controlId”)

This the id of the control that will be will be bound to the SharePoint list item.  The auto-generated value attempts to duplicate the value of the “id” attribute using an xslt function concat.  You can use your own format, but the chosen format for the id’s are “ff + field index + record index” where the field index is an arbitrary number, usually the order in which the fields appear in the designer (1,2,3, etc), and the keyword $Pos is an XSLT variable defined earlier in scope, referring to the position() of the row in the result set.

Bound Control Property (“propertyName”)

This is the property on our bound control that will ultimately be used to represent the SharePoint field value.  For SharePoint FormField controls, this property is “Value”.  Most ASP.NET controls can be used, assuming that the propertyName and eventName are properly set.

Bound Control Event (“eventName”)

This the event on the bound control that you want to be handled when the form posts information back to the server.  How this works is really interesting: it uses reflection to get the Event of your control, then binds the postback event to the DataFormWebPart's HandleChangedField method.  This method essentially fetches the value of your control (via the PropertyName) and then tracks that the field has changed or needs to be inserted.

For SharePoint FormField controls, this event is “ValueChanged”.

Data Source Primary Key (“keyField”)

Based on examples, the “key field” refers to the attribute in the dsQueryResponse XML which represents the primary key for this record.  This is likely always going to be "ID".  (ie, /dsQueryResponse/Rows/Row/@ID)

Data Source Primary Key Value (“keyValue”)

The value of the primary key, “ID”.  The ddwrt:EscapeDelims method is used to convert certain characters (,=;'{}") to a SharePoint unicode string equivalent (ie, “,” is converted to “_x002C_”).  For SharePoint Designer XSLT, this is likely always going to be ddwrt:EscapeDelims(@ID).

Data Source Field Name (“dataField”)

This is the name of the SharePoint field that we want to bind.  Since we’re pulling this value from the dsQueryResponse XML, it’s represented as it appears in the dsQueryResponse XML.

Some Examples

Updating a SharePoint text field using an ASP.NET TextBox:

<asp:TextBox 
    runat="server" 
    id="myTextBox{$Pos}"
    Text="{@Field1}" 
    Value="{@Field1}"
    __designer:bind="{ddwrt:DataBind(
                'u', 
                concat('myTextBox', $Pos),
                'Text',
                'TextChanged',
                'ID', 
                ddwrt:EscapeDelims(@ID),
                '@Field1')}" />

Insert a SharePoint text field as a ASP.NET DropDownList:

<asp:DropDownList 
    runat="server"
    id="myDropDown{$Pos}"
    __designer:bind="{ddwrt:DataBind(
        'i',
        concat('myDropDown', $Pos),
        'SelectedValue', 
        'TextChanged',
        'ID',
        ddwrt:EscapeDelims(@ID),
        '@Field2'}" />

Conclusion

If you’re using the auto-generated XSLT, the default format works fine.  However, if you want to craft the markup by hand or roll your own customizations, understanding this syntax is helpful.

submit to reddit

Monday, September 21, 2009

About the Selenium Toolkit for .NET

As part of the development process my open source project, I’ll be using my blog to post updates.  So subscribe via RSS, by email, follow me on twitter, or just bookmark me.

The Selenium Toolkit for .NET is based on my experiences implementing Selenium for .NET based projects.  When I started this project, I set out with the goal to minimize the time investment needed for developers to come on board, so they could concentrate on developing and running tests sooner.  This has largely been realized by separating the test-framework plumbing from the tests using an nunit addin and streamlining the setup process by creating an installer package that contains several utilities in a single download.

One of the more interesting and useful features that has come out of that initial goal is the ability to configure the tests through configuration elements in the app.config.  This feature makes it easy to run slightly different configurations between developer machines and build server without having to alter the tests.  Beyond this feature, and what excites me most, is that the toolkit and its configuration are separate components from the nunit addin.  This division makes it possible to include addins for other testing frameworks such as MSTest, xUnit, mbUnit, etc when available.  In addition, the toolkit uses a provider model for creating selenium instances.  This extensibility model will hopefully lead to future versions of the toolkit with features such as proxy-server detection, embedded user-extensions and alternate user-defined implementations of the ISelenium interface.

On the NUnit addin side, I'm presently compiling against version 2.4.8 simply because it was the framework I started the project with.  Unfortunately, the current design of the addin has a dependency to a specific nunit assembly, which results in some runtime errors if a newer version of nunit is used.  I'll likely be moving to 2.5.2 within a week if I find the time to do some regression testing.  Down the road I might investigate changing the addin to take advantage of some of NUnit's newer features, such as the RowTest extension.

The installer is functional, but there's still work to be done.  For instance, I'd like to have the Selenium IDE silently install into Firefox as part of the overall installation, and I'd like to provide some examples and Visual Studio Templates included as well.  I'll likely be converting from the Visual Studio installer package to a WiX format, to provide greater flexibilty during the user-experience.  WiX projects can also be built from the command-line (whereas VS installer projects can't), which will help to automate the packaging process.

Currently, the toolkit is listed as "beta" only because I can't guarantee that some of the interfaces won't change.  If you're downloading and running for tests, you might have to update some assemblies or tweak app.config files, but the core logic for running the tests shouldn't change.

The toolkit is available here:  http://seleniumtoolkit.codeplex.com

Wednesday, September 16, 2009

Testing NUnit Addins from within NUnit

Injecting your code into someone else's container

Note: This post refers to an internal feature of the NUnit.Core library and cannot be guaranteed in future versions.

Yesterday I released my first open source project, Selenium Toolkit for .NET, if you’re into functional web-testing I highly recommend you check it out.  I’d like to share a piece of code from that project – it’s either the biggest hack I’ve ever done or pretty clever.  Let me know what you think.

I don't like manually doing things more than once if I have to. Ironically, while building a tool to help automate functional web testing, I found that I had to do a lot of manual verification despite all the unit tests that I had written for my components. It started to get pretty frustrating: make a small change to my addin, uninstall and reinstall it, then open and run my sample test-fixtures to see how the NUnit framework had interpreted my changes. If I was going anywhere with this project, this was going to slow me down.

Fortunately, while spelunking through the NUnit.Core library, I found a really useful utility class that the fit the bill nicely and worked out pretty well. The TestAssemblyBuilder uses the nunit internals to find all the tests in an assembly and put them into a single Suite for inspection, execution, etc.

namespace Example
{
    using NUnit.Core.Builders;   

    public class ExampleTest
    {
        [Test]
        public void CanGetTestCount()
        {
            TestAssemblyBuilder assemblyBuilder = new TestAssemblyBuilder();
            TestSuite suite = assemblyBuilder.Build("AssemblyName.dll", false);

            Assert.AreEqual(4, suite.TestCount, "Not all tests were found.");
        }
    }
}

What’s really interesting here is the TestAssemblyBuilder uses a singleton within the NUnit internals, CoreExtensions.Host, to resolve all the core components for building up the suite.  This object implements the IExtensionHost interface which is also used to install our addin:

public interface NUnit.Core.Extensibility.IAddin
{
    bool Install(IExtensionHost host);
}

With this singleton at our disposal this is a pretty powerful option as I can now inject my addin into the framework with any configuration or mock that I want and test without environment dependencies.  In this example, I’m able to test how many times my Selenium instance would be started without ever launching a java host or browser:

namespace SeleniumToolkit.NUnit.Tests
{
    using NUnit.Core.Builders;
    using Selenium;
    using SeleniumToolkit;
    
    [TestFixture]
    public class FixtureBuilderTests
    {
        [Test]
        public void When_Fixture_Owns_Session_SeleniumFactory_Should_Only_Create_Sessions_For_Fixtures()
        {
            // create config that influences how the addin will work inside NUnit
            SeleniumConfiguration config = new SeleniumConfiguration();
            config.AddinSettings.RecyclePerFixture = true;
            
            // create basic event listener and suite-builder for installation into addin
            var eventListener = new SeleniumEventListener(null); // null = no java host
            var suiteBuilder = new SeleniumTestFixtureBuilder(config);

            // mock out the factory that creates our selenium objects
            var factory = MockRepository.GenerateMock<ISeleniumFactoryProvider>();
            var selenium = MockRepository.GenerateMock<ISelenium>();

            // tell our mock'd factory to always return our mock selenium
            factory.Expect(f => f.Create(null,0,null,null)).IgnoreArguments()
                   .Return(selenium).Repeat.Any();

            // set our expectations for how many times selenium will start/stop
            selenium.Expect(s => s.Start()).Repeat.Times(3);
            selenium.Expect(s => s.Stop()).Repeat.Times(3);

            // inject our mock into the toolkit
            SeleniumFactory.Configure(config, factory);

            // install addin
            SeleniumNUnitAddin addin = new SeleniumNUnitAddin();
            addin.Install(CoreExtensions.Host, suiteBuilder, eventListener); // injection method

            // using installed addin, test construction of fixtures
            var assemblyBuilder = new TestAssemblyBuilder();
            TestSuite suite = assemblyBuilder.Build( 
                                               "NUnit.TestAssembly.FixtureScenario.dll", 
                                               false);                        

            // run our sample fixtures against our configured runtime
            suite.Run(eventListener);

            // verify our behavior is as expected
            selenium.VerifyAllExpectations();
        }
    }

}

I should point out here that I don’t have my addin installed in NUnit’s addin folder. In fact, because I’m manually injecting it into NUnit, installation isn’t necessary. I also discovered that having the addin installed introduced some unexpected behavior with the tests in a few places.

To ensure that I'm testing my addin in isolation, it's important to clean up the CoreExtensions singleton after each test. While the NUnit core provides a mechanism to remove items from its extension points, it requires that you pass in the instances you want to remove, which didn’t quite fit my needs.  I suppose I could have implemented equality comparisons in my extensions, but I opted for the hack ‘em out using reflection option. It’s gross, but it works:

public class AddinUtil
{
    public static void Uninstall()
    {
        IExtensionPoint eventListeners = CoreExtensions.Host.GetExtensionPoint("EventListeners");
        IExtensionPoint suiteBuilders = CoreExtensions.Host.GetExtensionPoint("SuiteBuilders");
        IExtensionPoint testBuilders = CoreExtensions.Host.GetExtensionPoint("TestCaseBuilders");

        RemoveExtension(typeof(SeleniumEventListener), eventListeners);
        RemoveExtension(typeof(SeleniumTestFixtureBuilder), suiteBuilders);
        RemoveExtension(typeof(SeleniumTestCaseBuilder), testBuilders);
    }

    private static void RemoveExtension(Type type, IExtensionPoint extensionPoint)
    {
        ArrayList items = GetInternalExtensions(extensionPoint);
        ArrayList toRemove = new ArrayList();

        foreach (object item in items)
        {
            if (type.IsAssignableFrom(item.GetType()))
            {
                    toRemove.Add(item);
            }
        }

        foreach (object item in toRemove)
        {
            items.Remove(item);
        }
    }

    private static ArrayList GetInternalExtensions(IExtensionPoint extensionPoint)
    {
        object extensions = extensionPoint.GetType()
					  .GetField("extensions", 
							BindingFlags.NonPublic | 
							BindingFlags.Public | 
							BindingFlags.Instance)
					  .GetValue(extensionPoint);
        return (ArrayList)extensions;
    }
}

Conclusion

This technique provides a brief glimpse of how to use automate testing nunit addins inside nunit using dependency injection.  I’m fairly certain that I will still have to manually verify the addin’s behaviour from time to time, but with this approach I hopefully won’t have to do it that often.

submit to reddit

Announcing Selenium Toolkit for .NET

I’m pleased to announce that I’ve released my first open source project!

The Selenium Toolkit for .NET contains a bundled installer for Selenium libraries (Selenium-RC, Selenium IDE and Selenium client library for .NET) and an NUnit Addin that makes getting started with Selenium easy.

More information can be found here:  http://seleniumtoolkit.codeplex.com/

Thursday, July 23, 2009

Using RuntimeTypeHandles to improve Memory of .NET Apps

It's been a few months since I wrote my article Creating a better wrapper using AOP, and I haven't thought much of it, but a recent comment left by Krzysztof has motivated me to re-open the project.  Krzysztof has an interesting optimization that I want to try, and perhaps I will delve into that in another post, but today I want to expand on my intentions of improving both performance and memory management as mentioned in the caveats of my article.  In truth, most of this article is inspired by the work of Jeffrey Richter's C# via CLR and Vance Morrison's blog, and I've been itching to test out the concept of using runtime type handles for a while.

Some Background

Most developers are led to believe that Reflection is a performance hit, but few understand why.  Here's my attempt to explain it in a nutshell.  I’m neither a Microsoft employee nor expert in this matter, I’m simply paraphrasing and I encourage you to pick up Jeff’s book.  If I’m paraphrasing incorrectly, please let me know.

When your code is executed for the first time, the CLR finds all references to Types in the MSIL in order to JIT compile them.  As part of this process, Assemblies are loaded and Type information is read from the meta-data and put into the AppDomain’s heap using internal structures – mainly pointers and method tables.  The first time a Type’s method is called, it is JIT compiled into native instructions and a pointer refers to these compiled bits.  Nice, light and fast.

Reflection however is different.  By calling the Type’s built-in GetType method, we are forcing the runtime to read the meta-data and potentially construct dozens of managed objects (MethodInfo, FieldInfo, PropertyInfo, etc) and collectively these can be somewhat large data structures.  Often as most reflection methods use strings to identify methods, we’re performing a case-insensitive scan of the meta-data.  When we call those methods our parameters have to be pushed onto the stack as an array of objects.  When compared to compiled native code with pointers, you can see why this is slower.  (Roughly 200x slower)

Clearly, the .NET runtime doesn’t need these large data-structures to execute our code.  Instead we can leverage the same pointers that the CLR uses through their managed equivalents: RuntimeTypeHandle, RuntimeMethodHandle and RuntimeFieldHandle.  At their most basic level, they are the pointers (IntPtr objects) to our Types, without all the additional reflection performance overhead.  Since an IntPtr is basically just a numerical value (a ValueType nonetheless), they use considerably less memory.

An interesting point: an example from Vance’s blog demonstrates that typeof(Foo) is considerably slower than typeof(Foo).TypeHandle because the JIT recognizes you need the pointer and not the Type.

Even more surprising, anObj.GetType() == typeof(string) is faster than (anObj is string) for the exact same JIT optimization.  Amazing.

Using Handles

If your application holds onto Type data for extended periods, it may be worth your while to use handles.  Here’s a few examples of using them.

Get the handle for a Type
[Test]
public void CanGetHandleFromType()
{
    RuntimeTypeHandle handle = typeof(string).TypeHandle;
    Type type = Type.GetTypeFromHandle(handle);

    Assert.AreEqual("A String".GetType(), type);
}
Get the handle for a Method
[Test]
public void CanGetHandleFromMethod()
{
    MethodInfo m1 = typeof(Foo).GetMethod("Do");
    RuntimeMethodHandle handle = m1.MethodHandle;

    MethodInfo m2 = MethodBase.GetMethodFromHandle(handle) as MethodInfo;

    Assert.IsNotNull(m2);
    Assert.AreEqual(m1, m2);
}

Applying Handles

Getting back to my AOP example, I can now create a really simple mapping table for my AOP wrapper that’s lean(er) on memory and will cut down on needless calls to the Reflection API, thus speeding things up considerably.  Note that I’m doing all the Reflection work upfront and then storing only pointers.

Update: After some initial profiling, I wasn’t surprised to discover that loading the MethodInfo by the handle is as expensive as the original GetMethod call.  As such, I’ve opted to store my mapping table as Dictionary<RuntimeMethodInfo,MethodInfo> instead of Dictionary<RuntimeMethodInfo,RuntimeMethodInfo>

public class InvocationMapping
{
    public InvocationMapping(object instance)
    {
        _table = new Dictionary<RuntimeMethodHandle, MethodInfo>();
        _instance = instance;
    }

    public static InvocationMapping CreateMapping<TWrapper>(object target)
    {
        InvocationMapping mapping = new InvocationMapping(target);

        Type wrapperType = typeof(TWrapper);
        var wrapperProperties = wrapperType.GetProperties();

        Type targetType = target.GetType();
        foreach (var property in wrapperProperties)
        {
            MappedFieldAttribute attribute =
                                    property.GetCustomAttributes(typeof(MappedFieldAttribute),true)
                                    .OfType<MappedFieldAttribute>()
                                    .SingleOrDefault(mf => mf.TargetType == targetType);

            if (attribute != null)
            {
                PropertyInfo targetProperty = targetType.GetProperty(attribute.FieldName);

                mapping.Add(property, targetProperty);
            }
        }

        return mapping;
    }

    public Dictionary<RuntimeMethodHandle, MethodInfo> MappingTable
    {
        get { return _table; }
    }

    public void Add(PropertyInfo property, PropertyInfo targetProperty)
    {
        if (property.CanRead && targetProperty.CanRead)
        {
            _table.Add(property.GetGetMethod().MethodHandle, targetProperty.GetGetMethod());
        }
        if (property.CanWrite && targetProperty.CanWrite)
        {
            _table.Add(property.GetSetMethod().MethodHandle, targetProperty.GetSetMethod());
        }
    }

    public bool Supports(RuntimeMethodInfo handle)
    {
          return _table.ContainsKey(handle);
    }

    public object Invoke(RuntimeMethodInfo handle, params object[] args)
    {
         MethodInfo method = _table[handle];
         return method.Invoke(_instance, args);
    }

    private Dictionary<RuntimeMethodHandle, MethodInfo> _table;
    private object _instance;
}

My next post will look at combining this approach with a IProxyBuilderHook and/or ISelectorType.

submit to reddit

Tuesday, July 14, 2009

64-bit Apps / 32-bit Assemblies

Our team was working late the other night and got tripped up on how "Any CPU" works with 64-bit operating systems. I had developed a simple command-line utility that used some third-party assemblies that were installed in the GAC. Everything worked great on my local machine until I deployed it into the build environment, where the app simply blew up and reported an awkward "FileNotFoundException".

At a quick glance, it seemed obvious: the 3rd party assemblies weren't in the GAC. My head snapped back a bit when C:\Windows\Assembly showed that the exact versions I needed were in fact installed. I double checked my project references and painfully grudged through security policies, FusionLog files and web.config settings and with each attempt I became increasingly aggravated and annoyed. When I copied the 3rd party assemblies out of the GAC and into my utility's folder and got a BadFormatException, I realized that the only difference between my machine and the build environment was the 64bit operating system.

On a hunch, I recompiled my utility to target "x86" and suddenly everything worked. The team was baffled -- why didn't "Any CPU" work?

What does “Any CPU” mean?

The .NET Framework inspects the meta data of your dll or exe to determine how to load it. By default, "Any CPU" creates a native process to that OS. In other words, 32 bit process for 32bit OS and 64 bit process for 64bit OS. When a 32bit application (x86) runs on a 64bit OS, it runs as a WoW64 emulated 32bit process (Windows on Windows).

The following table outlines how the Visual Studio Build Configuration is interpreted between 32bit and 64bit OS.

Any CPU x86 x64
32 bit OS Native (32 bit) 32 bit process N/A
64 bit OS Native (64 bit) WoW64 process (emulated 32 bit) 64 bit process

The real gotcha is that your referenced assemblies must match the process space of the application they're being loaded into. Any assembly that is compiled as "Any CPU" is considered "neutral" and can be loaded into either a 32bit or 64bit process.

How do I determine what platform my assembly requires?

There are a few ways to determine if your assembly is Any CPU, 32bit or 64bit:

Global Assembly Cache

If your assembly is in the GAC, you can find this information in the Processor Architecture column.

assembly_32bit

Corflags

The corflags.exe tool that ships with the .NET SDK is a very powerful and dangerous tool. Just supplying the name of your exe or assembly to corflags shows some vital PE meta information. More great information can be found here: http://blogs.msdn.com/joshwil/archive/2005/05/06/415191.aspx

corflags

Incidentally, instead of recompiling the application with the “x86” target, I could simply have hacked the header using corflags:

corflags myapp.exe /32bit+

However, hacking the header of the assembly using corflags will invalidate the digital signature. Although you can always re-sign the assembly using the strong-name (sn) utility, it’s easier to just recompile and deploy.

Cheers.

submit to reddit

Monday, June 29, 2009

Using Linq with inline ASP.NET

The other day while working on a SharePoint project, we needed a simple utility to show us the current build and version numbers of deployed assemblies.  Rather than going through the hassle of creating a custom web-part or compiled assembly, I decide to opt for a simple ASPX page with inline code.

The approach worked well.  I had IntelliSense and I wasn’t limited to any language features until I added a few simple Linq statements.  I then ran into this fun error:

error CS0234: The type or namespace name 'Linq' does not exist in the namespace 'System' (are you missing an assembly reference?)   
    at System.Web.Compilation.AssemblyBuilder.Compile()

Despite the fact that .NET 3.5 was installed and other compiled assemblies worked fine on this machine, the ASP.NET process was having problems compiling the Linq features on its own.  It just needed some additional guidance on where to locate those assemblies…

First, the compiler needs a hint on how to resolve the Linq assembly, located in System.Core:

  <compilation batch="false" debug="true">
    <assemblies>

      <!-- add –>
      <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" /> 
    </assemblies>
  </compilation>

Then, the module that compiles our code needs a hint to build using 3.5:

  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4"
                type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
        <providerOption name="CompilerVersion" value="v3.5" />
        <providerOption name="WarnAsError" value="false" />
      </compiler>
    </compilers>
  </system.codedom>

submit to reddit

Monday, June 22, 2009

C# Multithreading: Blocking Similar Requests

It's an abuse of Moore's Law: as computers get faster, software will get slower.  And while there are many reasons why software feeds on additional resources, whether it's providing a more intuitive user interface, coding for security or simple feature bloat – it’s largely the fault of software developer's assumption that disk, memory and CPU will continue to increase in capacity and power while the cost decreases.

With the advent of multi-core processors, it's evident that software cannot afford to assume that execution will occur on a single thread.  We need to embrace multi-threaded techniques to allow our software to scale with the platform.  Developing for multi-threaded applications requires special consideration.

I want to share a simple code snippet that I've frequently used to block individual threads from executing the same code twice.  It's especially handy in dealing with process intensive or time-sensitive requests where race-conditions can occur. For example, a recent project needed to dynamically generate an image and cache as a file – if requests were allowed to overwrite the file as it was being served by another thread, the results would be disastrous.

The concept uses the "double-checked locking" pattern, which is commonly used for synchronized lazy-initialization, such as creating singletons.  Unlike the singleton pattern, this example assumes there are multiple requests for different objects, so the technique is modified slightly.

A “Double-Checked Lock” Singleton

For those that aren't familiar with the "double-checked locking" pattern, I'll outline here using a Singleton example.  In short, double-checked locking is "Check twice before doing any work, with a lock in the middle."

Note: Some may claim that the thread-safety of the double-checked lock pattern simply cannot be guaranteed.  This is true for environments where the processor or application runtime model can vary (Java, C++, etc).  However the CLR does guarantee thread synchronization.

This example outlines the double-checked lock being used to guarantee that only one singleton is created:

public class MySingleton
{
    private static volatile MySingleton _instance;
    private static readonly _lock = new object();
public static MySingleton Instance { get { // 1: first check if (_instance == null) { // 2: lock a common object // all other threads must wait until the lock is released lock(_lock) { // 3: second check if (_instance == null) { // 4: thread-sensitive work _instance = new MySingleton(); } } // 5: release the lock } return _instance; } } // other methods }

If you've never seen this type of pattern before, it may at first seem awkward (“why are you checking for null so much?”).  Here's a quick run down of how this plays out in a multi-threaded environment:

  1. Thread #1 enters the MySingleton Instance_get method
  2. Thread #2 enters the MySingleton Instance_get method at the exact same time as Thread #1.
  3. Thread #1 determines that the instance is null and proceeds to the next statement which puts a lock on a common object that is available to all threads.  This lock will block all other requests until the lock is removed.
  4. Thread #2 attempts to access the _lock object but cannot because it is currently locked. Execution pauses at this statement.
  5. Thread #1 which is now in a sensitive code region that can only be executed by a single thread, determines that the instance is still null and proceeds to the next statement which performs the thread-sensitive work of creating the singleton.
  6. Thread #1 releases the lock.
  7. Thread #2 is no longer blocked and can access the lock.  It puts a lock on the _lock object to ensure that no other object can access this region.
  8. Thread #2 determines that the thread is not null.  No additional work is performed and it releases the lock.
  9. Thread #1 returns the instance.
  10. Thread #2 returns the instance that thread #1 created.

Using Synchronized-Keys for Similar Requests

As mentioned previously, the pattern above ensures that only a single instance of our object is created.  However, this technique doesn't work well for methods that vary their response based on input because we're locking a single object to create sensitive regions.  By locking only a single object, we create a nasty side-effect that synchronizes all requests to a single thread.

To solve this problem, we need to put our lock on a different object so that we are only blocking similar requests.  We need a key that is synchronized for requests with the same input.

This is where the “SyncKey” comes in:

public sealed class SyncKey : IDisposable 
{ 
    private static Dictionary<string,SyncKey> _inner = new Dictionary<string,SyncKey>(); 

    public static SyncKey Get(string key) 
    { 
        // lock the table to ensure that only one thread can access 
        //    the dictionary at a time 
        lock(_inner) 
        { 
            // if this is the first request for this key, it will not be present 
            //    in the dictionary.  create and store it. 
            if (!_inner.ContainsKey(key)) 
            { 
                SyncKey item = new SyncKey(key); 
                _inner.Add(key, item); 
            } 
            // return the synchronized key 
            return _inner[key]; 
        } 
    }
 
    private static void Remove(SyncKey item) 
    { 
        // lock the table to ensure that only one thread can access 
        //    the dictionary at a time 
        lock(_inner) 
        { 
            // for the request that first instantiated the key, 
            //    the sensitive work is complete and the key can be safely 
            //    removed from the dictionary 
            // for subsequent requests, although the key was used to prevent 
            //    a duplicate request, it no longer exists in the table 
            //    and can be safely ignored. 
            if (_inner.ContainsKey(item.Key)) 
            { 
                _inner.Remove(item.Key); 
            } 
        } 
    } 

    private string _key; 

    SyncKey(string key) 
    { 
        _key = key; 
    } 

    public string Key 
    { 
        get { return _key; } 
    }

    public void Dispose() 
    { 
        Remove(this); 
    } 
}

An example using this strategy:

public class MyObject 
{ 
    public string SensitiveMethod(string inputParameter) 
    { 
        string key = GetKey(inputParameter); 
        // 1: first check 
        string result = GetItemFromCache(key); 
        if (result == null) 
        { 
            // create a sync key for this request 
            using(SyncKey sync = SyncKey.Get(key)) 
            { 
                // 2: lock request-specific object 
                lock(sync.Key) 
                { 
                    // 3: second check 
                    result = GetItemFromCache(key); 
                    if (result == null) 
                    { 
                        // 4: thread sensitive work 
                        result = BuildResult(key); 
                        CacheResult(key,result); 
                    } 
                } // 5: release lock 
            } // dispose sync key 
        } 

        return result; 
    } 
} 

Results

I built a small contrived example that pushes 1000 threads through a fixed set of input using the following three strategies:

  • No locking – all requests are executed without blocking.
  • Lock – Locking on a shared lock object.
  • Sync Lock – Locking occurs on a request specific key.

sync-lock-chart

Some notes on the findings:

  • No locking —The example doesn’t reflect CPU and resource-starvation that would occur by flooding the system with multiple requests.  If it did, it’s likely that the execution time would be several magnitudes longer.
  • Lock – duplicate requests are avoided, but the total execution time is longer since the requests are pinned to a single thread when the shared object is locked.
  • Sync Lock – duplicate requests are avoided, but execution time is shorter because only similar requests are blocked, allowing other requests to be processed.

submit to reddit

Monday, June 08, 2009

CSS for C# Developers: You should learn CSS

When I read Rob Conery's post about I suppose I'll just say it: You should learn ASP.NET MVC, it resonated strongly with me: the bloated abstraction of WebForms has placated developers into thinking they don't need to know HTML to build web applications.  We've spent the better half of this decade blissfully ignorant using server-side technology to "shoehorn" client-side concepts, and we (the asp.net developer) have been negligent on staying on top of the revolution that has been quietly happening client-side.

Thankfully, Microsoft's recent formal inclusion of jQuery for the ASP.NET MVC project has got developers discovering how powerful jQuery and client-side development can be, and that excitement is changing the way developers think about developing for the web.  I believe there's a new renaissance coming, one that isn't based on the bloated server-centric model of WebForms, but rather a new breed of sites with lean, semantic markup and rich client-side interactivity using JavaScript fuelled AJAX. Or at least, one can hope.

With all the attention client-side scripting is getting, there's never been a better time to learn CSS.  (If you're going to develop for the web, why not go all in?)  Until recently, I never did much user-interface development, but after a few short UI-centric projects I'm personally climbing onto the soapbox to challenge backend developers to drop their "I don't do pretty" attitude and learn this important skill.

So if you’ve secretly wanted to learn CSS but didn’t have a good reference point, this is my attempt at providing a crash course:

The basics

If you’re generally familiar with the basic concepts behind CSS, you can skip ahead, but no harm will come to you read it.

CSS Selectors

As developers, we love to think of the browser’s Document Object Model (DOM) as an object graph with pretty collections of childNodes and attributes that we can programmatically manipulate using imperative code instructions.  While this concept translates really well into technologies like XPath, it doesn’t fit CSS selectors so literally.  The syntax (is exactly the same syntax jQuery uses) is actually very straight-forward, and focuses primarily on all nodes of a specific criteria rather than targeting specific child nodes.

Type Selectors

Styles can be applied to all elements of a particular Type (or TagName):

/* single type (all h1 tags) */
h1 {
   color: blue;
}

/* multiple types (all h1, h2, and h3 tags) */
h1, h2, h3 {
   color: blue;
}
Id Selectors

The hash/pound/number symbol (#) is used as a selector to elements with a specific “id” attribute.  Note: This approach should only be applied to controls without the “runat=server” attribute since ASP.NET server-controls dynamically generate their IDs.

<style>
#title {
   color: blue;
}
</style>
<h1 id="title">Foo Heading</h1>
Class Selectors

Obviously, the more appropriate technique would be to assign the element a “class”, which in ASP.NET translates to our CssClass for most WebControls (otherwise you have to access this value through the Attribute collection under the appropriately named “class” key).  Note that the “class” is not tied to a specific type, and can be reused on other elements:

<style>
.title {
    color: blue;
}
</style>
<h1 class="title">Blue Heading</h1>
<p class="title">Blue paragraph</p>
Combine selectors to be specific

You can also get specific and limit the scope of a selector to a particular tag, by prefacing the selector with the tag name.  Note there is no space between the tag and class:

<style>
h1.title {
   color: blue;
}
p#description {
   color: green;
}
</style>
<h1 class="title">Blue Heading</h1>
<p id="description">Green Paragraph</p>
Child Selectors

You can also refer to child elements, which affords us the ability to provide additional formatting without having to modify our markup.

<style>
// all li elements under a ul with a "menu" class
ul.menu li {
   list-style-type: none;
   display: inline;
}
</style>
<ul class="menu">
   <li>inline 1</li>
   <li>inline 2</li>
   <li>inline 3</li>
</ul>
Applying multiple class selectors

Another important (and not well known) thing to point out is that you can have multiple class names for a single element, which can reduce duplication:

<style>
a.navLink {
   text-decoration: underline;
   color: red;
}
.selected {
   font-weight: bold;
}
</style>
<ul>
   <li><a class="navLink" href="#">one</a></li>
   <li><a class="navLink selected" href="#">two</a></li>
   <li><a class="navLink href="#">three</a></li>
</ul>

There are a few more selectors I haven’t covered here, but you can more details and tutorials here:

Inheritance in CSS

From a pure developer perspective, inheritance in CSS is similar to inheriting classes:

  • all tags derive from a common ancestor
  • each Type (tag) has their own set of default properties.  (Each browser has a default style sheet that is loaded automatically)
  • each node inherits properties defined from its parent

However, CSS inheritance deviates from this analogy as properties are merged in combination from multiple sources (wildcard, class, id and type selectors), somewhat like multiple inheritance:

  • a node’s properties are overridden as selectors are matched, from least specific to exact matches.
  • style sheet documents are processed from top to bottom, and in order of appearance in the source HTML

While this sounds complicated and difficult to troubleshoot, tools like FireBug and Internet Explorer Developer Toolbar have made this a trivial task.  My deepest respect goes to the user-interface developers who painfully slugged this stuff out manually only a few years ago.

A simple inheritance example:

<style>
body {
   background: #fefef2; /* eggshell */
}
h1 {
   text-decoration: underline;
   background: #ffffff; /* white */
}
.title {
   color: #0000ff; /* blue */
}
</style>

<!-- titleeffective style applied after inheritance:
{
   text-decoration: underline; /* from h1 */
   background: #ffffff; /* from h1 */
   color: #0000ff; /* from .title */
}
-->
<h1 class="title">Underlined blue title with white background</h1>

Note that the only way to prevent inheriting settings from a parent node is to explicitly supply a value for the property.

<style>
body {
   background: #fefef2;
}
h1 {
  text-decoration: underline;
  background: #ffffff;
}
.title {
  text-decoration: none;
  background: #fef2f2;
  color: #0000ff;
}
</style>
<!-- effective style applied after inheritance:
{
   text-decoration: none; /* back to the default */
   background: #fef2f2; /* back to the default */
   color: #0000ff; /* new value */
}
-->
<h1 class="title">Blue title with eggshell color</h1>

DocType matters

Much like setting the content-type of a Response in ASP.NET so that the browser will understand what the content is, the DocType is a crude processing instruction at the top of the document that instructs the browser how they should process the markup.  Without this instruction, most browsers will assume the content is ancient and they will use the oldest rendering engine available.

As to which doctype you should use, it largely depends on the markup you have, but you should strive for the most compliant possible.

A List Apart has one of the best references on this topic.

The Box Model

The Box Model is another core concept of CSS.  All elements are contained in their own box and have margins, borders and padding.

Commit to memory: Margin, Border, Padding, Content.

  • The margin is the amount of space reserved as buffer between elements.  The margin is always transparent.
  • The border appears between the margin and the padding.  It has many different styling options.
  • Padding separates your border from your content.  It takes up visual space and is the color specified by the background – if you want your element to be larger or have more color, padding is what you want.

Commit to memory: Top, Right, Bottom, Left

When specifying values for padding, margins or border widths CSS provides two approaches.  Either declare each value separately (border-top: 0px; border-right: 0px; border-bottom: 0px; border-left: 0px) or inline as one statement in clockwise order starting at top (border: 0px 0px 0px 0px;).  This comes up frequently, so memorize now and thank me later.

Also note that there’s a shortcut for the shorthand, where top & bottom and left & right are the same values (border: 0px 0px;).

Fonts

Fonts can be tricky, and I tend to lean on the graphic designer to pick the typography for the site.  From a development perspective, although you can choose any font it must be available on the user’s machine, and only a few fonts are truly available across operating systems.  A great reference of browser surveys can be found here: http://www.codestyle.org/css/font-family/index.shtml

From a CSS perspective, you can supply a number of different fonts in comma-delimited format, and the browser will apply the first match from left to right.  Outside of actual Fonts, there are five generic fonts which all browsers implement.

Keep in mind that there is much debate on whether you should specify fonts in “em”, “pt”, “px” or “%” for font-sizes.  I won’t settle that debate here.

Digging Deeper

Congrats on reading thus far, if you skipped ahead, no cookie for you.

Pseudo Selectors

While pseudo selectors are bordering on advanced topics, a crash course in CSS would be incomplete without mention of some pretty important CSS selectors:  a:link, a:visited, a:active, a:hover.  These are special selectors that can be applied to anchor tags for their various states.  The first two (“:link” and “:visited”) allow you to specify the style of the anchor tag based on the user’s history; the latter refer to user actions with the hyperlinks.  The “:active” selector is applied the user is clicking on the hyperlink; the “:hover” selector is applied when the user moves the mouse over the anchor.

Astute developers pick up that “:hover” allows you to define styles that would normally be applied using “onmouseover” and “onmouseout” events using JavaScript.  One of my favorite applications of the “:hover” tag is to change the background image of an element when the user hovers over it.  With some extra effort, you can change the relative position of the background image to achieve a “sprite” effect.

Some trivia: there is no equivalent of these selectors as an inline style attribute, they can only be defined in a style block or style sheet.  Also, the “:hover” tag can be applied to other tags, but only anchor tags are supported in IE 6.

Background Images on Elements

CSS provides the ability to set the background property of an element to point to an image, which is major shift from standard HTML.  By moving our images from the markup into the CSS, we not only reduce the amount of markup required, but we separate presentation from content.  This technique is essential for creating impressive effects, such as drop shadows and nifty borders.

The syntax:

/*
element {
   background: color url(path) repeat attachment position
} */

div {
   background: transparent url(../images/bg.png) repeat-y fixed 0 0
}

By specifying the repeat value of an image, your image only needs to be a few pixels in size.  In addition, you can specify an offset in pixels to have the image indented.

Few key takeaways:

  • The path of the image is resolved from the location of the css file, not the requested page.
  • Remember to set “no-repeat” if you only want the image to appear once.
  • When adding background image to an element, the image size is not taken into consideration.  If you want more of the image to be displayed, adjust the padding of the element to suit.

Not everything is a div, dummy

The div tag is one of the most popular tags in XHTML/CSS as it's used to create logical sections for your layout.  While divs are preferred over tables, using divs exclusively to represent content isn't necessarily a good thing.  If you've fallen into this trap or have trouble knowing when you should use a div versus a span, I'm going to break you out of a bad habit by demystifying what the div tag is by looking at the how it's described by most browser's default style sheet:

div { 
    display: block; 
} 

That's it!  So maybe it would help us to understand what "display" does?

There are a bunch of settings for "display", but the short list is: "none", "block", and "inline".  Setting display to "none" basically means that the content won't take up any layout space and is thus invisible.  Elements with display set to "block" are considered a chunk of content that has a line break before and after, whereas "inline" means it's part of the content.  It's best described by looking at the default's for some tags:

Tag Display Default
body block
h1,h2,h3,h4 block
p block
div block
ul, li block
bold, strong inline
italic, em inline
a inline
span inline

A great breakdown of “display” and how it’s used, including support for all modern browsers, is available here.

If what you really need is a container for some content, P and UL are great substitutes.  You’ll be surprised at how quickly your content begins to look less like div-soup and more like xml.

<!-- before -->
<div id="contacts">
  <div class="person">
     <div class="details">
          <b>Person Name</b><br/>
          <i>555-1234</i>
     </div>
  </div>
</div>

<!-- after -->
<ul id="contacts">
   <li class="person">
        <h3>Person Name</h3>
        <ul class="details">
             <li class="phone">555-1234</li>
        </ul>
   </li>
</ul>

Start with a clean slate

Working with CSS can get tricky, especially managing the complexity of your style sheets to support multiple browsers.  One of the best approaches to minimize this complexity is to override the default settings for all elements to a minimalist state, and then slowly build up your styles to suit your needs.  This approach reduces duplication and helps ensure that your settings aren't inconsistent between browsers.

Here's a quick example that removes the padding and margin for all elements, and turns off the legacy blue-border around the image tag:

// remove all margins and padding from all elements
* { 
margin: 0; 
padding: 0; 
} 

// remove legacy border around images
img { 
    border: none; 
} 

Here are a few great starting points for a clean slate:

Floating

Using "floating" to position elements can be tricky, and there are certainly a few tricks to make it work for all browsers (I'm looking at you Internet Explorer 6), but mastering it means you'll never need to use tables to layout your content again.  Or at least, only use tables when representing data.

At a very high level, when an element has a float applied to it, it is no longer part of the normal flow of the document.  An element with a “float:left;” will float to the left until it meets the left edge of it’s containing block; likewise a “float:right;” implies the element will nestle up to the right of it’s container.  Floating can be turned off by setting a “float:none;” to the next element.

The secret to getting floating to work is ensuring that the element being floated has a width explicitly defined.  Likewise, setting a width to the parent element that contains the floating element solves many problems.

Still, as developers, we know from experience that this is a major cross-browser problem and it’s likely the principle reason why we leave CSS to the experts.  Truth is, every browser except Internet Explorer got the Box Model right, and the fix is shockingly simple: floating problems in Internet Explorer 6 are generally solved by ensuring that the floated element (in IE’s terms) “has a layout specified”.  In most cases, specifying “display:inline;” works:

.container
{
      float: left;
      display: inline;
}

A great reference on float theory can be found here: http://www.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/

Static, Relative and Absolute Positioning

A close relative to floating is the concept of “absolute and relative positioning”.  Personally, I’ve always felt that absolute position was a last resort when compared to using floats, but in concept may be easier to understand.

Since “static” is the default behavior for content, the real work is understanding that “absolute” and “relative” provide meaning to the css properties “top”, “left”, “right” and “bottom”.

When an element uses “absolute” for it’s positioning, the “top” and “left” properties can be used to position the element anywhere in the document, where (0,0) represents the top, left-hand corner of the document.

When an element uses “relative” positioning, the “top” and “left” properties indicate where the element appears in relation to the element that came before it.

And here’s the magic: if an element inside a “relative” positioned element specifies an “absolute” position, the “top” and “left” properties can be used to position the element anywhere within the containing element where (0,0) represents the top, left-hand corner of the relatively positioned element.

A great tutorial on positioning can be found here:  http://www.barelyfitz.com/screencast/html-training/css/positioning/

Don't trust your eyes

While the Internet Explorer 8 Developer Toolbar is considerably better than previous versions, FireBug, the popular addin for FireFox, is still the king.  Aside from being able to hack the CSS values in real time, one of the most useful features that FireBug provides is that it can highlight the contents of an element as you move your mouse over them.  The highlighted area, which uses different colours to represent padding versus margins, shows how the browser has reserved space for the visual element.  I've discovered there are times where FireFox renders the content correctly, but the overlaid highlight for margins and padding doesn't exactly match the visual appearance.  From my own experience, I've discovered that these discrepancies are often more apparent in other browsers.  If you can get FireBug's visual overlay to match the desired visual, you're less likely to have issues in other browsers.

The following example shows how FireBug highlights a paragraph with a width greater than it’s parent.

<style>
div {
  float: left;
  width: 300px;
}
p {
  width: 350px; /* bigger than parent! */
}
</style>

FireBug-Highlight

Learn Paint.NET

Lastly, while not a CSS tip, it would be an injustice to think that you as the developer are not capable of cutting and resizing images.  Let the graphic designer be responsible for producing the content, but as a developer you need to learn be independent and cut up the image yourself if needed.

Paint.NET is awesome, and when compared to Photoshop or GIMP, it's as easy to use as ms paint.  There are lots of tutorials online that hold your hand from start to finish on creating some impressive graphics.

Conclusion

Thanks for reading.  If you’re a backend developer who’s never spent any time in the user-interface, I hope this has help shine a light for you, please send me some feedback.  If you’re a front-end developer and I’m completely off my rocker, feedback is also appreciated.

Cheers.

submit to reddit