Amazon Linux (Basic 64-bit Amazon Linux AMI 2011.09 AMI Id: ami-1b814f72) currently comes with Python 2.6.7 on it. At first, I thought I’d just be able to update to 2.7 with yum, but as far as I can tell, there isn’t a package for that already.

Joshua Holmes wrote about updating Python, which was a great help. My experienced varied a little, so I thought I’d share in case it is useful to someone else. For example, I didn’t want sqllite, but I did want ssl support. Also, there were some cases where I needed to use sudo when logged in as ec2-user.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

sudo yum install make gcc gcc-c++
sudo yum install openssl-devel.x86_64
 
cd ~
wget http://python.org/ftp/python/2.7/Python-2.7.tgz
tar xfz Python-2.7.tgz
cd Python-2.7
./configure --prefix=/opt/python2.7 --with-threads --with-ssl --enable-shared
make
sudo make install
 
cd ~ 
echo '''
 alias python='/opt/python2.7/bin/python'
 PATH=$PATH:/opt/python2.7/bin
 ''' >> .bash_profile
source .bash_profile
 
echo '''
 /opt/python2.7/lib
 ''' >> opt-python2.7.conf
sudo mv opt-python2.7.conf  /etc/ld.so.conf.d/
sudo ldconfig
 
python -V
Python 2.7

Notes

Line 26 is output from Python — not something you input (if that wasn’t obvious).

The configure script (line 8 ) specifies which optional libraries will be included in Python. I’m not sure what the typical list includes (for example, which are included in the official Python install for Windows?), but when you run make (line 9), it will report all the missing libraries for Python modules (“Python build finished, but the necessary bits to build these modules were not found”). If you use a module with a missing library in a Python program, you’ll get a runtime error.

The echo lines (13-16) are editing your user profile file for bash so that when you type ‘python’ you’ll get the 2.7 version instead of the default 2.6.7 version. I had a situation where I needed to run python under sudo, but root doesn’t have the alias, so it kept running 2.6.7. After some unfruitful attempts to add the alias to /etc/profile (sudo doesn’t execute that), I just added a symlink and invoked ‘python2.7′ explicitly (thanks to Chris Brinker):

sudo ln -s /opt/python2.7/bin/python /usr/bin/python2.7
sudo python2.7 -V
Python 2.7

A while back, I used WiX to build an installer, which was handed off to IT to deploy a web site. After a fair amount of anguish and frustration, I eventually realized that my installer was essentially a difficult to create and maintain batch file. Half the project was just custom command calls out to appcmd.exe anyway. If you’re so unfortunate as to absolutely have to create an MSI install, WiX isn’t a bad way to go, but it was a layer of massive unnecessary complexity in my case. Instead, I ended up creating a 7zip self-extractor that ran an actual batch file when launched.

One challenge is that I actually had a few installers, and I wanted to share code between them, which I was able to do after discovering the CALL command. Here’s an example:

call lib.cmd CopyFiles "C:\ServiceInstallDir"

This is essentially a function call, where “CopyFiles” is the name of the function, and “lib.cmd” is the file where it is implemented. Arguments follow the name of the function, the destination directory being the single argument in this case.

The lib.cmd file looks something like this:

@echo off
REM Within the "function" the args will be shifted, so 3 here becomes 2, 2 becomes 1, etc.
call :%1 %2 %3 %4 %5 %6 %7 %8 %9
goto :EOF
 
:Heading
REM %1 - Text for heading
echo ------------------------------------------------------
echo ^| %~1
echo ------------------------------------------------------
goto :EOF
 
:CopyFiles
REM %1 - Install directory
call :Heading "Copying files..."
if exist "%~1" rd /s /q "%~1"
md "%~1"
xcopy *.* "%~1" /s 
goto :EOF

Each label in this file acts as a function call. The CALL at the beginning passes control off to the label, including the additional arguments. The function ends by jumping to the special :EOF label (which exits the batch context). Note also that functions can call each other, as where the “CopyFiles” function calls the “Heading” function.

It’s a great way to encapsulate little bits of functionality in a common place.

Before addressing the tedium, though, why does it even matter whether you check for null arguments and throw a ArgumentNullException? You’ll just get a NullReferenceException if you don’t anyway. Is the ArgumentNullException somehow better?

