The organisation will next week show off a Wi-Fi enabled bus at the Paris-hosted Public Transport Exhibition 2004. It will also launch a public trial of the technology, on the number 38 bus, which runs between North and South Paris. Buses on the route have already been equipped with Wi-Fi, RATP said. Travellers will be able to connect their (suitably equipped) PDAs and notebooks with the bus’ on-board access point. However, Internet connectivity is only provided at Wi-Fi speeds when the vehicle passes within range of a fixed hotspot - at a major terminus, for example. For the rest of the journey, connectivity is maintained through a GPRS link. link

 "I can't do all that stuff you say I should do, but how do I handle the situation ..."
  The response:
  -- IT WON'T WORK HERE doesn't work here.

I think that to get a group to be agile, you have to get people to do something like one of these things:

1. Go in that room there and do all 12 XP practices until you actually do know better. (XP)
2. Go in that room there, don’t let anyone screw with you, work on whatever you think you can get done for a month. Keep doing that until everyone is happy. (Scrum)
3. Go in that room there, in peace love and understanding, ship software every month (*), and think about it. (Crystal Clear.)

There is a telling sameness to all of these, is there not? —> This is a wonderful summary of a summary! There’s not much to be removed (see Saint-Exupery, below). In Italian, the expresso of an espresso is called a "ristretto" (any Italians online?). This is the agile ristretto. It belongs on a Blog or something. "La perfection est atteinte non quand il ne reste rien a ajouter, mais quand il ne reste rien a enlever." (Saint-Exupery)

 >Documents work
 >> because you can use them early (models that build knowledge),
 >> because they persist (you're not crippled by your imperfect memory),
 >> because they're efficient (you don't have to keep repeating the same
 >> conversation with perfect fidelity), because they can capture
 >> details (not just vague impressions), because they can be reviewed,
 >> critiqued, and corrected (unlike your trembling thoughts), because
 >> they remain (unlike you, you job-hopper!), etc.

Excellent points. Extreme programming demands this of the code as well as any documents the customer may require.

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike. www.paulgraham.com/hp.html

 > Surely, you're not calling design documents you built in the middle
 > of a project "up-front" design?

Let’s talk about "project" and "up-front" for a second.

In the old world I came from, a project had a feedback loop. This feedback loop could be considered to have covered design to unit testing, roughly a period of 6 months to a year on many projects. In other words, I would get feedback on my design 6 months after I made it.

Now let’s enter the fractal nature of XP.

My design to unit test feedback loop is the duration of a card in most cases. In some cases it’s as small as design/refactor/new test/new code/refactor/ (which may be a scope of minutes). In some cases it may be as large as an iteration (after all, we didn’t pick the cards in this iteration at random, we had a plan). It may even have been as large as a release plan.

The difference is that I get my feedback quickly and the design I do at any given stage is as small as it needs to be instead of as large as it can be. But I still do design "up-front". I have a plan before I leave the release meeting. I have a plan before I leave the iteration meeting. I have a plan before I even start refactoring before that first unit test. I have to make the same decisions I would have made in the BDUF, the only difference is that I make them as late as possible. In short, I make them just before I do the task that requires that decision to have been made.

XP is fractal. It’s possible to think about an XP project as a large collection of projects, each small enough to be written on 3*5 cards. And I do design for every one of those projects up front.

In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. He invented the worlds first wiki, a web-based collaborative writing tool, to facilitate the discovery and documentation of software patterns. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming. link

• The dealer gives the customer all the chips for this iteration
• Then the customer "shuffles" the cards and lays them down
• As each one is laid down, development uses a different color of chips and places the number of chips that story costs.
• If the customer is okay with it, they then take an equivalent number of chips from their "stack" and place it to the "bet" pile.
• If the customer isn't okay with it, the story can be split (kind of like "double down" in blackjack) and/or cards can be "reshuffled"
• At any time, the customer may "reshuffle"
• When the customer is out of chips and is okay with the current "bets" and card order, the planning session is adjourned

 >An activity that I /do/ still have trouble with, however, is writing.
 > When faced with having to compse anything more substantial than an
 > email response, I feel the fear start to creep in and I get myself all
 > tied in knots.  Even after I start to put some words down, I often
 > find myself getting stuck because the thing isn't flowing and the task
 > of finishing seems overwhelming.

Yup, writers block definitively, as John Roth diagnosed already. But if you’re able to describe it in such flowering detail as above, there’s no need to have it.

 > So on my way home last night (after another frustrating couple of
 > hours trying to get some thoughts on paper), I was thinking about how
 > I could make my prose writing come as easily as my code writing.  I
 > started wondering if I couldn't somehow employ a TDD-like cycle in my
 > writing process.

I am often writing articles with my business partner, who’s<br>especially good at collecting lots of nice stuff on the web. The first thing I have do with the "drafts" I get from him, is to find the<br>structure fitting best to the available data. This is currently donein a Mindmap using freemind (freely available at sf.net, IIRC). For some<br>time I also tried vimoutliner (www.vimoutliner.org) for this, but found that for this process, the two-dimensional display of a mindmap is better suited to my brain.

When the outline is finished, I start to grow the flesh on the bones. That’s relatively easy, as I confine my work strictly to the current paragraph.>

The next step is easy, if I have the time: I let the stuff settle for a few days, then go over it once more and clean up the unbelievable mess I created then. If I don’t have the time, I need to play about two hours nethack, which erases my brain just as well…

So the steps are:

 - data collection
  - gradually by experience
  - by force (coauthor delivery)
 - data organization
   - mindmap
   - outline
 - draft
   - follow the map
   - work local
 - refactor or polish
   - grammar, spelling, rhetoric
   - present line of thought more clearly

