There is a growing trend towards smaller and smaller fonts on blogs (e.g. 0.60em). While it's a simple matter of customizing your local stylesheets, or overriding the font size at the GUI level,it is a bit of a hassle.. Nonetheless, it seems to be a growing belief that using a small font someone implies professionalism or academic worth.

Yet when will the cycle end?

When Java first hit the development ecosystem, to many it wasn't just a method of doing efficient, high-level development, but rather it became a new religion: You couldn't only use Java as the glue between existing code, or even as the overwhelming bulk of your solution. A partial-Java solution simply wasn't good enough.

Instead your product had to be 100% Pure Java. The still sought-after eventual goal was a complete Java solution, from applications right down to the operating system, with only the smallest possible binary kernel, if even that. All of this would be running on a Java-aware processor, engineered specifically for Java.

Sun created a "100% Pure Java" campaign to push this philosophy, including banners and designations for appropriately certified software, and advocated it as a very desired moniker. Users were led to feel that mixed solutions were impure and somehow dirty: Are you some sort of nut running an impure solution, dirtied with some pointer munging, buffer overflow vulnerable C code? While there were (and remain) methods to call native code, they were discouraged.

Of course there is a lot of validity to this agenda. Primary being the fact that pure Java solutions are theoretically cross-platform, with no ties to external technologies. Compare this to a solution leveraging C libraries, which would require a rebuild or binary available for every distinct target platform. Additionally Java could only impose its sandbox and extensive security constraints if you stayed in the world of Java, and thus callouts to native code represented a risk.

In the real world, though, it often meant that developers were constantly solving long-conquered problems, redundantly reinventing solutions in Java that long existed elsewhere, or waiting until adequate libraries eventually appeared: Developers were pressured to use Java alone even when it was a hammer and the solution really needed a chisel.

Thankfully .NET hasn't been pushed in such a single-minded way (even if some of its champions have foolishly taken up such a misled cause, including some at Microsoft. Instead of a justified part of the solution, it becomes a religion. .NET! .NET! .NET! .NET!), and indeed Microsoft themselves has always facilitated, and even advocated, "impure" solutions. The majority of the .NET Framework, for example, is actually a very thin veneer over the existing Win32 facilities and libraries -- it was either that, or version 1.0 would have come with a much smaller, much less efficient library.

The "orchestration layer over native code" implementation is the reason .NET hasn't suffered the performance difficulties that Java has.

Microsoft chose to leverage what they'd already done, to maximize both performance, and to maximize the breadth of the library. 

This advantage isn't limited to Microsoft, though, and the developer can utilitize this functionality as well. .NET offers very simple COM and P/Invoke functionality to leverage "legacy" code (or even new code developed in a best-solution, non-.NET technology), allowing you to easily use your existing DLLs and/or COM libraries as first class partners in your .NET solutions. Even if they're created in "dirty" languages.

