My head was still spinning from the party of the day before. Not because of heavy drinking of wild partying (there was none of those) but because the stream of unleashed energy that Rob Ashton is. A quiet beer can turn into a heated discussion decorated with jewels such as “Javascript is the f… second coming of The Messiah”. Heretic, yes… but by Jove was funny!
Package Management deep-dive with Open Wrap
For this short last day I decided to look at Open Wrap again. My first contact with it was not very successful… and neither was this second one.
I agree that demoing nightly builds and bragging about it is nice. When things go as planned. Which was not the case. I have seen Sebastian, the speaker, have the same problems in another session and it’s not cool at all and projects an unprofessional image.
Problems aside I liked the tool and some of the ideas behind it but I won’t be using it for my projects as I do not like the idea of my package manager taking over my project’s build.
CQRS in the Wild
I was not expecting this session to become one of my favorites of the conference, so it is nicer when it catches you by surprise.
What made it become a favorite? Well, almost everything: the topic is interesting to me, the problem domain is familiar, the trade-offs are similar, there’s empathy to the approach to the solution, details of the solution were at the right level given the session’s time constraints, the speaker did a great job communicating the process and was extremely honest with the problems that they are facing and have not solved yet.
And besides the framework that he is using is Open Source. Another alternative to look into if and when the need comes.
Making your Rails App Sing
I knew this talk was almost completely away from my range of experience, but Rob is really enjoyable to listen to and I was not in the mood for more Javascript.
The session had almost anything to do with Rails but with a bunch of services you can use from a Rails application or from another sort of application (given there is a hook or you are in the mood to deal with a REST-y API) to solve problems that someone building a site selling some content might face. He spoke from his experience with his own business but I can see myself considering some of the services showcased in the future.
The Three Amigos
And another session for entertaining purposes only (almost). It is always fun to watch three guys having fun on stage and sharing jokes and laughs. The idea was sort of a competition between the ASP.NET MVC + Entity Framework platform and Ruby on Rails in order to build a simplistic web application.
The application/technology part was kind irrelevant and was an excuse to make fun of each other for a while. I have to point out that starting with Rails is easy (and blazing fast to get started once you are comfortable to spend lots of time in the console), but so it is with MVC scaffolding and EF code first. I have to point out the amount of goodness that was released recently in the MVC ecosystem that have substantially changed how to start a quick and dirty project and yet have something that can scale further the drag and drop data-source plus a grid.
Unit Testing with Auto-Fixture
Last session of an amazing conference. Luck was that the schedule was changed some time ago so that I could watch the session of someone I have been following from some time: Mark Seeman.
Some time ago a former colleague of mine pointed me the project that was the subject of the talk: AutoFixture. It looks great on paper and the dimension he was presenting was using the tool as a way to create your subject under test in a “maintainable manner”. And I quote it because I was left with the impression that the problem to solve has other alternative solutions that are, in my opinion, orders of magnitude simpler, less intrusive and more self-explaining. But hey, whatever push your boat.
Once again I have to be picky with the example chosen. Yes, it was guiding the audience towards the need to use the tool being presented, but the process, labeled as TDD, has little to do with TDD: why on Earth would anyone driving the implementation of an interface come up with a first set of tests that has nothing to do with the interface being test-driven? A more strict TDD would have most likely taken the developer towards another (simpler) solution. But that would have not made the tool appear as a desired solution.
All in all, I think AutoFixture is pretty elegant and I liked the session but I could not let the bitch in me go off a sample, could I?