magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘May, 2005’

Two of the three bugs on my watch list have in recent days been makred for inclusion in Mustang (Java 6). RFE 4057701 entitled “Need way to find free disk space” has been in since virtually the year dot, and was originally dropped from the first NIO JSR:

Resolution of this request is considered a high priority for Mustang.
Active development on this feature has been in progress for the past
several months. I expect that we will complete this work within the
next couple of months. These methods will be in Mustang-beta.

I’m trying to work how how this feature required “several months” of development, but at least it’s a “high priority”. Lets gloss over the fact that even if I am programming in Java by the time Java 6 is out it’ll be another year or two before my clients will be using it.
<!-more->
Less important, but still a “woho!” moment for me, is the inclusion of RFE 4726365 – “Java 2D to support LCD optimized anti-aliased text (sub-pixel resolution)”.

The quality of Java2D text antialiasing leaves a lot to be
desired in comparison to OS naitve antialiasing, especially
ClearType on Windows.

Java2D uses gray scale antialiasing. At point sizes below a
certain threshold (around 14pt it seems) this just does not
look very good, with text appearing ‘lumpy’ and uneven.
Either the way antialiasing interacts with font hinting
needs to be improved, or there should be a settable
rendering hint so that text below a certain size is not
antialiased. In Windows standard text antialiasing, this
works well. Larger font sizes are antialiased, where the
most benefit is seen, and smaller font sizes are untouched,
making them legible.

Decent anti-aliasing is one of the key features in making Java UI’s fit in better with native applications, and the fact that the UI will pick this up automatically should mean existing applications will look better for free, at least where LCD’s are concerned. Now I hope someone looks at RFE 4109888

Advertisements

Just for a bit of fun, I thought I’d see how many of the people over on the Rails mailing list were actually getting to use it in their day jobs. Completely unscientific, and obviously a completely self-selecting sample group, but like I said it’s just a bit of fun.

The four questions I asked were, “are you using Ruby on Rails”:

  1. As the primary development tool at your Day Job
  2. As a small part of your Day Job
  3. Not using Rails in your Day Job, but are using Ruby
  1. For OS/outside work/hobby

    Of the 50 responses received in around a day an a half, here are the results (note: people could respond more than once – many people are doing it as both a job and a hobby as example):

  2. As the primary development tool at your Day Job – 50%
  3. As a small part of your Day Job – 22%
  4. Not using Rails in your Day Job, but are using Ruby – 18%
  1. For OS/outside work/hobby – 66%

    No analysis – this is deeply unscientific – but feel free to come up with unfounded claims as to how Rails is going to take over the universe or something – I’m sure the blogsphere will lap it up.

Rails, as you’ll no doubt be aware from the recent spate of blog-hype (sometimes so breathless in it’s praise that I fully expect some bloggers to keel over after choking on their own spleens) can be considered as a cross between AppFuse and NakedObjects, only for Ruby.

Like AppFuse Rails takes a series of technologies and with the help of some scripts creates a project for you in which most of the simple configuration and wiring is done for you. Like NakedObjects, Rails gives you a UI and persistence mechanism based on a domain model. Unlike NakedObjects Rails is highly flexible – you are free to change pretty much anything you want.

Initially the thing that makes you sit back and start to listen to at least some of the hype is the amount of work the helper scripts can do for you. Once you’ve created a DB table, you simply have to type:

ruby scriptgenerate model MyModel

To generate a persistable domain model and test stubs (I’ll talk more about the pattern used here later). Then you can generate the controller, with this simple command:

ruby scriptgenerate controller MyModel

Adding scaffold :recipe to the resulting controller dynamically enables all views required for CRUD operations for your Model. This can be shortened to:

ruby scriptgenerate scaffold MyModel

This does both of the above steps, and exposes all the scaffolding code inside your controller. For the most part, this code is there (in rails-speak) as scaffolding around your application. It’s there to get yourself started. As such you are encouraged (expected even) to edit virtually all the code generated for you – the obvious conclusion from which is that the generation steps have to be considered to be a one-shot deal. If you change the Rails version, you may now be required to edit much of your code by hand. This is by no means a fatal flaw – but when analysing the productivity gains of Ruby, the initial benefit of code generation should be seen as just that – an initial benefit. Rails will stand (or fall) based on Ruby itself – both its technologies, tools and workforce.

In Rails (well, ActiveRecord) you can support simple ordered collections fairly easily. Say I had a Post object, with multiple Comment objects, but I want to keep the Comment objects in order they were posted, where posted_on holds the posted date:


class Post "posted_on"

	

...

end

This has been a post on behalf of the just-letting-you-know-I’m-alive and the I’m-blogging-this-so-I-can-find-it-with-google-later parties.