I looked around on the Internet and didn’t find a simple, no frills unit test framework for PowerShell that leveraged Hamcrest matchers. So I wrote one! Being relatively new to PowerShell, I probably haven’t leveraged common PowerShell idioms. Hopefully, it’s easy enough to modify and tailor to your project. This is my first shot at it. Comments and suggestions are welcome!

Official PSHamcrest Page:
http://rayli.net/blog/pshamcrest

Codeplex Page:
http://pshamcrest.codeplex.com/

Latest release:
http://pshamcrest.codeplex.com/releases

Browse the latest source code:
http://pshamcrest.codeplex.com/SourceControl/BrowseLatest

After incorporating binary serialization into a C# application that loaded data from an Excel spreadsheet, I was able to get a 33% decrease in execution time by caching the generated object into a binary file. It’s a quick-and-dirty way to get a speed increase especially when you’re loading a lot of external data that changes, but doesn’t change frequently.

The first step for serializing a class into a binary file is to mark the class as Serializable.

[Serializable]
public class YourClass
{
	// your class definition.
}

Now that your class is ready to be serialized, you can use ObjectSerializer. The ObjectSerializer class below allows anyone to serialize an object into a binary file. Serializing or de-serializing a class marked with the [Serializable] attribute takes no more than 3 lines of C# code.

public class ObjectSerializer<T>
{
	protected IFormatter iformatter;

	public ObjectSerializer()
	{
		this.iformatter = new BinaryFormatter();
	}

	public T GetSerializedObject(string filename)
	{
		if (File.Exists(filename))
		{
			Stream inStream = new FileStream(
				filename,
				FileMode.Open,
				FileAccess.Read,
				FileShare.Read);
			T obj = (T)this.iformatter.Deserialize(inStream);
			inStream.Close();
			return obj;
		}
		return default(T);
	}

	public void SaveSerializedObject(T obj, string filename)
	{
		Stream outStream = new FileStream(
			filename,
			FileMode.Create,
			FileAccess.Write,
			FileShare.None);
		this.iformatter.Serialize(outStream, obj);
		outStream.Close();
	}
}

To serialize an object using ObjectSerializer, first instantiate the ObjectSerializer class. Then use the SaveSerialziedObject() method to serialize the object.

YourClass yourObject = new YourClass();
ObjectSerializer<YourClass> objSerializer =
	new ObjectSerializer<YourClass>();

// serializes yourClass to SomeFilename.bin.
objSerializer.SaveSerializedObject(yourObject, "SomeFilename.bin");

To deserialize the binary file generated from the previous operation, instantiate the ObjectSerializer class. Then use the GetSerializedObject() method to retrieve the original object.

ObjectSerializer<YourClass> objSerializer =
	new ObjectSerializer<YourClass>();

// deserializes yourClass from SomeFilename.bin.
YourClass yourObjectFromFile =
	objSerializer.GetSerializedObject("SomeFilename.bin");

And there you have it… quick-and-dirty binary serialization in C#!

What is a tracing JIT?

Although tracing JITs are a complex technology, the core concept is about optimizing execution of the hot paths in a program.  The emphasis is specifically on hot paths that return to the start of a path which sounds very much like a loop.  However, the traditional definition of a programming loop is only a subset of these hot paths.  The broader definition includes code that spans methods and possibly even modules.  This broader definition of a loop is what’s called a trace.

Why use traces?

By JIT compiling the traces, code that is executed frequently runs faster.  Code that isn’t included in traces isn’t compiled.  The claim is untraced code would not benefit as greatly from JIT compilation since it is not executed as frequently.  The basic trade-off is the time needed to JIT compile and cache the resulting code versus the time needed to execute the code.

When does tracing happen?

Tracing takes place as instructions are interpreted.  Whether it’s Java, Python or Javascript, the code must be interpreted by a virtual machine.  It is during this stage that loops are detected and identified as traces.

How is a tracing JIT different from other JITs?

Run-time profiling for optimization and specific CPU and memory optimizations are done with most JITs to adapt the application for best performance.  However, non-tracing JIT implementations (Sun’s Java VM and Microsoft’s CLR) do this at the method level.  When code is determined to be “hot,” the entire method containing that code is JIT compiled and cached.  Tracing JITs do this at the trace level and may consist of a portion of a method (just a specific loop), multiple methods and even multiple methods from different modules.

Who is using tracing JITs?

