First time here? You are looking at the most recent posts. You may also want to check out older archives or the tag cloud. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS. Thank you for visiting! (hide this)

November 2010 Blog Posts

How to convert dates from Google Reader and Facebook API with Json.NET

Lately I’m working together with Daniela on a news feed reader for WP7 and one of its features is Google Reader synchronization. (It is called FeedTso, and if you are interested in knowing when it will be released I recommend you go and subscribe to the newsletter on the FeedTso site.)

I’ll talk about the Google Reader API in a future post (I’ll opensource the API when FeedTso is on the MarketPlace) but for the moment I want to discuss how I deserialize the JSON Date that I receive from the Google Reader API (and from what I’ve been told, Facebook API behaves the same) using Json.NET.

Json.NET has two converters to DateTime:

But unfortunately the Google Reader and Facebook APIs, instead of returning the date in one of the two aforementioned formats, they just return the number representing the unix time: 1290774032435185.

The easy solution would have been to just deserialize to an integer and then expose another property that converted the unix time timestamp to a DateTime, but I wanted something cleaner, so I decided to create a UnixDateTimeConverter for Json.NET.

I looked at the code of the original JavaScriptDateTimeConverter and I basically created mine removing all the parts that were parsing the “new Data(“ part of the value.

public class UnixDateTimeConverter: DateTimeConverterBase
    public override object ReadJson(JsonReader reader, Type objectType,
                         object existingValue, JsonSerializer serializer)
        Type t = ReflectionUtils.IsNullableType(objectType)
                  ? Nullable.GetUnderlyingType(objectType) : objectType;
        if (reader.TokenType == JsonToken.Null)
            if (!ReflectionUtils.IsNullableType(objectType))
                throw new Exception(String.Format("Cannot convert null value to {0}.",
                                   CultureInfo.InvariantCulture, new object[] { objectType }));
            return null;
        if (reader.TokenType != JsonToken.Integer)
            throw new Exception(String.Format("Unexpected token parsing date. Expected Integer, got {0}.",
                                         CultureInfo.InvariantCulture, new object[] { reader.TokenType }));
        long ticks = (long)reader.Value;
        DateTime d = ticks.ConvertFromUnixTimestamp();
        if (t == typeof(DateTimeOffset))
            return new DateTimeOffset(d);
        return d;

    public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
        long ticks = 0;
        if (value is DateTime)
            ticks = ((DateTime)value).ToUniversalTime().ConvertToUnixTimestamp();
            if (!(value is DateTimeOffset))
                throw new Exception("Expected date object value.");
            DateTimeOffset dateTimeOffset = (DateTimeOffset)value;
            ticks = dateTimeOffset.ToUniversalTime().UtcDateTime.ConvertToUnixTimestamp();

I also had to implement a few utility functions because the original converter uses some private methods: a small helper to check whether a type is Nullable and an updated version of my UnixTime to DateTime conversion methods (now implemented as extension methods):

static class DateTimeUtils
    public static DateTime ConvertFromUnixTimestamp(this long timestamp)
        DateTime origin = new DateTime(1970, 1, 1, 0, 0, 0, 0);
        return origin.AddSeconds(timestamp);

    public static long ConvertToUnixTimestamp(this DateTime date)
        DateTime origin = new DateTime(1970, 1, 1, 0, 0, 0, 0);
        TimeSpan diff = date - origin;
        return (long)Math.Floor(diff.TotalSeconds);

This the first time I extended Json.NET and I’ve to say I’m impressed: the parsing is extremely well thought, no wonder why Json.NET is faster than the official DataContractJsonSerializer serializer.

In case you needed something similar, I packaged the 3 classes in zip file to make it easier to download.

What happened to Lucene.Net? It got forked

A weeks ago I wrote a call for help for Lucene.Net: not enough activity and not enough contributors. A lot happened since that post so I think it’s worth doing a little recap of what the situation is now.

What happened?

The newsletter thread received hundreds of emails, and lot of discussion on my post as well. Most of the discussions were about trying to understand the reason of such a lack of activity and committers, and try not to repeat the same errors: it turned out that most people think the reason is that Lucene.Net is “just” a line-by-line port of the the Java version, it feels obsolete (both because of the site not being updated and not official release, and because it is still a VS2005 project) , and because there are very strict rules that have to be followed inside the ASF.

The official position of the main committer

At the end, following the latest answer by one the first committers of the project, George Aroush, the final decision has been to try and revive the development on Lucene.Net in its current state, hosted in the ASF and being a line-by-line port of the Java version, by the end of 2010, as per request of the Board (otherwise the project will go in the Attic). And once this goal of keeping Lucene.Net alive is accomplished, they will start working on the 3.x version, and only then they will decide whether to keep the Java-like approach or making a more .NET-like API but still keeping the convenience of having the line-by-line port from the Java version.

Forking Lucene.Net

The email from George left a bad taste on my mouth, and apparently I was not the only one what that feeling. There are developers, especially the ones that could get involved, that care about which VCS you use, which version of the IDE you use, which development process and which conventions you use, and hate dealing with politics, boards, release voting and so on. Many probably just stepped away from the discussion (like I did), but other decided to go a step forward and forked Lucene.Net.

Actually there are two project (that I know of):

  • Lucere.Net, which would like to build a “conceptual port” in order to have both the internals and the external API following the conventions and paradigm of .NET development and libraries. It was started by Troy Howard, one of the most active commenter on my post, which already setup also a google group.
  •, which has a slightly less ambitious goal: just nettify the current Lucene.Net API, converting getter/setter methods to properties, using enums instead of classes-used-as-enums. And this project is backed by

I have not time to contribute to these projects, but I’ll be following the developments and see where they go. Having a real .NET version of Lucene will not hurt :)

