The newest on-line resource for serious Ruby information has gone live.

Ruby Code & Style, an on-line magazine from Artima, has just published issue #1.

Check out the names on the advisory board. It’s a Who’s Who of everybody who’s anybody in the Ruby world.

The premiere issue has three outstanding articles:

First up, Jack Herrington, author of Code Generation in Action (Manning, 2002) and Podcasting Hacks (O’Reilly, 2005), has written Modular Architectures with Ruby

Next, Austin Ziegler gives us Creating Printable Documents with Ruby

And there’s a reprint of Ara Howard’s article, Linux Clustering with Ruby Queue: Small is Beautiful, which first appeared in Linux Journal but deserves repeat attention

A big thanks to the advisory board, and especial to Bill Venners for starting this whole thing.

To cut a long story short, we think that most financial online tools are a joke. We want to offer leading edge statistical tools with unknown ease of use. Then we combine these hard facts with soft facts :-). Stay tuned ..

Sven C. Koehler is still working on our conference videos, but a copy of our slides is available. Futurometer is still in the early development stages, but it's big fun.

I especially like the "bird flu" plot showing how much media attention it gets.

It seems like every development project begins with the date, and we’re held responsible for "making the date". Making the date is not a development responsibility. Here’s why.

 >>  On Sun, Oct 16, 2005 at 11:48:34PM -0200, Luiz Esmiralha wrote:
 >>  >
 >>  > Maybe another question can help clarify the issue.
 >>  >
 >>  > Why pay 100 grand a year for a programmer just to make a guy in the US
 >>  > or Europe happy if I can get the same job paying 20 grand a year for a
 >>  > guy in India?
 >>
 >>  Well those aren't anything near the figures.  I know someone who is
 >>  the IT director for a UK company that uses outsourcing.  The financial
 >>  savings are around 15%.  If he sets up a UK shop in one of the more
 >>  deprived areas of the UK he will be able to get to somewhere near that
 >>  figure - lower salaries, govt grants etc.  As a result he is seriously
 >>  looking at doing just that.
 >>

 In a recent survey, average savings from offshoring are around a bit
 less than 10%. 5% of the companies polled acheved savings around 50%
 (cases where they replaced 400 bucks/hour resources for 50 bucks/hour
 resources).

 The realistic target saving when offshoring operations is estimated
 around 30% as companies become more mature in the way they conduct
 offshoring.

 20 grand a year for a programmer in Brazil is a very good figure. I
 don't know the current average salary of a programmer in the US or UK.
 The 100K figure was based on supposition rather than fact.

 >>  > Your analogy implies that Indian software lacks quality. Quality seems
 >>  > to be measured (or guessed?) in CMM levels by every company in the US
 >>  > and the rest of the world is following this trend. Given that fact, I
 >>  > would like to remind you of the many companies in India appraised at a
 >>  > CMM 5 maturity level.
 >>  > I don't believe in CMM, but the guys in India didn't make it up, they
 >>  > just happily jumped on the SEI bandwagon.
 >>
 >>  I don't believe in CMM either and I dont believe it necessarily produces
 >>  a high quality product.  It has been my experience (of three different
 >>  Indian outsourcing companies) that product quality is variable, and
 >>  a lot of the developers are what I would class as juniors even though they
 >>  are not sold as such.  Undoubtedly some of this can be tracked to
 >>  the fact that development of apps that distant from the users is not the
 >>  best way of doing things. Also there is a disinclination for the Indian
 >>  guys to question the spec if they think it is inconsistent or lacking in
 >>  detail and to raise questions with whoever is leading the project.
 >>
 >>  Some (maybe most) of these issues are often also present for the big US/UK
 >>  consulting firms.
 >>

 I worked with the 'Big Five"  in some projects and they present a
 uniform pattern in their staffing that I call "War Movie Team".

 These teams are usually composed by a seasoned sargent (consultant)
 which marvels the spectator (customer) with his ability and 10 rookies
 (juniors or trainees). The sargent is usually assigned to another post
 in the middle of the movie and must leave the rookies to their own
 luck.

 In unrealistic war movies, the rookies will use their talent combined
 with the experience they acquired with Sarge to overcome the enemy and
 come home as heroes. In real wars and real projects, they are
 slaughtered by snipe fire, hidden mines and disease and return to
 South Dakota in bodybags.

Wee is a framework for building highly dynamic web applications. It is inspred by Seaside.

www.euruko.com

• The framework: Ruby on Rails
• The favored webserver: lighttpd with FastCGI
• An embedded database: SQLite

Locomotive includes the Ruby MySQL and PostgreSQL bindings. If you have MySQL/PostgreSQL installed, or want to use them, Locomotive is ready.

Locomotive will be nice to your existing rails installation as Locomotive is entirely self-contained.