The Mozilla Team uses a tracing JIT in the JavaScript engine for Firefox.  It’s codenamed TraceMonkey and is enabled by default in Firefox since version 3.5.  Adobe Labs has a tracing JIT called Tamarin.  It’s basically a JavaScript engine as well.  Technically, it’s an implementation of ActionScript which is based on ECMAScript which JavaScript is based on.  Tamarin and TraceMonkey are so closely related that they both use the same backend: NanoJit.

A Python interpreter called PyPy recently switched from being based on partial evaluation to a tracing JIT.  Microsoft is researching and prototyping a tracing JIT compiler (TJIT) for the common intermediate language (CIL) called SPUR.

Where can I find out more?

This post only scratches the surface.  There’s plenty more about tracing JITs!

• Andreas Gal’s blog
• Lambda the Ultimate thread on tracing JITs (highly recommended)
• Hacker News thread on tracing JITs
• Tracing JIT Notes
• Wikipedia entry on trace trees

How can Python interpret Python source code faster than an interpreter written in C?

The short answer is it can’t.  The long answer is that PyPy is actually two pieces of software:

1. an interpreter
2. a translator

The interpreter understands the full Python language.  The interpreter is written in RPython (Restricted Python).  RPython is statically typed which makes it easier to compile into more efficient code.  This characteristic is very important for the next step.

The translator takes RPython code as its input and translates it to a lower language like C.  Although the interpreter was originally written in Python (specifically RPython), the translator translates it to C which can be compiled into a much faster interpreter that could rival or even surpass CPython.

What’s the point of doing this in RPython?  Why not just code it in C like CPython?

The difference boils down to the perceived difference between hacking away at an interpreter written in RPython (PyPy) versus an interpreter written in C (CPython).  The claim is that an interpreter coded in RPython allows for faster experimentation.

Can a Python interpreter based on RPython code translated into C rival or exceed the performance of CPython?

At this moment (April 7, 2010), the answer is no.  Default CPython bests its PyPy-C equivalent on just about every benchmark.  On some benchmarks, the measurements are close.  On others, CPython is clearly the winner by far.

This is false advertising!  If CPython does better on most benchmarks, how can PyPy claim to be faster?

The answer is JIT!  The developers of PyPy created a JIT compiler for Python by adding a few hints to their RPython interpreter.  The PyPy JIT compiler just-in-time compiles RPython code to native code which is why it’s able to get such fantastic speed gains when compared to CPython.  PyPy-C-JIT crushes CPython on the majority of the speed tests at the PyPy Speed Center.

That doesn’t seem fair…  Of course native code will be faster than interpreted code.  What if CPython is coupled with JITting?

Turns out PyPy still comes out ahead.  CPython can be coupled with Psyco, a Python extension module that can JIT compile Python code.  The Psyco JIT approach differs from the PyPy approach, because the former focuses on partial evaluation and the latter on tracing.  I don’t know the difference yet (maybe another blog post?), but what we do know is this tracing JIT approach outperforms the Psyco approach.

So there it is…  PyPy in a nutshell.

UPDATE: It seems I’m not the only one interested in PyPy’s claims.  I came across a related thread on Stackoverflow: PyPy — How can it possibly beat CPython?

DISCLAIMER: I have not used PyPy — just very curious about the problems it solves.

Python in the Browser, Jimmy Schementi
Using Python in the web browser leverages Microsoft’s Python implementation.  The goal is to use Silverlight/Moonlight with IronPython as a client-side browser language.

State of PyPy, Maciej Fijalkowski
PyPy is an implementation of Python written in Python.  But why?  (UPDATE:  What is the purpose of PyPy?)

Python 3: Next Generation, Wesley Chun
This talk went through a laundry list of new features and bug fixes in Python 3.

Unladen Swallow: fewer coconuts, faster Python, Collin Winter
Unladen Swallow is Google’s Python implementation branch of CPython.  It claims significant speed improvements.  Currently, the interpreter is a virtual machine with a JIT built using LLVM.

Understanding the Python GIL, David Beazly
Discussed key issues with the global intepreter lock (GIL).  It seems improvements in Python 3 solve some problems associated with the GIL, but create new ones.  Beazly goes over how difficult the problem is, and how he feels it can be solved.

Easy command-line applications with cmd and cmd2, Catherine Devlin (a.k.a. PyOraGeek)
The talk title was a bit deceiving.  She prefaced the talk with a disclaimer, because the topic was actually command-line interpreters.  This is more along the lines of applications like the bash shell or Python’s REPL.  cmd is Python’s class for line-oriented command interpreters.  cmd2 is Devlin’s enhancements to cmd.