I take advantage of this functionality regularly, utilizing existing best-solution libraries and functions, regardless of whether they're pure .NET or not. For instance in creating the static version of the "best of" blog entries, I quickly -- maybe 2 hours -- wrote a quick transformation tool that basically imported the "best of" RSS feed (it isn't included in the normal category lists), then doing some XSL transformations (using extension objects in the XSL given that XSLT alone wasn't adequate for some special purposes -- for instance HTMLDecoding the description block of the RSS) to the resulting XHTML, as well as creating an index page.

One goal when creating this solution is that the resulting pages are all fully XHTML compliant, and they pass the W3C validity checks. While I could easily see how the pages rendered in Mozilla/Firefox/IE/Opera, and of course they all rendered fine, technically there were a couple of deviations from the spec. Some of these errors and warnings were caused by unavoidable transformation issues, while others were caused by minor mark-up errors in the original blog entries (both because of my own errors when doing it by hand, but also because of Radio Userland's "helpful" auto-"cleanup" of HTML. It is remarkable how often auto-formatting is detrimental).

HTML Tidy to the rescue.

I had several options with HTML Tidy, the easiest of which would be to ShellExecute out to the EXE, telling it to process an existing file. I could have taken more time and tried to make a managed C++ version of Tidy, but I really didn't want to spend that much time.

I decided to have a bit more fun, not to mention building a more integrated, higher performance solution, and use the Tidy dll from the micro-.NET utility. I grabbed the Tidy source code (Tortoise CVS is a great solution for this, in this case using :pserver:anonymous@cvs.sourceforge.net:/cvsroot/tidy), updated the included MSVC projects to Visual Studio 2005, and added them to the transformation utility solution. I set the Tidy dll project output to the build directory of my .NET utility (in this case $(SolutionDir)\blogStatic\bin\$(ConfigurationName)). The MSVC build worked perfectly right away, which is amazing given that Win32 isn't an officially supported build.

To reference the Tidy dll methods, of course I had to add the DLL import signatures, in this case adding only the ones I had a need for.

  [StructLayout(LayoutKind.Sequential)]
  struct TidyBuffer
  {
    public IntPtr bp;           /**< Pointer to bytes */
    public uint size;         /**< # bytes currently in use */
    public uint allocated;    /**< # bytes allocated */
    public uint next;         /**< Offset of current input position */
  };

  class FileClean
  {
    [DllImport("libtidy.dll")]
    public static extern IntPtr tidyCreate();

    [DllImport("libtidy.dll")]
    public static extern int tidyParseFile(IntPtr tidyPointer, [MarshalAs(UnmanagedType.LPStr)]string fileName);

    [DllImport("libtidy.dll")]
    public static extern int tidyParseBuffer(IntPtr tidyPointer, ref TidyBuffer tidyBuffer);

    [DllImport("libtidy.dll")]
    public static extern int tidyCleanAndRepair(IntPtr tidyPointer);

    [DllImport("libtidy.dll")]
    public static extern int tidySaveFile(IntPtr tidyPointer, [MarshalAs(UnmanagedType.LPStr)]string outFileName);

    [DllImport("libtidy.dll")]
    public static extern int tidyRelease(IntPtr tidyPointer);

    [DllImport("libtidy.dll")]
    public static extern int tidySetCharEncoding(IntPtr tidyPointer, [MarshalAs(UnmanagedType.LPStr)]string encoding);

    [DllImport("libtidy.dll")]
    public static extern int tidyOptSetBool(IntPtr tidyPointer, int value, int Bool);

    public static bool CleanFile(System.String outputfileName, System.IO.MemoryStream docDataStream)
    {

      int result = -1;

      IntPtr tidyPointer = tidyCreate();
      try
      {
        // We want the resulting file to be UTF8 encoded
        tidySetCharEncoding(tidyPointer, "utf8");

        byte[] docDataArray = docDataStream.ToArray();

        TidyBuffer tidyBuffer;
        tidyBuffer.size = (uint)docDataArray.Length;
        tidyBuffer.allocated = (uint)docDataArray.Length;
        tidyBuffer.next = 0;

        GCHandle pinHandle = GCHandle.Alloc(docDataArray, GCHandleType.Pinned);
        try
        {
          tidyBuffer.bp = Marshal.UnsafeAddrOfPinnedArrayElement(docDataArray, 0);

          if (tidyParseBuffer(tidyPointer, ref tidyBuffer) >= 0)
          {
            tidyOptSetBool(tidyPointer, 29, 1);
            tidyOptSetBool(tidyPointer, 23, 1);
            if (tidyCleanAndRepair(tidyPointer) >= 0)
            {
              result = tidySaveFile(tidyPointer, outputfileName);
            }
          }
        }
        finally
        {
          pinHandle.Free();
        }
      }
      finally
      {
        tidyRelease(tidyPointer);
      }

      return (result == 0);
    }
  }

Most of this should be self-evident, however the two tidyOptSetBool calls may be a little cryptic. For the sake of brevity I haven't used the constants, but 29 is the TidyMakeClean value of TidyOptionId enum (see tidyenum.h), and 23 is the TidyXhtmlOut value. Together these indicate that I want to clean the documenting, converting it to XHTML. Note that I've also set the encoding to UTF8.

Voila, after transforming the RSS to the memory stream as quasi-conformant HTML, I passed the stream to this function, along with the desired output filename, and out went a cleaned-up, valid XHTML document. Pedants everywhere were thwarted from pointing out minor deviances from the standard. I could have processed to another buffer, and then done follow-up processing in .NET as well, but this was sufficient.

This is a trivial example, but it really exemplifies the great value of the easy interoperation of .NET. With it I could instantly leverage existing code, without having to search out bastardized ported versions, and instead could go right to the source.

We hadn't gone to the Ontario Science Centre for quite a few years (maybe 7 or 8 years), but after a mini-trip to Ottawa, and then a trip to Niagara Falls, were called off due to inclement weather (the former because it was too warm, and the latter because it was too cold), we decided to just bring the kids to the Ontario Science Centre today.

The place has improved dramatically.

7 years ago the OSC was largely full of malfunctioning equipment - leftovers from the original installation - and a lot of rather terrible computer demonstrations powered by Apple Mac Classics (though of course they weren't called Classics when they first made them, but they still were eye-opening to a lot of visitors years back, when the idea of a mouse controlled GUI was pretty novel).

A few of the better old displays still exist, include some Mac Classics still going strong, but they are now supported by a lot of fabulous new displays that kept our 3 year old overloaded with excitement until closing time. She is on the young end for a visit to the OSC (although the KidSpark area was perfect for her), but even much older children were having a blast. Parents were learning something as well, and indeed parents were often the first to start pressing the buttons or pulling the levers on the interactive displays.

All in all it really has improved, and was a very enjoyable visit. It's great to see such an attraction getting a facelift (much of it is ongoing, with several huge new improvements being built right now).

Now if Toronto could get a real world-class Aquarium.

I don't image myself a great photographer by any means -- I've simply learned the rules of framing a shot, along with the technical details of capturing it well. Given that I take a lot of pictures, invariably some of them turn out quite nice (and a lot turn out terrible -- oh thank you digital camera technology. This was much more expensive with the 35mm).

Really, I consider myself a photography technician (in this case capturing a visit to the Science Centre. All shots in this entry were shot at ISO 1600 with no flash. Aperature was usually fairly fast - f/5.6 or so. Shutter speed varied between 1/20th to 1/60th of a second, so a firm, steady grasp of the camera was paramount), and my best shots aren't themselves a form of art, but are simply capturing the beauty of the world around us. Beautiful moments we see every day.

In any case, when asked to provide photography advice I have one peeve that I always mention: Flash photography.

Flash lit pictures are, as a general rule, terrible. They usually feature a starkly lit subject - one that's often both overexposed and underexposed at the same time -- overlaid atop a barely visible background (almost detached from it, as if it was photoshopped in). Most ambient lighting has disappeared, replaced by the cold, artificial light of the flash. Shadows are cast across the scene (the further the flash is from the lens, the more of a visible shadow there will be, yet the closer the flash is to the lens, the worse that direct reflection and red-eye becomes). 

My general disdain for flash photography was one of the reasons why I bought the Canon Digital Rebel XT -- It features up to a 1600 ISO (which refers to the sensitivity of the sensor - in this case equal to 1600 film, which is very "fast" film. Many sensors have amplifiers that you can engage to increase the ISO, but it also increases sensor noise), with a slightly grainy but otherwise excellent picture at that speed, coupled with "fast" (lots of light) lens options. I've captured many wonderful pictures simply by setting the ISO to 1600 and disabling the flash, holding the camera as steady as possible, and then taking multiple shots with the hope that one of them turns out.

These were all pictures that would have turned out terrible with a flash, but instead I've captured gorgeous ambient light streaming in, colour reflections off of the wall, and the detail of the environment around the subject. As sensor technology improves, and we get even higher ISOs with reduced noise (and larger sensors that make use of more of the light), a lot of great photographs will result.

Of course there is a place for flash photography: It's critical for capturing fast moving moment indoors, professionally staged scenes with lots of professional lights, and even a skillful use of fill flash on a harshly lit day outside; however flash photography in general, in particular indoors, is grossly overused, turning a lot of beautiful photographs into so-so snapshots. 

The sensitivity of a camera and lens combination is a selling point that gets far less attention than it should.

If you were expecting me to say something about Macromedia Flash...well I aim to please. Check out this link.

http://www.honda.ca/HondaCALive/noFlashEng.htm

That's what you get if you visit Honda Canada and you don't have Flash (or more correctly if their shoddy script can't detect Flash. I have Flash in Firefox, but alas I'm redirected to this "too bad" page). While I can appreciate elements of the site being implemented in Flash (e.g. the car configurator), forcing Flash to see anything at all is amazingly ignorant. The wording almost implies that without Flash you're not welcome to Honda cars, which is just astounding hubris.

22 years ago my home computing experience was defined by my eldest brother's Commodore 64, along with an old flat-keyboard Atari 400 (take a look at that keyboard. Imagine spending hours typing in entire applications, your fingers pulsing in pain. Now imagine your neighbour curiously pushing the button that opens the cartridge cover, an action which hilariously also turns off the power. That happens to be a very destructive act when you have no persistent storage). Primary school computing consisted of programming stick figures bouncing o's on Commodore PETs.

These were pretty exciting times in personal computing, with seemingly endless potential, and a wide range of publications had appeared to cater to the burgeoning market. One of the most successful of which was Compute!, a magazine that stood apart by being largely platform agnostic (versus the rags that catered to a specific zeal, advocating why, for instance, the Ti-99/4a was the greatest computer ever).

I headed to the library monthly to read each issue, eager to see what new innovations were happening in the industry. These scans are from the February 1984 issue (if you're price comparing with today, note that the CPI inflation since 1984 is 1.86x), one of many that I bought on eBay some time back to use as office wall art, as obviously this was a very shaping period of my life.

Each Compute! issue featured one or more type-in game or application (as did most other home computing magazines), often ported to several platform. Sometimes they were BASIC, while other times it was a BASIC loader followed by pages of machine language. Fun times, and I have a great memory of some of these games. I also have memories of spending hours typing in a game to have it lock up when we went to run it.

These type-in applications were actually my original motivation for learning to program. My dream was to eventually submit my own application, imagining the glory of having thousands of people across the land typing my work into their computers. I would be a hero to people everywhere!

Of course the whole type-in fad faded before I had a chance for such illustrious glory. For a short while there was a standard for printing programs as 2D barcode patterns, and with the appropriate scanner you could scan it right off the page. Neat idea, but some technical difficulties kept it from taking off.

Several trends seem obvious looking through this magazine. Educational software of all sorts was a huge market in those days (and it seemed to be the greatest intended use for home computers), with Spinnaker being one of the largest vendors.

And of course there were games. SSI was a significant publisher of games, featuring several ads in every issue. Though they originally started as a wargame company (hence the Strategic Simulations company moniker), they began generalizing into all sorts of (mostly terrible) games.

It's also evident that the still struggling "everyone will be a programmer" philosophy was strong. BASIC, for instance, was intended as a language that everyone would use to achieve their computing needs -- certainly not as the primary language of many corporate developers -- with the whole family writing programs to do what they needed to get done.

CompuServe was the dominant pre-Internet, allowing users in several countries to communicate, participate in discussions, and even play primitive multiplayer online games. Of course it was insanely expensive, so I stuck to local BBSs.

And of course one of the most interesting sections of these sorts of magazines were the mail-order shop ads (a trend that reached its pinnacle with Computer Shopper several years late -- 800 pages, 99% of which were full-page ads).

I hope you enjoyed this trip down memory lane, or in many cases pre-memory lane. I had to scan these images anyways, so I figured I might as well share. I've stuck to ads -- rather than actual magazine content -- to avoid copyright issues.

Here's my original speculation, and here's what people think is starting to happen.

Of course in reality many firms, especially near airports (or where "live cams from the sky!" are prevalent in the local media), have been painting logos on their buildings for years, but it's going to take on a much greater use as satellite imagery proliferates and becomes more of a commodity.

This is a preview of an article scheduled for completion before the week is out (and while it shares superficial similarities to a recent Paul Graham article, it was started before Paul "published", and has been a topic that I've long wanted to cover).

I've dedicated a little more time to writing now, and should finally complete another commissioned magazine article over the next month (this one on distributed/symmetrical computing with .NET), which will be satisfying to finally .

Introduction

Software development can be a tremendously rewarding and enjoyable career.

Few careers offer comparable opportunities to weave intricate, complex structures that, while virtual, have such a  positive impact on the world around them. Few offer the freedom and creativity that software development does, or the very real potential for entrepreneurial riches.

Whether it's building a new peer-to-peer application, control software for a massive power generator, or improving the workflow of the corporate scorecard system, done right this can be a very fulfilling, enjoyable, challenging pursuit.

This article describes the wonder and curiosity that many developers start out with, whether it's when they pick up their first JavaScript in 1 Hour book, when they start toying with the gcc compiler for the first time, or when they started their first Computer Science course in university. It describes how that natural enthusiasm can be crushed, and how it can hopefully be regained or maintained.

This is written for the developer, whether a new recruit or a veteran, motivated or unmotivated, spirited or crushed, yet it's also written for software development managers (who might identify how to make the workplace more enjoyable and more rewarding).

A Passion for Software Development

Does your mind race at all hours, abuzz with potential solutions for vexing software development challenges? Do you lie awake at night -- anxious like a preschooler on Christmas Eve -- eager for morning to arrive so you can implement the crafty coding structures you just thought up? Do you frequently find yourself powering up your system in the twilight hours to implement the fruits of an epiphany?

Or do you put in just enough face time and superficial effort that sacrifice makes up for undelivered results? Do you purge your mind of software development the moment the virtual end-of-day whistle goes off, sliding off your Aeron dinosaur satisfied that it's one day closer to the weekend? Do you dread Mondays, motivating yourself to keep going with the dream of a far off vacation?

Do you eagerly embrace new technologies, seeing it as a challenging opportunity to learn something new when a solution calls for a new skill? Would you voluntarily dive into the innards of the Firefox web browser if a solution demanded it and you'd never touched it before? Do you swim through documentation, thirstily absorbing new APIs, tools, and languages to expand your skill-set, eagerly embracing industry advances?

Or do you dread anything different, praying that you're tasked with challenges that require only the skills you've long held, allowing you to apply them in a mechanical, repetitious fashion? Do you hope every project is an echo of a prior project? Do you put off any task requiring research, and show disdain towards new languages, techniques and practices, hoping that they don't gain traction?

Are you really passionate about software development?

Be honest with yourself.

A desire to outshine a teammate isn't passion. Nor is a motivation to impress the boss. Neither is a combination of the two worn as a magic defensive cloak against downsizing spells. All of those are second-rate, artificial passion substitutes: Mixed into the recipe, they yield subpar results, often leaving a nasty aftertaste called burnout and dissatisfaction.

Instead I'm talking about a bona fide interest and enjoyment of the craft and challenge of software development, even outside of career or job security issues (though it benefits the same). This isn't a job ad demanding that you're "passionate about business reports!", but rather is just a moment for sober reflection on whether you're over-clocking life, or running idle instructions in a tight loop.

If you're like most software developers in the industry today, a feeling of enthusiasm and enjoyment for the pursuit is just a distant memory (often during the happy days of university and your first job). Instead it has become a career, and is just something you do from 9-5 (or more when passion is replaced by sacrifice). Skills have likely stagnated, moving just enough to compete with coworkers, or to avoid obsolescence.

Of course there are those who've never (and will never) enjoyed this career. The only advice I can offer to those people is a suggestion that life is too fleeting to spend so much time doing something you don't enjoy.

Many others, however, remember the passion, and sporatically get a taste of it again. For those people I propose some personal habits that coupled with workplace practices (for managers, as well as people who rightfully manage up), that will help recapture, and maintain, that passion.

Software developers who truly love what they are doing are the ones creating the most innovative code. They're the ones with productivity rates multiples of their peers in the industry. They're the ones getting paid to do what they love doing.

...