I recently co-authored an article with Gael Fraiteur (creator of PostSharp) on how AOP frameworks such as PostSharp can be used to automate the implementation of common design patterns in .Net.
The article is now available to view on the InfoQ website here. A more offline friendly PDF version is also available here and from PostSharp’s brand new site.
Hope you enjoy what we have to say on the topic, and please don’t hesitate to give us your feedbacks!
It’s been 2 weeks since we released any new content into the world of Here Be Monsters and for our trappers that no doubt feels like an eternity! So with great pride, I’d like to tell you that the wait is over and that you have plenty to look forward to!!
A series of new quests are now available, come speak to mystics Jessica and Miranda at the Stonehenge to kick off a chain of quests which leads to your encounter of a fearsome and powerful ruby dragon by the name of Spyrion who reveals to you the whereabouts of the missing trapper captain Bashak and that she is in urgent need for assistance from you!
Norris, the gnome who helped you out at the start of your journey, also needs some help to fend off Spyrion’s army of Goblins who are causing havoc in the gnomish homeland. And surprise surprise, the Pixies are up to no good again, seriously, those guys…
Along the line you will also receive two powerful new traps – the Ring of Runes and the Thunderdome which you need to reassemble in order to capture the great Chimera.
By popular demand from our players, you can now change the appearance of your ‘folk’ (your avatar in the game) at a small price by bringing up the change profile dialogue and choosing ‘the ‘Change Appearance’ option:
We have a new chat system which allows for easier Spot and Buddy chat, and a global chat feature is also in the pipeline for the near future!
We have also revamped the crafting UI which now has a unified interface for working with any building that can be used for crafting — workshops, laboratories, windmills, etc.
Also, when you click the ‘Add Success Potions’ button you no longer have to add success potions manually, instead we’ll intelligently apply as many success rate potions as necessary from (both your backpack and barns) to raise the success rate of your crafting task to 100%:
You and your buddies’ actual homes are now shown on the map, so if you have a nice and big mansion in your homestead it’ll be immediately visible and on the map, not a bad way to show off the prowess of your homestead to your friends!
Several new achievements that are tied to the new quests have also been added, such as the Guardian of Stonehenge achievement below,
Wow, that’s it! Quite a big change this week, and we have even more exciting improvements lined up for you for the next week or so too, keep your eyes peeled and watch this space!!
I talked about the XML and JSON serialization of F# types in a previous post, and since then F# 3.0 has been released and a new [CLIMutable] was quietly added amidst the hype surrounding the awesome type providers!
When applied to a F# record type, the CLIMutable attribute tells the F# compiler to generate a default parameterless constructor as well as property getters and setters so that when working with the record type from other .Net languages it’ll appear as a pretty standard, mutable CLI type that you’d expect.
However, when working in F#, the normal rules as far as record types are concerned still apply – immutability by default, pattern matching, cloning using the with keyword, etc.
For a simple record type Person, let’s have a look at the compile code with and without the CLIMutable attribute:
Without the CLIMutable attribute, this is how the record type is normally compiled:
With the CLIMutable attribute applied, things look a lot different:
That’s all well and good, but why is this useful you might ask?
Because many serializers, such as the BCL’s XmlSerializer (as well as other serializers available in the open source space) only work with types that has a default constructor and contains property setters.
Unlike the DataContractSerializer which only requires a type to be decorated with a Serializable or DataContract attribute, the XmlSerializer on the other hand, also requires the type to define a parameterless constructor.
Whilst both serializers generate XML outputs, DataContractSerializer is intended for marshalling data (that conforms to a ‘contract’) for transportation over the wire and therefore less concerned with readability of its output and offers little option for you to customize the generated XML. It’s therefore quite happy to spit out rather unreadable XML for our Person record type above:
<FSI_0004.Person xmlns=“http://schemas.datacontract.org/2004/07/” xmlns:i=“http://www.w3.org/2001/XMLSchema-instance”><Age_x0040_>30</Age_x0040_><Name_x0040_>Yan Cui</Name_x0040_></FSI_0004.Person>
Meanwhile, in the land of the XmlSerializer, its sole purpose of existence is to generate XML and offers a platoon of options to help ensure its output meets your functional and aesthetic needs. By default it’ll generate nice, indented output for our CLIMutable version of Person record type:
<?xml version=“1.0″?>
<Person xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=“http://www.w3.org/2001/XMLSchema”>
<Name>Yan Cui</Name>
<Age>30</Age>
</Person>
In addition, you can customize the XML output using the normal XML-related attributes:
<?xml version=“1.0″?>
<Person xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” PersonName=“Yan Cui”>
<PersonAge>30</PersonAge>
</Person>
Of the OSS JSON serializers I benchmark regularly, JSON.Net (v4.5.11 tested) works with both normal and CLIMutable record types from F#. ServiceStack.Text (v3.9.37 tested) doesn’t work with ‘vanilla’ record types on deserialization (fields are left with default values), but you can workaround by making the fields mutable or add the CLIMutable attribute to the type.
I hope this proves to be useful to you, and if like us you have a lot of C# code hanging around just to get pretty XML out of your F# record types, dare I say it’s about to throw away those C# code! 
Just a quick note to say that another minor update to DynamoDB.SQL has been release, you can view the release notes here.
The latest update adds support for a TSQL style WITH keyword for specifying optional parameters for tweaking the query/scan operation. For queries, you can specify the NoConsistentRead and PageSize options to use eventually consistent read and throttle the number of items returned per request respectively. Similarly for scans, you can use the PageSize option for throttling your scan requests too, but the DynamoDB scans does not support strong consistency.
According to DynamoDB best practices, you should avoid sudden bursts of read activity, using the new PageSize option you can make sure that your query/scan does not consume too many read capacity unit in a short burst and end up causing more critical reads to be throttled.
For example, a query which returns 10 items per request using eventually consistent read will look something like this:
whereas a scan will look like:
For more details about the full syntax, please refer to the Getting Started document, which has been updated to include the new WITH keyword.
Enjoy!
Whilst searching for an elegant solution to apply string interning across a large number of classes (we’re talking about hundreds of classes here..) it dawned on me that I can achieve this with ease using PostSharp’s LocationInterceptionAspect. All I needed was something along the lines of:
You can apply this attribute to a class or even a whole assembly and it’ll ensure every piece of string constructed is interned, including string properties and fields defined by its subclass, which is exactly what I was after.
For example, take this trivial piece of code:
If you inspect the compiled code for the Base class in ILSpy you will see something along the lines of:
notice how the setter for BaseStringProperty has been modified to invoke the OnSetValue method defined in our aspect above as opposed to the setter method. In this case, it’ll call the String.Intern method to retrieve a reference to an interned instance of the string and set the property to that reference.
For more details on PostSharp’s interception aspects, I recommend reading Dustin Davis’s excellent posts on the topic:
PostSharp Principles: Day 7 Interception Aspects – Part 1
PostSharp Principles: Day 8 Interception Aspects – Part 2
As we’ve specified the multicast inheritance behaviour to multicast the attribute to members of the children of the original element, the string properties defined in both A and B classes are also subject to the same string interning treatment without us having to explicitly apply the InternAttribute on them:
What’s more, this attribute also works with F# types too, including record and discriminated unions types. Take for instance:
If you look at the generated C# code for the discriminated union type, the internal MyDuType.CaseB type would look something like the following:
notice how the two internal item1 and item2 properties’s setter methods have been modified in much the same way as the C# examples above? The public Item1 and Item2 properties are read-only and get their values from the internal properties instead.
Indeed, when a new instance of the CaseB type is constructed, it is the internal properties whose values are initialized:
Finally, let’s look at the record type, which interestingly also defines a non-string field:
because we have specified that the InternAttribute should only be applied to properties or fields of type string (via the CompileTimeValidate method which is executed as part of the post-compilation weaving process as opposed to runtime), so the internal representation of the Age field is left unaltered.
The Name field, however, being of string type, was subject to the same transformation as all our other examples.
I hope this little attribute can prove to be useful to you too, it has certainly saved me from an unbearable amount of grunt work!
