Wednesday, 17 September 2014

Text templating with … (gasp) … Excel!

Excel has many unlikely uses (did you know that Excel 97 contained a hidden Flight Simulator?). I’ve just reminded myself of another one: fast text templating.

I needed to convert a data structure that looked like this

image

into one that looked like this

image

In other words, I needed to convert from a delimited text string into XML elements.

It took me about 60 seconds in Excel. Here’s how:

  1. I copied the text containing all the keywords and pasted it into a single cell of an Excel spreadsheet
  2. I selected the cell, and clicked on the Text to Columns tool (you find this in the Data tab)image
  3. In the Text to Columns Wizard, I indicated that the data was Delimited, and then entered the appropriate delimiter – the pipe (‘|’) character in this case. When I clicked Finish, Excel split each keyword into its own cell, going across the sheet.image
  4. Next, I needed the keywords arranged vertically instead of horizontally – in rows instead of columns. So I selected all the columns by clicking the first cell, then pressing Ctrl+Shift+[Right Arrow] to select all the way to the last keyword. Ctrl-C copied all the keywords. After clicking in an empty cell, I selected the Paste Special option. In the Paste Special dialog, right at the bottom, you’ll find the Transpose option, which will convert columns of data into rows, and vice versa.image
  5. In the cell next to the first keyword, I typed a formula that would wrap the keyword in the XML boilerplate. To concatenate strings use ‘&’, and to include quotes in a string use a double quote. So the formula I needed was
    ="<Keyword Name=""" & A3 & """ />"
    image
  6. I selected that first cell again, and double-clicked the solid square at the bottom right of the cell’s selection border. This replicated the formula all the way down the page to the last row with something in it.
  7. Did the Ctrl-C/Ctrl-V dance to copy and paste the generated XML into my code file.
  8. Job’s a good ‘un!

Monday, 10 February 2014

Getting Started with SignalR - and not a Chat room in sight!

You might have heard of SignalR, a real-time communications library for the web from Microsoft. It’s open source, it’s hip (it supports WebSockets!) – and just about all the Getting Started tutorials are about Chat applications. How many times have you had to write a Chat application in your career? I’d bet a two-toed sloth could keep count for you on one foot and still have digits to spare.

I want to show you how SignalR can solve elegantly a problem you will almost certainly have faced at some point: reporting progress of long-running operations on web pages. I say you’ve probably faced the problem – and if you’re anything like me, you’ve probably ducked out of solving it too, leaving your web site visitors in the tender care of a wait cursor while your web application does its thing in its own sweet time. Getting a server to report back to a web page has always been a fiddle, and many of the techniques in common use feel like hacks. SignalR changes all of that.

Read my three-part guest series on the Safari Books Online blog:

Friday, 5 July 2013

The Easy way to Record and Share Sermons - Introducing TruthVine Studio

One of my goals for TruthVine, my new sermon-sharing service, is to make recording and uploading sermons as easy as sending an email. All churches, great and small, should have the capability to share the Gospel online, not just those blessed enough to have an IT guru in the congregation.

To that end, I’m pleased to announce TruthVine Studio, free to all subscribers of the TruthVine service.

A screenshot of TruthVine Studio

Using this is simplicity itself:

  1. Press the big Record button when the preacher mounts the pulpit steps
  2. As he introduces his sermon, fill out the details in the relevant boxes
  3. Press the Stop button after the final “Amen”
  4. Hit Upload – and you’re done! The sermon will magically appear on your TruthVine powered website.

Should there be a period of paper shuffling before the preacher begins, you can easily trim the sermon before you upload it. Simply click and drag over the part of the recording you don’t want, then press the Trim (scissors) button.

Just think of the effort that saves you:

  • You don’t have to spend hours learning how to use complicated recording software.
  • You don’t have remember the sermon details to tag the files with later – type them straight into app.
  • You don’t have to spend ages waiting for your tool of choice to encode multiple versions of the file – TruthVine Studio exports a High Quality Mp4, a smaller Mp4 file, and an WMA file (for burning to CD) – and it takes advantage of your multi-core laptop to do all three at once.
  • You don’t have to go to a separate website, enter the sermon details all over again, then wait – again – whilst it uploads.

TruthVine Studio handles all of that in just a couple of clicks. We’ve been using TruthVine Studio at our church for the last couple of weeks at our church, and sermons have typically been on our church website within a minute of the service finishing.

If you fancy giving it a go, head over to the TruthVine site and sign up – it’s completely free during our preview period.

Shoutouts

I just wanted to say a few quick thank-yous to several folks for tools, resources and code that have been a huge help in building TruthVine Studio. In no particular order:

Thursday, 30 May 2013

How to debug silent crashes in .Net

Here’s a quick note to my future self, and any other interested parties in the present on how to diagnose a particularly tricky kind of unhandled exception. I’m talking about those ninja exceptions which manage to evade any kind of unhandled exception logging you’ve rigged up around your .Net applications.

I was debugging just such a problem today. A customer would double click the application, and nothing would happen. Our application is configured to log any unhandled exceptions to a log file. But no log file was being created. There was, however, an entry written to the application event log: it told me that a TypeInitializationException had been thrown, and even gave me a stack trace. But it told me nothing about why the type had failed to initialize.

To complicate matters, this was one of those heisenbugs where, though I could replicate it under normal circumstances, it would go away if I attached a debugger to the process. What I needed was a crash dump – a snapshot of the entire state of the application at the moment the exception happened.

DebugDiag was my first port of call. That’s a nifty tool from Microsoft which can be configured to create dumps from your application under particular circumstances,  including when it crashes. Handily, it will also analyse the dump file, and help you work out why the application crashed. Inexplicably, DebugDiag failed to capture any dumps for my application.

So I turned to Windows Error Reporting. From Windows Vista SP1 onwards you can tweak some flags in the registry, and have windows automatically capture dumps for you – assuming you’re using .Net 4.0.

Capturing dump files with Windows Error Reporting

All you need to do is set create a key at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\[Your Application Exe Name]. In that key, create a string value called DumpFolder, and set it to the folder where you want dumps to be written. Then create a DWORD value called DumpType with a value of 2.

image

Now get those ninjas to crash your app.

You should see a *.dmp file appearing in the folder you chose. Double click it – and you’ll see some Visual Studio magic, introduced in VS 2010. You can debug a dump file almost as if it were a live application. When you see the Minidump File Summary screen, you just need to click Debug with Mixed.

image

Unmasking the ninja

So what was this ninja exception that was evading my logging routines? It was an exception being thrown by my exception handling code!

The original exception was a ConfigurationErrorsException, thrown by the configuration API when loading my application’s user settings from a corrupt user.config file. My exception handling code looked like this:

private void ReportUnhandledException(Exception exception)
{
    try
    {
        Tracing.TraceUnhandledError(exception);

        ReportExceptionToUser(exception);
    }
    catch (Exception fatalException)
    {
        Tracing.TraceUnhandledError(fatalException);
    }
}

The problem was caused by a static constructor in the Tracing class. We’re using the System.Diagnostics TraceSource api to log our exceptions, and the constructor was setting all of that up. The TraceSource API, it turns out, also tries to load the application configuration, so that was throwing an exception.

The solution? Use Environment.FailFast instead of trying to log the secondary exception. That simply writes a message to the event log then bails out, with no chance of causing mayhem by raising further exceptions.

private void ReportUnhandledException(Exception exception)
{
    try
    {
        Tracing.TraceUnhandledError(exception);

        ReportExceptionToUser(exception);
    }
    catch (Exception fatalException)
    {
        Environment.FailFast("An error occured whilst reporting an error.", exception);
    }
}