Wednesday, 6 March 2013

Flashback - Microsoft TechEd Europe 2010

I have been feeling quite retrospective at the moment. Upon hearing that 2 of our staff members will be heading to TechEd overseas this year, it brought back all sort of memories for me of my own experiences at TechEd Europe in 2010.

My work has been a big supporter of our local TechEd over the last 10 years, and I have been lucky enough to go to TechEd Australia on 5 occasions. I have always enjoyed a week away from my desk, deeply diving into the latest and greatest technologies that Microsoft has to offer. When I was given the opportunity to visit TechEd Europe in 2010, I jumped at the chance!

Overall the European version is order of magnitude bigger than our TechEd. There are many thousand more people, there are significantly more session and it is a whole day longer. One of the most wonderful aspects of TechEd Europe was the challenge of being in a none English speaking city. I can tell you that my German is very weak to say the least. I can't begin to explain the massive difference between visiting Berlin for a conference as opposed to the Gold Coast.

While I was impressed by the quality of most speakers at TechEd Europe, I was glad to see that a number of the speakers I had seen before in Australia. It made me proud that our smaller event has clearly been pulling some of the best speakers from Microsoft in the last few years. Having said that the sheer quantity of information was the most impressive aspect of visiting TechEd Europe.

I would highly reccommend visiting TechEd Europe as an Australian. It was a wonderful place to learn about new technologies and interact with many different cultures. While I have travelled quite a lot in my young life, this trip to Europe (which just happened to have 5 weeks of holidaying around my visit to TechEd) was an absolute highlight of my life thus far.

Tuesday, 26 February 2013

MonoTouch Review

Over the last couple of months I've had the pleasure of delving into the iOS world through the wonderful technology called MonoTouch. For those that are unaware MonoTouch is an environment that allows you to write C# .NET code which is compiled down to machine code for use on an iOS device like and iPhone or iPad.

This is great, if only because it means that I don't need to learn objective C. Not that I have anything against it, it's just easier to write in one language at a time. It's also great for the ability to share code between solutions.

