Slashdot Mirror

Any time I receive an Excel spreadsheet I open it in RagTime which can equally export its spreadsheet components so they can be opened in Excel by clients.

RagTime isn't only a spreadsheet, but its spreadsheet components allow me to do more than I could ever imagine trying to do in Excel. It is also a layout package and thus provides a one stop tool for data intensive publishing such as price lists and the sports results systems I cut my teeth on.

RagTime was originally developed for the Mac only but the developers got badly burnt after investing heavily in a new version which made ground breaking use of Apple's soon to be abandoned OpenDoc component technology for which it was particularly well suited.

Understandably they were then a bit tardy getting an OS X version out, but that version is now at .4 release so it is most likely very stable. However I'm still waiting for a response from their nominated Australian distributors so I can acquire my own copy. Meanwhile I've been surviving on the free (for non commercial use) RagTime Solo which was their final version for OS 9.

Check here. The only reason I know this is because I've seen it discussed on Slashdot before. And I might have gotten it mixed around as well. Anyway U.S. billion is not always the same as a billion in other parts of the world. Silly, right?

Maintenance Commands su(1M)

NAME
su - become super user or another user

SU(1) FSF SU(1)

NAME
su - run a shell with substitute user and group IDs

Well, just look at the examples :-). A closure is something like a local (lexical) variable that happens to be a function, and can freely access in its body all variables (including other local variables) visible at the point where it is defined. The closure can be used just like any other local variable, i.e. it can be passed to other functions as a parameter, and it can be returned from the function where it was defined as a return value (that's what's not working in GCC). The respective receiver of the closure may then call it freely.

Can you direct me to a web-site that explains exactly what closeures are and then explains how to do them in C++ with step-by-step instructions of what's going on so I am able to follow.

C++ doesn't have closures. GCC has a half-complete substitute, as explained in the parent posting. Google points here. The GCC implementation ist explained here.

• resource (costs/people/tools)
• quality
• time
• scope

See also Quality is free.

Are you sure MT is what you really want? I'll bet a wiki would be a better choice; we just installed one here at work and we're going crazy-go-nuts with it. We've installed PhpWiki, but Twiki looks useful, too.

The "home" of wiki is at http://c2.com/cgi/wiki, and the main book on the subject of wikis, The Wiki Way, has a companion website with downloadable code at http://wiki.org/.

Briefly, a wiki is a website that allows one to create and edit web pages without having to mess with accounts and permissions--just type in one's text into an edit box, click "submit", and it's up and running. We use it as a knowledge base, and I'm going to use it to record billable events and notes.

"The simplest possible database that could possibly work"--Ward Cunningham

See TruckNumber at Cunningham & Cunningham, Inc..

See TruckNumber at Cunningham & Cunningham, Inc..

I took a class where we used something called a Wiki. The concept is simple. You have a community of people who all contribute to the content of the site and even have the power to create their own pages. In our case, we submitted our homework on it, and we could have other people review and edit it (and keep track of the changes). We had a glossary that we kept building, and we had our own journals, and it worked really well for us, until the end, when we had so much content that we actually slowed the server down.

The best part is that it's pretty easy to set up, really easy to use (once you get the hang of it), and really cool for everyone involved.

This is the site for it http://c2.com/cgi/wiki

He's talkin about MD5 hashing of small sections, as someone suggested the other day here.

If you actually have the source code, there are other fairly quick ways to find copy & pastes, eg the BWT-based method I implemented in CPD.

That method is pretty fast - it mainly depends on the file scanning time, not the sort we used to find the duplicates (eg using a suffix tree sort instead of quicksort won't gain you much here). However its a bit of a memory hog. I originally wrote the algorithm in perl, though, and it used a lot less - it would probably work on something the size of Linux.

I've come up with a new variation based on rysnc that will be quicker than the original MD5 suggestion, still requires no access to the original source, and sucks a hell of a lot less memory than the BWT method. Its also possible to do incremental checks (extremely quickly) using this method, something we couldn't do before.

There are other interesting techniques based on gzip and the like if this kind of thing interests you.

Lisp's elegance comes from the fact that there are so few constructs in the language,

and basically everything is a list

(OK, that's enough to prove I'm a SmugLispWeenie, I guess ... ;-)

But they're basically just lists, that's all. So you have this wonderful flexibility, but the parse tree doesn't actually tell you very much about the program; you have to "parse the parse tree" to recognize higher-level constructs.

Moral: Lisp is very, very, very cool, but it has not already done everything every other language is doing. So yes, it may sound familiar from you Lisp book, but it's not the same.

Are these additions "language-level constructs"? Hard to tell. The syntax the programmer deals with is just as if it were, even if everything eventually gets expressed in lower-level terms. The distinction is just not meaningful in Lisp - there just is no hard barrier between the language designer and the user, Lisp users design their language all the time.

Man, this has been done 30 freaking years ago already. Lisp (yeah, remember the parentheses?) has had this from day 1 essentially. walk the Wiki on this.

Then again, it's sort of redundant to mention the PPR in this story, since it tends to turn up in Google searches.

Bartleby.com has all kinds of reference books available, and lots of other stuff online. Like all of the Harvard Classics.

I'm suprised I'm the first to mention Project Gutenberg. Maybe people don't think of it as a reference site, since mostly it's good for downloading whole public-domain texts. But various volunteers (including me) are now in the process of proofreading the famous Britannica 11th Edition for inclusion in the Gutenberg set. At the current rate, it'll be done in about a year. But perhaps with more volunteers...

There's NOTHING wrong with being taught something for its own sake.

Actually, I'd say that there is. There's nothing wrong with learning a subject for its own sake or with studying a subject for its own sake.

However, "being taught" is something entirely different. (hint: it's passive voice; who's the actor?) I'll not argue the point much further (I've actually got other things to do than slashdot), but rather just point you to this wiki entry and encourage you to read the results of a a google search on "unschooling".

