Thoughts and opinions of a technology enthusiast.

30 Podcasts You Should Be Listening To (part 2)

flickr-abletoven-rss-headphonesIn part 1 of this series I highlighted the first block of 30 podcasts I listen to very regularly. I have listened to many of these since they began (often retroactively) and very much enjoy them. There are a lot of tech shows in here with a mix of science, food, history and popular culture mixed in for good measure.

Today I bring you round 2 of the podcasts. I highly recommend you check out any of these great shows and subscribe to them if you’re interested.

Get-It-Done Guy

Officially titled “Get-It-Done Guy’s Quick and Dirty Tips to Work Less and Do More” this show is a member of the Quick and Dirty Tips network. Host Stever Robbins touches on productivity tips with real-world applications that you can use to help you get organized, stay organized and get stuff done.

Part of what makes this show so listenable is wit, sarcasm and comedy used just frequently enough to help keep the show entertaining without devolving into nonsense. I enjoy following the exploits of Bernice, Europa and Melvin at Green Growing Things and Stever’s own personal stories about pursuing musical theatre.

Shows are typically delivered weekly and range from 5-10 minutes.

Girl on Guy

Comic and actor Aisha Tyler hosts this show where she interviews people from the entertainment industry. Most of the guests are involved as actors or writers in comedy, others are a bit further afield. The interviews are usually quite personal focusing on stories from and background of the guest. Some recent guests include Ryan Stiles and John Cho.

This is, as you’ve probably noticed, not the kind of show I listen to most of the time. I have a ton of computers/technology/programming/self-improvement type shows in my feeds. In a lot of ways though Girl on Guy fits in to the self-improvement category. Hearing stories about how other people have faced and won (or failed) in the face of adversity can be very illuminating.

Aisha, and her production crew if she has one, do a great job of putting the shows together. The audio quality is excellent. Girl on guy episodes typically run about 90 minutes.

Going Linux

Larry Bushey and Bill Smith bring a look at Linux from the perspective of people looking to make the switch from an alternative OS. The show comes in three flavours, a topic, listener feedback and “Computer America” episodes which showcase Larry’s monthly appearance on a radio program in the US where he is their Linux expert.

Larry has been doing the show for a number of years and Bill is his most recent co-host. Some of the back catalogue tended to take a rather anti-Windows rather than pro-Linux stance some of the time, but this has mostly gone away over the past year or so. If you’re new to Linux I highly recommend you check this out.

Audio quality is pretty good for the most part and episodes range from about 20 minutes for the feedback shows to about 90 minutes for Computer America.

Grammar Girl

Like other shows from the Quick and Dirty Tips network, this one has a very long title: Grammar Girl’s Quick and Dirty Tips for Better Writing. Each week host Mignon Fogarty brings a language tip or the solution to a common language problem.

This was the first show from the QDT network that I subscribed to, and really probably one of the first 10-15 podcasts I ever listened to. I have really enjoyed the show for several years and it has helped refine my writing quite a bit.

As with the rest of the network, audio quality is very good and episodes of Grammar Girl are generally in the 5-10 minute range.

Hacker Public Radio

Hacker Public Radio (HPR) is a show developed by and for the Linux/Open-Source/Hacker community. Taking the more fundamental definition of hackers as hobbyists rather than the more sensationalized view of hackers as evil computer geniuses, the show provides a platform for anyone to contribute a show about any topic they may feel is of interest to the hacker community at large.

The community produces five shows a week, every week. Episode number 1500 is scheduled to come out on Friday, May 2nd.

That said the community is always looking for more content. If you’ve ever contemplated podcasting, this is an excellent venue to test it out without having any long-term commitments. Make an episode. If you want help check out the show notes for this episode and get in touch with me, or ping me on twitter @kdmurray.


Hanselminutes is a show hosted by and aimed at people working in the software industry. Unlike the hosts of other developer shows, Scott Hanselman takes about 30-60 minutes each week to talk to the people in Software and explore things beyond the code and in some cases beyond technology. This is a great show for anyone in software who wants to expand beyond the role of a code monkey.