The rest of the talks I attended were about software testing!

Why not run all your tests all the time?  A study of continuous integration systems, C. Titus Brown
Brown compared continuous integration systems: Hudson, Buildbot, CruiseControl, Bamboo, Bitten, Pony-build (his project).  Despite this possible bias, a strong recommendation was give for Hudson (Java-based).

Tests and Testability, Ned Batchelder
Batchelder discussed testing lifecycle: test isolation, harvesting output, dependency injection and mocking.

Rapid Multi-purpose Testing, Holger Krekel
Krekel’s py.test is a command-line tool to collect, run and report about automated tests.  It supports test skipping, test running modes, parametric testing, test discovery, and multi-cpu testing.

New and Improved: Coming changes to unittest, the standard library test framework, Michael Foord
These changes will be new for Python 2.7:

• New assert methods.
• No more fail methods, standardize on assert*.
• Better multiline string testing.
• Unit test discovery.
• cleanup() method cleans up in reverse order (improvement over current tearDown() method).

Backported to Python 2.4, 2.5, and 2.6.  Check it out at unittest2.

What more can you ask for?

Unfortunately, forms hardly ever stay the same throughout the course of a clinical trial or a research study.  Forms frequently need to adapt to new data points that were unforeseen during the protocol definition phase.  So how can we handle this?

We could go ahead and naively make the new changes, but what happens if the change asks for a field to be deleted?  Even if we just hide the field and keep the previous underlying data, how can we display the data that was captured now that the field is missing from the form?

One solution for this is form versioning.  The ability to load alternate versions of a form is a frequently overlooked feature when designing a system to handle CRFs for a clinical trial, forms for a research study, or generally any forms that tend to change.

Form versioning allows us to:

• Retrieve and display data even if the field is no longer part of the current version of the form.
• A dropdown list’s items can be added, removed, or changed and we’ll always be able to retrieve exactly what items were present before changes were made.
• Keep the validation rules (edit checks) specific to a specific version of the form.
• Tell customers that mid-study changes are a breeze because the form versioning technology keeps mid-study changes isolated from existing data.

Next time you’re designing a system that stores CRFs or basically stores form data, it may pay to integrate form versioning into your system.  It definitely saved me a lot of time.  Although I can’t say mid-study changes are my favorite thing in the world, I can say that form versioning makes mid-study changes a whole lot easier.

The array indexing operator cannot be overloaded; however, types can define indexers, and properties that take one or more parameters. Indexer parameters are enclosed in square brackets, just like array indexes, but indexer parameters can be declared to be of any type, unlike array indexes, which must be integral.

The syntax for indexers resembles the C# syntax for properties rather than its syntax for operator overloading. Here’s a quick snippet for providing array-like access to a List you’d like to keep hidden within a class:

// overloads the square brackets to provide array-like access.
public T this[int i]
{
    get { return this.List[i]; }
    set { this.List[i] = value; }
}

Worked for me, and hopefully it works just as well for you!

UPDATE: As I do a quick search now, this Stack Overflow post just turned up.

Below is a list of common mistakes for developing a Tablet PC application.  All are avoidable early in the project’s life-cycle. Some of these mistakes I own, and others I’ve seen from other project managers and developers. Hopefully, this list helps others avoid these common mistakes.

There are already plenty of re-hashed lists on the Internet describing how to address goal setting, client and stakeholder buy-in, or various software and management anti-patterns. This is not one of those lists.

Mistake 1 – I need to learn another operating system
Mistake 2 – It looks fine on my machine, so it’ll look fine on the tablet
Mistake 3 – It’s just Windows, so I don’t need to worry about fonts
Mistake 4 – It works in notebook mode, I don’t need to worry about slate mode
Mistake 5 – 3-hour battery life is more than enough
Bonus – I’ll think about security when it’s up and running

Mistake 1. I need to learn another operating system. Some programmers (and some clients) still think Tablet PCs use a special mobile operating system with its own set of SDKs and APIs. Currently, the majority of Tablet PCs run Windows XP (with Tablet PC enhancements) or Vista (which has the core Tablet PC functionality built-in). Although development tools specific to the Tablet PC such as Digital Ink and the Text Input Panel are available, no one says you have to use them. Most applications you use on your desktop or notebook will work just as well on a Tablet PC.

Bottomline: No new OS, just some added libraries for Windows.

