There’s been a lot of talk in the .NET community about Sinatra clones, namely Nancy and Nina in recent times but there are several others as well. Unfortunately, all these frameworks are missing the underlying reason that Sinatra is awesome and that is Rack. Sinatra packs a hell of a lot of functionality yet weighs in at 1198 lines of code including documentation. The main reason for that is the fact it is building on top of Rack which has allowed the authors to concentrate on creating a framework without having to worry about the details of dealing with server requests. So what is Rack, why you should care and why does it matter to you as a .NET developer.
This is in some respects a follow up to my previous post in that it has been triggered by our internal project in Ruby. When working in Ruby I consciously lean towards integration tests. Sinatra and Sequel make this really easy as using rack-test and running against an in-memory SQLite database it is easy to simulate a full conversation of HTTP requests and they run reasonably quickly too.
How does this relate to learning a new language? When writing anything in a new language you will make mistakes. You are likely to structure your application poorly. At a minimum you will find there is a much better way of achieving the same result. If you have based your work on unit tests you will have a straight-jacket tying your to your code making the effort to heavily refactor it much greater than it needs to be. Tests will need to be moved, rewritten, thrown away and renamed. However, when you use integration tests you are only verifying the behaviour of the whole system not its moving parts. This means you can replace the internals of your application entirely and your integration tests will not need to be changed and will ensure you have a system that still behaves the same as it did before.
Am I saying that you should never use unit tests in a new language? Of course not. However, you should chose the right level of test to match your level of understanding. Once your application’s structure has ossified it makes sense to exercise the complex parts directly through unit tests. The second you make that shift to using using tests you are setting your structure in stone so you want to make sure that does not happen before it has to.
We are doing an experiment in using Ruby for an internal project at work. I am the most experienced in Ruby so I’m leading the choices of gems and so forth and the team questioning those choices has lead to a bit of a personal epiphany.
I know that for a long while I have preferred simple tools and components. Simple tools tend to be more enabling as they give you control over precisely what is happening in your application whilst managing the boilerplate code for you. I’ve also focused my personal development and reading on fundamental principles to give me a solid grounding in concepts that can then be applied to any situation or language.
These opinions are being reflected in the tools I use for my Ruby development and therefore what I am encouraging the other developers at my company to use: Sinatra and Sequel. I enjoy the power you get from both to exploit all that is available from HTTP and SQL. I find it much easier to apply my knowledge of HTTP gained through reading about REST, though I doubt I’ll ever write a truly RESTful application. Things such as returning the correct HTTP codes and headers to enable client and proxy caching are ridiculously easy to do when compared to ASP.NET MVC. Being able to leverage my knowledge of SQL allows me to fine tune that vital query yet Sequel will still give me back easily consumable objects.
Choosing these simple tools for our task will help the team to learn Ruby and build an application, the real point of the task, rather than spending a large period of time learning how to use a more powerful framework such as Rails. The simpler tools should also let them exercise more of their existing knowledge, again allowing them to focus on learning the Ruby language rather than being distracted by Ruby frameworks.
As for me, I’m happy I’ve chosen this method of working and learning. I think it will stand me in good stead for working in any language I may want or need to learn in the future. It will be interesting to hear what the team thinks of this approach as we proceed.
Very interesting article on a reduction in contribution to open source and the possibly underlying forces behind it.
I recently heard that RMS is pissed at cloud service companies because they are
causing the decline of open source. I do have to say I agree with him that
there’s a decline in open source, but I’m going to lay out a completely
different reason why. This is based on my experience as being classified a “Long
Beard” during an era where consumer internet shifted and the front-end became
Twitter has made numerous changes to fix its API. Those experiences have taught
providers what mistakes not to make when launching a service.
But there is still a lot for providers to learn.
Your end users are Product People. You need to toss out this stupid idea that
making something usable by DHH fanbois means you’re not HARD CORE. You can still
be hard core and make something they can use, hell something any programmer can
use. By doing this you will reduce costs for the people who use your software
which is what that kind of software is good at.
The shift in thinking is to focus on usability as if it ware a linguistic
concern rather than a graphical concern. Product People focus on the design and
interaction of their product through graphics because that’s how their customers
have to interact with what they make.
Long Beards need to focus on the design and interaction of their product through
linguistics because that’s how Product People interact with infrastructure
Something I’ve seen at various times is:
1 2 3 4
I’ve always preferred using:
1 2 3 4
Great article by Davy Brion which echoes the feelings I’ve been having around .NET for a while:
They (Microsoft) provide architectural and design guidance for everything from your database to your business layer to your service layer all the way to your presentation layer. Unfortunately, a lot of that guidance is of a terribly low quality. Follow their guidance and odds are pretty high that either your database implementation details are leaking through all the way to your screens, or that a lot of your business details are taken care of in the database.
And on the recent cut in resources for IronRuby:
I found it extremely telling that Microsoft is capable of putting resources on products like WebMatrix and LightSwitch (both of which are targeting the very-very-lower-end developers, or even non-developers) while at the same time, they are severely cutting back the resources for projects like IronRuby, IronPython and the DLR (which drew more interest from the higher-end developers than the lower-end developers). So what exactly does that tell us? I can only consider that to be a very clear message that the lower-end developers will always be the primary target of Microsoft, and that they really care less and less about the higher-end developers.
We’re looking at automating our acceptance criteria at work and we’ve chosen Cucumber for doing it. Yesterday I scoured the web for useful articles and so on to find out what the established best practices are for working with Cucumber. This is a link dump of the things I found that were useful.