What to do?

For reasons I’ve not fully understood people are seeming me as a kind of authority in the Lucene.Net, and I got quite a few emails from people asking what they should do now that Lucene.Net is in such a bad situation. My personal opinion is that Lucene.Net, even if it doesn’t have official releases, is a solid library, which powers lot of projects, and you should keep on using it. Even if the project is not very appealing for developers to contribute to, from the end user point of view it is an awesome library, and it has all the features that you might need from a full-text search engine.

So, keep on using it, but also keep an eye on those two projects if you want a more idiomatic API and want to take advantage of all the goodness the latest versions .NET brought to the table.

Speaking in Bern about SOLID

While I was organizing the NHDay, this summer I got in contact with Kay Herzam, one of the founder of the Bern .NET User Group: we started talking and we decided to do something together: the collaboration started with Kay announcing the NHDay to his fellow user group members, and this turned out pretty well, since 5 people from Switzerland registered and came to the NHDay after Kay announced it.

We decided to go on with the collaboration: so on December 9th, 2010 I will be speaking in Bern, at the 5th annual user group meeting, about SOLID principles.

Design for testability as a way to good coding

There are 5 principles that if strictly followed make you write good code: they are called SOLID principles.

But it is difficult to measure what is good code: in this session we will have a look at these SOLID principles and see more practically how to make sure our code is good code. In particular we will have a look at the probably more common and more easy to apply among these principles, the Dependency Inversion Principle.

If you live near Bern and want to come and hear me, you can register online on XING (which apparently is a very popular social site in German speaking area). Or if you don’t have a XING account you can register via the DNUG-Bern contact form.

The event will start at 18:00 on the 9th of December, and will be held at WISS, in Bern.

Hope to see you there.

Subtext 2.5.2: now works 100% in Medium Trust

In June this year we released an important version of Subtext that included lots of refactoring and was the first step to being ASP.NET MVC based. Then after a few weeks we released a bug fix version (2.5.1) but still an important bug was left open, and it prevented one of our contributor and long time user Travis Illig to upgrade to 2.5 because some of the changes we made to the skinning component broke support for Medium Trust (VirtualPathProvider had some problem in Medium Trust).

Unfortunately we were never able to replicate the problem because on “normal” Medium Trust everything worked fine: but thankfully Travis has been able to debug to code on his server, find the bug and also submit a patch.

And during the All Saints holiday Phil merged the patch and we released a new releases with just that bug fix. And apparently now all the problems have been fixed since Travis just blogged from the new installation on Subtext 2.5.2.

So, if you were running into issues with Medium Trust, go ahead and download the new Subtext 2.5.2.

Just one little note on the full version number is The revision number is 0, which means that the release file has been built on a local machine: this because we are in the process of migrating our build process from our now obsolete build server to the TeamCity build server nicely provided and supported by CodeBetter. But this is a story for another time.

Of course, if you still run into Medium Trust problems with your Subtext installation, please let us know.

All NHibernate Day materials and videos are online

Almost one month passed since the NHDay in Bologna and but we didn’t forget about the promise we made about streaming and having the videos online for people that couldn’t attend.

And now, after all the processing required to get the vidoes out of the cameras, processing and uploading them fighting with the “digital divide” that affects some areas of Italy, all the vidoes, presentations and samples (when available) are online.

If you are interested all the live recording are available online, too. And you want to download the original video for offline viewing, you can go the NHDay channel on Vimeo and download the original video (I think you need a free account on Vimeo to download the file).

Hope you like them.

Lucene.Net needs your help (or it will die)

UPDATE: There is a follow-up, which explains what happened in the community after this post: What happened to Lucene.Net? It got forked

Lucene.Net, the .NET version of the famous Lucene search engine, is in a pretty critical stage. The short version is that Apache Software Foundation is considering killing the project because the community behind Lucene.Net is not active enough and since the project graduated from the incubator to a real project on its own, no “official” releases have been made (only source releases) and the site is not compliant to the “branding” guidelines.

For the long version, please read the mail sent out to the Lucene.Net mailing list, Lucene.NET Community Status and the heated discussion that came out from this email:

Lucene.Net is a pretty widely use full-text search library: it is used by many opensource project like Umbraco, Orchard, NHibernate.Search, Subtext and even RavenDB is using Lucene.Net as foundations for the querying side of the product. And it’s is also used by lots of software agencies and consulting companies to build the solutions they sell to their customers.

Since none of the committers have a blog (or at least, not that I know of), since I’m a fan of Lucene.Net, with this post I wanted to raise the awareness about this problem and asking for your help.

If you are using Lucene.Net in your solutions or in your opensource project, consider spending some time helping out with Lucene.Net. Or even better, if you are working in a company that is selling solutions based on Lucene.Net, “ask your boss if you can get paid to help out - then put it on the company blog”. No, starting a money raising page will not help.

If no new people comes to help, the project will put back in the Apache Incubator and a new proposal has to be made and voted, or the project will be put in the Attic and then if someone want, a fork can be created (unfortunately the name has to be changed since Apache owns the name Lucene.Net).

So, if you want to help keeping Lucene.Net alive, please step up now, join the mailing list, and state your intentions over there.

kick it on