"The Lovers" by Gilles Tran (2001). Find more in the Hall of Fame

I still remember my first ray traced spheres on old XTs 15 years ago :-).

There is a competition and the monthly irtc. See the May-June viewing page and relax.

Computers are a grate time-killer, especially once you get into 3D images and animations. Enjoy it!

example graphs

 Will this company be successful and become another Google?
 First, graphical data mining has never been a big hit. And second,
 there are lots of competitors in the business intelligence sector,
 including at least Business Objects, Cognos, Hyperion and MicroStrategy.
 So make your bets and wait for the next multibillion-dollar IPO.

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

Been coding hard now on SW and CFaR. I would really need some good vodka now before getting up early tomorrow morning to catch the train.

Hope you all had a good weekend, -A.

This vodka bottle reminds me that I am way behind on Futurometer. We will kick ass there soonish!

Summertime .. so all we do is to ski-roller. High time for the snow to come back and cool it down a bit. I found that pic a long time ago on I have forgotten what website.

As part of my interview, I was required to sit and pair program for about half an hour. We worked on an writing a unit test for an actual defect that currently existed on the project (although it could easily have been a real user story, or a contrived scenario if the project had not yet started).

I thought this was a great idea, and a great source of knowledge for both sides. I was able to show that I did indeed know how to program, write unit tests, knew my way around an IDE, had acceptable interpersonal communication skills, etc. I was also able to get a different perspective on what the team dynamics were like, which I could not have gotten from a formal interview setting.

The interesting thing is that both me and my partner (one of the interviewers) taught each other about some tools and approaches that we were not previously aware of.

Even though I didn’t get the job (the position was withdrawn), I kept in touch and became friends with the interviewer/partner, and the things we taught each other came in useful in our future development work.

This company also asked for code samples and a mini-presentation, which I also thought was a great idea for separating the wheat from the chaff.

Since I have had responsibility for helping interview, select and recommend job candidates in the past, I know for a fact that the best resume and interview performance in the world is inconclusive. You can still get a lemon, even though the lemon may be very good at piling on the BS.

From my perspective as a job candidate, I am confident in my skills and my abilities. I know that I can quickly adapt and excel in any position within my skill set. However, its very frustrating when I cannot convince the potential employer of this through only a traditional resume and interview.

In future interviews that I go for (which will hopefully only be with XP/Agile shops), I am going to suggest this as a way for the hiring company to get a better idea of my skills, knowledge and abilities, both technical and interpersonal. If I am ever part of a hiring team in the future, I will definitely propose that code samples and a pair-programming session be part of the interview process for candidates who make it to the final stages. This is admittedly very time-consuming, but probably much less net investment than being forced to live with (or try to get rid of) an employee who looked much better "on paper".

Thanks, Chad

"The quantity of meaning compressed into a small space by algebraic signs, is another circumstance that facilitates the reasonings we are accustomed to carry on by their aid."

• Charles Babbage, quoted in Iverson’s Turing Award Lecture

paulgraham.com/power.html

The first person to write about these issues, as far as I know, was Fred Brooks in the Mythical Man Month. He wrote that programmers seemed to generate about the same amount of code per day regardless of the language. When I first read this in my early twenties, it was a big surprise to me and seemed to have huge implications. It meant that (a) the only way to get software written faster was to use a more succinct language, and (b) someone who took the trouble to do this could leave competitors who didn’t in the dust.

Brooks’ hypothesis, if it’s true, seems to be at the very heart of hacking. In the years since, I’ve paid close attention to any evidence I could get on the question, from formal studies to anecdotes about individual projects. I have seen nothing to contradict him.

  >>Here is a version of Forth that runs under Windows, written in Whitespace:
  >
  >>
  >>I can't get it to run.  Do you think my browser has clobbered the code?
  Hmmm. I did exactly as the web page[1] suggests: "What do you do? Simply
  print it out and delete the file, ready to type in at a later date.
  Nobody will know that your blank piece of paper is actually vital
  computer code!"  I sure hope that I didn't mistake my only copy of the
  source code for an ordinary blank page!

  Perhaps writing my Befunge[2] compiler in Malborge[3] and then making it
  to a Forth[4] compiler written in Whitespace[1] wasn't such a good idea...

 References:
 1 http://compsoc.dur.ac.uk/whitespace/
 2 http://dmoz.org/Computers/Programming/Languages/Befunge/
 3 http://www.freebsd.org/cgi/query-pr.cgi?pr=28147
 4 http://www.cbel.com/forth_programming_language/

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

 In years past, we have implemented some extremely complicated databases in
 Forth.  The first was done in the mid 1970's for the company Cybek in NJ,
 and it was used in some extremely complex applications.  FORTH, Inc. also
 did some very complex databases for other companies, one of which was still
 in use last time I checked, at www.calmuni.com.  That one was a
 2-dimensional database, with a huge bit matrix in the center used to
 calculate overlapping bonded indebtedness.  A few years ago my contact  there
 told me that a state agency had just spent several million $$ trying to
 replicate it using modern database tools, but the result was too large and
 too slow to be usable.

 In the late 1980's we added class-based techniques to it, which many people
 liked (although I personally preferred the earlier, simpler version).

 It's hard to describe the whole approach in a newsgroup post, though.  It
 certainly didn't resemble SQL!

"Process waste" is the behaviors that don’t produce a working product. The biggest waste in the industry today is "programming in the debugger". This is so endemic nobody even calls it waste. Our vendors work very hard to supply us with advanced debuggers, so we can merrily cause problems and then fix them, instead of preventing problems.

Another big waste is delayed integration. Some shops account for how many modules we must write, then specify the modules’ interfaces, and tell each programmer to write a module separate from the others. Then at the end of this cycle the programmers start trying to integrate. They might not even have build scripts to plug the modules together; they might find themselves manually integrating by clicking on the user interface to an IDE.

Delayed integration costs some orders of magnitude more than the cumulative cost of continuous integration does.

Get ahead of these problems. Write tests first, constantly review code, don’t own code, and integrate continuously. Write and maintain build scripts that support all these behaviors seamlessly.

Don’t delay surprises. If "our product has an installer" appears as a motherhood story, integrate the installation system early, and test it every day. Don’t wait for the last iteration.

The ideal is that the last week before a big release should look and feel just like any other.

 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 :-)

…I arrived at the classroom ten minutes before the lecture began. I was worried that there wouldn’t be any seats left, but I discovered one at the fourth row from the front so I hurried over and sat down. The classroom, which can hold around 200 people, filled up almost instantly. By the time I entered the room, Mr. Miyamoto was already sitting in a chair next to the blackboard.

Since Miyamoto was apparently too busy to make any special preparations for the event, it was decided to move from a traditional lecture format to a more informal discussion. To start off things, the instructor in charge discussed CERO [the Japanese game rating system], age restrictions, GTA, Kakuto Chojin, and other topics related to game regulation.

And then Miyamoto stepped up to the mike. Applause…

www.video-fenky.com/features/miyamoto.html

 >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.

1) Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

2) Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.

3) Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

4) Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

www.jwz.org/doc/worse-is-better.html