ronin

Gilad Bracha: So why not get rid of constructors and have a class declaration create a factory object instead? Well, Smalltalk did just that a generation ago. Every time you define a class, you define the factory object for its instances. I won’t explain the Smalltalk metaclass hierarchy here. Suffice to say that it is a thing of beauty, resolving a potential infinite regress with an elegant circularity.

This is a good article, and I’ve certainly hit the problems talked about with both Smalltalk and Java. I’m looking forward to some examples…

The XML configuration madness continues. Serialised XML for application configuration? That can’t be good.

I guess that the development process goes like this:

• Write config file in xml, test, change, test change.
• Serialise file
• Release to test environment.
• Discover problem
• Deserialise file, investigate.
• Edit source xml, test, change, test, change.
• Serialise file.
• Rinse, repeat.

At some stage we’re all going to drown under the sea of xml configuration files piling up all around us.

Charles Nutter makes some good points about how he would change Ruby. It’s interesting to see the different perspectives of somebody actually trying to implement Ruby in a new environment.

Previously I had thought Xindice was never going to do another release, but blow me down if not just 3 years after the last beta they go and do a point release.

Elliotte Rusty Harold: Type Inference: Another Bad Idea for Java 7

Type inference actually makes some sense in languages like JavaScript and PHP that are built around this, and had this feature from day 1. It makes no sense in a language like Java that’s built around the opposite. It makes Java look weakly typed, but it isn’t. In fact, if anything this is now more strongly typed…

Good analysis of a bad idea. I really dislike the idea of adding more and more language features that require new syntax or something like described in the above article. It just makes it confusing. Either create a new Java which has all the old crap tidied up, or go ahead and write a new language that can run on a JVM which has all the features and language constructs you need.

This is why I really like Smalltalk. There are very few reserved words, and the language is highly extensible so you can go ahead and implement new ideas without breaking anything old, requiring arcane syntax, or making the language less usable. Ruby struggles in this area also due to all the different ways of doing something.

Simplicity has a lot going for it.

Darren Hobbs: Tiny Types

I consider it playing to the strengths of a statically typed language.

I like this pattern, and have used it once on a large Java project. Generally I prefer dynamic languages, Smalltalk and Ruby etc, but if you have types why not use them effectively.

Blaine Buxton puts it in terms I like:

Tiny objects make unit testing easier, aid in reuse, stop duplication dead, provide for better messages when things do break, puts functionality closer to where it is used, and I could go on all night.

I don’t necessarily use this all the time, I find a lot of developers reject the idea because of the number of Types you end up with. If I’m working on something of mine, or from scratch then I’ll use this approach, otherwise I tend to stick to the style of the original author.

One thing I’m not sure about is an example Darren wrote:

It’s much harder to accidentally pass dollars into a method that was expecting pounds sterling (but actually took a double so it could have been anything).

Money is money is money, would some methods really only take Sterling and not Dollars? Ever? Maybe this was a passing comment or maybe I don’t get this particular example.

This is a good technique to learn and I’d encourage anybody who hasn’t used it to give it a go. Maybe you’ll like it or maybe not, at least you’ll know. One really good outcome that I find is behaviour finds itself in a Class where it belongs, not in some Manager/Helper class just because it’s the first place the behaviour is needed. Not only does this technique work for primitives, but it works equally well for collections, especially where you have some find/collect type methods.

Blaine Buxton in Java VM Puts Shackles On Development Tools

…in 2007 with dynamic languages finally getting recognition that few people are screaming for the capabilities of a Smalltalk VM. The productivity of Smalltalk owes not only to its dynamic nature, but to its always running and lively IDE.

Developers coming from traditional environments just don’t have the exposure to that way of working. It probably never crosses their mind that an environment that is “alive” is more productive. The only way a Smalltalk like environment would happen for another language is if it is written by somebody coming from Smalltalk and wanting the same tools.

I for one would be all for a Ruby IDE that was essentially an image.

Steven Colebourne: Configuration in Java - It sure beats XML!

Is the Java community slowly remembering what’s good about Java? I’m talking about static typing.

I can’t count the number of times I’ve had this rant. The article is mostly inspired by being sick of editing XMl files which can become tiresome and error prone when they start getting large or numerous.

There are a few caveats that need to be made when thinking about configuration, in no particular order:

• When the configuration is about setting up how an application works, and it doesn’t change per environment then use the language you are writing your application in. If the language isn’t good enough to handle setting up some configuration, then maybe your using the wrong language? It’s a good idea to use a Fluent interface when thinking about configuration languages, in fact it’s good to think about them all the time.
• If a property can change per deployed environment then it’s better to externalise that from the code. As a commenter on Steven’s post pointed out, having to explode an EAR/WAR to change where some log files go isn’t very cool for somebody deploying a third party app. Often it pays to tokenise config files and then have an automated detokenisation process which provides the actual config values per environment. Deployers may not have the skills to go diving into a piece of code to change it, and it would be a PITA for them if they had too. Property files work well for them.
• Think hard about what values are really going to change, get this wrong and configuration can become a nightmare. Try and go with convention over configuration. Define your deployment environment and be firm about not adding extra configuration because “you might need to change this value in the future but we don’t really know”. If it’s going to change in the future then change it in the future. Obviously this doesn’t apply for things that will always change, e.g. IP Addresses.