The ArgumentNullException has a couple of benefits: It clearly indicates that the caller is to blame and by including the parameter name quickly narrows down the problem instead of requiring you to figure out which reference within the body of the method is null.

Although an ArgumentNullException is preferable, the null checking can overwhelm a short method. Here’s a contrived example:

public static void PrintThings(string[] things)
{
  if (things == null)
  {
    throw new ArgumentNullException("things");
  }
 
  foreach (var thing in things)
  {
    Console.WriteLine(thing);
  }
}

Half the method is dedicated to checking the parameter for null. Now imagine if a relatively short method had three parameters to check. It would be all null checks and hardly any code.

In the spirit of conciseness, I’ve frequently had some kind of helper function that does the null check:

public static void PrintThings(string[] things)
{
  Arg.NotNull("things", things);
 
  foreach (var thing in things)
  {
    Console.WriteLine(thing);
  }
}

The trouble is, Visual Studio’s static analysis doesn’t recognize this as a parameter validation of “things”, so you’ll get the CA1062 warning.

The work-around is to create a ValidatedNotNullAttribute and include it in the helper method, which signals to static analysis that, trust me, I really am checking the parameter. Here’s a complete example:

using System;
 
namespace CA1062Test
{
    public static class Program
    {
        static void Main()
        {
            PrintThings(new string[] { "one", "two" });
        }
 
        public static void PrintThings(string[] things)
        {
            Arg.NotNull("things", things);
 
            foreach (var thing in things)
            {
                Console.WriteLine(thing);
            }
        }
 
    }
 
    static class Arg
    {
        public static void NotNull(string name, [ValidatedNotNull] object value)
        {
            if (value == null)
            {
                throw new ArgumentNullException(name);
            }
        }
    }
 
    sealed class ValidatedNotNullAttribute : Attribute
    {
    }
}

Notice the trivial ValidatedNotNullAttribute implementation — it doesn’t matter what it does so long as it is named “ValidatedNotNullAttribute”. The attribute is applied to the parameter being checked in the NotNull function, so it only has to be specified once in the helper declaration, and not on each use of the helper.

The Code Book

Development Environment

I don’t love Eclipse, so I was excited when Palm announced Ares. Ares combines most of the tools you need for webOS development in a simple, browser-based IDE. Built-in JSLint support is awesome. Viewing logs while an app is running is simple. The editor and debugger are surprisingly capable. Source control integration is a great feature.

The visual designer, though possibly the most visible feature of Ares, wasn’t that helpful for me. There’s just not enough documentation to figure out how to accomplish what I want. The developer site has just barely enough documentation to build an app in the “traditional” Mojo way, let alone translating from Mojo to the Ares designer. The Ares presentation from Developer Days was hugely disappointing. So I just ended up creating a regular Mojo application instead, which worked just fine. It would be nice if you could choose up front which style of app to develop, and have the “New Scene” menu item either create an HTML scene or an Ares “chrome” scene as appropriate.

Source Control

Even though Ares keeps your code in the cloud, it’s still a good idea to use source control for change tracking. I looked at a bunch of online Subversion hosts, and ended up picking Unfuddle. It’s free, which is a big factor for a hobby project, and has worked reasonably well. It took me a little while to realize that adding a new project file in Ares does not add it to source control automatically — you have to do that as a separate step.

Unit Testing

Another benefit of my Subversion repository was that I could work on my project outside of Ares and still keep everything organized. The main thing I found missing in Ares was a built-in way to do unit tests, so I took care of those on right on my PC. I used the Jasime JavaScript unit test framework, running the tests from a local “runner” HTML file within Firefox so that I could step through any failing tests using the Firebug debugger.

Summary

Learning to develop for webOS definitely took some effort, but now as I’m going through the same learning process for iOS, I realize that writing code in JavaScript and building views in HTML provides for a gentler learning curve than Objective-C and Cocoa. I started my professional development career as a C programmer, but the merger with Small Talk makes Objective-C an odd beast.

Cipher Suite is kind of a niche application, but hopefully it will be fun or useful to a few people. It took a lot of spare-time hours over several months to put it together, but I wanted to do my small part to support the great webOS community.

