I’ve been looking around all over for a way to configure multiple exchange accounts to work with Outlook 2010. The official word is that “Outlook 2010” isn’t supported by BPOS yet, and it’s left at that. One of the fortunate things about working for a company like InterKnowlogy is that we often have the liberty to experiment with and use non-standard or un-supported technology on a regular basis. Here’s the exact steps to setup Outlook 2010 on Windows 7.

Note that you will no longer be using the BPOS client to start outlook, and these instructions are for Outlook 2010 on Windows 7 only.

Server Information (Do this for each BPOS email account)

Login to Outlook Web Access.

Click on Options in the top right hand corner.

Click on About in the navigation bar on the left.

Find the entry for Mailbox server name and write it down or record it as you will be using it later.

Log out of Outlook Web Access.

Create an Outlook Profile

Make sure you have Outlook 2010 installed.

Open the Control Panel.

Click User Accounts

Click Mail.

In the window that pops up, click Show Profiles.

Click Add.

Enter a new name for the profile. i.e. Your email address

Click OK.

Click Manually configure server settings or additional server types.

Click Next.

Select Microsoft Exchange.

Click Next.

Enter the mailbox server name (that you wrote down or copied from the previous section) in the field Microsoft Exchange server.

Enter your full name in the field User Name.

Click More Settings.

If you are prompted with an error that the action cannot be completed, click OK.

We have a hierarchy of objects, a base Fruit class, an Apple class, which is a Fruit, and an Orange class, which is also a Fruit. In addition, we have a FruitBasket which has an enumerable of Fruit, and a Tree which I can "PickFruit()" from.