I think that there’s a difference between code and prose showing here. You expect your code to give certain results for a given input, and you are free to not care about the implementation at all. With prose, implementation is almost everything. So the cost of providing a "working release" is higher with prose than with code. At least for me.

 >find myself getting stuck because the thing isn't flowing and the task
 >of finishing seems overwhelming.

Writing is like every other kind of art. It is never finished. Feeling better now?

Writing is like dealing with animals. Don’t be afraid of it, and it won’t hurt you.

Your fellow author in pain, S.

(Source: Ron Jeffries in the XP-mailinglist) Well, Don't do Code Reviews, do Pair Programming. Frankly, code reviews are /so/ much worse than pair programming that a dose of them would make me fly to pair. Let's see if we can replicate my experience.

Here's one path through a network of a million decision points:

To do code reviews, everyone has to read the code beforehand, unless you're doing a walkthrough, see below. I'd ask everyone to come together physically to the review. Then I'd ask them to report truthfully how much time they spent reviewing the code. Early on, I would report truthfully that I had spent zero or very little time, in hopes of getting others to admit the truth. When they admit the truth, I'd dismiss the meeting and reschedule it.

Then, after a while, the only alternative is a walkthrough, since no one is preparing effectively for the review. So we do walkthroughs for a while. They are intensely boring, and few people stay involved. Note in your mind the people who are present but not involved. At the end of the session, say, holding your hand up, "Who else had a real problem staying engaged with this walkthrough?" If there's honesty in the room, hands will go up. Prompting may be necessary. Then: "Any ideas?"

Surely someone will think of "doing this in smaller groups or one on one". Try it. Ask the team whether "we should empower the one-on-one folks to change the code, and under what circumstances." Don't mention that this is pair programming.

Try an experiment. You're "interested in collaborative programming". Interested parties should come to the room to help. On the screen, start writing a program. Ask for help with it, get the room to pair with you. Get stuck (no need to fake this if you are me). Someone will start telling you what to do. Don't get it (no need to fake this either). Get them to come up and do it ... grabbing the chair that is accidentally beside you, while you move over.

Note that reviews often find things. Observe how many of them are resisted by the original programmer, or are "too much trouble to fix now". Build a few BVCs relating to time spent prepping, in the meetings, number of useful suggestions (by person if you can do it without problems), number of changes made in response to suggestions, ...

Code reviews are intensely painful, in my experience, and we were trained by Freedman himself. There will be no need to set them up to be perceived that way, though it will take honesty among the group to express it. After doing enough code reviews, which take way more than half the groups' time by the way, a team who has heard of pair programming should be begging to pair. About all you have to do is make sure that no one treats the review session as nap time, and that you are /early/ in recognizing the people who think it's a waste of time. Because they're right.

Amongst other things this article tells you when best to have children :-). [groups.yahoo.com/group/extremeprogramming/files/when%20should%20we%20test.pdf]

 JR> Yes, those are the "certified" Linux releases, but Oracle versions prior to
 JR> 10g could be installed on other distros.  The screenshots seem to indicate
 JR> that the Installer now checks which Linux you're running, which leads me
 JR> back to the original question.

 I haven't tried it myself, but Wim Coekaerts once mentioned
 an "-ignoreSysPrereqs" installer option that would get you
 past that Linux distribution check.

Or suggested by DJ: edit the oraparam.ini file and edit the supported versions section.

Or: run

 runInstaller --help

and actually read it :-)

Welcome to the Open BEAGLE W3 page. Open BEAGLE is a C++ Evolutionary Computation (EC) framework. It provides an high-level software environment to do any kind of EC, with support for tree-based genetic programming, bit string and real-valued genetic algorithms, and evolution strategy.

The Open BEAGLE architecture follows strong principles of object oriented programming, where abstractions are represented by loosely coupled objects and where it is common and easy to reuse code. Open BEAGLE is designed to provide an EC environment that is generic, user friendly, portable, efficient, robust, elegant and free.

The Open BEAGLE code is compliant with the C++ ANSI/ISO 3 standard. It requires the Standard Template Library (STL). No specific call in the core libraries are made to the operating system nor to the hardware.

Make sure you also check out distributed BEAGLE. Distributed BEAGLE was created to distribute the evolutionary process using the EC framework Open BEAGLE. Its key features are robustness, fault tolerance, adaptability for heterogeneous networks, and transparency for the user. Distributed BEAGLE uses the Master-Slave model to distribute data over the network.

When doing an Open BEAGLE EC application, just 3 little modifications to your code are needed to enable Distributed BEAGLE. There's two types of program that can be executed by using different configuration files. The first one evolves the population over one generation by applying Darwinian selection and genetic operators. It usually runs on the same computer as the master. The second one evaluates the individuals's fitness. The slaves can be eventually used as screen savers.

The master is called DAGS for DAGS is an Agile Grid Scheduler. It is not specific for a given evolutionary algorithm. DAGS uses dynamic adjustment of the size of sets of individuals that are sent to the slaves based on the recent history of the evaluation clients. If an evaluation client lags to return results, the data is redistributed to another evaluation client. There's a database in the master that insures data persistency. link

The pics shows "history flow" from IBM research. Tons of other good links can be found in the c2-wiki.

Visualising is really interesting and up for a major change. I am totally sick of all these boring search-engines out there and yeah, grep -r is still my best friend. Another reason why I despise MS-Word, he, he and use LaTeX. It took me years to fall in love with that programming-language, which happens to be a word-processor, too.