Some of my favourite episodes have focused on the most non-technical aspects of working in the technology industry including talks on community, relationships and the environment surrounding tech conferences. I’ve also really enjoyed the semi-regular “Hanselminutea” episodes with frequent guest Richard Campbell.

As of this writing the most recent episodes are: “Teaching my daugter to code with hopscotch”, “The Go programming Language”, “BitCoin Explained”, “Creating the Plex Software Ecosystem” and “I’m a Blind Software Technician”. Hanselminutes is a member of the PWOP podcast network.

A History Of Alexander / Hannibal

Two separate podcasts by Jamie Redfern which offer a deep dive into the life and times of two of the ancient world’s most capable military commanders. Broken up over the course of dozens of episodes these shows provided me with a great deal of knowledge and entertainment about a subject I really enjoy.

The Alexander show has actually been released twice. The first run was Redfern’s first attempt at podcasting. While it was great content, some of the audio issues in early episodes made listening a bit challenging. The “Remastered” edition of Alexander has solved all of those problems.

The Hannibal show was produced later and did not have these same issues. It also has a great deal of fantastic historical content.

Most episodes run about 30 minutes, and both shows have completed their runs.

The History of Rome

Host Mike Duncan is passionate about History. His deep love for the subject shows in his five year run (2007-2012) of the History of Rome. From the early origins of the Roman kingdoms to the fall of the Western empire, Duncan provides a fantastic and very well researched look into a crucial time in history.

This was the first history podcast I really enjoyed. I had tried a few others before this, but had found them either too dry and boring, or too poorly produced to hold my interest. THoR does not have either of these problems. Episodes are also nice and compact with most weighing in at about 25 minutes.

I was also very Duncan has a new show that started in the fall of 2013 (Revolutions) that I haven’t begun listening to yet. It is queued up on my phone for my next trip and I’m excited to start a new historical adventure.

IRL Talk

Irreverent is the best word to describe this show. Hosted by Jason Seifer and Faith Korpi IRL Talk provides a nerd’s-eye view to things happening in the world of technology and the Internet. It’s silly, yet informative, and helps balance out my somewhat tech heavy podcast lineup.

The best part about this show, without a doubt, is the chemistry between the hosts. Each knows how to push the other’s buttons (granted Jason does most of the pushing) and each has areas of expertise that have just enough common ground to hold the show together. Faith has tons of knowledge of movies and is involved in more artistic endeavours like dance. Jason’s primary weapons are making people feel uncomfortable, and his utter mastery of the long troll.

IRL Talk provides about an hour of excellently produced content with each episode.


I’ve known Knightwise for several years and really enjoy his platform-agnostic take on issues, and learning how to make technology work for you, instead of the other way around. This is definitely one of the shows I look forward to.

This is practical advice. Stuff you can put to use in every day situations, and for the most part stuff you will want to put to use as soon as the show ends. Every now and then Knightwise will include a “storytime” episode which is essentially an audiobook format of one of his blog posts.

Audio quality is usually pretty good (unless he records from his car) and episodes usually run about 60 minutes or so.

Image Credit: abletoven on Flickr.

Revisiting Short Order Code

Short Order Code album artIn perusing some of the archival content on my laptop, I realized that I didn’t really have any permanent copies of my short-lived development podcast Short Order Code up anywhere on the web.

So, for posterity, and in case I ever want to link to the content again I’ve decided to post these episodes (now four years old) to the blog. With each episode I will be including the entire text of the original blog post. Keep your eyes peeled for these posts over the next week or so.

Never Again – Enterprise Client Development

Never Again.


I know they say “never say never” but I can truly say that never again will I recommend trying to produce a piece of software for internal corporate use that is a desktop client. I’m done.

For the past two years I’ve been working on a project to create a new desktop client application to replace an old desktop client application. After two years of effort I have come to the conclusion that there had to have been a better way.

Building the software was a long and complex process, a bit longer and more complex than we anticipated, but overall it was manageable. We created an application that the team is proud of and we can’t wait to get the thing deployed so we can call this project done. Therin lies the rub. Deployment. The key difference between web applications and desktop clients – how do I get the software to my users?

