Build Server Rules

Breaking the build server is Serious Business. Fortunately there are a set of rules put together by a group of wise and thoughtful men to encourage good build server practice. And beer.

Build Server Rules

  1. The penalty for breaking the build is a beer.
  2. A broken build beer can only be written up while the build is broken.
  3. Once the build is broken, broken build beers will not be given until the build is fixed. It is considered bad form for other users to check in while the build is broken.
  4. Broken builds resulting from environmental factors on the build server such as locked files or other transient behavior shall not be penalized.
  5. Amnesty can be requested for tasks that can only be tested on the build server.
    1. Amnesty must be requested in advance.
    2. Amnesty requires the agreement of the build server council.
    3. While amnesty is in effect anyone can check into the build server with impunity.
    4. Amnesty ends once the task is complete and the build server is green.
  6. Build beers must be cashed in upon a contributor reaching 12 broken builds. Multiples of 6 may be purchased.
  7. Disputes are judged by a majority ruling of the build server council. Decisions and lulz are final.

Like developers must learn to honor the build server, testers must also be kept on their toes for that rare occasion when your code contains a bug.

QA Rules

  1. Each undiscovered bug in a release, judged as one that should have been found by the council, is a beer.
  2. The penalty for a bug found existing in multiple releases is a QA beer per release.

Hey, Homer, I'm worried about the beer supply. After this case, and the other case, there's only one case left.

kick it on DotNetKicks.com

PDC 2008: Creating SharePoint Applications with Visual Studio 2008

Hello. I'm Leonard Nimoy. The following tale of alien encounters is true. And by true, I mean false. It's all lies. But they're entertaining lies. And in the end, isn't that the real truth? The answer is: No.

The rip in the fabric of space time between our universe and the bizzaro universe, where I am a SharePoint expert, continues to grow. First I presented a 400 level SharePoint session at TechEd and now I have helped put together a SharePoint presentation for PDC!

“Creating SharePoint Applications with Visual Studio 2008” presented by Chris Johnson walks through creating a SharePoint application using the Visual Studio 2008 extensions for SharePoint (VSeWSS). A bunch of people from Intergen contributed to the end product. I helped write the overall script with Mark Orange, one of Intergen’s actual SharePoint experts, and I wrote the application used in the presentation.

The application featured a new project announced at PDC: the Silverlight Control Toolkit. SharePoint hosted a Silverlight chart control that visualized data called from a WCF web service and SharePoint’s web services.

PDC Fireworks

The Wellington .NET usergroup had a special event last week covering what was announced at PDC. I gave a brief 15 minute introduction to using the Silverlight chart control. You can get the slides from my talk (all 6 of them!) here.

Duffman thrusting in the direction of the problem!

Thoughts on C# 4.0 and .NET 4.0

I have purchased the Springfield YMCA. I plan to tear it down and turn the land into a nature preserve. There, I will hunt the deadliest game of all... man!C# 4.0 Dynamic Lookup

I really like the way the C# team tackled bring dynamic programming to the language. C# is a static language but it is good to see that the C# team is pragmatic enough to realise that will always be situations where you don’t have type information at compile time.

With C# 4.0 rather than having to bust out ugly System.Reflection operations to interact with unknown objects, the new dynamic lookup hides any ugliness away from the developer. Statically typing an object as dynamic is a great solution as it lets you treat a specific object, which you don’t have type knowledge of, as you want with regular property and method calls while still keeping static typing throughout the rest of your application. I think this is a much better solution than the dynamic block discussed in the past.

Dynamic lookup also opens up some new interesting paradigms by offering the IDynamicObject interface to developers. The first thing I thought of when I saw it was Dynamic LINQ to JSON. I’m sure uses will come out of it that no one ever considered [:)]

C# 4.0 Covariance and Contravariance

Very happy to see this feature. I bumped my head into generic variance issues a number of times when writing LINQ to JSON. No longer having to worry about IEnumerable<JToken> not being compatible with IEnumerable<object> is great. They even kept it type safe!

C# 4.0 Named and optional parameters

Is it just me or did Anders wince when announcing named and optional parameter support in C# 4.0? Microsoft has said that they plan to keep the C#/VB.NET languages in sync and I wonder if this is C# inheriting VB.NET features by default.

.NET 4.0 Code Contracts

From everything I have seen of it so far I love the Code Contracts feature. Statically defining type information has been around forever and is A Good Thing. Its about time that we are able to statically define valid values as well.

