Tales from the Evil Empire

Bertrand Le Roy's blog

News


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff

Archives

December 2010 - Posts

Mandatory look back at 2010

(c) Bertrand Le Roy 2010Yeah, it's one of those posts, sorry.

First, the mildly depressing: the most popular post on this blog this year with 47,000 hits was a post from last year about a fix to a bug in ASP.NET. A content-less post except for that link to the KB article that people should have found by going directly to the support site in the first place.

Then, the really depressing: the second most popular post this year with 34,000 hits was a post from 2005 about how to display message boxes on a web page. I mean come on. This was kind of fun five years ago and it did solve one of the most common n00b mistakes VB programmers trying to move to the web were making. But come on, we've traveled about 4.7 billion miles around the Earth since then. Do people still do that kind of stuff? I should probably put a big red banner on top of this post.

Oh [supernatural entity of your choice]. Hand me that gun, please. Third most popular post with 24,000 hits is from 2004. It's about how to set a session variable before redirecting. That problem has been fixed a long time ago. Oh well.

Fourth most popular post. 21,000 hits. 2007. How to work around a stupid bug in ASP.NET Ajax 1.0. Fixed in ASP.NET 3.5? ASP.NET Ajax 1.0? Need I say more?

The fifth one (20,000 hits) is an old post as well but I'm kind of fond of it: it's about that photo album handler I've been organically growing for a few years. It reminds me that I need to refresh it and make a new release. Good SEO title too.

Back to insanity with the sixth one (16,000) that's about working around a bug in IE6. IE6. Please just refuse to pander to that browser any more. It's about time. Let's move on, please.

Actually, the first post from 2010 is 15th in the list. We have a trio of these actually with server-side image resizing and FluentPath.

So what happened? Well, I like the ad money, but not to the point that I'm going to write my stuff to inflate it. Actually I think if I tried I would fail miserably (I mean, I would fail worse).

What really happened this year was new stuff: Orchard, FluentPath and the stuff with the Netduino. That stuff needs time to get off the ground but my hope is that it's going to be useful in the long run and that five years from now I'll be lamenting on how well those posts are still doing.

So, no regret. 2010 was a good year.

Oh, and I was on This Developer's Life this year! Yay!

Anyways, thank you all for reading me. Please continue doing that. And happy 2011!

Migrating a blog from Orchard 0.5 to 0.9

img_0338My personal blog still runs on Orchard 0.5, because the theme that I used to build it is not yet available for more recent versions, but it is still very important for me to know that I can migrate all my content and comments to a new version at any time.

Fortunately, Nick Mayne has been consistently shipping a BlogML module a few days after each of the Orchard versions shipped.

Because the module gallery for each version is behind a different URL and is kept alive even after a new one shipped, it is very easy to install the module for both versions.

Step 0: Setting up the migration environment