SourceForge is a Very Bad Idea (tm) at this point.

The only source code that is available is almost two years old, and the SourceForge.net people have intentionally killed further outside development of the official SourceForge project.

The current version of SourceForge is *not* available as source, at least, not without paying big bucks. In other words, it's no longer open source. Of course, SourceForge.net will squirm and twist things like there's no tomorrow to get away with not admitting that they closed SourceForge.

Additionally, the version of SourceForge that is available is unbelievably difficult to set up, doesn't run very well, and is very SourceForge.net specific. It's set up to run on PostgreSQL, and yet all the documentation (what (very) little there is) talks about MySQL.

If you want something like SourceForge, only more oriented towards a smaller, more private, organization, you should investigate GForge. GForge is a much reworked fork of SourceForge. The fork was started by Tim Purdue, one of the original, and primary, authors of SourceForge, and is now being actively developed by the community.

GForge has also had it's goals and orientation changed slightly from SourceForge's. SourceForge was designed to work as a huge farm, managing hundreds of thousands of users and programs. A huge portion of it's functionality is superfluous and overly complicated. GForge is a simplified and better organized application designed specifically for use by smaller groups and companies for their own projects.

Personally, for what it sounds like the original poster is looking for, I'd recommend GForge coupled with a good Wiki. That should cover almost everything he needs.

Most of Microsoft's value-add has been stolen^h^h^h^h^h^hcopied or acquired.

I continually wonder when people who continually spout the nonsense you do are going to wake up and realise that the thousands of developers and researchers employed by Microsoft aren't just sitting there and playing Minesweeper all day.

Yes, MS sometimes buys products off other companies. So does Apple (Logic and Shake, and of course NeXT/BSD). So does IBM (Lotus, Informix). Furthermore, MS puts enough development into those products that they properly evolve: the current version of SQL Server retains no remaining code from Sybase (which the original version was based on). But WinNT was a completely new OS, not based on VMS (though it was designed by VMS's lead architect).

The idea that MS never innovates is just nonsense. Examples like their using a WIMP GUI (which, if you recall, was ripped off from Xerox by many different OS companies, yet no one ever accused Amiga of not innovating) are total red herrings, especially given the number of times that the Windows UI has been ripped off by others. (Mac OS X dock = shinier Win98 taskbar, and all the things that GNOME/KDE have ripped off)

It's almost always possible to take any computing innovation and point to a precursor, saying "Ah, that's not new, look - it's just an evolution of that previous thing." But "Just" Is A Dangerous Word.

The reason MS has a this reputation is that it rarely innovates in big ways, just as creating new markets or completely new types of products. This is not from lack of innovative ability (spend half an hour wandering through Microsoft Research and realise just how innovative they can be) but from a corporate philosophy of deliberately not pioneering technology advances. Remember that they've been burnt in the past (Windows For Pen, anyone? And MS Bob, of course) - the saying "Pioneers are the ones with the arrows in their backs" is a very wise one for the tech industry. Much better to let someone else take the risk and prove the market before moving in.

However, while MS rarely innovates in new product types, it does innovate in small product features - IntelliSense and Cleartype (sub-pixel rendering had research precursors, but had never been part of a windowing system before) are two examples that stick in my mind. But the reason they stick is because MS actually gave them names and touted them as innovations, which it doesn't often do.

To summarise: MS develops and produces thousands of products. To pull a couple of ancient examples and claim that this shows MS does nothing other than sell boxes makes me wonder if you know anything about the company besides what you read on Slashdot.

-- Yoz

JustIsaDangerousWord is a relevant page too. Maybe more so.

Ward Cunningham's Wiki on Patterns has an interesting page on the attitude of referring to details as *just* details.

Very often, the person saying "Oh you just did it this way" has some more learning to do.

Ward Cunningham's Wiki on Patterns has an interesting page on the attitude of referring to details as *just* details.

Very often, the person saying "Oh you just did it this way" has some more learning to do.

If you haven't already read them, find something by Cory Doctorow (he's made his novel Down and Out in the Magic Kingdom freely available if you don't want to buy it, but it's worth it) or Charles Stross. Another good author more hyperpunk than cyberpunk is Eric Nylund; his two novels Signal to Noise and A Signal Shattered are great. I find picking up an anthology like The Year's Best Science Fiction helps me find authors whose work might interest me; that's how I found Charles Stross's work, at any rate. There are plenty of others out there, go digging around and you'll find tons of pointers on the Web for what to read.

