First Post: Kicking off a New Blog

A [Not So] Brief Personal History

Before I dive into my first blog post, I suppose a brief introduction is in order. My name is Mike Strobel, and my foray into the world of .NET development started back in May 2004, when I began working at CDC Software through Georgia Tech’s co-op program. Having been an avid Java developer until then, I immediately took a liking to the C# language and the .NET Framework, which had reached v1.1 just a year earlier. Following the release of C#/.NET v2.0 in 2006, I turned my back on Java development forever. While I’ve since considered myself exclusively a C#/.NET developer, I have occasionally delved into other languages and platforms to satisfy academic curiosity. To this day, language design remains an area of academic interest for me, and I’m sure I will blog about it from time to time. For today though, I will kick off my new blog by chronicling my adventures with the Windows Presentation Foundation (WPF).

Game Development with “Avalon”

My love affair with WPF began in November 2005. I was getting a head start on a project I would be completing the following semester as part of Georgia Tech’s Video Game Design and Programming course. For months, I had been planning to develop a turn-based strategy game similar to those of the Master of Orion series. Naturally, I wanted to have a highly customized UI, but I didn’t want to limit myself to raster-based widgets or fixed resolutions. Indeed, I wanted resolution independence coupled with the ability to completely customize a control’s appearance. Surely that isn’t too much to ask for, right? Well, as it happens, it wasn’t. I had heard some mumblings about a spiffy new vector-based, hardware-accelerated UI framework under development in Redmond. After crawling through MSDN and watching several old PDC presentations, I quickly became acquainted with a project code-named “Avalon”. The timing of this discovery turned out to be ideal—the September 2005 “Avalon” CTP had just been released, and everything I had read suggested that this was exactly what I needed. Though documentation was scarce, I muddled through whatever samples I could find, and within a few days decided that I had found my UI framework.

The next few months were a blast. Well, mostly. There was a brief period of “adjustment” following the release of the January 2006 CTP—specifically, the slew of the breaking changes that came with it. But I knew what I had signed up for, so I took the pain, brought my code back up to spec, and continued on my merry way. By the end of the semester, I had more than surpassed my highest expectations with regards to the game’s UI. I had custom styles and templates for every control from buttons and sliders to scroll bars and drop-down lists. I had a custom hex grid control for the galactic map, and I even had a unique color scheme for each of the playable races in the game. Not too shabby for an undergraduate project, especially coming from someone with zero experience in game development. The project later underwent a complete rewrite and has since evolved into an open-source hobby project that’s still under active development, but that’s a story for another time.

“Real-World” WPF Development with a Smart Client

Upon finishing my degree in the Spring of 2007, I formalized my role at CDC by accepting a full-time position as a software developer with their Technology Development group. In short, my team develops the core frameworks atop which the product development teams build their applications. My primary responsibility since then has been the development and maintenance of the CDC Smart Client Framework.

The Smart Client project had been under development for about two years before I became involved with it. At the highest level, the Smart Client Framework is actually two entities: a self-updating application deployment framework and a composite application environment in which CDC’s enterprise applications may execute and communicate with each other. When I first became involved with the the Smart Client project, the application environment was tightly coupled to the Windows Forms (“WinForms”) architecture. Although we had minimal support for CAB applications, and thus WPF applications could theoretically be integrated as well, our add-in system was heavily biased towards WinForms applications. This was largely due to the fact that the product managers for our CRM application (the first application specifically built for the Smart Client) had decided early on to stick with the tried-and-true WinForms UI system over WPF. Given that WPF was still pre-beta at the time (and would undergo several major API overhauls), this was probably the right call. With an aggressive roadmap ahead of us and insufficient manpower to properly explore WPF support, our initial release was, for all intents and purposes, strictly a WinForms environment. And it worked great.

Then something unexpected happened. Near the end of the CRM development cycle and about five months into my full-time tenure, our team’s lead architect resigned. This created a sort of knowledge vacuum in the team, as our departed colleague had been the lead developer on the project since its inception, and he took with him much of the working knowledge of the Smart Client internals. Over the next several weeks, my remaining colleagues and I became intimately familiar with the Smart Client architecture, and over time I became the de facto lead for the “client side” code. Once the CRM product had shipped, we began planning for the eventual migration of our ERP software from a web-based frontend to a Smart Client frontend. Then things really started to get interesting.

The VP of the Technology Development team, to whom I report, had been following WPF rather closely. He and I were both convinced that WPF represented the future of Windows client applications. He authorized me to begin a side project, initially “under the radar”, to investigate first-class WPF support for our Smart Client. After several late nights and weekends of clever coding, I had managed to refactor the framework to be UI toolkit-agnostic. Through liberal use of generics, I maintained compile-time compatibility with our original API while laying the groundwork for an eventual shift from a primarily WinForms environment to a primarily WPF environment. We have since abandoned our original WinForms-based shell in favor of a pure WPF replacement, and the Smart Client looks and performs better than ever. Hurrah!

Current Projects

Now that the Smart Client Framework has stabilized, I’m juggling new projects. The most interesting of these involves developing a new UI frontend for our ERP software. This project presents some interesting challenges due to the design of the backend. I’ll be discussing some of these challenges in an series of blog posts entitled, “From VT-100 to WPF: The Evolution of an ERP System”. Stay tuned!