Friday, October 31, 2008

Ponoko is a pretty unique concept - an online shop for individualised goods, where you search a market place or upload designs to have something manufactured just for you.

It's pretty cool for geeks - you can create line art of where you want the laser to cut or etch, and they will cut your design from flat sheets of wood, acrylic or other materials. I have made a one-of-a-kind picture frame for my daughter, and toyed around with a bunch of interesting ideas that I haven't yet followed through with.

If you want a more free-style approach, you can even get them to cut based on your hand drawn sketch - all automatically (Photomake).

Anyway... the interesting news today is that they have broadened their set of materials to include bamboo, felt and plain old cardboard, which should lead to some more variety in the products people can make.

Materials gallery

Kirk

posted on Friday, October 31, 2008 8:23:04 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]

Now that's cool.

Miguel demoed Mono running on the IPhone at PDC. He wrote about it a few months ago.

I guess the video will wind it's way up here on Channel9.

image

Kirk

posted on Friday, October 31, 2008 1:25:35 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]

Reading about how dynamic is implemented in C# 4.0 over on Sam Ng's blog: Dynamic in C#

How did they implement the new dynamic 'keyword' in C# 4.0? Using the DLR, of course!

Very cool to see that the C# version of dynamic dispatch is implemented over the same mechanisms for call actions, dynamic objects and binders to generate expression trees, with some C# specifics in the binder to implement C#'s rules for dispatch etc.

It's interesting to see the flow-on effects of using a dynamic type in an expression and how the 'dynamism' then flows on to subsequent expressions or invocations involving the resulting object.

Quite a nice bit of work, and well explained by Sam. He's going to post more in the series, so worth subscribing to his blog.

Kirk

posted on Friday, October 31, 2008 12:06:10 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]
 Wednesday, October 29, 2008

The PDC session videos are up on Channel 9: Breakout sessions

They don't seem to have download links for the WMV's (or at least, not for me), so if you want to download the video files you've got to view the source of the page and copy the wmv url into your browser.

For example, Ander's C# talk is available at:

http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/TL16.wmv

Basically, replace TL16 in the above url for the session code to download other sessions.

Cheers,

Kirk

posted on Wednesday, October 29, 2008 9:38:50 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [2]
 Tuesday, October 28, 2008

As linked to by the C# Futures site, here are the four main groups of C# 4.0 proposed features:

Dynamic lookup

Dynamic lookup allows you to write method, operator and indexer calls, property and field accesses, and even object invocations which bypass the C# static type checking and instead gets resolved at runtime.

Named and optional parameters

Parameters in C# can now be specified as optional by providing a default value for them in a member declaration. When the member is invoked, optional arguments can be omitted. Furthermore, any argument can be passed by parameter name instead of position.

COM specific interop features

Dynamic lookup as well as named and optional parameters both help making programming against COM less painful than today. On top of that, however, we are adding a number of other small features that further improve the interop experience.

Variance

It used to be that an IEnumerable<string> wasn’t an IEnumerable<object>. Now it is – C# embraces type safe “co-and contravariance” and common BCL types are updated to take advantage of that.

Most of these features are similar in spirit to what was shown at the Lang.NET symposium, but with a few details worked out.

The Dynamic features are going to be great when dealing with objects from DLR languages or COM. Named parameters sounds kind-of nice, but not world-changing. Variance support when assigning collections is going to be very handy, so is probably my favourite of the four feature groups.

Read more at the C# Futures site.

Kirk

posted on Tuesday, October 28, 2008 2:41:46 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]

As promised, here's more information on what's happening on Guy Fawkes day in Wellington:

Fireworks

We've just heard some of the cool stuff coming out of the Professional Developers Conference, and we've got our spies deployed in the audience -- so come along to our special user group event next Wednesday in Wellington to hear all about it!

Print out the above PDF, or forward this post along to all of your workmates. It's going to be a great 2 hour session, and we'll have stuff to give away to a few lucky attendees.