If you search the web for a solution, you might come up with a couple of proposed solutions:

• WinForms: How to create a control transparent to other controls – The official word from Microsoft, the solution is presented in several pages of poorly formatted VB code that makes you immediately want to look for something simpler, such as…
• C# Transparent Label (also referenced from Rick Strahl’s blog) – This solution is much simpler; it’s just a Control subclass that doesn’t paint a background and draws the label text in OnPaint.

After working with the second solution for a while, I discovered that it doesn’t handle updating the text very well. Just changing the Text property itself doesn’t do it, and if you invalidate the control, you get the new text painted over the old text. If you’re the kind of person who fusses about minutiae like legibility and such, this isn’t ideal.

So here’s a solution that has worked reasonably well for me, and that scores high marks in the simplicity category:

/// 
/// A label that is transparent.
/// 
public class TransparentLabel : Label
{
  /// 
  /// Paints the background with the parent's background image.
  /// 
  ///
e
  protected override void OnPaintBackground(PaintEventArgs e)
  {
    Rectangle rect = new Rectangle(Location, Size);
    e.Graphics.DrawImage(Parent.BackgroundImage, 0, 0, rect, GraphicsUnit.Pixel);
  }
}

It basically scoops up the correct part of the parent’s background image and uses it as the background for the control. Yes, it still isn’t transparency, just a much better job of “camouflage” than the default behavior. If you’re painting the parent’s background, with a gradient brush for example, you can paint that into a bitmap instead and set the parent’s BackgroundImage to the bitmap for this solution to still work.

public static GraphicsPath GetRoundedRectangle(Rectangle rect, int rad)
{
	int d = 2 * rad;
	System.Drawing.Drawing2D.GraphicsPath gp =
			new System.Drawing.Drawing2D.GraphicsPath();
 
	gp.AddArc(rect.X, rect.Y, d, d, 180, 90);
	gp.AddArc(rect.X + rect.Width - d, rect.Y, d, d, 270, 90);
	gp.AddArc(rect.X + rect.Width - d, rect.Y + rect.Height - d, d, d, 0, 90);
	gp.AddArc(rect.X, rect.Y + rect.Height - d, d, d, 90, 90);
	gp.AddLine(rect.X, rect.Y + rect.Height - d, rect.X, rect.Y + d / 2);
 
	return gp;
}

It’s trivial to convert that GraphicsPath to a Region — just call the appropriate Region constructor. You can then fill the region:

var path = GetRoundedRectangle(rect, 3);
e.Graphics.FillRegion(Brushes.Orange, new Region(path));

If your corner radius is sufficiently large, you might not notice anything wrong with the result. With a value of 3, it is pretty obvious:

The top left corner looks perfect:

The bottom right corner is decidedly un-round:

I started to wonder if all those round rectangle functions were wrong, but drawing the GraphicsPath itself shows that the code is correct:

The problem is that when converting the GraphicsPath to a Region, it uses the inside of the GraphicsPath, so you lose the outside pixels on the sides, which you can see when drawing the path and then filling the region:

It turns out to be a whole lot easier and effective to do a little p/invoke here:

[DllImport("gdi32.dll")]
static extern IntPtr CreateRoundRectRgn(int x1, int y1, int x2, int y2, int cx, int cy);
// ...
var region = Region.FromHrgn(CreateRoundRectRgn(rect.X, rect.Y, rect.X + rect.Width, rect.Y + rect.Height, 3, 3));
e.Graphics.FillRegion(Brushes.Orange, region);

Here’s the output from that code:

It looks like a little larger corner radius is needed to get the same rounding, but otherwise it is perfect.

I found a good example of this in Chapter 5 of Professional Silverlight 2 for ASP.NET Developers by Jonathan Swift, Salvador Alvarez Patuel, Chris Barker and Dan Wahlin. As I describe it, and continue the discussion through this post, you’ll notice that the term “resource” is overloaded in Silverlight: There are resources in the normal .NET sense, backed by .resx files, and there are resources that are simply a dictionary of objects instantiated in XAML within a Resources element. Hopefully the usage will not be overly confusing.

