Loading ...
Sorry, an error occurred while loading the content.

107819Re: [XP] Design Agility? (was: Duplication vs Intention Revealing code)

Expand Messages
  • yahoogroups@jhrothjr.com
    Jun 1, 2005
      From: "Steve Bate" <steve.at.technoetic.com@...>
      To: "extremeprogramming@yahoogroups.com"
      Sent: Wednesday, June 01, 2005 3:13 PM
      Subject: RE: [XP] Design Agility? (was: Duplication vs Intention Revealing

      >> > Which design would be the most agile given the additional
      >> > requirement and why?
      >> I'd have to see a representative sample of German numbers
      >> to make any kind of a guess. My German is way too far
      >> behind me to remember much more than ein, zewi, drei,
      >> vier und zwanzig (blackbirds or some such.)
      > http://www.smartphrase.com/German/ge_numbers_voc.shtml
      >> Quite frankly, I wouldn't use that as any kind of a criterion
      >> for agility; I'd expect to rewrite it from scratch and look at
      >> the surrounding system to see how easy it would be to
      >> do that without having to make massive changes elsewhere.
      > It wouldn't be a big problem in this case to rewrite all the
      > code since it's a relatively small function. This issue
      > can also apply to larger programs when I18N is added after an
      > initial implementation (rather than being specified up front).
      > Rewriting a large application might not be considered an
      > acceptable solution for some (many?) customers.

      This is one of those things I consider a "scare story". The
      fact is that an application which is very heavily oriented toward
      text processing in English might need a complete rewrite to
      internationalize it, but most applications that one would want
      to internationalize after the fact aren't quite as text intensive.

      Let's take an example I'm familiar with: PyFIT (the Python
      port of FIT and FitLibrary.) Internationalization is a topic
      we're probably going to be discussing in the next few months.
      From my viewpoint, it's not going to be a difficult problem.

      One might think that Fit does a lot of text processing, and that
      would be true. However, most of the work revolves around
      two issues: converting a "user friendly" name to a Python
      identifier, and localizing error messages on the way back.

      I've already got a leg up on the first because I support both
      batch and FitNesse in one package, which means that I
      already have three different algorithms to convert an external
      name to an identifier, and the mechanism to decide which one
      to use.

      That mechanism is undoubtedly going to have to be extended
      in a couple of ways (one of which I'd be doing anyway, even
      if I wasn't thinking about internationalization), but it isn't going to
      cause a humongous revolution in the code base.

      The other issue is localization of error messages. As it turns
      out, I already have a central table of error messages, indexed
      by code and with parameters to insert. All of that mechanism
      is embedded in one exception. The reason for that table isn't
      looking ahead: the table has 43 messages,
      and I've been a bad boy: there are still quite a few
      places where I just raise Exception with a message. I'm going
      to have to centralize those, but that's a few hours of drudgery
      that is payback for not doing it right once I'd built the mechanism.

      I expect there will be a few more items in the type adapters
      having to do with locale dependent stuff, and a lot of it is
      going to be a learning experiance, but most of it will yield
      fairly readily.

      John Roth

      > Steve
      > To Post a message, send it to: extremeprogramming@...
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
    • Show all 17 messages in this topic