19 Feb 2014 | net |
For the last two weeks I've been working on an internal project. Being a low risk project, I had the option of introducing new technology that was harder to introduce in other projects. I'm hoping to write a few posts about my experiences with NancyFx, EventStore & NodaTime, to name a few of the things I'm using.
One library I've been looking for a chance to try is the NodaTime library, written by the famous Jon Skeet.
The experience of using NodaTime in a few words:
- extremely low learning curve
- perfect API
- everything is where you expected it to be and named as you expect it to be named
I can't say that I've experienced major issues with the native DateTime form .NET. But I have often felt that it is not a perfect match for representing a concept or not being clear enough in a public APIs. When trying to represent a particular day, or a time in a timezone or UTC the DateTime abstraction did not capture the full intent.
So far the most useful types for me from NodaTime have been: Instant & Duration.
Instant represents a specific point on a clear and unambiguous time axis. This is a common representation also found in other languages - like the time_t type in C - representing the number of ticks from the Unix epoch (January 1st 1970 00:00 UTC).
The "zero point" used everywhere in NodaTime is the Unix epoch: midnight at the start of January 1st 1970, UTC. (UTC itself did not exist in 1970, but that's another matter.)
Duration represents an exact number of ticks on the same time axis. This is similar to the TimeSpan type from .net.
I have also used a LocalDate type to represent a birth date.
As I've said I'm using Nancy to expose an HTTP API and EventStore for persistence. For moving data across this boundaries I'm using the awesome and now almost standard Json.NET library. My first worry was that I'm going to have to convert the types from NodaTime to and from a format supported by API and events consumers.
Almost as expected, I've found that NodaTime already provides a NuGet package for this. Flawless Json.NET serialisation is available by installing the NodaTime.Serialization.JsonNet package.
If you value the expressiveness and correctness of your code, I encourage you to give NodaTime a try. It risks becoming an addiction, but it is definitely worth it.
As a starting point continue reading the excellent User Guide for NodaTime.
In the end I'd like to thank Jon Skeet and the rest of the authors that made this awesome library available for the rest of us.
08 Feb 2014 | general |
With hope that this will also mean writing more often, I've finally decided to move to a modern blogging platform.
Moving away from Wordpress
Wordpress is a mature blogging platform, full of extraordinary features. You get automatic updates, easy updates for
plugins, nice interface to manage the whole thing and a lot of available plugins & themes.
Why move away from this?
It requires hosting, it is kinda slow and it is not exactly low ceremony.
- You get to host it for free on Github pages.
- You get to write markdown.
- You get full control over the theme.
- You are free to use modern web technologies.
- You get to manage content with GIT.
- It's low ceremony - write, commit & push to publish.
I've finished migrating posts, and content to Jekyll. Even if some of the content required manual fiddling, it has not been a difficult experience. Now waiting for Google Webmaster's Tools to tell me what I've screwed up.
One thing I've noticed is that my blog now is blazing fast - which is normal, considering it's just a bunch of static web pages hosted on Github.
02 Jul 2013 | programming |
Verry good advice by Rob Ashton about TDD and testing in general. My favorite line from the slides: "Listen to the pain"
Listen to the pain
Focus on the outside, testing in ASP.NET MVC from Rob Ashton
19 Jun 2013 | programming |
In the context of a question asked on the RavenDb mailing list I've decided to share my thoughts on the Repository Pattern.
It is a common mistake to consider the Repository pattern a generic "good practice", without actually considering what it is good about it.
According to Martin Fowler's P of EAA a Repository
"Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects."
This makes a lot of sense, and even if you are dealing with an anemic domain model, you don't want to have data mapping code mixed in with your domain object code. The key here is "data mapping code". You don't want code that deals with the internal representation of your data storage (whatever your actual storage is) mixed with code that performs business operations on your objects.
Back in the day, when we used to write SQL code in our apps, it was essential that you implemented a layer that encapsulated the SQL queries and SQL mapping code from the rest of the application. With the technology choices available today, we rarely need to write SQL code or SQL mapping code. Today we have NHibernate, Entity Framework, Linq2SQL, RavenDb etc.
Consider NHibernate - the session you open acts like an in-memory collection of domain objects, where you can query, fetch and add domain objects without needing to do any SQL specific stuff. The data-mapping and SQL stuff is encapsulated in your NHibernate mappings code. The NHibernate session IS your repository. It also acts as a Unit of Work, but that is a different pattern.
The same thing happens with RavenDb's client. It provides a "session" which encapsulates all the persistence details like http calls, (de)serialization, caching, concurrency, a lot of safety checks, while acting like an in-memory collection of domain objects. When you do session.Load() or session.Query(), you do this in a very similar way to what you would do when dealing with an in-memory collection of domain objects. The RavenDB's session IS your repository.
Do HNibernate or RavenDb sessions hide ALL the details of the persistence engine? No, but you don't want them to be hidden from you. Except for the most trivial applications, you can't ignore the way your data is persisted. You are going to need to handle relationships between the objects in your persistent store, you are going to need to handle concurrency problems and you are going to have to write efficient queries. All these concerns are application specific and no abstraction is going to be good enough to handle all your application's use cases. But the concept of session from NHibernate or Raven does provide an abstraction over the persistence details, while exposing to the developer ways in which efficient operations can be performed.
There is also a very strong resemblance between the session from RavenDb and the session from NHibernate, but that is probably because Ayende is (was?) one of the most active and knowledgeable developers and "evangelist" for NHibernate, and also because the session is a good model for a unit of work. Ayende also has some good posts about the Repository pattern.
One question that always pops up in the context of the Repository pattern is Unit Testing. How do you mock the ISession from RavenDb or NHibernate. Well ... you don't. It's very hard to mock a non-trivial repository. Instead you "use the real thing", just in an in-memory form. RavenDb's ecosystem provides an embedded, in-memory store that is perfect for running unit tests against the real store. NHibernate provides a SQLite back-end which, while not perfect, can be used for fast tests against a real sql implementation.
In conclusion, before you start defining the IRepository which i know sounds like a cool "good practice", stop for a minute and check if you are not already using an abstraction over your persistence.
31 Aug 2012 | programming |
Lately I've started watching episodes from CleanCoders.com, a podcast created by Uncle Bob ( Robert C. Martin ) and i must say they are excellent.
I must confess that when I've purchased the "Names" episode I was a bit skeptical about how much can be said about how to name the things you use in your code. I have already been paying much attention to names and overall "cleanness" of my code so I was not expecting to learn a lot of new things, but as usual, Mr. Martin as blown my mind with his way of explaining the "hows" and "whys" of doing things.
I can say almost the same about the "Functions" episode. Very important small details that even if I was applying previously in my code, I can now actively think about them when writing code.
Also for me one important gain from watching the videos was that now I can better explain to others the importance and details of clean code using the arguments and reasoning of Uncle Bob.
I highly recommend following all the videos on cleancoders.com. No matter if you are a junior dev or have lots of years of experience I'm sure you will gain a lot of knowledge from them. The videos are created in a non-conventional and funny way which makes them pretty entertaining to watch.
Thank you Uncle Bob for the great videos.
Continue to Clean Coders.