Ozziemedes

Confessions of a Slacker (and OneNote Niftiness)

2010-01-27T09:26:00.002+10:30

A quick update on DPGA and this blog...

For those following this blog, I've been qujiet for a couple of weeks. One reason for this is that I've been setting up a SQL Server blog over at http://ozziemedessql.blogspot.com, where I'm doing a series of posts on querying metadata for fun and productivity. The other reason is that I have been working on building user story cards for the DPGA application.

As an aside, I've been building the DPGA story cards using Microsoft's OneNote application, which lends itself nicely to this kind of relatively ad hoc documentation. It's possible to create OneNote post templates containing preconfigured content (which I've done), so that each time you create a new note within a given section it is based on an existing note. The net result looks something like this:

Is it not nifty? I just click "New Page" and I get a clean pre-formatted template and can populate data directly into the table.

The DPGA app is fairly complex (lots of different TYPES of functionality), so building user stories isa relatively time consuming process. Anyone who wants to help out by building story cards is more than welcome to do so. Just leave a comment with an email address I can hit you back on and I'll set you up with access to the one-note repository on the DPGA project site. This is a great opportunity to get involved in the design of the tool.

Once I've got all the user stories worked out, I'll publish a "project backlog" (basically a list of user stories to be implemented) and will work through the priorities. Once that's done, I can start working with code!

Until then - Code Well and Code Often!

Note: Game Assistant Contributions

2010-01-07T15:04:00.001+10:30

Just so people are aware – I’ve created a project on CodePlex for this project, so people will be able to inspect the source code and discuss what I’ve done, how I’ve done it. I’m happy to accept that my code will not be brilliant quality at the start – this project is as much about teaching me to code as teaching others.

Also, if people want to help out on the project, I’m happy to accept other contributors. My only request is that you focus on the real objective of the project – i.e. learning about what’s possible in the .NET framework – and make sure that your code is commented properly. I’d also ask that you post blog entries on any modules submitted to the project, so both I and my readers can learn from what you’ve done.

Proposed Technologies for Game Assistant

2010-01-07T12:39:00.002+10:30

In my last post, I put together a feature list for my Gaming Assistant project. At this point I’m ready to propose a set of technologies that will be used to build my solution.

Technology Selection

I’m going to take a structured approach to the technology selection. There are five key technology choices I need to make, as follows:

Code Platform (choices: VB.NET, C#, other)
Visual Platform (choices: winforms, ASP.NET, WPF, Silverlight, DirectX)
Remoting Platform (choices: WCF, SOAP web services, TCP/IP Sockets)
MultiMedia Platform (choices: Live Services, DirectX, WPF MediaElement, SkypeAPI)
Structured Data Persistence & Distribution Platform (choices: XML files, SQL Server Compact Edition, SQL Server Express Edition)

Let’s tackle these one by one.

Code Platform

This is a personal choice only, not a criticism of any of the other options. I like the conciseness of C#. VB.NET might be a little “friendlier” to read, but I find myself having to read a lot more code to understand what’s going on in VB.NET than C#. I could possibly also look at alternative technologies with Common Language Runtime support (e.g. IronRuby, IronPython) but I’d be going back to square one, whereas with C# I at least have some idea about the syntax. So… C# it is.

Visual Platform

This is a much tougher choice. Most of the folks who will be using this program will also be geeky enough to have computer hardware capable of supporting all of the DirectX (and thus WPF and Silverlight) vector graphics features. So let’s walk through the pros and cons of each product.

Windows Forms

Pros	Cons
I have some experience writing simple windows forms	Windows forms is based on GDI+, not on DirectX
Windows forms does not require .NET Framework version 3.0 features, so backward compatibility may not be as hard to implement	This means the “design palette” is not as functional as with other visual platform options
WinForms offers a rich eventing model and provides full multithreading support	Windows Forms offers minimal support for vector graphics – particularly important for map rotation/zoom

ASP.NET Web Forms

Pros	Cons
I have plenty of reference material on ASP.NET	I have minimal experience working with ASP.NET
Using ASP.NET I could build something along the lines of a Web 2.0 “mashup”	Managing session state and asynchronous events can be painful
ASP.NET supports the full functionality of the .NET framework in server-side code-behind	ASP.NET requires extra effort around database security
	ASP.NET does not support vector graphics to the same degree as other options
	ASP.NET requires a server
	For the app I want to build, ASP.NET will have to be mixed with AJAX or JQuery controls, requiring an additional language learning curve

Windows Presentation Foundation

Pros	Cons
I have done a 3 day course on WPF	I have less direct experience working with WPF than WinForms
WPF supports vector graphics and DirectX
WPF uses XAML for form design – and as such is more declarative than WinForms – this simplifies coding slightly
WPF supports the full functionality of the .NET framework in code-behind
WPF does not require Javascript, AJAX or JQuery knowledge

Silverlight

Pros	Cons
Silverlight is heavily based on WPF	I have no direct experience working with Silverlight
Silverlight supports vector graphics and DirectX	Silverlight supports only a subset of the full functionality of the .NET framework in code-behind
Silverlight uses XAML for form design – and as such is more declarative than WinForms – this simplifies coding slightly	Silverlight is a web-control set, and as such, runs in a sandbox that will make remoting awkward at best.
Silverlight will work on a Mac.

Native Direct-X

Pros	Cons
DirectX provides high performance access to graphics hardware	I have no real experience working with DirectX
DirectX natively supports most of the things we want to do	DirectX is a complex API for developers who haven’t written games before
DirectX offers the opportunity to design a very rich interface	DirectX is very resource dependent – this could be a strength if I were artistically inclined, but I’m not, so having to create shader textures, rich bitmaps and so forth… too hard
DirectX is a stable set of APIs – it has been around since the mid-90s.
DirectX provides feature-rich audio capabilities, including DirectVoice – it’s audio conferencing API
Because DirectX is a set of modular APIs, it can be included into other visual platforms if required

After working through the list above, I’ve decided that WPF provides the best mix of functionality and access to other tools.

Remoting Platform

What do I mean by “Remoting”? Remoting is the glue that connects one instance of the application to another over the network, allowing sharing of information, feeds (e.g. Chat) and streams (video/voice). Out of the APIs listed above, it’s probably going to be easiest to run with Windows Communication Foundation (WCF), as it serves as a wrapper/abstraction layer for the other two options (TCP/IP Sockets and Web Services).

Multimedia Platform

I think I’m going to park this one for now while I do more research. There’s a lot of options out there (windows native and third party APIs) and I’d like to spend some time evaluating them more thoroughly before I make a choice. Once I get a bit further into the project, I’ll post my reviews online here.

Structured Data Persistence & Distribution Platform

Having spent over a decade as a SQL Server DBA/Developer, the product family of choice for me is going to be SQL Server of some sort. XML is an option, but it’s stored as plain-text and therefore prone to hacking. XML is also a bastard to query – XPath is a pain to use, and XQuery is not supported natively in all situations.

The choice to me seems to be between SQL Server Compact Edition (runs in-process with the application, no support for stored procedures, but very small footprint) or SQL Server Express Edition (provides more features, but also requires a fairly large installation footprint).

For the purposes of this application, I’m going to favour deployment footprint as the determinant of which edition to use. As such, SQL Server Compact Edition will be used. I will use Sync Services to make sure that players can inspect and annotate their character sheets offline, and have their changes synchronized back to the GM once they connect.

I know I promised that I’d add some scheduling to this post, but the platform selection discussions got a bit bigger than I intended.

I’ve had a deeper think about scheduling and decided that I’m also going to manage the activities on this project using a 1-man “agile” approach. This means that the next post will lay out the process of turning the high level features from the previous post into a set of user stories to be implemented. I will rate the user stories by priority and effort, and seek to build a schedule from that.

Note that this is an out-of-hours project for me, so I’m only going to commit 10-15 hours a week to working on it, where the 10 is the actual coding/design effort, and the 0-5 extra is the blogging time. I may spend more time on development or blogging occasionally, but this project should be considered to be a long-term initiative.

MIA but now returned…

2010-01-06T12:12:00.001+10:30

Wow… what a year 2009 turned out to be. I ended up doing a lot of travel – especially during the latter half of the year, and ended up working long hours on most of the projects I was assigned to last year. I didn’t have the spare energy to do the personal learning or the blog posting required to be able to achieve the objectives of this weblog, but I’m back on deck now – refocused, rejuvenated and ready to start chasing Eureka moments again in 2010.

So… to keep myself honest, I’m going to post somewhat of a schedule here that I’ll try my best to meet. I’m also going to put my dev work in the context of a real-world project that will make use of .NET 3.0 and 3.5 technologies as a way to task orientate my learning, and the information I’ll be sharing on this blog.

So – let’s get started then!

The App

The project I’m going to be working with is a dice-and-paper role-playing game assistant. I’m an old school gamer (in the pre-PC gaming sense) who has some friends interstate who are keen to do some dice-and-paper gaming, so I want to build an application that can facilitate a distribute gaming session, where participants are in different cities, or perhaps even different countries! For now, I’m going to focus on Dungeons and Dragons Ed 3.5, as it’s relatively well-known, and still widely enjoyed. However, once the initial cut is out, I may look at using some extensibility tools to see if I can make the game system “pluggable” and look at writing some plug-ins for the White Wolf “World of Darkness” game system, and perhaps look into wiring up Cyberpunk 2020 and Shadow Run.

Requirements

Video & Voice

The first thing I want the tool to do is display multiple web-cam feeds and play multiple voice streams. I also want to be able to have the tool enable private conversations between the Game Master (GM – aka Dungeon Master) and individual players.

Text Messaging

The next thing I need is the ability for the GM to send text messages to individual players, and be able to see a feed of text messages being sent between the other players.

Roll, baby, Roll!

Another feature I need to implement is a centralized dice rolling system. In a distributed gaming environment, relying on players to be honest with dice rolls can – well… let’s call it an exercise in optimism. So a centralized dice manager is critical. The dice roller needs to have the ability for all of the GM’s rolls to be made private. The GM also needs to be able to make certain player rolls private between the GM and the chosen player.

What a character…

Another core feature is character sheet tracking. Character stats, abilities, experience points, To-Hit and Saving throw targets, Inventory, Banked Inventory and personal character notes all need to be tracked. We will store some of this information in SQL Server database tables. The database will also store relevant tables used for resolving combat and non-combat character situations. I will also need to build a forms-based GUI for displaying and editing information in the character sheets. The GM needs edit-level access to all character sheets, and the players need to be able to edit certain fields.

A fast game is a good game…

A “nice to have” feature would be to include an sand-timer that the GM can trigger to force players to come to a quick decision. This is particularly useful in combat scenarios where you don’t want players “meta-gaming” too much – i.e. haggling over who is going to hit the dragon with swords, where the archer is going to stand, what spell the magic user should be casting, or who the cleric should be healing first. An alarm that plays in the audio channel of all players when the sand-timer empties should get the message across.

Combat Assistant

Another “nice to have” will be the inclusion of a combat ticker that can help the GM manage initiative rolls, character/enemy action sequencing and resolve the results of dice rolls. Ideally, this would pop up in a separate window and provide support for various character choices such as subduing an enemy, charging, retreating, performing a defensive disengagement or calling an aimed strike.

Maps, maps and more maps!

Once again, on the “nice to have” list will be a map management tool, that allows the GM to:

“Automagically” generate dungeon and building maps (this actually requires some quite complex rules, which is why this feature is a nice to have)
Upload maps created by the GM in Visio or JPEG format.
Display currently visible map segments to players
Manage the “Fog of War” based on player lines of sight.

In-Game Economics and Politics

The final “nice to have” feature (and probably the most difficult to implement) is tracking of in-game economics and politics. For example:

If a band of adventurers clears all the goblins out of a dungeon, who moves in later? What impact does this have on human, demi-human and humanoid populations in the area? Who are the movers and shakers in the region?
If the player characters killed the goblin smith who was working on a doomsday weapon for a major political player, can they find out who did it? And what form will their retribution take?
What about the slightly higher level scenario of a dark army levelling most of the towns in a given region and putting their crops to the torch? What are the impacts of population change and resource changes?
If the players drain a major shrine of its healing power to raise one of their fallen comrades from the dead, will this anger the locals?
Given the typically feudal milieu that many role-playing games are set in, what sorts of problems might our characters set off by rising above their station, or mingling with lower castes than their own.

A good GM will typically define a set of “factions” with whom adventurers can raise or lower their reputations. A reputation tracker will be an important part of this module, but the GM should also be able to do some basic price modelling based on the demand and supply of resources, keeping in mind that humanoid races may participate in black-market economies, and that monsters can have an impact on the local demand and supply of goods (e.g. the undead roaming the marsh-lands, impacting the supply of peat to locals, or the bandits paying for their supplies with fools gold). These impacts can probably be categorized as geographic, systemic, magic or malefic to help make the modelling easier.

Well… that’s a pretty fair volume of text for a single blog post. I’ll sign off for now, but in the next post I’ll discuss the technologies I intend to use for the Game Assistant, and start building a schedule for follow-up posts.

Moving from GedZone on Live Spaces

2009-05-10T05:10:00.002+09:30

This is the first in what I hope will be a decent number of blogs on Blogger. I actually started this blog on GedZone but I'm moving content over here as I'm disappointed in the Live-Spaces blogging engine's capabilities to support extensibility and RSS aggregation. I also have a blog over on Xanga.

So… firstly, a few things about me.

I’m an information technology professional who works for a large IT outsourcer. I’ve been somewhat rudderless there for about two years, trapped between infrastructure software support and software architecture (particularly in the SQL Server area), and catching just about everything Microsoft related that has fallen through the cracks, but largely twiddling my thumbs waiting for work to come along. One specific area in which I’ve spent a lot of hours is in tools support for development with the .NET platform. I can’t say I’ve had a huge amount of time to spend using those tools yet, but I’ve written a couple of hundred pages of documentation for support and development teams on tools such as SQLNexus, Microsoft’s RML utilities for SQL Server and their Visual Studio Team System Database Edition tools that ship with VSTS 2008.

My employer is currently undergoing some interesting organizational changes as a result of a merger between it and a competitor. One of the things that is happening is that I’m moving across into the Microsoft Solutions Practice, in which my role will incorporate elements of a number of more formally defined roles – solution designs using Microsoft’s various application servers will certainly be a big part of my job, but I will also be responsible (along with my peers) for defining training paths, product capability maps, tools evangelism and standards evangelism. It looks pretty interesting, but I’m having to boost my skills both up into the software architecture space, and sideways into the sales support and software development areas. Just to round all this out, I’ve also decided to work towards raising my profile in the Microsoft developer community, and the blogging on this site will be the first step.

I’ve just got back from two weeks touring around the south west of Western Australia. The trip was a lot of fun (despite having cataclysmic elements such as tipping the car onto its right side
while driving a very loose pebbly dirt road near Pemberton and getting stuck in Manjimup for 4 days). From a .NET learning perspective it was also quite productive! The great thing about driving around on my own is that I had nights to myself, and spent several evenings cutting C# code for some demos which you’ll start seeing up here over the coming weeks.

In the demos, I went back to my “CompSci 101” training and started out with a “Hello World” app. I then built that out with some user I/O, starting out with a static class for tracking the time between console events, and an instantiable class with private properties for file logging. I then reused the classes from my console app in a WinForms version of the Hello World demo. I’ve also started working on a “Demo 2” series that will focus more on inheritance, polymorphism and other OO features such as indexers, serialization and code attributes. I’m also taking pains to introduce a few .NET framework classes in each demo, so the output won’t just be “Here’s the C# language…” – it will be “Here’s the .NET Framework” as well.

Over coming months I’ll be gearing up to actually video-casting some of this material, and preparing live presentations for user groups on more advanced topics. The products that will probably get most input from me in the new role at work will be BizTalk, SharePoint and Dynamics CRM, so expect to see more about these products. I will also be looking to stand up the infrastructure required to record some demos using these tools, and will start posting that material once I’m done exploring the .NET framework.

Well… that’s it for now. Code often… Code well!!!

An introduction to Microsoft .NET and Object Oriented Programming (OOP)

2009-05-09T14:33:00.004+09:30

First proper techy post! :)