In the localization example from the book, they created a resource file called LocalizedStrings.resx. Then they instantiated the automatically generated strongly typed class by including it in the Resources associated with a user control. Finally, they could then bind the Text property of a couple of TextBlock controls to a particular string from the resources:

<UserControl x:Class="SilverlightLocalizationExample.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Localized="clr-namespace:LocalizationExample.Resources">
 
    <UserControl.Resources>
        <Localized:LocalizedStrings x:Name="LocalizedStrings" />
    </UserControl.Resources>
 
    <StackPanel x:Name="LayoutRoot" Background="LightBlue">
 
        <TextBlock Text="{Binding TextBlock1,
            Source={StaticResource LocalizedStrings}}" />
 
        <TextBlock Text="{Binding TextBlock2,
            Source={StaticResource LocalizedStrings}}" />
 
    </StackPanel>
 
</UserControl>

You’ll want to be sure to use the PublicResXFileCodeGenerator custom tool to generate the code from the .resx file, otherwise the binding doesn’t work.

So what if you want to dynamically change languages, such as with a language drop-down?

The solution I came up with incorporates string resources into the view model. I was hesitant to do this at first because it felt funny having resources in the view model. Aren’t the strings purely a view component? Ultimately I decided that supplying the correct strings to the view based on language choice is a reasonable thing for the view model to do, and the resulting implementation and usage felt pretty good.

The base class for all view models simply has a Resources member:

public virtual object Resources
{
  get { return null; }
}

Each subclass then returns the appropriate object containing the resources:

public class MyViewModel : ViewModel
{
  private MyViewModelResources _resources;
 
  MyViewModel()
  {
    _resources = new MyViewModelResorces();
  }
 
  public override object Resources
  {
    get { return _resources; }
  }
 
  // ...
}

The class MyViewModelResources is the class generated from MyViewModelResources.resx. You might be saying, “Wait a minute. That class is basically static. What are you doing creating an instance of it?” Well, I don’t think there’s a way to bind to statics, so you need to have an actual instance around. Of course, the view will actually end up calling the static property (such as SubmitButtonText) when you include one in the binding path. Also, this isn’t any different from instantiating the resource class in XAML as the first example does.

Modifying the first example to use the view model (and setting the view model as the DataContext) makes the XAML look like this:

<UserControl x:Class="SilverlightLocalizationExample.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Localized="clr-namespace:LocalizationExample">
 
    <UserControl.Resources>
        <Localized:MyViewModel x:Name="ViewModel" />
    </UserControl.Resources>
 
    <StackPanel x:Name="LayoutRoot" Background="LightBlue" 
        DataContext="{StaticResource ViewModel}">
 
        <TextBlock Text="{Binding Resources.TextBlock1}" />
 
        <TextBlock Text="{Binding Resources.TextBlock2}" />
 
    </StackPanel>
 
</UserControl>

So what about the dynamic switching of languages at run time?

Since the “Resources” property is in the binding path, changing its value will update the bindings and the UI updates with the new strings. You just need to notify the view that the Resources property has changed. To make this easy, I created a helper method in the ViewModel base class, RaiseResourcesChanged, that effectively says, “Attention all view models, please update your views’ resources.” The message gets propagated to each view model instance by having a static ResourcesChanged event in the ViewModel base class that each ViewModel instance subscribes to at construction. When the event fires, the base class in turn raises the INotifyPropertyChanged.PropertyChanged event for the “Resources” property.

public class ViewModel : INotifyPropertyChanged
{
  private static event EventHandler ResourcesChanged;
 
  public ViewModel()
  {
    ResourcesChanged += ViewModel_ResourcesChanged;
  }
 
  protected void RaiseResourcesChanged()
  {
    var handler = ResourcesChanged;
    if (handler != null)
    {
      ResourcesChanged(this, EventArgs.Empty);
    }
  }
 
  void ViewModel_ResourcesChanged(object sender, EventArgs e)
  {
    RaisePropertyChanged("Resources");
  }
 
  // ...
}

Any single view model can then change the CurrentUICulture, call the helper method, and the UI updates automatically for all views:

Thread.CurrentThread.CurrentUICulture = newCulture;
RaiseResourcesChanged();