As an aside to all this, I’ve recently gone through the experience of moving all of my current project’s configuration from xml/property files into a Configuration database. Now when an application starts up it registers itself with the configuration service, if it doesn’t have any configuration it will be given a copy of a default set of values. We have an admin console where users with appropriate privileges can edit and add new values, or reset values back to defaults and so on. This way we have zero(almost) configuration packaged with an application. Applications identify themselves, get given a configuration, and off they go without any help from us. If a new team comes along and needs to use one of our apps they just take the application and deploy it as is. We can see it in the admin console when it gets started and then edit, or give the appropriate priveleges to one of their administrators so they can, the config that they need.

Looking up the configuration is done through a common JNDI name which then points the application to the correct place, this can be overriden if necessary which is why the “almost zero” configuration per app, it’s totally optional and it works by convention if it can.

The configuration is also cached by a client framework so updated values will be available when the application next reads them. This is useful for log levels and the like where you might want to up the priority to debug to do some debugging for a while and then set it back to error when your done.

We created a basic taxonomy of Tags that an application can use to identify itself, these are inserted into the application during the build process. Examples of tags are:

• The application name
• Which type of appserver the application is going to run in

There are a few more specific to our domain, but you probably get the idea. In the admin console we can search for different Tags which allows us to find all instances of an application that are running. This will include developers machines, integration environments, test environments, and third party environments we have no control over.

Testing was something we didn’t really consider upfront, which was a mistake. It was soon obvious that we needed to be able to bootstrap a configuration into a Unit Test(The config framework itself did have unit tests). Luckily the interface wasn’t too bad and with a simple mock JNDI environment we were up and running. It adds some overhead to the setup of a test fixture but isn’t all that bad.

Another benefit to this approach was when an application registered itself it provided it’s manifest file as part of the identification process. We now have all the version information for each application running in all our environments. This becomes highly valuable when supporting deployments in third party environments which we have no access too.

Us: What version are you running?

Them: Not sure, how do I find out?

Us: Go to the filesystem, find the deployed application, open the manifest, tell us what value attribute X has.

Them: How do I log onto Unix?

Us: Err…

Now we just look in the admin console, find out which version they have and get started looking at the problem. Not having access to an environment can be a pain when trying to find out which version and configuration an application is using. Now we just don’t have that problem.

It’s no silver bullet that’s for sure, but it does ease the pain of having to configure for many many difference environments.

Dejan Bosanac over at O’Reilly points out a style of initializing singletons which I hadn’t seen before.

I think there’s 3 things worth saying about this:

1. Don’t use the Singleton pattern if you can avoid it. I should really dig up some references for this comment but I can’t be arsed.
2. Use a static initializer if you can. It avoids having another class involved and I think it reads a bit easier.
3. If you really need to have the Singleton inited on the getInstance call, then go ahead and use the on demand holder. In my experience the first call to a Singleton is the getInstance method so the static initialiser will be called at that stage anyway.

Obie Fernandez blogs about the “What makes Ruby roll” session at JAOO.

One of the questions the panel was asked was “How can Ruby avoid the same fate as Smalltalk?”. My favourite answer has to be from Kevin Henney(I’m assuming the quote is accurate):

Someone will have rewritten it by then. Yes, will succeed where Smalltalk failed because it’s not bound up in the smalltalk environment (you can open up Ruby files in Notepad). Also, do not underestimate how important a ‘normal’ if statement is. The biggest problem with Smalltalk is Smalltalkers.

If I can paraphrase: “The problem with smalltalk is smalltalk and the people who use it”.

Makes me laugh, probably becuase it’s true, but you get arrogant people in all communities, Ruby will probably end up with a few since it’s so popular currently.

Blain Buxton follows up saying: “An image-less Smalltalk would have a nicer entry point…”.

I think this is very true. I seem to remember something called Smallscript that didn’t require an Image, and I’m sure there must be a few more kicking about.

In the end I guess it matters what the Ruby community wants to achieve. Ruby and RoR certainly has a massive mindshare at the moment but who really knows where it’s going to go. Is the goal to become some kind of enterprisey language that corporates feel comfortable deploying? And if so how would the Ruby community even make that happen, I don’t think any amount of endless evangilism about how good Ruby is will do any good, IMO it’s going to take some serious backing by a large technology company before it can start to make those inroads into the Enterprise world. And if it does, then it needs to play nice with Java, C#, and whatever else is being used , it can’t be an island.

If you keep reading Obie’s post there are a couple funny posts which are worth reading for the hell of it.