At 7:30pm we're welcoming families and partners along for pizza and subway -- so if you're planning on catching the fireworks, this is a great way to have some food before the explosions begin.

RSVP to kirkj@paradise.net.nz to reserve your (and your families) place.

Kirk

posted on Tuesday, October 28, 2008 10:37:10 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]

Well it was like the calm before the storm this weekend, with just one early blog post with leaked information to whet my appetite.

Now we're hearing all about Azure:

I'm looking forward to hearing about Azure. As JB said, we knew something was coming, now it's good to find out what it is :)

Kirk

posted on Tuesday, October 28, 2008 10:15:36 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]

James Newton-King is busting out a beta version of JSON.NET 3.5, and has made some pretty good improvements of up to 400% when serializing / deserialising:

image

(Second set of columns are the improved Json.NET)

Well done James!

Kirk

posted on Tuesday, October 28, 2008 10:03:01 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [1]
 Sunday, October 26, 2008

This post shows how to create an Automatic Property, by turning an existing private field into a property.

 

You've got a private field that you would like to expose to users of your class, but you only want them to be able to get, not set the value.

You could expose the field itself to callers, but it's better to expose a property so that you can set different permissions for get and set, add behaviour when the value is set, and make it easy to version your class so that callers won't notice when you change your internal features.

For this walk-through, I'll assume you've already got a private field on your class that you want to expose publicly.

Encapsulating Fields

So starting with your private field, that has no public access:

class TestClass

{

    private int _Property1;

}

You can use the refactoring support in Visual Studio's right-click menu to wrap the field with a property:

Right-click field, and choose encapsulate field

Go ahead and select the "All" option to update all usages of the _Property1 to use the new property we are creating:

EncapsulateField2

Now all code will reference the Property1 property, rather than the private field:

class TestClass

{

    private int _Property1;

 

    public int Property1

    {

        get { return _Property1; }

        set { _Property1 = value; }

    }

}

Our final requirement was that Getting the value should be public, but the setter should be private, so external callers can't update our fields value.

You can do this by overriding the access of the setter, to make it more restricted:

class TestClass

{

    private int _Property1;

 

    public int Property1

    {

        get { return _Property1; }

        private set { _Property1 = value; }

    }

}

Note the addition of the private keyword to the property setter, while the public keyword now will just apply to the getter.

Automatic Properties

C# 3.0 added a handy new feature called Automatic Properties.

If all your accesses to a field (e.g. _Property1) are going through a property (Property1), then it seems like a waste to have to create a private field by hand.

Automatic Properties in C# will let the compiler do the work of creating the private field for you. All you have to do is create the property.

Change the code to:

class TestClass

{

    public int Property1

    {

        get;

        private set;

    }

}

If you have no body for the getter and setter, the C# compiler will automatically create a field to store the value in. The accessibility of the setter can be set to private as above, so you have all the benefits of a private field, without having to create it yourself.

Now external callers can only reference the property Property1, while internal callers within your class can access both the getter and setter.

By following the above sequence of encapsulating, you won't have to manually change any of the callers of your original field to use the property:

  1. Encapsulate field
  2. Update all references to point to the new field
  3. Remove the original field, and the contents of the getter and setter
  4. Update access of the getter and setter as desired (e.g. make set private)

Snippets

If you're starting from scratch, and you don't already have a field to encapsulate, there are a couple of handy snippets you can use:

prop [tab] [tab] - this will create a regular automatic property, and let you set the type and name:

public int MyProperty { get; set; }

propg [tab] [tab] - this will do the same, but with a private setter:

public int MyProperty { get; private set; }

 

I hope this post gives you some quick tips when dealing with properties.

Kirk

 

Extras

It's always tempting to go off on a tangent talking about technicalities. If you're interested in such stuff, read on...

Field names for automatic properties

The compiler will choose a "magic" name for your field that is storing the data exposed by the automatic property. You can't refer to it directly from your code, and the compiler will make sure it's unique.