Another useful tool for optimizing cold startup is Microsoft’s free CLR Profiler 2.0. While this tool has the aesthetics of a wadded-up paper sack, it does have the ability to graph each assembly that gets loaded, and the method that caused it to be loaded. This makes it easier to figure out why a particular assembly got loaded, allowing you to consider whether there might be a way to avoid loading it or postpone loading it until some less critical moment.

To generate the assembly graph, click the Start Application button in the profiler. It lets you browse to the executable, which it will then launch. When you close the application, the profiler displays a summary screen with a bunch of information about the managed heap and garbage collection. You can close that window. Instead, go to the main menu and pick View > Assembly Graph. You’ll see something like this:

Assembly Graph Window (click for larger image)

At the far left edge of the graph, you can see the total number of assemblies (30) that were loaded during the application run. The edges from there represent method calls that caused other assemblies to load. Underneath the method name is the total number assemblies loaded through the full call stack. As you move to the far right side of the graph, you eventually see each individual assembly that is loaded. If you click on a node in the graph it sort of highlights (is plaid technically a highlight color?) the edges in and out of the node. That can be really handy when the graph lines criss-cross over each other.

In my case, where I’m writing a Word add-in, I have some initialization that must happen on the main thread at startup. Other initialization is put on a low priority background thread, which allows Word to start up quickly while continuing to load up the add-in functionality for when it will be used. To get a better picture of startup, I commented out the background thread. Then I looked for call paths that loaded lots of assemblies to figure out if any of those could be deferred to the background thread.

I found that making an XML-RPC call was pretty expensive in terms of code loading. The RPC call itself was pretty fast — just talking to another process on the same machine, but it took loading classes from five additional assemblies just to make the call, which hurts cold startup performance. At this point we’re trying to figure out if the current performance is acceptable or if we need to tweak the add-in’s behavior a little to delay the RPC call to the background thread. 

Mr. Richter’s reason for disliking properties is that they look like fields but don’t behave like them, thus confusing developers. He gives a good list of ways in which properties are different from fields — think of all the ways that a zero argument method is different from a field and you’ll about have it — saying that those differences are bound to trip people up.

I disagree for a couple of reasons:

1. Properties are really pretty easy to grasp.
2. Most programmers adhere to the rule that all fields are private (which Mr. Richter also recommended), so there aren’t really fields to be confused by. Expect everything to be a method and you’ll generally be fine.

I say “generally” because there are some cases where the opposite is true: a property can behave more like a field than a method. For example, you can use the postfix increment operator on a property (that has both get and set accessors) and it behaves as it would on a field. That is, the operator gets the property value and sets the incremented value back in. [Added June 26, 2008]

A benefit of properties that isn’t really mentioned in the book is a more explicit (for lack of a better word) “bean-ness”. Java has the bean concept, where an object has get and set methods to create a set of properties, but the C# syntax is more elegant and apparent. With the explicit properties, you can do things like XML serialization, property editors, etc. with reasonable default behavior.

It’s probably true that .NET properties get abused and overused (see the official guidelines), but I still kind of like them.

The guidelines are these:

1. A method’s parameters should be the most general type possible.
2. A method’s return value should be the most specific type possible.

As an example of the first guideline, a method should accept IEnumerable rather than IList if IEnumerable is all that is needed. The user of a method can always pass in something more specific, but being general allows the greatest flexibility. Of course, the most general parameter type would be object, but I don’t think you have to worry about this guideline suddenly causing you to write methods like this:

FileStream CreateFile(object fileName, object fileMode, object fileAccess);

Clearly you wouldn’t want the method implementation down-casting all the parameters in order to do something useful with them. If the method can actually do something useful with  plain object parameters, then that is probably the right type.

Conversely, following the second guideline suggest that you should return a FileStream rather than a Stream (assuming that what you actually have is a FileStream). The caller can always treat it as something more general, but never something more specific. In this case, the most specific type provides the most flexibility.

The author did provide a caveat to the second guideline, however. If you want to allow the implementation of a method to change, you might pick a return type that is slightly more general. The example he gives is that even if a method happens to use a List internally, it may be appropriate to return an IList so that the internal implementation could change to use an array without affecting the callers.