Frank Carver’s musings about software and life
It’s a long-running argument. Are modern, dynamic, languages such as Ruby and Python really much more concise than more mainstream languages such as Java? What constitutes “big” in each case? Stephan tries to flush out some hard facts, and gets a lot of comments.
I develop almost all my code these days using Test Driven Development (TDD). By taking this approach I never bother about unit test code coverage, but some developers seem very concerned by it.
One thing that I have never considered doing is retroactively adding tests just to increase some code-coverage metric. Dan Manges has written in interesting explanation of why that might be, using some examples in Ruby.
So the question is: are dynamic-typed languages (ruby, python, smalltalk, etc.) easier or harder to maintain than static-typed languages (Java, C#, etc.)? It seems there are arguments both ways.
On the one hand, dynamic languages tend to be a bit more concise, and reducing code size is a great way to simplify maintenance. On the other hand static languages typically support better and more intelligent tooling, which is also a great way to simplify maintenance.
Ola Bini has some thoughts, but has so far been unable to come up with any hard data one way or another. is there any?
The Maintenance myth | Ola Bini: Programming Language Synchronicity
A thoroughly enjoyable presentation from RubyFringe, one of the best I have ever watched.
It starts with a few minutes of demonstration of a reasonably cool music tool, but the real meat is in the presentation which follows - a fast paced, insightful and downright humorous rant about a wide range of topics from Leonardo daVinci to mountain lions, web applications and venture capital.
I guess this a bit old by now, but I hope they continue with this at least for the moment: a roundup of some of the interesting things going on in the Git world.
My current work is centred around Java, and all our applications are deployed in java containers. It might one day be useful to deploy JRuby applications, and in particular rails apps, to these same containers. Here’s a list of things to beware of in such situations.
When I first saw this it looked great: a ruby REST wrapper which supports a lot of useful test and integration possibilities. However, the deeper I looked, the more disappointed I became. I’m now saddened to believe that this is based on yet another misunderstanding of what REST is.
As far as I can tell, the ActiveResource concept, on which this approach is based, is merely an attempt to impose a constrained CRUD data-model over HTTP. There is no concept of content negotiation - all data is XML according to pre-assumed schemas. There is no support for automatic discovery and use of hrefs between resources. There is even the suggestion that it’s a good idea to casually extend the HTTP protocol with extra custom methods.
All of these are typical problems found in projects which use the name REST without the key bits which make it really work. The end result is just another fragile, application-specific RPC protocol. Sigh.
nutrun » Blog Archive » Testing web services with ActiveResource
Even though this article uses the term “web 3.0″, it’s still worth reading. The idea of moving from specific “cloud computing” implementations to a more generic and pluggable approach is a neat idea. Using ruby as a scripting language for “agents” and Erlang for the infrastructure seems a good balance, too.
InfoQ: Vertebra: EngineYard’s Next Generation Cloud Computing Platform
Although I don’t do much with Erlang or Ruby at the moment, I really like the approach taken in this article of connecting applications using the Jabber protocol. It looks as if it really has a lot to offer as a messaging infrastructure, a potentially key component as yet unexplored for “rosebud”.
nutrun » Blog Archive » Distributed programming with Jabber and EventMachine