Mistake 2. It looks fine on my machine, so it’ll look fine on the tablet. Okay, great!  It’s just a vanilla Windows machine with some extra bells and whistles. I can just develop my application on my workstation, and then deploy it when I’m done.

Almost — like any kind of development, it’s important to test in the environment where it will be used. Some times this isn’t possible, but hey, you’re developing for a tablet, it only makes sense to at least test it on a tablet. Microsoft does offer some emulation software (with limitations) that tries to duplicate a tablet environment, but nothing can replace testing it directly on your target system.

Probably the biggest time-saver is having a development environment that mirrors the screen resolution of the Tablet PC. If the monitor is the right size and it can rotate, you’ve got a winner! Tablet PCs often have an extra wide or extra tall screen, and they can change between notebook and slate mode. With the right monitor, you won’t need to deploy to a tablet every time you tweak something just to see if your application looks okay.

Bottomline: Make sure to test on your target system, and shell out the money for the right monitor.  The development time you save will be well worth the cost.

Mistake 3. It’s just Windows, so I don’t need to worry about fonts. This one is a killer.  Font size is probably the last thing I would worry about. Unfortunately, I’ve seen some good applications completely tank in front of the customers just because of font size.

Windows should keep the font size consistent whether it’s on a desktop, notebook, or Tablet PC.  And… it does. Tablet PCs, just like desktops and notebooks, come in a variety of resolutions. Imagine squeezing everything on your monitor into an 10-12″ screen at the same resolution. Changing the resolution fixes the situation in a way, but then those magnified resolutions don’t take advantage of the added width or height of a tablet PC. And the accessibility settings?  …the “Extra Large Fonts?” Another no-go.  Because you’re starting out with a smaller screen, the font size difference isn’t substantial enough to make much of an improvement to the user.  Try it, and you’ll see.

It really doesn’t seem like much of an issue, except when you’re working with an older user.  If they can’t read the text, forget all the Ink widgets and latest technology you implemented, because your application is now considered completely useless by the people who should be using it. Make sure to use larger fonts (18pt worked for me!) in your application, or better yet, allow the user to adjust the fonts within your application.

Bottomline: If they can’t read the application text, don’t let the door hit you on the way out.  Use larger fonts or let the user decide what font to use.

Mistake 4. It works in notebook mode, I don’t need to worry about slate mode. Most developers work on monitors that are wider than it is tall. So naturally, you’ll find yourself developing your Tablet PC applications in that environment. You’ll also find that you tend to work with the tablet in the notebook mode as well.

Not much harm in that, until you switch to slate mode. If your application GUI objects took advantage of the extra screen width, those objects will now either be off the screen or squeezed into about half the space. A number of techniques exist to leverage the added width or the added height, but I’ll leave that for another post.

Bottomline: Make sure your layout works in both notebook mode and slate mode.

Mistake 5. 3-hour battery life is more than enough. The battery is not so much a software development issue. However, if you’re taking ownership of developing a Tablet PC application, understanding whether the customer’s needs are met by the selected hardware is at the the top of your list. If the hardware doesn’t fit the customer’s needs, your application will never get used by anyone but you.

Learning how the customer uses the tablet is essential.  Will they be running around all day in the wards?  Are they traveling from site to site?  Will they require Wi-Fi (battery drainer!)? If any of these are true, you’ll need to get extra battery packs.  After getting the extra packs, either detail an SOP for swapping out the battery after hibernating the tablet, or better yet, start the project with tablets that have hot swappable batteries!

Bottomline: Understand in detail how the tablets will be used with regard to battery life.  If 3 hours is not enough, make sure the users understand how to swap in a fresh battery.

Bonus: I’ll think about security when it’s up and running. I know, I know… I said 5, but I thought I’d throw in this one, since it’s a show-stopper. A tablet, just like a notebook, is meant to be portable. The price we pay for this convenience is it’s also a very good target for theft.

If a tablet containing patient data is lost or stolen, the law requires those patients be notified. The healthcare professionals responsible for the loss will be in a world of hurt and paperwork, but it doesn’t stop there. Your application will also come under scrutiny. How do you secure the protected health information? Is the patient data de-identified?  How?  What data was lost? Who else has seen that data? And that’s just for starters! As a first step, I recommend full disk encryption.  TrueCrypt has worked well for me, and here’s list of full disk encryption providers.

Bottomline: Security, especially for tablets in a health care environment, cannot be an afterthought, it must be integrated into the design process.