We now have to get a piece of software pushed out to several hundred end users. The task sounds simple until you start to take into account the gotchas that accompany this simple task:

  1. Who needs the software?
  2. What is their machine name?
  3. Do they have all the pre-requisites?
  4. Will the pre-requisites break something they already have?
  5. How will you deploy it?
  6. Did you test all the possible software/hardware configurations?

Determining the first two items on the list is a lot harder than it sounds. Does everyone who needs to know actually know that this new software is coming? Do you have a good sense of the users of the current legacy system that your application is replacing? How old is the list of hostnames you’re working from? Is there actually any documentation for the old system? If so, has anyone validated it in the past 5 years?

Software pre-requisites are another nasty piece of business. Making sure that the libraries you have are licensed for deployment is important. If your users departments need to purchase licenses to use your software, did you tell them in advance? Did you now they wouldn’t already have that “standard” application installed? How impressed were they to take on an additonal $20K in software license fees in late September?

Beyond licensing the nastiness continues with deployment of the dependencies. Can they be pushed out the same way as your application? Do they require restarts? Do they need to be deployed before you can deploy your own application?

On top of that you may have certain versions of libraries that you’ve tested with your application and that you’ve used throughout the build and test process. If you’re working with a server-side web application you probably have full control of the environment you’ll deploy to in production. Not so with a client. You may not know you have an incompatibility until you start pushing your application out to actual users. Now what? You’re supposed to go live in less than a week and your product will cripple some critical application on the users’ machines.

Now that you have all that sorted out and you know how you’re going to deploy your application, the question is whether or not you’ve tested all of the permutations of hardware and software that could impact (or be impacted by) your application. Are your users on laptops or desktops? Are they running Windows XP or Windows 7? Are any of those Windows 7 machines running 64-bit versions of the OS? You did make sure your pre-requisites were all Windows 7 compatible, right? Do you need to package up a version of the .NET Framework or the JVM with your application? Do the users have any applications installed which rely on older (or newer) versions of the libraries you’re pushing out?

Oh, and you did realize that nearly half your user base is running in some sort of virtualized desktop environmnt, right? Do you know how to deploy to them? Will your software work properly in a virtualized environment?

Oh, and you did realize that about 20% of your users don’t ever come into the office right? You can deploy over someone’s low-bandwidth VPN connection, right?

These are all examples of questions that require solid answers before you can deploy a client application in an enterprise environment. The smaller the group, the easier it is. But if you have more than 100 end users or if any of them are in critical customer-facing roles you had better be damn sure you can answer all of these questions months before you plan to deploy. Otherwise you’ll be deploying months after you planned.

From now on I’ll be looking for web-based solutions to as many new application builds as possible. Going through the circus of trying to put software on my users’ machines is not an experience I care to repeat. In this increasingly heterogeneous world of multiple platforms, multiple operating systems and bring-your-own-device programs it is more important than ever to be able to consolidate the development effort to the server. It is a far simpler thing to deal with the quirks of a few browser versions than to worry about how many employees won’t be able to do their work the next time you release a software update.

Programming Languages 101

A few weeks ago I got an email from my brother asking about some programming tools for a project he wanted to try. He’s a fairly technically savvy guy, but has very little experience programming. He had asked a couple of questions which made assumptions about the lineage of some modern programming languages — assumptions which are totally reasonable given the names, but which didn’t reflect the actual nature of the languages.

This post is based on the email response I sent him.

Disclaimer: I realize that I have glossed over a number of technical details, and even introduced some of the concepts in a way which may even have some technical inaccuracies. This is not intended to be a technical manual, simply an introduction to a technical topic in terms that most non-programmers should be able to figure out.

Typically there have been two primary types of programming languages, compiled and interpreted. The source code of a compiled language is read by a lexer, parsed and then re-written into low-level machine instructions which can be executed directly on the hardware involved. Compiled languages almost always need to be recompiled for each individual platform because the physical instruction sets of Intel (x86), SPARC, ARM and other processors are all different. Operating system calls are also different. This means that code compiled to run on an Windows-based Intel machine won’t run on a Solaris-based SPARC machine.