For example, my "Property1" has the following fieldname chosen by the compiler:

private int <Property1>k__BackingField;

You can see how it can be guaranteed to be unique -- it uses characters that are not allowed in C#!

Encapsulation

Why is it nicer to use a property than a field? There's a few reasons that I listed above: different permissions for get and set, add behaviour when the value is set, and make it easy to version your class so that callers won't notice when you change your internal features.

Accessibility

If you expose a field as public, you can't restrict your callers from updating it's value. A property can be made public for get, and private for set, which makes it easy to expose data, but still encapsulate it within your class.

Behaviour

Sometimes you'll want to do some validation checks when a property is set. For example, you might want to check that Property1 is never set to 0:

set {

   if (_Property1 != 0)

      _Property1 = value;

}

If you use a property, then you have the ability to add this logic inside the get or set method -- with a field that's not possible.

Versioning

If you expose a public field to callers, changing the name or data type of that field breaks the contract your class has with it's callers, and they will all need to be updated.

With a property, you can change the internals of your class, and where it stores the data, without affecting the caller of your property -- as long as the property has the same name, type and accessibility, they won't know anything has changed.

This helps with versioning your class, as changes to your class won't affect the rest of your program.

 

Cheers,

Kirk

 

Previous C# tips:

And other Visual Studio tips:

posted on Sunday, October 26, 2008 8:45:38 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]

This post shows how to create an Automatic Property, by turning an existing private field into a property.

 

You've got a private field that you would like to expose to users of your class, but you only want them to be able to get, not set the value.

You could expose the field itself to callers, but it's better to expose a property so that you can set different permissions for get and set, add behaviour when the value is set, and make it easy to version your class so that callers won't notice when you change your internal features.

For this walk-through, I'll assume you've already got a private field on your class that you want to expose publicly.

Encapsulating Fields

So starting with your private field, that has no public access:

class TestClass

{

    private int _Property1;

}

You can use the refactoring support in Visual Studio's right-click menu to wrap the field with a property:

Right-click field, and choose encapsulate field 

Go ahead and select the "All" option to update all usages of the _Property1 to use the new property we are creating:

EncapsulateField2 

Now all code will reference the Property1 property, rather than the private field:

class TestClass

{

    private int _Property1;

 

    public int Property1

    {

        get { return _Property1; }

        set { _Property1 = value; }

    }

}

Our final requirement was that Getting the value should be public, but the setter should be private, so external callers can't update our fields value.

You can do this by overriding the access of the setter, to make it more restricted:

class TestClass

{

    private int _Property1;

 

    public int Property1

    {

        get { return _Property1; }

        private set { _Property1 = value; }

    }

}

Note the addition of the private keyword to the property setter, while the public keyword now will just apply to the getter.

Automatic Properties

C# 3.0 added a handy new feature called Automatic Properties.

If all your accesses to a field (e.g. _Property1) are going through a property (Property1), then it seems like a waste to have to create a private field by hand.

Automatic Properties in C# will let the compiler do the work of creating the private field for you. All you have to do is create the property.

Change the code to:

class TestClass

{

    public int Property1

    {

        get;

        private set;

    }

}

If you have no body for the getter and setter, the C# compiler will automatically create a field to store the value in. The accessibility of the setter can be set to private as above, so you have all the benefits of a private field, without having to create it yourself.

Now external callers can only reference the property Property1, while internal callers within your class can access both the getter and setter.

By following the above sequence of encapsulating, you won't have to manually change any of the callers of your original field to use the property:

  1. Encapsulate field
  2. Update all references to point to the new field
  3. Remove the original field, and the contents of the getter and setter
  4. Update access of the getter and setter as desired (e.g. make set private)

Snippets

If you're starting from scratch, and you don't already have a field to encapsulate, there are a couple of handy snippets you can use:

prop [tab] [tab] - this will create a regular automatic property, and let you set the type and name:

public int MyProperty { get; set; }

propg [tab] [tab] - this will do the same, but with a private setter:

public int MyProperty { get; private set; }

 

I hope this post gives you some quick tips when dealing with properties.

Kirk

 

Extras

It's always tempting to go off on a tangent talking about technicalities. If you're interested in such stuff, read on...

Field names for automatic properties

The compiler will choose a "magic" name for your field that is storing the data exposed by the automatic property. You can't refer to it directly from your code, and the compiler will make sure it's unique.

For example, my "Property1" has the following fieldname chosen by the compiler:

private int <Property1>k__BackingField;

You can see how it can be guaranteed to be unique -- it uses characters that are not allowed in C#!

Encapsulation

Why is it nicer to use a property than a field? There's a few reasons that I listed above: different permissions for get and set, add behaviour when the value is set, and make it easy to version your class so that callers won't notice when you change your internal features.

Accessibility

If you expose a field as public, you can't restrict your callers from updating it's value. A property can be made public for get, and private for set, which makes it easy to expose data, but still encapsulate it within your class.

Behaviour

Sometimes you'll want to do some validation checks when a property is set. For example, you might want to check that Property1 is never set to 0:

set {

   if (_Property1 != 0)

      _Property1 = value;

}

If you use a property, then you have the ability to add this logic inside the get or set method -- with a field that's not possible.

Versioning

If you expose a public field to callers, changing the name or data type of that field breaks the contract your class has with it's callers, and they will all need to be updated.

With a property, you can change the internals of your class, and where it stores the data, without affecting the caller of your property -- as long as the property has the same name, type and accessibility, they won't know anything has changed.

This helps with versioning your class, as changes to your class won't affect the rest of your program.

 

Cheers,

Kirk

 

Previous C# tips:

And other Visual Studio tips:

    posted on Sunday, October 26, 2008 8:59:49 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [1]
     Saturday, October 25, 2008

    Here's a great Visual Studio 2008 option that I didn't know existed until a few months ago:

    Save new projects when created option in Visual Studio

    Under Tools -> Options -> Projects and Solutions, you can uncheck the "Save new projects when created" option to let you whip up a little project to test something out, without having to bother with saving it somewhere permanent.

    When creating a new project, instead of this:

    File -> New Project dialog, with prompts for location and solution name

    You'll get this:

    File -> New Project dialog, with prompt only for project name 

    No longer do you have to name your project "ConsoleApplication64"! You can use ConsoleApplication1 as often as you want :)

    Where does it save these temporary projects, you may ask? They get stashed in a Temporary Projects folder underneath your profile's AppData directory.

    When you close the project or quit Visual Studio, you'll get a prompt asking you if you want to keep the project:

    NewProject3

    If you choose Discard, it will be removed from disk and you'll never see it again!

    ConsoleApplication1, here I come!

    Kirk

     

    Previous tips:

    posted on Saturday, October 25, 2008 10:06:03 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]
     Friday, October 24, 2008

    Just placed my order for the second edition of Framework Design Guidelines by Kryzstof Cwalina and Brad Abrams at Fishpond. They've got a good pre-order special of $59.42 (might be today only).

    I'm really looking forward to reading all of the new guidelines in book format, although Kryzstof has been reasonably open by publishing them on his blog as they were developed, and has released a Framework Design Guidelines Digest with some of the useful nuggets from the book.

    posted on Friday, October 24, 2008 1:35:17 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [1]
     Thursday, October 23, 2008

    A common scenario is wanting to delete an item while iterating over a collection using foreach:

    foreach (string name in names)

    {

        if (name == "Kirk")

        {

            names.Remove(name);

        }

    }

    Unfortunately, this will give the dreaded InvalidOperationException:

    Collection was modified; enumeration operation may not execute.

    This is because modifying the state of a collection invalidates the enumerator that foreach uses behind the scenes to loop over the collection.

    A common work-around is to convert the foreach to a for loop:

    for (int i = names.Count - 1; i >= 0; i--)

    {

        if (names[i] == "Kirk")

        {

            names.RemoveAt(i);

        }

    }

    You'll notice that the for loop goes backwards from the end of the list (position: Count - 1) back to the start (position: 0), so that when an item is removed, our current index i is still a valid position in the list.

    How do you do it?

    Kirk

    Source (such that it is) Program.txt

    posted on Thursday, October 23, 2008 11:08:06 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [1]

    Via Scott Wylie's blog - you can join a focus group to tell Microsoft NZ what you think about being a Microsoft developer.

     

    It could be another opportunity to provide feedback that may feed back to the product development teams within Microsoft, plus they say you'll receive a "token of appreciation", and those are always good :)

     

    Details below:

    This is your chance to tell us what you think about Microsoft!

    Invitation for The Microsoft New Zealand Developers Focus Groups 2008

     

    We want to hear from you. Tell us what you love and hate about Microsoft! Every year we use your feedback to improve our products and services. This year, in addition to the annual online survey, we are planning to hold focus groups around the country and are looking for NZ developers to have their say.

     

    Scott Wylie (http://blogs.msdn.com/scottwylie), the Director of the Developer and Platform Strategy Team for Microsoft NZ, will be facilitating these sessions. Scott’s role is to listen and understand your feedback which will enable his team to provide better support and resources for NZ developers.

     

    If you would like to participate, please email your interest to nzeditor@microsoft.com with your contact details and preferred focus group (by session number as listed below) you would like to attend. We will confirm you attendance shortly after via email and phone. You can be assured that all information shared will be kept confidential.

     

    Christchurch Convention Centre / Tuesday 11th November 2008

    Kilmore Street, Christchurch

    Session 1: 8:30 -10:00

    Session 2: 11:00 -12:30

    Microsoft New Zealand Wellington Office / Thursday 13th November 2008

    Level 12, Vodafone on the Park, Lambton Quay, Wellington

    Session 3: 8:30 -10:00

    Session 4: 11:00 -12:30

    Microsoft New Zealand Auckland Office / Wednesday 19th November 2008

    Level 5, 22 Viaduct Harbour Avenue, Auckland

    Session 5: 8:30 -10:00

    Session 6: 11:00 -12:30

     

    Refreshments and a token of our appreciation will be provided for your participation.  We look forward to hearing from those of you who are interested to participate in the focus groups. Please note that there are limited spaces available so please respond early to secure your space for the focus group.

    MSDN NZ Team

    nzeditor@microsoft.com

    posted on Thursday, October 23, 2008 1:11:45 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]
     Wednesday, October 22, 2008

    I've recently read two interesting accounts of the history of C#, one from Bart De Smet, and the other on Computerworld's website.

    “The C# Programming Language Third Edition” and thoughts on language evolution

    Bart does a quick run-through of the evolution of C# through version 1, 2 and 3, and briefly covers three of the influences on C# now and into the future: concurrency, dynamic languages and meta-programming.

    The A-Z of Programming Languages: C#

    This interview with Anders on Computerworld covers a lot of the 10 year history of C#, along with the influences and problems encountered along the way. Anders lists the same future influences as above, with the addition of declarative programming (LINQ, functional and DSLs being examples).

    Both articles are interesting reading if you want a brush-up before we hear all about what's going to be in C# 4.0 next week as the PDC news rushes into our RSS readers.

    Kirk

    posted on Wednesday, October 22, 2008 11:14:44 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]
     Wednesday, October 15, 2008

    I'm enjoying presenting in a few new locations around the country at the moment. Coming up, I'll be presenting at:

    All of the above events are free of charge, so hopefully you'll have a chance to come along!

    Kirk

    * More info about the "PDC Fireworks!" event will come shortly.

    posted on Wednesday, October 15, 2008 9:18:56 AM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]
     Monday, October 13, 2008

    As well as (or despite) the commercial videos on YouTube, there's a whole culture and community of people on there.

    This video, An anthropological introduction to YouTube is a good watch, covering the back-story behind the YouTube phenomena, and a bit on how the culture is building around vlogging and personal messages on YouTube.

    It's 55 minutes:

    posted on Monday, October 13, 2008 11:03:17 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]

    I enjoyed reading this book. Christopher Fairbairn, organiser of the Christchurch .NET User Group recommended it to me as containing a bunch of useful tips for running a user group, and I have to agree with him.

    The author is Dr. Greg Low, who has spent a long time organising MSDN and SQL Server user groups in Queensland, Australia. Greg is a big supporter of Code Camps, and has helped organise Code Camps in Australia and spoken in New Zealand. When I first met Greg, I was impressed by his enthusiasm and energy.

    The Rational Guide to Building Technical Communities is all about improving your user group, with ideas on running your group more consistently; finding, recruiting and growing your speaker pool; recruiting volunteers; and running the meeting successfully.

    The book has the following sections:

    • Overview
      • People, Not Technology
      • Something for everyone
      • Finding speakers
      • Tried and true
    • Starting and growing user groups
      • Pizza does not define a user group
      • Don't reinvent the wheel
      • Recruiting members
      • Content and handouts
    • User group meetings and conferences
      • Using technologies
      • Recruiting volunteers
      • Conducting meetings
      • Tips for presenters
    • Legal and finance
      • The fine print
      • Funding

    Some things (like Legal and Finance), we've got sorted now in New Zealand with our incorporated society (although the section on different types of insurance we might need was an eye opener), and others I still struggle with.

    Most interesting to me was how to attract and keep new members by making them feel welcome in the group. Some ideas, like introducing new members at the start of a meeting I will try out at our next meeting.

    Greg repeats a marketing adage: "the easiest customer to find is the one you already have", and that's too true. Each time someone comes along to our user group, we have to give them as much opportunity as possible to stay in our group -- by pitching future topics at their level, and making sure that they know about them. In our Wellington group we're trying to have some more introductory or general purpose topics to try and appeal to more people.

    In summary, I guess the most useful things I drew from this book were about the human side of running a user group. That's what I find the most enjoyable and rewarding, and Greg gives some good tips on how to make it happen.

    Cheers,

    Kirk

    posted on Monday, October 13, 2008 9:09:11 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [0]
     Monday, October 06, 2008

    Some of the common hacks use an inner frame to host your site, while the attacker controls the surrounding frame.

    Using the following Javascript code, you can make sure your site is running the top frame in the browser:

            <script type="text/javascript">
              
              if (parent.frames.length > 0) {
                parent.location.replace(self.document.location);
              }
              
            </script>

    The code will reload the current page in the parent window if it is within a frameset.

    Kirk

    posted on Monday, October 06, 2008 10:55:17 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [3]
     Thursday, October 02, 2008

    Cool to see that Amazon will be offering Windows pay-as-you-go EC2 instances:

    Coming soon: Amazon EC2 with Windows

    It will be good to have another option for running SQL and ASP.NET solutions out in the cloud.

    posted on Thursday, October 02, 2008 9:14:13 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [1]

    If you're using certificates to authenticate, and you get the above error, then the root cause may be this:

    System.ServiceModel.Security.MessageSecurityException
    The security timestamp is invalid because its creation time ('2008-10-02T02:50:25.161Z') is in the future. Current time is '2008-10-02T02:44:44.909Z' and allowed clock skew is '00:05:00'.

    Basically, if your client and server have clocks that are different by more than 5 minutes, the timestamp that they send to each other when they authenticate may be more than the tolerance allowed (default 5 minutes).... and it will fail.

    The solution is to change one of the clocks :)

    Kirk

    posted on Thursday, October 02, 2008 3:30:58 PM (New Zealand Standard Time, UTC+12:00)  #    Comments [2]