So, there’s my 5.  Hopefully it’ll save you guys the need to find them out on your own.  Happy tablet hacking!

As a (primarily) Java developer, I’ve also noticed that C# handles abstract classes that implement interfaces differently. In Java, an abstract class can implement an interface, and not provide implementations of all of the interface’s methods.  It is the responsibility of the first concrete class that has that abstract class as an ancestor to implement all of the methods in the interface.

C# on the other hand seems to require that the abstract class provide implementations for all of the methods on the interface. Even if that implementation is just a method signature.

Like these 3 posts (1 (bottom), 2, 3), I am struggling with why the Microsoft Team chose to do this.  Why ask the developer to write a little stub for the interface method, when the abstract class has no intention of implementing it at all?

I believe it’s a natural artifact of virtual and non-virtual methods in C# (gotcha #2).  In Java, methods are virtual by default (as far as I’m aware, Java doesn’t support non-virtual methods).  However, C# (being derived from C++) does support non-virtual methods.  When an abstract class implements an interface in C#, you are given the chance to describe the interface methods as abstract, virtual or non-virtual.  Here’s exactly what each options means:

1. abstract - No attempt at an implementation is made in the abstract class.  It’s up to the first concrete class to provide an implementation.  As a side note, defining a method as abstract implicitly defines it as virtual.  If this weren’t the case, you wouldn’t be able to override it in the child class which defeats the purpose of an abstract method.
2. virtual - An attempt was made in the abstract class to implement this method, but the child class has the option of overriding it and providing its own implementation.
3. non-virtual – Again, an attempt was made at an implementation in the abstract class.  However, the child class cannot override this method.  If a child class defines a method with the same name, the method will not be associated with the interface implemented in the abstract class.  The method associated with the interface is the non-virtual method defined by the abstract class.

Java can do options 1 and 2, but it lacks option 3.  Java could define the method as final to prevent it from being overriden, but this is slightly different than non-virtual.  The final keyword is more along the lines of seal in C#.  By allowing an option 3, C# provides finer control over how interfaces are inherited.  If C# went the route of Java and permitted abstract classes to put off interface method definitions, these methods would need to be virtual by default.  However, this would be inconsistent with C# methods being non-virtual by default.

In a nutshell, the C# developer is forced in the abstract class to decide exactly which of the three options to assign to the interface method.  Anyway, that’s my best guess…

How do you systematically make use of the varied Tablet PC screen resolution dimensions using C#?

Designing a CRF specifically for a Tablet PC can be a challenging experience, but it can also be one of the most rewarding.

The Tablet PC is very similar to a traditional desktop computer or a laptop.  As I write this entry, most Tablet PCs are running some variant of Windows.  Whether it’s Windows XP Tablet PC Edition or Vista (which has built-in support for Tablet PC specific functionality), you’re basically dealing with a Windows machine and you can pretty much treat it as such…  almost.

Maybe it’s not so much the variety.  One of my biggest obstacles was that the dimensions change.  They don’t change just once in a while (like when the resolution changes when you connect your laptop to a TV), they can change many times during a single session!

For example, convertible Tablet PCs (like the one in the image above) provide the ability to change from portrait to landscape and back again all in seconds.  In addition, most Tablet PCs come in screen dimensions that are either wider or taller depending on whether it’s in slate mode or the more traditional notebook mode.  Taking advantage of a taller or wider screen is going to be the topic of a future post, but let’s say you have a layout for making use of the added height or width, how do you know when to use which?

The first step is determining whether the screen dimensions are in portrait (slate) mode or landscape (notebook) mode.  Here are two straight-forward methods for determining which mode the Tablet PC is using:

public bool IsPortrait()
{
    return Screen.PrimaryScreen.Bounds.Height >
        Screen.PrimaryScreen.Bounds.Width;
}

public bool IsLandscape()
{
    return !this.IsPortrait();
}

We can setup a thread that calls one of these methods at specified intervals (polling solution), or we can leverage the .NET event architecture so that our application responds to dimension changes. Leveraging the event architecture is intuitively more efficient and more reliable, so add this to your Form_Load() method:

Microsoft.Win32.SystemEvents.DisplaySettingsChanged +=
    new EventHandler(SystemEvents_DisplaySettingsChanged);

Now, define the event handler:

void SystemEvents_DisplaySettingsChanged(object sender, EventArgs e)
{
    if (ScreenProperties.IsPortrait())
        // do portrait handling
    else
        // do landscape handling
}

And just like that, your form is now responding to screen resolution dimension changes!