In order to do the migration, I made a local copy of the production site on my laptop (data included: I'm using SQL CE) and I also created a new local site with a fresh install of Orchard 0.9.

Step 1: Enable the gallery feature on both versions

From the admin UI, go to Features and locate the Gallery feature under "Packaging". Enable it.

Enabling the gallery

You may now click on "Browse Gallery" on the 0.5 instance and "Modules" under "Gallery" for 0.9:

Browse GalleryModules

Step 2: Install the BlogML module on both versions

From the gallery page, locate the BlogML module and install it. Do it on both versions.

The BlogML module from the Orchard Gallery

Then go to Features and enable BlogML under "Content Publishing". Do it on both versions.

Step 3: Export from the 0.5 version

Click on "Manage Blog" then on "Export using BlogML" from the 0.5 version.

Exporting

The module then informs you of the path of the saved file:

The path to the saved file

Step 4: Import into the 0.9 version

From the 0.9 version, click "Import under "Blogs". Click the button to browse to the file that you just saved from 0.5. Then click "Upload file and Import"

Importing

Step 5: Copy the 0.5 media folder into 0.9

Copy the contents of the 0.5 version's media folder into the media folder of the 0.9 version. Once that is done, you can delete the "Default/Blog Exports" subfolder.

Step 6: Configure the target blog

Click "Manage Blog", then "Blog Properties" and restore any properties you had on the source blog. For me, it was the title and URL as well as to set the blog as the home page and show it on the main menu:

The blog properties

Step 7: Republish the new site to the production server

Once this is done and everything works locally, you are ready to publish to the production site. I use FTP.

The imported site

Note: this should work just as well for any couple of versions for which the BlogML module exists, and not just for 0.5 and 0.9.

Switching the layout in Orchard CMS

(c) Bertrand Le Roy 2010The UI composition in Orchard is extremely flexible, thanks in no small part to the usage of dynamic Clay shapes. Every notable UI construct in Orchard is built as a shape that other parts of the system can then party on and modify any way they want.

Case in point today: modifying the layout (which is a shape) on the fly to provide custom page structures for different parts of the site. This might actually end up being built-in Orchard 1.0 but for the moment it’s not in there. Plus, it’s quite interesting to see how it’s done.

We are going to build a little extension that allows for specialized layouts in addition to the default layout.cshtml that Orchard understands out of the box. The extension will add the possibility to add the module name (or, in MVC terms, area name) to the template name, or module and controller names, or module, controller and action names.

For example, the home page is served by the HomePage module, so with this extension you’ll be able to add an optional layout-homepage.cshtml file to your theme to specialize the look of the home page while leaving all other pages using the regular layout.cshtml.

I decided to implement this sample as a theme with code. This way, the new overrides are only enabled as the theme is activated, which makes a lot of sense as this is going to be where you’ll be creating those additional layouts.

The first thing I did was to create my own theme, derived from the default TheThemeMachine with this command:

codegen theme CustomLayoutMachine /CreateProject:true
/IncludeInSolution:true /BasedOn:TheThemeMachine

Once that was done, I worked around a known bug and moved the new project from the Modules solution folder into Themes (the code was already physically in the right place, this is just about Visual Studio editing).

The CreateProject flag in the command-line created a project file for us in the theme’s folder. This is only necessary if you want to run code outside of views from that theme.

The code that we want to add is the following LayoutFilter.cs:

using System.Linq;
using System.Web.Mvc;
using System.Web.Routing;
using Orchard;
using Orchard.Mvc.Filters;

namespace CustomLayoutMachine.Filters {
    public class LayoutFilter : FilterProvider, IResultFilter {
        private readonly IWorkContextAccessor _wca;

        public LayoutFilter(IWorkContextAccessor wca) {
            _wca = wca;
        }

        public void OnResultExecuting(ResultExecutingContext filterContext) {
            var workContext = _wca.GetContext();
            var routeValues = filterContext.RouteData.Values;
            workContext.Layout.Metadata.Alternates.Add(
BuildShapeName(routeValues, "area")); workContext.Layout.Metadata.Alternates.Add(
BuildShapeName(routeValues, "area", "controller")); workContext.Layout.Metadata.Alternates.Add(
BuildShapeName(routeValues, "area", "controller", "action")); } public void OnResultExecuted(ResultExecutedContext filterContext) { } private static string BuildShapeName(
RouteValueDictionary values, params string[] names) {
return "Layout__" + string.Join("__", names.Select(s =>
((string)values[s] ?? "").Replace(".", "_"))); } } }

This filter is intercepting ResultExecuting, which is going to provide a context object out of which we can extract the route data. We are also injecting an IWorkContextAccessor dependency that will give us access to the current Layout object, so that we can add alternate shape names to its metadata.

We are adding three possible shape names to the default, with different combinations of area, controller and action names. For example, a request to a blog post is going to be routed to the “Orchard.Blogs” module’s “BlogPost” controller’s “Item” action. Our filters will then add the following shape names to the default “Layout”:

  • Layout__Orchard_Blogs
  • Layout__Orchard_Blogs__BlogPost
  • Layout__Orchard_Blogs__BlogPost__Item

Those template names get mapped into the following file names by the system (assuming the Razor view engine):

  • Layout-Orchard_Blogs.cshtml
  • Layout-Orchard_Blogs-BlogPost.cshtml
  • Layout-Orchard_Blogs-BlogPost-Item.cshtml

This works for any module/controller/action of course, but in the sample I created Layout-HomePage.cshtml (a specific layout for the home page), Layout-Orchard_Blogs.cshtml (a layout for all the blog views) and Layout-Orchard_Blogs-BlogPost-Item.cshtml (a layout that is specific to blog posts).The contents of our custom theme

Of course, this is just an example, and this kind of dynamic extension of shapes that you didn’t even create in the first place is highly encouraged in Orchard. You don’t have to do it from a filter, we only did it this way because that was a good place where we could get the context that we needed. And of course, you can base your alternate shape names on something completely different from route values if you want.

For example, you might want to create your own part that modifies the layout for a specific content item, or you might want to do it based on the raw URL (like it’s done in widget rules) or who knows what crazy custom rule.

The point of all this is to show that extending or modifying shapes is easy, and the layout just happens to be a shape. In other words, you can do whatever you want. Ain’t that nice?

The custom theme can be found here:
Orchard.Theme.CustomLayoutMachine.1.0.nupkg

Many thanks to Louis, who showed me how to do this.

Displaying an image on a LED matrix with a Netduino

The Steam FactoryIn the previous post, we’ve been flipping bits manually on three ports of the Netduino to simulate the data, clock and latch pins that a shift register expected. We did all that in order to control one line of a LED matrix and create a simple Knight Rider effect.

It was rightly pointed out in the comments that the Netduino has built-in knowledge of the sort of serial protocol that this shift register understands through a feature called SPI. That will of course make our code a whole lot simpler, but it will also make it a whole lot faster: writing to the Netduino ports is actually not that fast, whereas SPI is very, very fast.

Unfortunately, the Netduino documentation for SPI is severely lacking. Instead, we’ve been reliably using the documentation for the Fez, another .NET microcontroller.

To send data through SPI, we’ll just need  to move a few wires around and update the code. SPI uses pin D11 for writing, pin D12 for reading (which we won’t do) and pin D13 for the clock. The latch pin is a parameter that can be set by the user. This is very close to the wiring we had before (data on D11, clock on D12 and latch on D13). We just have to move the latch from D13 to D10, and the clock from D12 to D13.Wiring the Netduino's SPI to the shift register

The code that controls the shift register has slimmed down considerably with that change. Here is the new version, which I invite you to compare with what we had before:

public class ShiftRegister74HC595 {
    protected SPI Spi;

    public ShiftRegister74HC595(Cpu.Pin latchPin)
        : this(latchPin, SPI.SPI_module.SPI1) {
    }

    public ShiftRegister74HC595(Cpu.Pin latchPin,
SPI.SPI_module spiModule) {
var spiConfig = new SPI.Configuration( SPI_mod: spiModule, ChipSelect_Port: latchPin, ChipSelect_ActiveState: false, ChipSelect_SetupTime: 0, ChipSelect_HoldTime: 0, Clock_IdleState: false, Clock_Edge: true, Clock_RateKHz: 1000 ); Spi = new SPI(spiConfig); } public void Write(byte buffer) { Spi.Write(new[] {buffer}); } }
All we have to do here is configure SPI. The write method couldn’t be any simpler. Everything is now handled in hardware by the Netduino. We set the frequency to 1MHz, which is largely sufficient for what we’ll be doing, but it could potentially go much higher.

The shift register addresses the columns of the matrix. The rows are directly wired to ports D0 to D7 of the Netduino. The code writes to only one of those eight lines at a time, which will make it fast enough.

The way an image is displayed is that we light the lines one after the other so fast that persistence of vision will give the illusion of a stable image:

foreach (var bitmap in matrix.MatrixBitmap) {
    matrix.OnRow(row, bitmap, true);
    matrix.OnRow(row, bitmap, false);
    row++;
}

Now there is a twist here: we need to run this code as fast as possible in order to display the image with as little flicker as possible, but we’ll eventually have other things to do. In other words, we need the code driving the display to run in the background, except when we want to change what’s being displayed.

Fortunately, the .NET Micro Framework supports multithreading. In our implementation, we’ve added an Initialize method that spins a new thread that is tied to the specific instance of the matrix it’s being called on.

public LedMatrix Initialize() {
    DisplayThread = new Thread(() => DoDisplay(this));
    DisplayThread.Start();
    return this;
}

I quite like this way to spin a thread. As you may know, there is another, built-in way to contextualize a thread by passing an object into the Start method. For the method to work, the thread must have been constructed with a ParameterizedThreadStart delegate, which takes one parameter of type object. I like to use object as little as possible, so instead I’m constructing a closure with a Lambda, currying it with the current instance. This way, everything remains strongly-typed and there’s no casting to do. Note that this method would extend perfectly to several parameters.

Of note as well is the return value of Initialize, a common technique to add some fluency to the API and enabling the matrix to be instantiated and initialized in a single line:

using (var matrix = new LedMS88SR74HC595().Initialize())

The “using” in the previous line is because we have implemented IDisposable so that the matrix kills the thread and clears the display when the user code is done with it:

public void Dispose() {
    Clear();
    DisplayThread.Abort();
}

Thanks to the multi-threaded version of the matrix driver class, we can treat the display as a simple bitmap with a very synchronous programming model:

matrix.Set(someimage);
while (button.Read()) {
    Thread.Sleep(10);
}

Here, the call into Set returns immediately and from the moment the bitmap is set, the background display thread will constantly continue refreshing no matter what happens in the main thread. That enables us to wait or read a button’s port on the main thread knowing that the current image will continue displaying unperturbed and without requiring manual refreshing. We’ve effectively hidden the implementation of the display behind a convenient, synchronous-looking API. Pretty neat, eh?

Before I wrap up this post, I want to talk about one small caveat of using SPI rather than driving the shift register directly: when we got to the point where we could actually display images, we noticed that they were a mirror image of what we were sending in. Oh noes! Well, the reason for it is that SPI is sending the bits in a big-endian fashion, in other words backwards. Now sure you could fix that in software by writing some bit-level code to reverse the bits we’re sending in, but there is a far more efficient solution than that. We are doing hardware here, so we can simply reverse the order in which the outputs of the shift register are connected to the columns of the matrix. That’s switching 8 wires around once, as compared to doing bit operations every time we send a line to display.

All right, so bringing it all together, here is the code we need to write to display two images in succession, separated by a press on the board’s button:

var button = new InputPort(Pins.ONBOARD_SW1, false,
Port.ResistorMode.Disabled); using (var matrix = new LedMS88SR74HC595().Initialize()) { // Oh, prototype is so sad! var sad = new byte[] {
0x66, 0x24, 0x00, 0x18, 0x00, 0x3C, 0x42, 0x81
}; DisplayAndWait(sad, matrix, button); // Let's make it smile! var smile = new byte[] {
0x42, 0x18, 0x18, 0x81, 0x7E, 0x3C, 0x18, 0x00
}; DisplayAndWait(smile, matrix, button); }

And here is a video of the prototype running:

The prototype in action

I’ve added an artificial delay between the display of each row of the matrix to clearly show what’s otherwise happening very fast. This way, you can clearly see each of the two images being displayed line by line.

Next time, we’ll do no hardware changes, focusing instead on building a nice programming model for the matrix, with sprites, text and hardware scrolling. Fun stuff. By the way, can any of my reader guess where we’re going with all that?

The code for this prototype can be downloaded here:
http://weblogs.asp.net/blogs/bleroy/Samples/NetduinoLedMatrixDriver.zip

More Posts