A couple of weeks ago, my coworker and Ignite Your Coding co-host John Bristowe and I did a live webcast interviewing Glenn Block, a Program Manager for .NET FX at Microsoft. Glenn’s one of the go-to guys on Prism, Unity, MEF and ways of building maintainable and reconfigurable applications out of pieces that you can assemble and rearrange in general. We’ll talked about building composite applications, design patterns, dependency injection and why it’s good for you, and other aspects of good object-oriented design as we understand it these days.
Ignite Your Coding is a series of webcasts in which John and I talk to some of the bright lights of the software industry about how they got started, what they’re doing, how they cope with the change that affects our industry constantly and whatever else they want to talk about, all with the goal of informing and inspiring you.
The recording of our webcast with Glenn (which took place on March 10th, 2010) is linked below, and we’ll set up RSS, Zune and iTunes feeds shortly.
The comic below, created by John Campbell, is a snarky but amusing deconstruction of Star Trek: The Next Generation:
I always found it funny that the “empathic” character Deanna Troi had the power to sense plainly obvious emotions and painful that they had to explain bits of human behaviour that one should’ve picked up by the end of adolescence. That being said, much of the show’s audience was teenage boys, and teens often figure out the world through stories, so why not explain that stuff? And as someone much wiser than me once said, science fiction is a sandwich: once you’ve gotten past the bread of aliens and future tech and the thin slices of plot meat, it’s all about the thick moral mayo.
The last panels in this comic had me laughing out loud, especially since I imagined the line as delivered by actor (and dater-of-inapproriately-young-women, the lucky bastard) Patrick Stewart himself, using that William. Shatner. Mode. Of. Delivery.
In case it’s not apparent who the comic figures are, here’s a quick guide…
“Debt” is a term so unpleasant that we don’t even pronounce one of its letters.Technical debt is equally unpleasant in its own way; like the financial kind of debt, it holds you back and haunts you. It’s the hard-to-change, error-prone parts of your code that bog down your project and its maintenance. Ward Cunningham – the guy behind the wiki and contributor to the concept of Extreme Programming – coined this clever metaphor, and it’s the topic of Thursday’s Ignite Your Coding.
Walking us through the topic of technical debt is our guest David Laribee, who’s going to be our technical debt counselor, providing advice on how to pay back technical debt. He coaches the product development team at VersionOne, has over a dozen years’ experience building enterprise software and coaching lean/agile teams in many industries. He’s also a co-organizer of the ALT.NET movement, and was a Microsoft Architecture MVP for 2007 and 2008.
In case you were wondering what Ignite Your Coding is all about: It’s all about helping you, the software developer, find ways to stay on top of the technological, economic and social changes that affect you and your work every day. We got our hands on some of the biggest thinkers and doers in our field and asked them if they’d like to chat about the industry, how they got started, where they see the opportunities are, how they deal with change and how to be generally awesome. We got some big names from the Microsoft/.NET world, but we also went farther afield and got some people from beyond that world as well, because a different perspective is often helpful.
If You Want to Catch the Live Webcast on Thursday and/or Ask David Questions…
"We kinda changed the water that we drink, in the sense that all through the design community within the company we talk, and we have a common goal in terms of trying to bring a certain change of sensibility," he said.
"For me it’s not even about the phone, but what’s interesting is that it’s the first product in the company with critical mass that’s embraced this … it will have an impact on other parts of the company."
If (or better still, when) you start building Windows Phone applications – or hey, any kind of application — I hope that you’ll follow the spirit of “Metro” (the codename for the design philosophy behind Windows Phone 7) and keep it in mind. Yes, it’s absolutely important to know the Silverlight and XNA APIs as well as how to read the touch sensors, GPS, accelerometers and so on, but it’s just as important to design your applications around the people who’ll use them. That means understanding your users, how they’ll use what you’re making, knowing how to give them what they need as quickly and unobtrusively as possible and delighting them. Yes, “a pretty interface” is included in all that – and there’s research to suggest that beautiful interfaces work better –but looks are merely part of the design equation.
Some Design Sessions from MIX10
Want some interesting lunchtime viewing on design? Look no farther than these two videos.
If you’re planning on getting into Windows Phone 7 design, you’re going to want to learn the “design language” – not a programming language, but the guiding principles and philosophies behind the new user experience – behind it. Here’s the MIX10 presentation on that topic, Designing Windows Phone 7 Series with Albert Shum, Michael Smuga and Chad Roberts:
Here’s a little something extra for those of you who like to think about design and user experience:
I whipped up this graphic, modelling it after a poster I remember seeing many years ago. I can’t remember what it was for – a museum, art gallery or exhibit, perhaps? – but I remember thinking that it was right on the money. If you remember the original poster and what it was for, please let me know, either via email or the comments!
I’ve heard a lot of people say that the need to have arguments in public and win popular support is an unintended consequence of social networking services. I think that things like Twitter and Facebook make it easier and that they vastly expand the reach of an argument, but that we’ve had that urge to have flamewars long before the internet.
Here’s a data point for my thesis: a placard from 1839 that wouldn’t seem out of place on any online debate, aside from the dated language.
For those of you not familiar with Azure, it’s Microsoft’s cloud computing platform made up of three parts:
Windows Azure, the operating system in the cloud where your applications run
SQL Azure, the database engine in the cloud where your data lives, and
AppFabric, which connects cloud, hosted and on-premises services together.
As for the Azure development patterns that fit common business scenarios, they are:
Transparence: Simply moving applications and data from servers to the cloud. The benefits are cost savings, not having to manage servers, cost-effective scaling and opportunities to prototype without having to invest in additional hardware and software.
Scale-in multi-tenancy: On-the-fly scaling by creating new Azure instances when demand increases. It’s hard to predict what demand for an online service will be; this “just in time” approach does an end run around having to make such forecasts and purchases based on them.
Burst compute: This is scaling based on known peak periods, such as the Christmas rush for retailers or the Superbowl for pizza delivery. A cloud-based system like Azure lets you acquire more server capacity during those known peak periods and release them once the peak period is over.
Elastic storage: This is data scaling – you can use Azure to extend your storage instead of purchasing more on-premises disk arrays.
Inter-organization communication: Using Azure to host an API to connect to your company’s services or data (which may live in Azure, on some hosted system or on-premises). It’s a good way to provide services to the outside world while keeping your infrastructure manageable.