.NET CLR is based on Colusa software's language-neutral OmniVM, a part of their Omniware product. OmniVM was based on research carried out by Steven Lucco at Carnegie Mellon University. Steven co-founded Colusa Software in February 1994 in Berkeley, California. Omniware was released in August 1995. Colusa started working with Microsoft in February 1996. Microsoft acquired Colusa Software on March 12, 1996. Steven is currently a senior researcher at the Microsoft Bay Area Research Center.

OmniVM was appealing to Microsoft because Colusa had already created Visual Basic and C/C++ development environments for the VM. The VM was also claimed to be capable of running Java. Microsoft took to calling the VM by the name of CVM, presumably for Colusa Virtual Machine. Or perhaps this is where the code name Cool came into being. Other names used at Microsoft include Universal Virtual Machine (UVM), and Intermediate Language (IL).

Microsoft denies rumors that C# went by the code name Cool, however there have been many apparent slip-ups by Microsoft employees where the word Cool is used in code snippets, file paths, etc.

As every induhvidual knows: http://c2.com/cgi/wiki?CowOrker

> So hackers start original, and get good, and scientists start good, and get original.

Then what are hello world programs?

I'd say anyone writing a 'hello world' program is hardly a hacker... 'Hello world' programs are used to get into the mood of a new language, a new environment, a new way of thinking, not to grow out as true programs (even though they often do so) (check out what the WikiWikiWeb has to say about this).

Regarding programs and programming, "this guy" has been programming and hacking for so long that he has probably forgotten more things about it than we can never dream to learn nowadays.

Not only he created one of the few successful dotcoms in the big bubble, he's written many books on programming (in LISP), and is actually creating his own version of a modern LISP dialect for Web and nowadays programming requirements. (and writing bayesian filters out of it)

One should know what's going to say is about before saying it.

peace

Wiki is a good an accessible way to generate content. The language is very intuitive (not as hard as HTML), and if even it was intended for open collaborative generation of content, there are a lot that provides authentication, ACLs, etc (i.e. TikiWiki provides a good portal system with easy administration and wiki as content generation language).

...the idea for Programmer How Tos?

sorry, that link is: http://c2.com/cgi/wiki?ChuckMoore

Not too long ago, I made a right-handed dvorak keyboard for my Dad, who had a stroke 3 years ago.

If you're in the US, just drop in on a Goodwill store and pick up a keyboard with interchangeable keys. Find your nearest flat-head screwdriver, and commence to modding.

If you need to get up to speed using it, check out KP Typing Tutor. It's free.

And I'm sure you can find a mod'able keyboard with a matching key cover as well ;)

• Wing IDE
• eric3
• Visual Python
• Others...

But only if you want to end up with a program that is already out of date.