Now, lets say I want to have an instance of a fruit basket, however, I also want another one that deals with only Oranges (I don't want it to even be possible to put apples in the basket) so that I can make orange juice, apples just ruin a good glass of orange juice. I have two possibilities, I can create another fruit basket and ASSUME that I only put oranges in, or I create another classes that only allows oranges to be inserted in. Because I decide that I want the compiler to absolutely not allow apples in with the oranges, I now have to create a new class:

publicclass OrangeBasket

{

public Oranges[] Oranges { get; set; }

}

Or if I now want to have a basket that holds potatoes, I have to build another class:

publicclass PotatoBasket

{

public Potato[] Potatos { get; set; }

}

Right. Pattern. We are repeatedly creating virtually identical objects that simply contain other objects or that apply some sort of processing to those specific elements, all because we want the consumer (the person that is using this object) to be able to put an specifically typed object in and get a specifically typed object out, without having to cast it.

C# 2.0 - 3.5

With the release of C# 2.0 Microsoft introduced this concept of "generics" in programming. It allows programmers to create generalized algorithms that take and receive specific objects, store or process them, and return them, without knowing the creator of the object being worked on or knowing specific type. C# 2.0 also included a number of generic collections and interfaces that implemented these features, the most useful in my mind being the generic IEnumerable<T> interface. This now allows us to rewrite our basket class like follows:

publicclass Basket<T>

{

IEnumerable<T> Contents{ get; set; }

}

Now, instead of having a PotatoBasket, a FruitBasket, and a OrangeBasket we can replace it like so while still using the same class:

The reason has to do with the relationships of types, covariance / contra-variance / invariance (Erick Lipperts post on the difference between covariance and assignment compatibility is a much better source for it's relation with mathematics and type hierarchies). With versions prior to 4.0 the C# compiler does NOT allow generics of one type to be assigned to generics of another type. Thus, an IEnumerable<Apple> cannot be assigned to a variable of IEnumerable<Fruit>. But lets say we were allowed to do this, why would it be a problem? Lets say I have an IList<Fruit> and an IList<Apple>; it seems to make perfect sense that I could so the following assignment:

This assignment would actually be plausable for IEnumerable<T> because IEnumerable<T> is immutable, it can not change, there's no way to "Insert" a new element into an IEnumerable. However, with an IList<T> it defines an Add(T item) method. An IList can be altered. In the previous example, if I were to take fruitList and look at the Add method in intellisense, it would show that I can insert any object that is a fruit into the add method of the fruitList, however, fruitlist isn't technically a list of fruits anymore given this senario, its a pointer to a List<Apple>. So in this flawed example, I could now call fruitList.Add(new Orange()); which would now be a runtime error because I can't insert an Orange into a List<Apple>. Bad. (In C# however, there is an edge case where this sort of error can occur with arrays. For instance, if you have a object[] objarray = new string[10]; you can then assign a fruit to one of the slots and cause a runtime exception. For more detail on this, see Erick Lipperts post on Covariance and Contravariance in C# arrays) So we have two things that should be solved. We know that there are certain situations where IEnumerable<X> should be assignable to IEnumerable<T>, specifically when X is a subclass of T, but we also realize that something like IList<X> should not be assignable to a variable of IList<T>.

C# 4.0

Enter variance modifiers for generic types that have now been introduced in C# 4.0.

out and in.

First, these can only be applied to generic type parameters of interfaces and delegates, in can only be applied to generic parameters that are contra-variant or invariant valid, and out can only be applied to generic parameters that are co-variant or invariant valid.

Gulp.

First, invariance, contra-variance, and covariance. In terms of types, if I have T1 and T2, those types are Invariant if they are the same type. For instance, a Fruit and a Fruit are invariant, a Fruit and an Apple is not invariant even though a Fruit variable can hold an Apple object.

Co-variant is where the inheritance chains are kept, if I have T1 and T2, the projection of T1 to T2 is covariant if T2 is lower in the inheritance chain than T1. For instance, a Fruit to Apple is Co-variant because Apple is an instance of Fruit.

Contra-variant is where the inheritance chain is reversed, if I have T1 and T2, the projection of T1 to T2 is contra-variant if T2 is higher up the inheritance chain than T1. For instance, an Apple to Fruit is contra-variant because Apple is an instance of Fruit, the relationship is reversed, flipped.

So, it allows me to do the following in C# 4.0 with the new variant structure:

Remembering that out is co-variant because it can return the item or a subclass of that item, in this case PickApples() is returning an IEnumerable that is lower in the inheritance chain than the variable it's being assigned to (by lower, I mean that its a subclass, or sub-sub..n class of the other object)

To demonstrate a class with contra-variance with an in parameter, lets say we have an interface and classes like so:

IPieMaker<in T> where T : Fruit

{

Pie MakePie(IEnumerable<T> fruits);

}

ApplePieMaker : IPieMaker<Apple> {/* ... Some implementation ...*/}

FruitPieMaker : IPieMaker<Fruit> {/* ... Some implementation ...*/}

Now, because the input parameter is contra-variant, I can have a variable declaration like so:

Wait. Seem odd? Because T is not specifying what Pie we are making only what is put IN to make the pie, I can put apples into a FruitPieMaker. It’s contra-variant.

Try and wrap you head around that :)

Note: There's a good possibility that I didn't accurately describe the terms covariance and contra-variance in relation to mathematical projection and ordering, corrections and better descriptions are greatly appreciated.

As I’ve continued working on this game due to the large amount of support from friends and professors here at Neumont, I’ve decided to rename the game due to another game being released with the exact same name by Lucas Arts (http://www.lucasarts.com/games/fracture/) I’m still unsure if I’m going to end up releasing a full game or trying to sell it at all via steam or xbox live or not, there is still a huge amount of work that still needs to be done on the game to make it production worthy.

As far as progress on the game goes, there are now power-ups, better game logic, a simple menu system that was thrown in last minute, several difficulty levels, level regeneration, two new space backdrops, new weapons, and the list goes on… needless to say there has been a good chunk of additional work put into this game since the last time you saw it.

In addition, I was given the opportunity to demo this game to the new prospective students this last Friday after they went through a XNA demo and had a chance to try out what you could do with XNA. A lot of the students were very impressed, though I couldn’t decide if it was a ‘oooo this is a cool game, or oooo this cool that someone here did something like this’ kind of reaction. Guess we’ll see when I get the chance to create and release a demo version :)

However, my blog is not complete without giving you some sort of media to look at, so, here is a desktop background made from one of the space backdrops in the game at 1920×1200 for your viewing / using pleasure.

One of the cool things about Neumont is that every so often an assignment comes along that intrigues and causes you to become way more obsessed and involved in that assignment or project than you normally are. One of my current class is a course in XNA, which is Microsoft’s game and graphical development libraries for building games for both Windows, and for the Xbox ad Xbox 360, making it a powerful game development suite powered by .NET and C# (My current language of choice).

The first very, VERY beta version of the game was turned in late last night… or early this morning depending on what time zone you’re in :) The basic premise was to make a simple 2D game from the techniques learned in class, vectors, shapes, zdepth, and text… just basic simple stuff. We were required to have more than one character with a frame based animated sprite, multiple opponents, and collision of some sort or another and some overall game logic (game over, you win, you lose… you know the drill) For those of you that know me from before I came to Neumont one of the big things that originally drew me into computers was making and creating games, my parents were rather strict and against me playing many, if any games at all, but for the most part they didn’t mind me making and creating my own games. Being 14-15 at the time, trying to wrap your head about 3D matrix transformations, vector math, ridged body dynamics, path finding and node graph transversal… Wow, parents must have thought I was crazy (Thanks for all the books mom and dad! :)

So, for your perusing pleasure, I present Fracture, the result 3-4 day coding, lots of coffee, ~40 source files and classes and approximately 7000 lines of code and the Photoshop skillz of yours truly ;) It’s a side scrolling, completely 2D sprite based game (no 3D objects or cameras or anything at all). Your goal is simple, survive to the end of the level, don’t hit the white circles that come in and bounce around the screen or the bullets they shoot at you and destroy as many of those dang white circles as possible.

So.

If there is enough interest, *cough*splutter*comments*cough*, I may continue working on this and get it release ready. You know you want to play an awesome game of shooting little white circles that are trying to run themselves into you and shooting at the same time to achieve the never ending highest percent destroyed per level up to the highest level possible :)

But for real, leave a comment, tell me what you all think, how it looks, even how much it sucks and what could be better :)