Slashdot Mirror

And the difference in the way fathers and mothers bought ice cream for their kids: the fathers like benevolent kings bestowing largesse, the mothers harried, giving in to pressure. So, yes, there does seem to be some material even in fast food.

...I've integrated it into our hourly build; it's handy info.

> If you see a warning, get rid of it right
> away! Once you slack off a bit, it becomes
> like dirty dishes piling up in the kitchen
> sink. Nobody wants to touch them, and
> everybody feels like most of them are the
> other roommate's anyway.

So true! This kind of goes back to the article the other day about having a public daily build. Checking code quality regularly can help keep things under control.

11. If you build it, it will ship.
Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack. This is the single biggest indicator that a team is functional and a product being developed.

> do you have an opinion about this?

Yup, some folks seem to prefer one or the other; I like Ruby but that may be just because I haven't needed to learn Python.

> how did you get started with Ruby?

My boss likes it, so he got me to write an hourly build thingy in it. It's been good times from then on...

Yessir.

> I work for a defense contractor and
> we are mostly a Linux shop.

Same here. I'm admin'ing a couple of servers for UltraLog... all running Linux. There's one Solaris box hanging on by its fingernails, but hopefully that'll go away soon too.

> Change one thing at a time: Isolate the
> key factor, grab the brass bar with both
> hands (understand what's wrong before fixing),
> change one test at a time, compare it with a
> good one, and determine what you changed
> since the last time it worked.

This is helpful with unit tests, too. If I find a bug, I want to figure out which unit test should have caught this and why it didn't. Then I can either fix the current tests, or add new ones to catch this.

Either way, if someone reintroduces that particular bug it'll get caught by the unit tests during the next hourly build.

> a web dashboard portal showing the latest
> results in an easily-assimilated color
> coded HTML table

So true. I've set up one of these for a project I work on, and it's really helpful to be able to see at a glance the status of a bunch of projects.

Seems like some lintish tools could be incorporated into a kernel daily build, and maybe something like CPD as well...

Linux is also proving popular in the public sector. Governments like the idea of not paying a proprietary vendor huge licensing fees for years and years.

This hourly build is driven by Ruby and Ant for the exact reasons that you mention - Ruby's great at parsing text (or XML using REXML).

Lots of little utilities and glue usages out there too. Like this site - an hourly build system using Java and Ant, driven by Ruby. Fun stuff!

Ditto. This is all driven by Ruby scripts.

It's really convenient to be able to loop thru a file with something as readable as:

File.new "data.txt" {|line|
puts line
}

Great stuff, Ruby.

> Why aren't we (the United States)?

We are. Lots of government projects run on open source. Like this, and this.

Yours,

Tom

Tom