(If you specify a program and it takes six months to write, then you end up with a program that's doing what you wanted six months ago. But instead if you specify it while it's being written, and release it often, and allow change (and plan for change, and dare I say embrace change), then you'll end up with a program that does what you want today.)

If you pair promiscuously (i.e., change pairs many times a day) you'll transfer knowledge between many people.

If you pair promiscuously (i.e., change pairs many times a day) you'll transfer knowledge between many people.

... And now I find the links: Lord of the Flies, Programming Outside The Cube. I really hope this helps, I'd hate to be hearded like cattle into a cube farm.

... And now I find the links: Lord of the Flies, Programming Outside The Cube. I really hope this helps, I'd hate to be hearded like cattle into a cube farm.

A good discussion on how to survive a cube farm (and things to look out for when designing them) from The Wiki Programming Outside The Cube

I don't think this article is a troll. I think its just sadly misguided. I appreciate much of the sentiment though: for the average computer user (who is not technically inclined) the variety of choices offered by OSS is intimidating, and the perceived (or actual) poor quality (or state of completion) of much of this software is effecting efforts to bring OSS to the masses.

This is, however, not the fault of developers. OSS is doing what it was always intended to do, and doing it better than ever. Developers are encouraged to experiment, build and contribute, in whatever way they like. The fault lies in the presentation of OSS software by distributors and major hosting sites, for example RedHat and SourceForge.

RedHat comes on 4 CDs. A first-time user is given more than ample opportunity to shoot themselves in the foot with options, and to choose to use software that is "sub-standard" by general commercial standards. This makes the software look bad, and that reflects on OSS as a whole.

SourceForge and FreshMeat, in searching and browsing, do not by default filter out pre-release software. Worse (IMHO) they do not have a facility to rate software (as is common on shareware sites). That makes it difficult to chose a stable, functional and quality piece of software for a particular purpose. The filtering mechanisms (other than rating) exist, but are not newbie-proof by default.

The message here is that OSS needs to prevent a user- or market-friendly outward appearance, instead of defaulting to hard-core developer modes.

To address two particular issues in the article to which I take exception:

Why gTk? Qt is older and more complete, Wx beats Qt in maturity and comes close to matching it in functionality. Wx also supports many more platforms than gTk, making it far more suitable for cross-platform development -- something OSS needs to support if its platforms are to attact commercial attention. The Wx license is also far more friendly to commercial development than gTk (or Qt).

I am making the implicit statement that commercial == proprietary, because this is how most of the world operates, and that isn't going to change any time soon. Sure, there is software that doesn't follow this model. But not a lot of it.

Next, the idea that all editors should support the OpenOffice format. Besides the fact that many of these editors predate OpenOffice, again have the question: why? What makes the OpenOffice format superior? Is it because it is based on a sucky data encoding failure called XML? Why not use a mature and powerful DTP standard like Tex?

Years of experience has shown that the golden goal of application interoperability is just not going to happen. Innovation demands going beyond standards and what has been done before. This is the only way that software -- OSS or proprietary -- has been able to progress over time. Linux's attraction compared to traditional Unix platforms comes from its differences.

It will help keep them focused on writing something that works correctly, and writing only what is needed. It should also keep them from wasting hours trying to figure out why something isn't working.

The Midas functionality looks really exciting, particularly for "Wiki"-like tools - no more ugly customized Wiki syntax!

WhyWikiWorks claims that the lack of wysiwyg editing on wikis is important for keeping the signal-to-noise ratio high. I wonder if using non-HTML text markup helps too.

On the other hand, wysiwyg editing would be great for Slashdot -- it's hard to lower the signal-to-noise ratio here.

On the topic of email spam, please take a look at my signature. It's a good practical elegant partial solution to the problem. And it's free (it's actually non-profit volunteer effort).

How about blocks in Java, or functors in the Jakarta Commons Sandbox?

You seem to be ignorant about something: both Perl and VB are Turing Complete languages, plus VB is a (native) compiled language since version 5, and if you count P-code, since forever (if Java is allowed to be a compiled language yet run on a VM, why can't VB P-code be considered compiled? Also, the VB compiler runs a couple of steps, first a translation of the code into something the VC++ compiler understands, then the compilation is done using the VC++ compiler (since version 5, and when native compilation is enabled). Hell, there may be a Perl compiler out there somewhere as well.

What I am trying to get at is there isn't any difference between most "programming" languages and "scripting" languages - they are all programming languages - it does not matter if the source is directly interpreted, compiled to p-code (or other byte-codes) and interpreted, or compiled to native machine code (which, BTW, is on most current processors *still* interpreted - ever hear of microcode?). There are scripting "languages" out there that have the C/C++ syntax - would a C scripter be any less of a application developer than a C programmer? Any language can be a scripting language, and just about any scripting language can be a programming language.

The only types of scripting languages that anyone could even think about rightfully "sneering" at would be a non-Turing Complete one - but in the end who gives a care if the application is developed, works, and satifies the client's needs? THAT is what matters in the end.

Oh, and BTW - I code in VB, and very well I might add (among other languages I know - I am programmer first, VB coder second)...

• http://www.zmag.org/pelac.htm
• http://www.parecon.org/
• http://www.zmag.org/lac.htm
• http://www.c2.com/cgi/wiki?ParticipatoryEconomics

Open source was originally free software. The people who tried to trademark "open source" wrote an Open Source Definition, which coincidentally, is really really close to the Debian Free Software Guidelines.

The term "Open Source" came about to try to cure the constant confusion people had with "free software" being free-beer or free-freedom. Obviously, "open source" has the same potential for confusion, as demonstrated by your response... it seems that another page of your source disagrees with you. In practice, people use "open source" to refer to practically anything under the sun where source is concerned, but you really shouldn't correct someone who is using a term more closely to to the original spirit than you are.

How so? OSS should never rely on patented or copyrighted code, otherwise it is not truly open source.

What? You are obviously suffering from some confusion.
Open source is NOT free software. Open source software is software where you can see & play with the source. FREE software, like public domain or BSD licenced software is free like freedom. Read this for further clairification.

That aside, EVERY piece of GPL'd code is copyrighted, as is BSD licenced code.
Patents are another issue entirely. There are countries that do not recognize business or software patents. It is the user that is limited in countries where the patent is valid, not the software.

Here's a prediction: the moment you succeed in making the distinction between "user" and "programmer" disappear, most of your potential users will disappear with it. Almost all of them who are not also programmers (in the old, pre-disappearance-of-the-distinction-between-users -and-programmers, sense), in fact.

Configurable desktops give users choices, and users like choices provided they're easy to make and easy to undo. Programming is about making decisions which are often hard to make and hard to undo. Unlike selecting a theme for a desktop, which is a matter of taste and the whim of the moment, programmers have to try to get lots of complicatedly interdependent things right in ways that matter.

I look forward to the first release of Tunes - hopefully some time before my retirement - with great anticipation, but at best such "entirely new software architectures" will empower some users do some things that they used to need to be programmers to do.

About two years ago I bagan using an XP style approach, or at least adopted many of the practices. Most notably Unit Tests with a Test First approach. Coded Functional Tests and Continuous Integration

To answer your questions one by one:

* the industry you are in

Financial Industry ( focusing on real-time trading application in the options, futures, and equity industries )

* the kind of project

Mostly applications that either provide infrastructure for doing electronic trading, or applications that implement particular trading strategies.

* how it was done before

The sorts of applications I would work on were often quick prototypes that were meant to exploit an opportunity in the market. This would often mean lots of shortcuts were taken because chances are the code would be thrown away anyway. Problem is that once in a while an application will become become succesful and grow out of one of these prototypes. Since little time was available for proper design, such applications generally became a maintenance nightmare as they kept growing. XP solved this problem by provideing a framework that allowed me to only design what I need when I need it, but enabled me to radically alter the design if ever necessary.

* what prompted you to make the switch to XP

I was exposed to it by some people who were working on a project at my company. I found many of the practices allowed me to create "prototypes" just as quickly as before, but with a higher degree of reliability and a framework that allowed them to grow as requirements changed. I was really sold on it when I saw how simply I was able to implement pieces of functionality that had previously just seemed more complicated.

Pair Programming gets a lot of flak. But really I fully credit it for getting me interested in these techniques. Because I generally paired with someone who knew these practices better than me, I was able to actively see the value of these practices while writing production code. It was far more of an eye opener than reading any book or article.

A lot has been said about Pair Programming that is just not true. It does NOT mean that there is one computer for every two people. Everybody has a machine. Just because you try to write all production code in pairs doesn't mean that everything is done in pairs. Also, you do not get paired up with someone like a ball an chain. Pairs switch, sometimes several times a day. Pairs are NOT assigned. If I need to write an ordermatching algorithm and I've never done it before, I'm going to try to pair with someone who has. By the time we are done with the task, we now have two people who know how to write an ordermatching algorithm. It's also untrue that one person is the designated typer while the other one just sits back and criticizes. Both people type, switching sometimes several times a minute while designing a class or method. Code is typed as a way to communicate concepts. If I want to convey the direction I think something should go, I write a little code. If the pair has another idea, he'll start tapping his ideas in the keyboard. It's a very actively collaborative process.

* how that switch work and how long it took

I haven't yet seen a project switch to an XP style process without problems, and from what I understand is that it is possible but slow. Part of the problem is that people who switch often do so from a less test-centric approach. This makes it difficult as XP is so reliant on aggressive testing to be succesful. It is also a new concept for many developers to take responsibility of some of the testing that has traditionally been soley in the domain of QA.

* and how things have been since moving to XP

Like I said, I have not been involved in a switch, but can speak about the difference I've seen between similar projects. One problem that I've solved in both a non-XP approach and an XP approach is in implementing the FIX protocol.

This protocol is relatively simple, but it is rife with various possibilities for boundry errors, off by one errors, and complicated resend logic. The big difference I found is that I never broke old logic when modifying the code. Generally when doing development, you are only testing the piece of functionality you are working on, so you get that working, but you break something else. This might not be discovered for quite some time. With an XP approach, while developing, you test everything you've ever tested. You find out immediately if your changes break old code.

Not only this, but despite the overhead of writing tests, I found functionality was implemented quicker, more reliably, and far simpler. Some of this was because I learned from previous mistakes, but primarily it was due to a different way to approach a problem.

* do you know others doing XP, if so how many

Yes. But they all do it a little differently. I have not seen two XP projects that look exactly the same. The core value I always see is the emphasis on repeatable tests.

About two years ago I bagan using an XP style approach, or at least adopted many of the practices. Most notably Unit Tests with a Test First approach. Coded Functional Tests and Continuous Integration

To answer your questions one by one:

* the industry you are in

Financial Industry ( focusing on real-time trading application in the options, futures, and equity industries )

* the kind of project

Mostly applications that either provide infrastructure for doing electronic trading, or applications that implement particular trading strategies.

* how it was done before

The sorts of applications I would work on were often quick prototypes that were meant to exploit an opportunity in the market. This would often mean lots of shortcuts were taken because chances are the code would be thrown away anyway. Problem is that once in a while an application will become become succesful and grow out of one of these prototypes. Since little time was available for proper design, such applications generally became a maintenance nightmare as they kept growing. XP solved this problem by provideing a framework that allowed me to only design what I need when I need it, but enabled me to radically alter the design if ever necessary.

* what prompted you to make the switch to XP

I was exposed to it by some people who were working on a project at my company. I found many of the practices allowed me to create "prototypes" just as quickly as before, but with a higher degree of reliability and a framework that allowed them to grow as requirements changed. I was really sold on it when I saw how simply I was able to implement pieces of functionality that had previously just seemed more complicated.

Pair Programming gets a lot of flak. But really I fully credit it for getting me interested in these techniques. Because I generally paired with someone who knew these practices better than me, I was able to actively see the value of these practices while writing production code. It was far more of an eye opener than reading any book or article.

A lot has been said about Pair Programming that is just not true. It does NOT mean that there is one computer for every two people. Everybody has a machine. Just because you try to write all production code in pairs doesn't mean that everything is done in pairs. Also, you do not get paired up with someone like a ball an chain. Pairs switch, sometimes several times a day. Pairs are NOT assigned. If I need to write an ordermatching algorithm and I've never done it before, I'm going to try to pair with someone who has. By the time we are done with the task, we now have two people who know how to write an ordermatching algorithm. It's also untrue that one person is the designated typer while the other one just sits back and criticizes. Both people type, switching sometimes several times a minute while designing a class or method. Code is typed as a way to communicate concepts. If I want to convey the direction I think something should go, I write a little code. If the pair has another idea, he'll start tapping his ideas in the keyboard. It's a very actively collaborative process.

* how that switch work and how long it took

I haven't yet seen a project switch to an XP style process without problems, and from what I understand is that it is possible but slow. Part of the problem is that people who switch often do so from a less test-centric approach. This makes it difficult as XP is so reliant on aggressive testing to be succesful. It is also a new concept for many developers to take responsibility of some of the testing that has traditionally been soley in the domain of QA.

* and how things have been since moving to XP

Like I said, I have not been involved in a switch, but can speak about the difference I've seen between similar projects. One problem that I've solved in both a non-XP approach and an XP approach is in implementing the FIX protocol.

This protocol is relatively simple, but it is rife with various possibilities for boundry errors, off by one errors, and complicated resend logic. The big difference I found is that I never broke old logic when modifying the code. Generally when doing development, you are only testing the piece of functionality you are working on, so you get that working, but you break something else. This might not be discovered for quite some time. With an XP approach, while developing, you test everything you've ever tested. You find out immediately if your changes break old code.

Not only this, but despite the overhead of writing tests, I found functionality was implemented quicker, more reliably, and far simpler. Some of this was because I learned from previous mistakes, but primarily it was due to a different way to approach a problem.

* do you know others doing XP, if so how many

Yes. But they all do it a little differently. I have not seen two XP projects that look exactly the same. The core value I always see is the emphasis on repeatable tests.

About two years ago I bagan using an XP style approach, or at least adopted many of the practices. Most notably Unit Tests with a Test First approach. Coded Functional Tests and Continuous Integration

To answer your questions one by one:

* the industry you are in

Financial Industry ( focusing on real-time trading application in the options, futures, and equity industries )

* the kind of project

Mostly applications that either provide infrastructure for doing electronic trading, or applications that implement particular trading strategies.

* how it was done before

The sorts of applications I would work on were often quick prototypes that were meant to exploit an opportunity in the market. This would often mean lots of shortcuts were taken because chances are the code would be thrown away anyway. Problem is that once in a while an application will become become succesful and grow out of one of these prototypes. Since little time was available for proper design, such applications generally became a maintenance nightmare as they kept growing. XP solved this problem by provideing a framework that allowed me to only design what I need when I need it, but enabled me to radically alter the design if ever necessary.

* what prompted you to make the switch to XP

I was exposed to it by some people who were working on a project at my company. I found many of the practices allowed me to create "prototypes" just as quickly as before, but with a higher degree of reliability and a framework that allowed them to grow as requirements changed. I was really sold on it when I saw how simply I was able to implement pieces of functionality that had previously just seemed more complicated.

Pair Programming gets a lot of flak. But really I fully credit it for getting me interested in these techniques. Because I generally paired with someone who knew these practices better than me, I was able to actively see the value of these practices while writing production code. It was far more of an eye opener than reading any book or article.

A lot has been said about Pair Programming that is just not true. It does NOT mean that there is one computer for every two people. Everybody has a machine. Just because you try to write all production code in pairs doesn't mean that everything is done in pairs. Also, you do not get paired up with someone like a ball an chain. Pairs switch, sometimes several times a day. Pairs are NOT assigned. If I need to write an ordermatching algorithm and I've never done it before, I'm going to try to pair with someone who has. By the time we are done with the task, we now have two people who know how to write an ordermatching algorithm. It's also untrue that one person is the designated typer while the other one just sits back and criticizes. Both people type, switching sometimes several times a minute while designing a class or method. Code is typed as a way to communicate concepts. If I want to convey the direction I think something should go, I write a little code. If the pair has another idea, he'll start tapping his ideas in the keyboard. It's a very actively collaborative process.

* how that switch work and how long it took

I haven't yet seen a project switch to an XP style process without problems, and from what I understand is that it is possible but slow. Part of the problem is that people who switch often do so from a less test-centric approach. This makes it difficult as XP is so reliant on aggressive testing to be succesful. It is also a new concept for many developers to take responsibility of some of the testing that has traditionally been soley in the domain of QA.

* and how things have been since moving to XP

Like I said, I have not been involved in a switch, but can speak about the difference I've seen between similar projects. One problem that I've solved in both a non-XP approach and an XP approach is in implementing the FIX protocol.

This protocol is relatively simple, but it is rife with various possibilities for boundry errors, off by one errors, and complicated resend logic. The big difference I found is that I never broke old logic when modifying the code. Generally when doing development, you are only testing the piece of functionality you are working on, so you get that working, but you break something else. This might not be discovered for quite some time. With an XP approach, while developing, you test everything you've ever tested. You find out immediately if your changes break old code.

Not only this, but despite the overhead of writing tests, I found functionality was implemented quicker, more reliably, and far simpler. Some of this was because I learned from previous mistakes, but primarily it was due to a different way to approach a problem.

* do you know others doing XP, if so how many

Yes. But they all do it a little differently. I have not seen two XP projects that look exactly the same. The core value I always see is the emphasis on repeatable tests.

About two years ago I bagan using an XP style approach, or at least adopted many of the practices. Most notably Unit Tests with a Test First approach. Coded Functional Tests and Continuous Integration

To answer your questions one by one:

* the industry you are in

Financial Industry ( focusing on real-time trading application in the options, futures, and equity industries )

* the kind of project

Mostly applications that either provide infrastructure for doing electronic trading, or applications that implement particular trading strategies.

* how it was done before

The sorts of applications I would work on were often quick prototypes that were meant to exploit an opportunity in the market. This would often mean lots of shortcuts were taken because chances are the code would be thrown away anyway. Problem is that once in a while an application will become become succesful and grow out of one of these prototypes. Since little time was available for proper design, such applications generally became a maintenance nightmare as they kept growing. XP solved this problem by provideing a framework that allowed me to only design what I need when I need it, but enabled me to radically alter the design if ever necessary.

* what prompted you to make the switch to XP

I was exposed to it by some people who were working on a project at my company. I found many of the practices allowed me to create "prototypes" just as quickly as before, but with a higher degree of reliability and a framework that allowed them to grow as requirements changed. I was really sold on it when I saw how simply I was able to implement pieces of functionality that had previously just seemed more complicated.

Pair Programming gets a lot of flak. But really I fully credit it for getting me interested in these techniques. Because I generally paired with someone who knew these practices better than me, I was able to actively see the value of these practices while writing production code. It was far more of an eye opener than reading any book or article.

A lot has been said about Pair Programming that is just not true. It does NOT mean that there is one computer for every two people. Everybody has a machine. Just because you try to write all production code in pairs doesn't mean that everything is done in pairs. Also, you do not get paired up with someone like a ball an chain. Pairs switch, sometimes several times a day. Pairs are NOT assigned. If I need to write an ordermatching algorithm and I've never done it before, I'm going to try to pair with someone who has. By the time we are done with the task, we now have two people who know how to write an ordermatching algorithm. It's also untrue that one person is the designated typer while the other one just sits back and criticizes. Both people type, switching sometimes several times a minute while designing a class or method. Code is typed as a way to communicate concepts. If I want to convey the direction I think something should go, I write a little code. If the pair has another idea, he'll start tapping his ideas in the keyboard. It's a very actively collaborative process.

* how that switch work and how long it took

I haven't yet seen a project switch to an XP style process without problems, and from what I understand is that it is possible but slow. Part of the problem is that people who switch often do so from a less test-centric approach. This makes it difficult as XP is so reliant on aggressive testing to be succesful. It is also a new concept for many developers to take responsibility of some of the testing that has traditionally been soley in the domain of QA.

* and how things have been since moving to XP

Like I said, I have not been involved in a switch, but can speak about the difference I've seen between similar projects. One problem that I've solved in both a non-XP approach and an XP approach is in implementing the FIX protocol.

This protocol is relatively simple, but it is rife with various possibilities for boundry errors, off by one errors, and complicated resend logic. The big difference I found is that I never broke old logic when modifying the code. Generally when doing development, you are only testing the piece of functionality you are working on, so you get that working, but you break something else. This might not be discovered for quite some time. With an XP approach, while developing, you test everything you've ever tested. You find out immediately if your changes break old code.

Not only this, but despite the overhead of writing tests, I found functionality was implemented quicker, more reliably, and far simpler. Some of this was because I learned from previous mistakes, but primarily it was due to a different way to approach a problem.

* do you know others doing XP, if so how many

Yes. But they all do it a little differently. I have not seen two XP projects that look exactly the same. The core value I always see is the emphasis on repeatable tests.

About two years ago I bagan using an XP style approach, or at least adopted many of the practices. Most notably Unit Tests with a Test First approach. Coded Functional Tests and Continuous Integration

To answer your questions one by one:

* the industry you are in

Financial Industry ( focusing on real-time trading application in the options, futures, and equity industries )

* the kind of project

Mostly applications that either provide infrastructure for doing electronic trading, or applications that implement particular trading strategies.

* how it was done before

The sorts of applications I would work on were often quick prototypes that were meant to exploit an opportunity in the market. This would often mean lots of shortcuts were taken because chances are the code would be thrown away anyway. Problem is that once in a while an application will become become succesful and grow out of one of these prototypes. Since little time was available for proper design, such applications generally became a maintenance nightmare as they kept growing. XP solved this problem by provideing a framework that allowed me to only design what I need when I need it, but enabled me to radically alter the design if ever necessary.

* what prompted you to make the switch to XP

I was exposed to it by some people who were working on a project at my company. I found many of the practices allowed me to create "prototypes" just as quickly as before, but with a higher degree of reliability and a framework that allowed them to grow as requirements changed. I was really sold on it when I saw how simply I was able to implement pieces of functionality that had previously just seemed more complicated.

Pair Programming gets a lot of flak. But really I fully credit it for getting me interested in these techniques. Because I generally paired with someone who knew these practices better than me, I was able to actively see the value of these practices while writing production code. It was far more of an eye opener than reading any book or article.

A lot has been said about Pair Programming that is just not true. It does NOT mean that there is one computer for every two people. Everybody has a machine. Just because you try to write all production code in pairs doesn't mean that everything is done in pairs. Also, you do not get paired up with someone like a ball an chain. Pairs switch, sometimes several times a day. Pairs are NOT assigned. If I need to write an ordermatching algorithm and I've never done it before, I'm going to try to pair with someone who has. By the time we are done with the task, we now have two people who know how to write an ordermatching algorithm. It's also untrue that one person is the designated typer while the other one just sits back and criticizes. Both people type, switching sometimes several times a minute while designing a class or method. Code is typed as a way to communicate concepts. If I want to convey the direction I think something should go, I write a little code. If the pair has another idea, he'll start tapping his ideas in the keyboard. It's a very actively collaborative process.

* how that switch work and how long it took

I haven't yet seen a project switch to an XP style process without problems, and from what I understand is that it is possible but slow. Part of the problem is that people who switch often do so from a less test-centric approach. This makes it difficult as XP is so reliant on aggressive testing to be succesful. It is also a new concept for many developers to take responsibility of some of the testing that has traditionally been soley in the domain of QA.

* and how things have been since moving to XP

Like I said, I have not been involved in a switch, but can speak about the difference I've seen between similar projects. One problem that I've solved in both a non-XP approach and an XP approach is in implementing the FIX protocol.

This protocol is relatively simple, but it is rife with various possibilities for boundry errors, off by one errors, and complicated resend logic. The big difference I found is that I never broke old logic when modifying the code. Generally when doing development, you are only testing the piece of functionality you are working on, so you get that working, but you break something else. This might not be discovered for quite some time. With an XP approach, while developing, you test everything you've ever tested. You find out immediately if your changes break old code.

Not only this, but despite the overhead of writing tests, I found functionality was implemented quicker, more reliably, and far simpler. Some of this was because I learned from previous mistakes, but primarily it was due to a different way to approach a problem.

* do you know others doing XP, if so how many

Yes. But they all do it a little differently. I have not seen two XP projects that look exactly the same. The core value I always see is the emphasis on repeatable tests.