Interpreted languages are not compiled. They are executed as they are read by some other process. These are sometimes called “hosted” programs since they don’t execute natively on the computer which is running them. The host process (web browser, game, or other runtime environment) reads the script line by line and then takes the appropriate action. So it’s the host process which actually reads files, communicates with the Internet or displays graphics on the screen. The interpreted language (script) is little more than a recipe. This is why differences in the implementation of the specification behind the script can cause such big problems. When you have 5 different web browsers which don’t quite agree on how to execute a particular construct of JavaScript it’s like the chef’s at 5 different restaurants having a different idea of what a medium-rare steak is. Sure it’s nice if one happens to do things the way you want, but you’ll never know until you try them all.

C is like the grand-daddy of modern languages. It’s curly-brace syntax pervades many modern languages (C++, Java, C#, JavaScript and many others). It is, however, a much lower-level language providing direct control of many system resources. C can also be optimized for speed and does not explicitly require any external frameworks or libraries to work. It’s a good language to have a grasp on, but may not be one you would ever use on a day-to-day basis.

JavaScript (a variant of and predecessor to the ECMAScript standard) was a language developed by Netscape in the 1990s to be a part of its web browser. Aside from the curly-brace design and the name, JS has absolutely nothing to do with Java. Until very recently, JS was purely an interpreted language. Its domain was to live inside the browser and help animate funny little things on screen or possibly display messages as you filled out a form. It’s only in the past few years that JS has really taken on a more leading role as massive libraries of complex JavaScript (jQuery) and people doing some seriously cool stuff with the language have led to uses of JS outside the browser. The node.js project is a perfect example. Node (whose executable is written in C) will serve as an engine for running JavaScript from the command-line much in the same way as Python, Perl and PHP do.

Just as most rules are made to be broken, so is the rule about a language being either compiled or interpreted. There are some languages which are a strange (and powerful) hybrid of both. Java and C# are both compiled languages. The thing is, they don’t compile down to natively executable machine code. They compile down to an intermediate format which is then interpreted when the code is executed. This provides a mechanism for the compiler to optimize the code for faster execution, while also providing a mechanism for the code to be ported to other platforms with minimal modifications.

From a language perspective C# and Java are like half-siblings… both members of a generation of languages designed to help build large cross-platform enterprise business systems, which have been drawn out into other areas due to sheer popularity. Visually the two languages look almost identical, with similar features and a “C-like” syntax, but due to each one being built to operate primarily with it’s own native framework (.NET for C# and J2SE for Java) the source code is essentially incompatible with the exception of a few trivial examples.

This all brings me to HTML5. This term has to be one of the most overused, over-hyped and poorly understood technological terms of the past decade. The name would imply that HTML5 is a new version of the HTML specification, designed to replace the rather aged HTML 4 specification in use on most websites today. And technically, that’s exactly what it is. There is a new version of HTML with some new tags (like <;video>; and <;canvas>;) which will provide web developers with some new tools to create compelling website experiences. The problem is that there are a lot more things behind the scenes that really make the next generation of web platforms powerful. A new version of HTML is just the start.

The new additions to the HTML DOM (Document Object Model) bring with them more powerful capabilities for JavaScript and CSS to help code and style the way web applications work. The <;canvas>; element is great, but it doesn’t do much without some fabulous JavaScript code to do the heavy lifting.

The next iteration of the CSS will provide more versatile styling for websites, allowing designs to function both for the desktop as well as the dozens or hundreds of combinations of screen sizes and browser capabilities on modern mobile devices. There’s a big difference between the kinds of things an iPhone 4S can display compared to a 3-year old BlackBerry Bold — both of which I have on the desk in front of me.

To wrap this up I really wanted to thank my brother for asking the question and giving me the opportunity to examine this question in detail. It isn’t something that I think about in my day-to-day work with software, but it’s still something important that bears examining from time to time.

Accessing HttpContext objects from other classes

I could swear I wrote about this at some point in the distant past, but I couldn’t find the article this week when I needed it to help troubleshoot an issue with another developer. The issue he was having was how to access objects from the executing web page’s HttpContext object from a class other than the CodeBehind of the executing web-forms page. Essentially he was looking for a way to map a web-path to a physical folder path without needing to hard-code it or know where the application was deployed on the server in question.

If done correctly, an application can reside anywhere in the file system and be deployed to a virtual directory at any depth without causing a problem with URL resolution. In the code-behind of a web-forms page, the code is simple:

However doing this from another page involves just a little bit more work:

It’s really quite straightforward when you see it, and I can’t believe that I forget how to do it. This method will also provide you access to lots of other useful objects which makeup the “state” of the application from an HTTP perspective.

Back to Basics

Over the past year my personal life as undergone some fairly major changes. I started a new job a little over a year back and there were the obvious changes that go along with that. But more importantly my wife and I welcomed our first child into the world and that was a life changing moment. Now, most of you know that I don’t talk about my personal life in the blog so suffice to say that we have thoroughly enjoyed our first year as parents. It is a wonderful experience and we eagerly await every new day to see what will happen next.

One of the things that changes when you have a new baby is the amount of time you can spend on yourself and your own hobbies and pursuits. I used to spend upwards of 4-6 hours every day outside of work on the computer blogging, coding, or otherwise toiling in one digital adventure or another. Now I find that the number ranges somewhere in the range of 0-2 hours per day. That is a pretty drastic reduction no matter how you slice it (about 80% for those of you scoring at home).

There are a number of projects that I have started and stopped over the past few years each of them trying to build a better mousetrap, or re-make something from scratch just to see if I could do it. With the limited time available to me now, I have become more focused on wanting to actually do more with the time I have — this means not reinventing the wheel every chance I get.

My wife and I have both found that we have become far more effective with our time, getting more done with less time than we ever have before. In the past couple of months I have started to extend that to my digital life as well. Gone are the days when I focused on a writing a to-do list, a backup utility, a blogging engine, a photo manager or a disk-erasing tool. There are lots of great (free) tools out there which can handle those tasks very well, even if they don’t satisfy all my neurotic desires (like how my historic completed work tasks should be handled, cataloged and stored for reporting purposes (you know, for when I will pull metrics on my completed work)).

I have also decided that diving in to learn a new, modern programming language is probably something that would realistically take more time than I’m willing to devote to the enterprise. Python, Ruby, Java, and the ASP.NET MVC framework are all on my list, but are undergoing changes and enhancements so frequently that I’m having trouble keeping up with what’s out there, nevermind trying to actually learn the stuff. But I do want to become a productive programmer in some language outside the rather constrained, and somewhat self-imposed, .NET bubble in which I have spent the majority of my professional career. Ideally I would like to write in something that I can port between operating systems without too much headache. Being able to produce code that will run on anyone’s machine is a great asset — especially when you have Windows, Mac and Linux machines in your own house to start with.

So the question is what can I learn that will allow me to:

  1. write code for multiple platforms
  2. grow as a developer
  3. not have to keep up with constant enhancements

The answer I came to was 42 C. It seems to satisfy all of the criteria above for me in a way that other languages don’t.

C is by nature intended to be a multi-platform system. If you’re able to confine your applications to CGI or the command-line this is made even easier.

C also requires developers to know much more about how computers and compilers work than more contemporary languages like C#, Java or Python. Though it arguably makes programming more difficult, I think it will help me become a better programmer over time as I learn some of the trickier parts of getting a computer to do what I want it to do.

The current ANSI standard specification for C was introduced in 1999. This means that for the past 12 years, the standard for C programming has remained essentially unchanged. This makes C a good choice for someone who doesn’t have a great deal of time to keep up with changes and enhancements in the specification.

For all these reasons, and my own simple curiosity I’m embarking on an adventure to learn and become proficient in C. I make no assertions that I’m trying to master the language as I can’t see myself getting beyond the hobbyist or perhaps open-source contributor stages. I do have some ideas for the first couple of projects I would like to tackle once I get the basics out of the way. Hopefully I’ll be able to release some source code back into the world over the next year or two — after all, I’m in no hurry.

C# IsNumeric implementation

Here’s a quick and dirty implementation of “IsNumeric” in C#. This is one of those methods that just seems to be missing from C# which appears in so many other languages.

UPDATE 12-Apr-2011: After some fantastic discussion elsewhere I’ve modified the code to handle a number of additional scenarios. A point was also raised that a combination of Int64.TryParse() and Decimal.TryParse() would accomplish the same thing. They would, almost, but those methods test for valid 64-bit integers and valid 64-bit decimals — they don’t test whether a string is numeric. Feed them a long enough string of numbers and they’ll return false. It’s a pretty fine distinction, I grant that, but I figured since I was writing the code I might as well make it as robust as possible.

I built 14 39 unit tests for this on the project I built it for throwing all sorts of weird and null data at it, and it seems to run fairly well and reasonably quickly. Any comments/suggestions are welcome.

Announcing EpubSharp

Over the past few days I’ve put some time into working on a library to create EPUB documents in .NET.  When I first did a search for this a few months ago I really didn’t find anything that suited my needs: a library that I could use to create EPUB documents on the fly, in code.

So I said to myself: “Self! You can write code, build the damn thing yourslef!”. So I did.

The initial version of the library has been published up on Google Code and is probably full of holes. If you’re interested, have a look and let me know what you think.  I’ll try to publish some more detailed specs for what the library does in the coming weeks.

For now, it can get got at: http://code.google.com/p/epubsharp/ — and yes, the documentation on that page is as sparse as it is here.  :)

New Podcast: Short Order Code

Over the past several months I’ve mentioned occasionally that I’m working on a new software development focused podcast. The time has finally come for me to make a more official announcement about this new endeavour.

The new show called Short Order Code. The show will be a
series of audio podcasts and video screencasts focusing on a number of
areas of practical software development.

The first episode is out now, and the next few are in various stages of being produced while I put together the final bits and pieces and trying to sort out my process.  Once that’s done and the first few episodes have been put together
I’ll try to provide more information around long-term plans for the

For those who may be wondering, this is not going to affect my
affiliation with the Aussie Geek Podcast (despite our . I love doing the show, and plan to continue in my co-hosting role for the foreseeable future as long as the AGP community is willing to have me. Time zone considerations will probably continue to make a mess of our schedule, but we’ll do our best to produce a great show for the community as often as we possibly can.

So keep your eyes peeled for more information, and head on over to the website at shortordercode.com and subscribe to the feed!

Honing the Craft

We were on vacation for a couple of months back staying with my wife’s family in the US.  I didn’t completely unplug during the trip, though I wasn’t checking work email, my personal accounts were down to a cursory glance once-per-day, and I’ve dialed back on the Twitter usage quite significantly.

In some of my relaxation time (while babysitting my sleeping 7-month old niece) I got the chance to do a bit of software development. My brother-in-law and I got to talking one night about a project he was hoping to get some help with. He had asked me as an adviser, and since the work was similar to things I’d done for work in the past I felt compelled to offer to help.

The project itself was simple enough: take this text file and put its contents into an Access database. The process has reminded me about why I like software development, and why I miss it.

Over the course of the next couple of weeks we went through a half-dozen iterations of the application, much in the same way that I would have worked with end-users inside our business unit at work.  It allowed me to work through a problem, understanding the true nature of the business problem that he was trying to solve, not necessarily just the problem as it was described in the initial requirements discussion.

I had the chance to pull out skills that I hadn’t exercised much in the past couple of years since my job role has changed, which was a great shift for me.  It’s given me the push I needed to get the podcast going, and to dive in to a few of my other projects with a bit more gusto.  Software is a craft, and its one that I need to continue to hone as time moves forward.  I could probably be considered little more than an apprentice right now, but with the entire Internet as my journeyman instructor I should be able to earn my ticket in the months to come.