.NET 4.0 Parallel Extensions

It is interesting to see parallel programming come as a library addition in the form of Parallel Extensions rather than a language feature (ditto for code contracts). I guess with a library you only need to create it once rather than having to figure out new concurrent programming syntax for every .NET language.

 

Bring on VS2010.

Json.NET 3.5 Beta 1 – Big performance improvements, Compact Framework support and more

I am starting to get organised towards releasing Json.NET 3.5. There are a lot of good new features coming in this version, almost all of them driven by user requests.

Compact Framework Support

Json.NET 3.5 includes a build for the Compact Framework 3.5. It supports all the major features of Json.NET.

Performance Improvements

A lot of features have been added to Json.NET over the past couple of years and it has been a long time since I had done any performance tuning.

I busted out a profiler and found some big gains in the JsonSerializer by doing some basic caching of type data. I managed to eek out a 400% increase in performance. Not bad for 20 minutes work.

Below is a comparison of Json.NET 3.0, Json.NET 3.5 Beta 1, the WCF DataContractJsonSerializer and the JavaScriptSerializer. The code for the results is in the PerformanceTests class and is over 5000 iterations.

Okay Marge, its your child against my child. The winner will be showered with praise. The loser will be taunted and booed until my throat is sore.

JsonSerializerSettings

There are a lot of settings on JsonSerializer but only a few of them are exposed through the JavaScriptConvert.SerializeObject/DeserializeObject helper methods. To make those options available through the easy to use helper methods I have added the JsonSerializerSettings class along with overloads using it to the helper methods.

public class Invoice
{
  public string Company { get; set; }
  public decimal Amount { get; set; }
  [DefaultValue(false)]
  public bool Paid { get; set; }
  [DefaultValue(null)]
  public DateTime? PaidDate { get; set; }
}

This example of the JsonSerializerSettings also shows another new feature of Json.NET 3.5: DefaultValueHandling. If the property value is the same as the default value then those values will be skipped when writing JSON.

public void SerializeInvoice()
{
  Invoice invoice = new Invoice
                    {
                      Company = "Acme Ltd.",
                      Amount = 50.0m,
                      Paid = false
                    };
 
  string json = JavaScriptConvert.SerializeObject(invoice);
 
  Console.WriteLine(json);
  // {"Company":"Acme Ltd.","Amount":50.0,"Paid":false,"PaidDate":null}
 
  json = JavaScriptConvert.SerializeObject(invoice,
    Formatting.None,
    new JsonSerializerSettings { DefaultValueHandling = DefaultValueHandling.Ignore });
 
  Console.WriteLine(json);
  // {"Company":"Acme Ltd.","Amount":50.0}
}

Writing Raw JSON

For a long time JsonWriter has had a WriteRaw method. I can proudly say that now it actually works. Serializing raw JSON is also much improved with the new JsonRaw object.

Changes

Here is a complete list of what has changed.

  • New feature - Compact framework support
  • New feature - Big serializer performance improvements through caching of static type data
  • New feature - Added DefaultValueHandling option to JsonSerializer
  • New feature - JsonSerializer better supports deserializing into ICollection<T> objects
  • New feature - Added JsonSerializerSettings class along with overloads to JavaScriptConvert serialize/deserialize methods
  • New feature - IsoDateTimeConverter and JavaScriptDateTimeConverter now support nullable DateTimes
  • New feature - Added JsonWriter.WriteValue overloads for nullable types
  • New feature - Newtonsoft.Json.dll is now signed
  • New feature - Much better support for reading, writing and serializing raw JSON
  • New feature - Added JsonWriter.WriteRawValue
  • Change - Renamed Identifier to JsonRaw
  • Change - JSON date constructors deserialize to a date
  • Fix - JavaScriptConvert.DeserializeObject checks for addition content after deserializing an object
  • Fix - Changed JsonSerializer.Deserialize to take a TextReader instead of a StringReader
  • Fix - Changed JsonTextWriter.WriteValue(string) to write null instead of an empty string for a null value
  • Fix - JsonWriter.WriteValue(object) no longer errors on a null value
  • Fix - Corrected JContainer child ordering when adding multi values

Links

Json.NET CodePlex Project

Json.NET 3.5 Beta 1 Download – Json.NET source code, documentation and binaries

kick it on DotNetKicks.com