Propositions for enhancements are welcome…

gegroet, Erik V. - www.erikveen.dds.nl/

 >FWIW, I didn't find it insulting.  I was offering my (somewhat
 >> educated) viewpoint.

 I knew that education would get you in trouble someday.
 If you were a dropout like some of us, we wouldn't be having all
 these communication problems.

 That's why I like to work with people who know they're idiots. It's
 just so much easier on all of us.

 If they're an idiot and they know it, I can work with them.

 If they know they're an idiot and they turn out to be smart, so much
 the better.

 If they're an idiot and don't know it, I know I don't want to work
 with them.

 And if they're not an idiot and they know they're not an idiot, I
 don't want to work with them. Why make someone like that suffer?
 After all you'd have to be an idiot to want to work with me.

 The C Programmer
    God consults with the C programmer on every major issue. (As anyone
    who study's processor design knows all to well.)
        The C programmer can walk on water.

 The VB Programmer
    The VB programmer does lunch with God every day.
    He is an olympic class swimmer.

 The Turbo Pascal Programmer
    The Turbo Pascal programmer occasionally has a word with God.
    He can swim pretty well.

 The Fortran Programmer
    The Fortran programmer sometimes catches a glimpse of God.
    He manages to keep himself afloat in shallow water.

 The QBASIC Programmer
   The QBASIC programmer knows who God is.
   He has trouble avoiding drowning in his own bathtub.

 The LOGO Progammer
   About the only thing a Logo programmer knows about GOD is that the
   word is short enough for him to sound out, but he has trouble spelling
   it.
   He needs someone else to cerry him across the water for him.

 The Assembly Language Programmer
   The assembly language programmer is God.
   He parts the water when he wishes to cross it.

 The Forth Programmer
   The Forth programmer don't view ever river he comes across as a
   challenge to his religious faith and just walks across the bridge.

 Von: "SD Magazine"<sd@newsletters.sdmediagroup.com>
 Betreff: SD People & Projects: Mo' Developers, Mo' Problems?
 Datum: Mon, 03 Oct 2005 19:09:26 -0400 (EDT)

 SD PEOPLE & PROJECTS

 October 2005: Bigger Teams Not Always Better
 By Amit Asaravala

 >>>> MO' DEVELOPERS, MO' PROBLEMS?

 Thinking about assigning more developers to a project
 to accelerate your schedule? Be careful. Putting a large
 team on the job could cause you more trouble than it's
 worth, according to a new study by software estimation
 and analytics vendor QSM.

 The study, based on data that QSM collected from 564
 information systems projects completed since 2002,
 revealed that large teams don't complete projects much
 faster than small teams, though they cost much more. In
 particular, teams with 34 people on average completed a
 100,000-line project in 5.6 months at a cost of $2.1
 million, while teams of four people on average took
 about two weeks longer but cost just $294,000. Thus,
 shaving two weeks off the schedule cost some companies
 as much as $1.84 million.

 Why such disproportionate production rates? Blame it
 on the bugs. The larger teams produced more than five
 times as many bugs as the smaller teams, which required
 the teams to reexamine their code more often, according
 to QSM. In the end, this ate into a large portion of
 the time saved by having more developers turn out more
 code per day.

 But before you decide to cut your team back to just
 four people, consider this: The size of the small team
 in the study was just an average, and QSM readily admits
 that it's saving the question of "optimum" team size for
 a future study.

 Rather, the real lessons here are that you'd better be
 sure that accelerating your schedule by adding more
 developers is worth the extra cost, and that you should
 have realistic expectations about how many days you'll
 actually save by doing so.

 --Amit Asaravala

Here’s a very interesting set of comments from Linus Torvalds and Theodore Tso on the problem with writing specs:

kerneltrap.org/node/5725

Here’s a great quote from Linus:

 The classic example of this is the OSI network model protocols.
 Classic spec-design, which had absolutely _zero_ relevance for the
 real world.We still talk about the seven layers model, because it's
 a convenient model for _discussion_, but that has absolutely zero to
 do with any real-life software engineering. In other words, it's a
 way to _talk_ about things, not to implement them.

 And that's important. Specs are a basis for _talking_about_ things.
 But they are _not_ a basis for implementing software.

And a good one from Ted Tso:

 In those cases, if you implement something which is religiously
 adherent to the specification, and it doesn't interoperate with the
 real world (i.e., everybody else, or some large part of the
 industry) --- do you claim that you are right because you are
 following the specification, and everyone else in the world is
 wrong? Or do you adapt to reality?

And another one from Linus:

 So don't talk about specs. Talk about working code that is
 _readable_ and _works_. There's an absolutely mindbogglingly huge
 difference between the two.

All heresy to the BDUF school of thought, of course. But relatively uncontroversial in the XP world. Interesting to see the parallel evolution.