The MonoTouch framework is available for use through the MonoDevelop environment exclusively on MacOS. They create solutions which can be hacked to be opened in Visual Studio (but with not a lot of use, since you don't have the emulator). The MonoDevelop application interactes with the XCode application in two key was, using their Interface Builder to create UI and hooking their emulators for running and debugging. You will also interact with XCode when setting up the Certification Profiles for Ad-hoc deployment or Distribution deployment.

Overall the MonoDevelop IDE is relatively clean. It is not Visual Studio but you get a number of the good features. Similar code highlighting, different default code formatting. The windows to layout are somewhat similar Solution Explorer, tabbed Code Editors, Application Output, Error Lists, etc. The highlighting of compliation error bugged me at first, but I slowly got used to it.

The only real drawbacks for me have been the occasional confusion when coming back from XCode emulation and wanting to go into Interface Builder. I often found that it was slow to stop the project and restart running, and there was general a down period before you could start running again. Our main drawback was there was no support out of the box for our Source Code control system Vault. Similar problems would exists with TFS I would assume.

How easy is it for a typical C# developer to start using? If you are given access to a Mac, it would be reasonable to expect half a day to a day setting up and writing Hello World apps. I would then expect that you could turn out a reasonable app that demonstrates various capabilities within a week. It is worth pointing out that you can be running emulated apps inside MonoDevelop using the unlicenced trial version. You only need to pay for a licence when you actually want to deploy to a device. You will also have to pay for being in the Apple Developer Program at this point as well, but both of these costs are relatively low. Our biggest cost was the hardware. If you have access to a Mac and you are a C# Developer, you should be giving it a try! Or maybe waiting to see what Xamarin 2.0 is like, and giving it a try instead!

Xamarin 2.0

A really exciting announcement has been made over the past couple of days regarding targetting iOS using the Visual Studio environment for the very first time. The ability to do this comes from a company called Xamarin which is responsible for the current suite of tools for targetting iOS/Android/Mac OS using C# called MonoDevelop. This develoment environment has allowed iOS development using the MonoTouch framework, but it has only supported directly under Mac OS itself. This new initiative called Xamarin 2.0 promises to give you the choice of using their new cross platoform Xamarin Studio IDE or Visual Studio to write Apps for the first time.

Through my work I have actually had the pleasure of using MonoDevelop quite extensively over the last 6 months. Overall I've found it to be an excellent IDE. While there are the occasional piece of strange behaviour, the integration with XCode for UI development is as good as I could have hoped for. It definitely feels like you are writing natural C#, just using the MonoTouch libraries to sort out pesky things like UI. I might even take some time to write up a post about my experience with MonoDevelop in the next few weeks, but for now let me just say it has been a very positive experience.

Having said all that, would I rather be in Visual Studio? Of course I would be. Firstly you get the familar standard tools that you would be using for C# development. Secondly, you get easy access to the standard source control systems like TFS or in our case Vault (Note: Vault has a beta MacOS Client application ironically written in MonoDevelop, but I'll post about that later as well).

I am really looking forward to the demonstration of how this all works, particularly how Xamarin 2.0 will interface with XCode for UI construction, how you will target the emulator, and how you will build and sign of IPA files from Visual Studio. From what I have read, it will involve Visual Studio connecting to a MacOS machine running the iOS SDK using remote control. I can't wait to see this with my own eyes and try it out!. There will be a live introduction on March 5th when we get our first real glimpse of this exciting product!

Wednesday, 20 February 2013

Sony Playstation 4

Sony has just launched the Playstation 4 in a huge press conference in New York. It is always a big deal when Sony launches a new product. If you've been watching the live streams of the announcement you would have seen a lot of cool game demonstrations and incredible graphics. However that really isn't a surprise. There should be a lot of big titles queued for a major console. The graphics should be better.

What is the new technology that the PS4 will bring to the table. We are talking about Sony so of course there is more grunt. An X86 processor, 8 GB of GDDR5 memory and local harddrive for storage. What other features are included? There is a new dual shock controller with a front touch button, a light for 3D tracking and a new share button. Connection with a "Playstation Cloud" service which will be the source for previous Playstation titles. There is no native support for previous titles. Local streaming to PS Vita to allow remote playing instantly (sounds familiar doesn't it, Wii U). The PS Move survives (sounds familiar Wii).

What was the rest of the press conference about? Explosions, beautiful artistic games, new titles. Media Molecule had an awesome content design demonstration. Final Fantasy from Capcom. Blizzard is bringing Diablo 3 to PS4. Lots of big news, but mostly news about content. Great games sure, but from my point of view nothing revolutionary from Sony themselves. We didn't see the console. We didn't hear price. The best we got is a vague mention of a release period "Holiday 2013".

At least we will know more by the end of the year.

Monday, 11 February 2013

Converting VB to C#: Part 5 - Evil VB Function Returns

Most of the things that I've discussed in these posts have been good VB code gone bad because of the change of language to C#. This example is a little different, this is bad VB code gone very bad, and it's not C#'s fault at all. Let's kick this one off with a flashback...

Long before VB.NET there was a family of languages known simply as Visual Basic. Starting with version VB1 in 1991 through to VB6 in 1998, these languages were the precursor to VB.NET. Believe it or not, VB6 was the language that I first started working on in my current position (Out of interest, it took us longer to transition from VB6 to VB.NET than it did to go from VB.NET to C#.NET even with a bigger codebase).

VB6 was a good language (but not a great one). It was missing a number of features that modern languages contain, one of those being the return keyword for functions. So, how did you return values in a VB6 function? Well, simply by using the function name as if it was a variable of the type that you would be returning. If you didn't cringe just then, you shouldn't consider yourself a programmer.

Believe it or not, this wacky syntax remains legal to this day in VB.NET! And it was precisely this that caused us one very bad error when we moved to C#.

So let's look at some bad VB:

Private Function GetFilename() As String

    GetFilename = Path.GetFullPath(Path.Combine(_folder, _fileName))
    If Not GetFilename.StartsWith(_folder) Then
        Throw New InvalidOperationException("DEATH")
    End If
    ' Create directory
    Dim directoryName As String = Path.GetDirectoryName(GetFilename)
    Directory.CreateDirectory(directoryName)

End Function

So how do you convert this to C#? Well you create a temporary variable, use it and then return it when you're done. That's easy, what could go wrong?

This is the right C# code:

private string GetFilename()
{
    string tempGetFilename = null;
    tempGetFilename = Path.GetFullPath(Path.Combine(_folder, _filename));
    if (!(tempGetFilename .StartsWith(_folder)))
    {
        throw new InvalidOperationException("DEATH");
     }
     // Create directory
     string directoryName = Path.GetDirectoryName(tempGetFilename);
     Directory.CreateDirectory(directoryName);

     return tempGetFilename;
}

This is the wrong C# code:

private string GetFilename()
{
     string tempGetFilename = null;
     tempGetFilename = Path.GetFullPath(Path.Combine(_folder, _filename));
     if (!(tempGetFilename .StartsWith(_folder)))
     {
         throw new InvalidOperationException("DEATH");
     }
     // Create directory
     string directoryName = Path.GetDirectoryName(GetFilename());
     Directory.CreateDirectory(directoryName);

     return tempGetFilename;
}

Can you spot the difference? By missing one tiny little place where we should have changed GetFilename() into tempGetFilename, we created infinite recursion! Safe to say, that's bad news. Code compiles, works fine up until you hit that line and then BANG! Stack Overflow. The worst kind of death!

The lesson here is simple. If the VB code wasn't being evil in the first place, we would never have gotten into this mess.

Sunday, 10 February 2013

Converting VB into C#: Part 4 - With Statements

I can hear C# developers already, "What the heck is a With statement?". In VB you can save yourself a bit of time writing the variable name of an object if you are going to be using it repetitively. You can get similar behaviour from a C# object intializer statement, so long as you are intializing at the time you want to set all those properties, but let's look at the more general case.

It's not hard to replace With statements. In VB:
With myObject
    .Property1 = 1
    .Property2 = 3
    .Property3 = .Property2
    .Update()
End With

In C# becomes:
myObject.Property1 = 1;
myObject.Property2 = 3;
myObject.Property3 = myObject.Property2;
myObject.Update();

Easy right? Well there is a subtle difference between these two blocks of code. A With statement in VB provides scope. You can imagine doing all sorts of evil, declaring temporary variables, whatever you like inside a With in VB, which is suddenly exposed in C#. Thankfully most of these will cause compile errors before you get started.

It should also be noted that a number the good C# conversion tools replace a With statement with taking a temporary variable with your object. As you can imagine this can cause even bigger issues particularly when objects are being passed to subroutines from inside a With block of itself as a variable.



 

Wednesday, 6 February 2013

Converting VB into C#: Part 2 - Chars

Part 2 of my tricks that we faced porting a large codebase from VB to C#. This article is going to focus on Chars.

Chars are implemented very similarly in C# and VB, but there is a slight difference that can cause a lot of heartache. VB users are quite used to the idea that a Char acts just like a little string, which makes it a little more complicated to get out the integer value of the char when you need it. In C# a char is more real, and as such you can simply unbox a char and get the integer value. After all, thats what it is.

How could that go wrong? Well how about we create a comma separated text file using simple string concatination to build our lines. We'll cheat and write to the console In VB:

Dim comma As Char = ","c
Console.WriteLine("Values: " & 14 & comma & 15 & comma & 16)
Console.WriteLine(17 & comma & 18 & comma & 19)

Let's do the obvious conversion to C#
char comma = ',';
Console.WriteLine("Values: " + 14 + comma + 15 + comma + 16);
Console.WriteLine(17 + comma + 18+ comma + 19); 

That seems fine right?

In VB the output is:

Values: 14,15,16
17,18,19
In C# the output is:
Values: 14,15,16
142

Wait... 142? What is going on here?

In the move to C#, the concatenation operator has moved from & to + which is fine except that it creates operator confusion with addition. Instead of concatinating the values in C# the second line is adding the integer value of the char (in this case 44) to the other integer values, to get the value 142. In most cases a compile error because of the type, it causes real problems when you are passing to routines that have overloads that accept integers and strings. 

So remember: friends don't let friends concatenate chars when attempting to create strings for methods that have overloads!