The purpose of this series of blog-post is going to be as follows:

To give beginners a few insights into how to program software using .NET programming languages (especially C#) and the .NET framework.
To help people understand why object orientated programming (OOP) is a powerful approach to software development.
To help people understand how OOP is supported by the .NET framework and the languages hich run inside the .NET CLR.
To provide some context about the run-time context of .NET applications, software architecture and design patterns and principles.
Some interesting coding scenarios and challenges.

To help me wrap my own head around the topics I'm going to blog about. Like they say - there's no better way to learn than to teach, right?

What this blog series will not deliver:

Comprehensive coverage of the entire .NET framework - sorry, but I don't want to still be blogging about IT on my 300th birthday.
DEEP coverage of object orientated programming practices... I'll try to provide useful examples, but I'm not going to go into the computer science behind every design pattern I introduce.
Authoritative advice for people who are already experienced software engineers. (There's already millions of sites out there for you folks!)
Guaranteed 100% rock solid "best practices" - I'm going to try to ensure that some of my practices will be at least "okay" and that others might even border on "good", but my advice is simply my advice... I'm not aiming to lay down "The Truth" in any singular, absolute or even expert way.

Some other stuff this blog series will contain now and then...

Audio discussions of various high level principles.
Video demonstrations of the principles outlined in the blog, including code walkthroughs and discussions of some of the design decisions behind the code.
Interviews from other members of the developer community - potentially including conference and/or user group demos and speeches.
Source code demonstrating the points I'm outlining in the blog.
Reviews of .NET programming books, training and other .NET resources (e.g. starter kits, CodePlex projects, tools & utilities)
References to good design practices for other platforms (e.g. SQL Server, BizTalk, WCF, etc)

So - that's the preliminaries done with. Now on to the meat of the matter!

Many people may hear a developer talk about the .NET framework and will tell them "Oh - that's all about web services, right?" If they repeat that question to a Microsoft marketing drone, they'll get applause! But for those of us working with software on a daily basis, the .NET framework is basically an abstraction layer that sits over the top of an operating system (Windows for those of you not using Mono or tinkering with the project formerly known as Rotor - more about those later!).

The .NET Framework provides a centralized set of visual controls, class libraries, object factories and more that allow developers to write applications without having to learn C++, COM and the Windows API - all of which are very difficult to work with, and prone to catastrophic errors when poor practices are used.
The .NET framework is extensible (many of the classes are not sealed, so are freely inheritable - especially many of the visual controls - great for custom control developers!) and probably one of the best documented software frameworks I've ever seen.
The .NET framework can be used to develop "ASP.NET" web applications (requiring Microsoft's IIS hosting platform), which render a mixture of server-side controls (i.e. their logic and rendering is all managed directly by ASP.NET) and native HTML controls. Server-side controls are rendered as native HTML in the stream sent to the client browser.
The .NET framework can be used to build standards compliant web services. Web services allow systems on different platforms to interoperate cleanly in a standards-based manner over the internet. If you've made a credit card payment online, odds are that the software that accepted the submission of your transaction and sent back an approval notice was a web service! Web services can be used for all sorts of things - ranging from social networking to weather reports, from stock market quotes to media streaming. The key point to understand here is that a web service won't display itself in a browser, but still uses HTTP (or HTTPS) as its communication protocol.
The .NET framework can be used to develop powerful, scalable enterprise applications that integrate cleanly not only with other Microsoft applications platform services (e.g. BizTalk, SQL Server, Exchange, SharePoint), but with other more generic toolsets as well (e.g. Websphere MQ, Oracle databases, Tibco's Enterprise Messaging Service, and so on).
The .NET framework can also be used to build, manage, automate and deploy rich Windows applications, including those using the new "Windows Presentation Foundation" interface controls introduced in Windows Vista and with the Microsoft Office business productivity suite.
The .NET compact framework (once described by Rory Blyth of .NET Rocks fame as "A wrapper around the System.NotImplementedException object") allows the development of mobile web applications, rich client mobile applications and even mobile games.
Finally, the .NET framework can be used to develop console applications and "lights out" services that run happily on Windows without the need for fancy GUIs.

What does all this mean to me? The power to get the job done, wherever the data, wherever the user.

Digging a little deeper... Microsoft's .NET platform has been designed explicitly to support object orientated programming and design (OOPD). COM and the Win32 API provided a rich framework of objects which could be manipulated using external code, but the pointer arithmetic was dangerous and you had to get that right with your base objects. If you inherited from flaky base objects, all of your inherited code would be at risk. This is one of the things that led to a lot of vulnerabilities in Microsoft's flagship Windows operating system over the late 90s and early years of the current decade. C++ is very powerful, but it also requires an INSANE degree of attention to detail.

So... what is all this object orientation stuff? How does it work? What does it do for me? The key points are as follows:

OOP allows developers to model real life THINGS based on the things they have in common. For example, mammals tend to have 4 limbs, 2 eyes - usually forward facing, two ears - typically capable of rendering hearing in a stereoscopic field, fur/hair/bristles, and teats to suckle their young on milk. However, it's possible to refine the definition of Mammal by breaking down additional definitions by genus, species, etc... in which the more specific refined models either override the base definition, or embellish it.
As an example of this form of embellishment, consider the felidae family, which contains most of the cats. The felidae family can be categorized into subfamilies such as pantherinae ("big cats" such as tigers, leopards, panthers and lions), acinonychinae (cheetahs), felinae (typically smaller cats) - each of which has distinguishing characteristics and behaviours.
The pantherinae are much larger and heavier than the other felidae subfamilies, for example. The cheetah has non-retractable claws and a super-flexible spinal column. Where the big cats are all capable of roaring, the cheetah "yips" and yowls. Cheetahs have longer tails than their cousins, but shorter body-length to leg-length ratios.
In the context of obejct orientated programming, a characteristic of a "Type" of thing is called an attribute of that thing, and the type itself is called a "Class". So in our feline example, "Felidae" would be a class of cats, in which the features common to all cats would be included as attributes. These would include the number of legs (4), type, number and distribution of teeth, stereoscopic vision, pivoting ears, good night vision, meat diet, and so on. The features specific to a "descendent" class of "pantherinae" would include higher maximum weight and length attributes than the class "felinae", a different list of preferred prey, and so on.
Howerver, cats don't only have attributes - they also have behaviours. Cats can stalk, run, leap, climb, eat, poop, and so on. There may be attributes that are specific to the behaviours of a specific class of felidae (e.g. Cheetahs have a higher maximum speed when running than other cats) which can be encapsulated (I'll get back to encapsulation in another blog) in the definition of their behaviours. In OOP these descriptions of behaviours are known as methods. This is because a software program executes a series of steps in a systematic order to model/perform the behaviour concerned.
So now we have the idea of a class that has methods and attributes. The attributes are qualitative or quantitative descriptors of a type's characteristics. The methods are the type's behaviours. However, this is only a model right now. We haven't created a specific cheetah, lion or manx cat yet. When we talk about object orientated programming, the key objective is to perform operations on objects which can be described as specific instances of a class.
Consider the cat you may or not have had when you were growing up. Let's arbitrarily call this cat "Fluffy". Fluffy is an instance of the felinae class. As a member of the felinae class, it knows how to do all the usual catty things (yawn, stretch, eat, sleep, schmooze for food, throw cat-litter out of the box, stalk balls of wool, upset mother) and it probably has the usual characteristics of a typical house cat. In OOP we define instances of a class as objects, and we have now arrived at what OOP is named for.
If I want to write a program to estimate the calories Fluffy burns each day, I would start by creating an instance of the felinae object called "Fluffy". If I knew Fluffy's schedule well enough I could then execute each of the methods on the Fluffy object to obtain a total for the amount of calories burned. Of course, the methods would have to return a calorific figure (which in itself is a specific "type" of information) after invokation, and would probably need to provide the method with a "time" value (or parameter) defining the amount of time spent by fluffy on each activity.
The type returned by a method and the types and parameter names (which are really just placeholders) passed to a method comprise its signature. You shouldn't be able to pass a dollar amount to the time parameter of fluffy's AnnoyMother method - it doesn't make sense. Likewise, returning Fluffy's name after calling the Yawn method won't help me figure out whether I need to put him on a diet or not - as such, it would be an invalid return type.
Type safety is one of the big pluses in the .NET framework. This means it will make sure you are passing the right kinds of types in and out of methods and throw a warning message (exception) if you try to pass something that doesn't make sense.

Now that I've got you that far, I'm going to call it quits for the night. Next time I'll start off with a discussion of some additional OOP concepts (encapsulation, obfuscation, polymorphism, inheritance and operator overloading) and might throw in some C# code demos to illustrate each of these concepts. This has been a very high level discussion for those who've never really grokked what OOP is all about. I'll start moving through the concepts more quickly in future posts.

A quick teaser

2009-05-09T14:29:00.005+09:30

For those of you who are interested in the .NET platform but are already familiar with OOP principles, you can skip the next few blog entries. For those of you coming into coding pretty much cold (or perhaps from effectively scripting objects in VB, VBA or similar without any OOP context), you'll see some introductory terminology wheeled out over the coming week or two. In these entries I'll be introducing (from waaaaaaay up at 50,000 feet) the basic building blocks of object oriented programming:

The mission statement of object orientation
Simple vs Complex Types
Structs vs Classes vs Interfaces
An introduction to classes, properties, member variables and methods.
Static, Abstract and Virtual modifiers and their meanings
Object/variable scope - both declarative and implicit
Constructors and the "new" keyword
Destructors, IDispose and the finalize() method
Inheritance, Polymorphism and Operator Overloading

I'll be trying to deliver this material in a fairly succinct and accessible fashion, so the hard core OOP crowd should excuse me if I'm not 100% complete with the textbook definitions. My focus on this site is going to be on application, not theory. However, in a few weeks' time I will be talking about some more advanced OOP principles and patterns. Once again, the focus will be on application, not theory, but for people coming out of the infrastructure world like myself, they're useful concepts to grok. I'll definitely be including links to more advanced content as I go.

You might be wondering "Where's the C# and .NET coding at?" - well... understanding the terminology and concepts I'm going to spell out in the next week is going to make it easier for you to understand material delivered further in subsequent entries. For example, learning how to declare a property in a C# class makes much more sense when you know what a property and a class are, and why you'd bother to build classes rather than simply writing procedural code. As I get into more advanced patterns and practices, I'll probably revisit some of the earlier examples and refactor them with the more advanced principles in mind.

I'm hoping to be able to write 1-2 blog entries a day for the next week, so check back regularly!

In the meantime: Code well, code often!