The framework was in public beta for over a year before it was actually released.... a lot of employers are looking for people who have watched the platform mature (or rather, go through puberty) in beta stages.
I knew that (I was mostly asking that other kind of question). Still, it flusters me. The message of the job market seems to be, "If you ever get off the Microsoft treadmill, even for a moment, even for a beta... you're toast."
It's bundled with the iBook but not the TiBook; which makes the purchase of the $200 Microsoft Office.X pretty much mandatory. I know you can buy AppleWorks for $79, but once you've committed to spend that much, the extra $121 for the larger package seems a better investment.
Which seems a shame; from what I can tell, AppleWorks seems pretty full featured, a good way to avoid paying "the Microsoft tax." (They even offer a cross-platform version that runs under both Mac OS and Windows, but only for educational customers.)
Everyone's assuming the appropriate rules here are from copyright law, which allow you to protect the expression of an idea but not the idea itself. That's probably right. It's not the way some big organizations want to play.
In the United States, most major sports leagues (NFL, NBA, NHL, MLB, etc.) believe that they own the rights to real time scores, and can permit or restrict any desired use. I ran into this at a previous job: we could "broadcast" football, basketball, and hockey scores at the end of every "period," and baseball scores at the end of every half inning, but we couldn't send updated broadcasts for every new score. That information needed (so said the leagues) to be licensed, and most of it had been exclusively licensed for the medium (Internet) we were interested in.
Do they have a legal leg to stand on? No. (IANAL.) Are they leaning on a great, big, huge stick with nails driven through it? Apparently.
The interesting thing is the way that free-software ideas have begun to influence major existing commercial players.
What he doesn't say, what few people remember, is that Bell Labs distributed Unix (including source!) widely to universities across the world. Some folks changed the source and re-released it (BSD); some changed the source and didn't re-release it except as a non-free binary (Sun and others, though they probably needed commercial licenses from AT&T); some took only the ideas and then used them in other projects (VMS, and eventually Microsoft Windows).
Here's my take on Dr. Ritchie's position: He's distributed code that was free and open source, without much of a license at all, and with no ideology attached, and it changed the world. He's watched Richard Stallman and others do sort of the same thing; the technology and the impact have been good, and maybe he's not sure the other stuff is as big a deal as people make it out to be.
This doesn't make DMR better than RMS, or worse; they reached similar destinations but took different paths. Some people are bothered by that. Some aren't.
I've dealt with Dr. Ritchie professionally. He is an incredibly open, honest, brilliant, and modest guy; he has a strong commitment to "the right thing" getting done, but without a lot of fuss or noise.
Okay, an iMac is very cool looking, it's got an LCD screen (possibly 17") instead of a (flat 17") CRT, some models have a GeForce4 MX instead of a GeForce2 MX, the CPUs are usually faster (800 MHz or 1 GHz instead of 700 or 800 MHz)... and, comparing (sorry) apples to apples, it's hundreds of dollars more expensive than a comparable eBook.
If you make a really good movie, people will show up next time.
If you make a really good movie and then a really bad movie, people will show up at least one more time. (Example: STAR TREKs IV, V, and VI.)
If you make a mediocre movie, fewer people will show up next time. (To some degree, a really bad movie is less harmful, since people hope it's a fluke, and the film makers might try harder afterwards.) Two in a row, even more so.
If you make a movie where I have to turn my brain off in order to ignore the inconsistencies -- if you think shiny things and loud noises are enough to keep me in my seat -- somebody may show up next time, but it won't be me.
Since when was lowering Microsoft's prices a major objective of OSS?
Lowering Microsoft's prices, thus levelling the playing field and letting the best product win... these are all objectives of the Open Source movement.
They are not objectives of the Free Software movement, whose goal is to convince everyone that all software should be both gratis and libre.
One source of criticism for the Open Source movement is that it concentrates too little on idealism and too much on pragmatism. That's also one source of praise.
Sun: You've licensed Java; you can distribute it, but you can't modify it.
Microsoft: Yes, we can; we're Microsoft.
Judge: Now you have to distribute it.
Microsoft: No, we don't; we're Microsoft.
Microsoft's "move" is to today replace Windows XP Service Pack 1 with a version without a JVM, and in June to also offer a version of the service pack with Sun's JVM. So far as I can tell, even in June, XP users who've already installed the service pack won't be able to get Sun's JVM from Microsoft, unless they re-install SP1 using the new version (if they're even able to do so).
Windows Server 2003, formerly Windows XP Server, is (according to Microsoft) "not impacted by the District Court's order and will include neither the Microsoft Virtual Machine nor Sun's JRE."
Like a lot of people here, I don't get it the point. Cross compilers are for developing for platforms that can't host development tools. When I did cross platform (Windows, Solaris, HP-UX) development, my tools were Vim and CVS plus the native compiler. Which platform would I edit on? Whichever was most convenient that moment.
On the other hand, for those who want to use MinGW for Windows development, check out the GPL Visual-MinGW. Al Stevens had some very nice things to say about it in the December 2002 issue of Dr. Dobb's. (The article isn't online, but the issue's table of contents is here.)
There are some significant licensing differences between MinGW and Cygwin. The Cygwin runtime is GPL (not LGPL!), but can be licensed for non-open use. The MinGW runtime is public domain.
Not sure of it's been posted by anyone on the two threads, but here's a Radar Image of the debris rain being picked up by weather stations.
That image is labeled "15:26 UTC 02/01/2003". If I'm doing the math right (and Texas is on Central Standard Time, a.k.a. UTC -6:00), that's 9:26 local time, 10:26 Eastern... nearly an hour and a half after the orbiter was destroyed.
This Slashdot article from this morning points to this dramatic page, which shows a similar radar map, archived from about 13:00 to 17:00 UTC. The trail appears at 14:05 UTC, shortly after the breakup, and lingers for the remaining two hours of the loop. (The original poster said it "disappears so suddenly," but I think it's just the end of the loop.) I hacked the URL a little, and watched it last until almost 21:00 UTC, nearly seven hours after the incident.
So what is it? A line of dust-sized particles too light to fall? Some sort of condensation or thermal effect? (There are some other line-shaped artifacts in some frames, but nothing so dramatic.)
To call yourself an "engineer" in several of the states in the U.S., you must pass two licensing exams. Texas in particular has been known to come down hard on people who use that title without taking the exams and being a licensed engineer. That's why I call myself a "software developer" instead of a "software engineer" if I can help it.
First, a software engineer must be an engineer. I have a bachelor of science degree in physics and master of science degrees in mathematics and computer science. In most states, I cannot even take the licensing exams and never will be able to unless I go back to college and get a bachelor's degree in some engineering field from an ABET-acredited school. (In some states, anybody can take the exams. Either way, my "liberal arts" degrees don't count for anything. Some other states consider math, physics, and chemistry bachelor's degrees acceptable, but not computer science degrees.) At any rate, the exams cover general engineering: electrical, chemical, civil, mechanical, industrial. The goal is to ensure you're a well rounded engineer.
Second, some states (at the urging of the local professional engineering societies) think any "engineering" effort must have at least one licensed engineer. This is a bigger deal than it might first appear.
Sure, I'd like to see someone who knows civil engineering involved with every non-trivial bridge that's built, and if Union Carbide built a chemical plant next door, I'd like a chemical engineer to be checking things out. (See also below.)
However, sometimes (Texas again) embedded software development projects are considered close enough to "engineering" to require, under law, at least one licensed engineer to be involved. Those civil and chemical engineers are considered qualified; with a master's degree and twenty years of experience, I am not.
There are a handful software professionals who are licensed engineers. (Want to guess what state they're in?)
Having said all that, let me say this. All the traditional engineering fields have universally understood, univerally accepted bodies of knowledge, usual captured as some kind of code (as in "building code"). That's why I feel the way I do about bridges and chemical plants. On the other hand, while most individual software engineers think they have such a body of knowledge, no two agree on what it is. There is an effort to define this; a draft version "is ready for field trials for a period of two years."
Even a school that offers a "software engineering" degree says, "There is no universally accepted definition of software engineering, though there are elements of a forming consensus."
My humble opinion? Engineering disciplines have with good mathematical foundations: here's the equation for the tensile strength of steel, here's the formula for voltage as we increase power. Software development efforts do not have such a foundation. Some attempts have been made to provide one, but they're almost never applied.
On my Windows 98 SE box, I now browse with Phoenix almost all the time. I've discovered, though, that some browser downloads Internet Explorer asks me about, Phoenix installs automatically. (Phoenix seems a little too promiscuous about accepting Java, and doesn't remove.class files when it flushes the cache. Check the %WINDIR%/.jpi_cache/ directory structure.)
It's the kind of thing you might expect from a 0.5 release; unfortunately, it's not the kind of thing you should only expect from Microsoft.
Then user stories (what others call "use cases") must be the glass slipper. XP addresses this; read Planning Extreme Programming by Kent Beck and Martin Fowler (Amazon.com, BN.com).
XP also calls for "customer on site"; the theory is, it's far quicker to get answers in real time rather than waiting for someone to write a 600 page document.
THIS DOES NOT SCALE UP. You know it, I know it, Kent Beck probably knows it. Some of the other agile development methods try to address this.
I've done a little test-driven development on my own.
Test-driven development seems to call for a series of baby steps, each corresponding to a unit test case. Unfortunately, I wasn't always able to identify "the next baby step"; even if I could pick what I thought was the next unit test, I sometimes found myself spending far too much time, and writing far too much code, for just that next test.
I also sometimes found that "the next test case" already passed. I don't know if I wrote more than I needed to early on, or I picked the wrong next case, or if there's more to all this than I've picked up.
When I was in good TDD mode, I was flying; test, red, code, green, refactor, green, next! It's a very rapid, and very intense, experience. There's a reason XP usually calls for a 40 hour week; by the time you're done with a few hours of this, you are tired! (But you've gotten a lot done.)
it would be nice to have 2 developers for every problem
It would be even nicer if two developers working together were more than twice as productive as either of them working alone... but that's pair programming, a different XP practice, and a whole different book (Amazon.com, BN.com).
I just can't stand other people nozing around in my half completed code...
Then you ought to (1) try the other XP practices before you try pair programming, and (2) learn how pair programming really works!
... the extreme attention to testing...
You don't think testing is important???
... and the team-spirit you ought to have...
Check out the work of James O. Coplien. He's an extremely hard core C++ guy, but when he was doing research at Bell Labs, he descovered that organization effectiveness was far more important for software development productivity than any technological advance.
I once worked at a start-up where someone started on Monday, and never came back after Wednesday night, leaving a voice mail message that said, "You never told me I was going to have to work with other people!"
You're going to have to work with other people. The better you work with them, the better you work, the better everyone works. (Hugs not required.)
... some XP projects are successful is because they actually have testing as part of the game plan.... the XP folks have the testing thing down.
The best thing about XP is that, with the possible exception of test-first (a.k.a. test driven) development, none of the practices are new and original. I mean that in the best possible way! All the practices are tried and true, based on experience long before Kent Beck was using the word "extreme" this way.
Then they take leave of their senses.... Design first is still valuable...
"Design" in the pure waterfall sense -- do 100% of the requirements before doing any of the design, do 100% of the design before doing any of the coding -- doesn't scale up to large projects or rapid development. It's important to use an iterative approach: do a little analysis, do a little design, do a little coding, do a little testing, repeat until done.
XP breaks the design/coding/testing cycle into very small iterations, each one as big as one automated unit test case. It's a very exploratory style of software development. XP doesn't mandate any high-level design artifacts (though it doesn't forbid them either).
What none of the XP books say is that developing unit tests is a design activity, and the unit tests are design artifacts! Unit tests outline the responsibilites of classes, in the original responsibily-based style of object oriented design.
XP programmers do design on whiteboards, and in their heads. Some of these artifacts are lost. Some would have become obsolete in a hurry. (The unit tests are guaranteed not be obsolete, at least as long as they're passing.)
I'll take that, any day, over a hundred pages of out-of-date UML diagrams.
If there's literally zero time for anything but unit testing -- if the customer is saying, "you must deliver perfect code in this agressive timeframe" -- then the project is doomed. (Can you put it to them that way?) Find some way to accept the job without being seen as responsible for its inevitable failure.
You can't do "big design up front." I'm sure there's no way you'll get detailed immutable requirements. You're going to need lots of unit tests and lots of automated tests. (If you're description of the other trends is accurate, it's a given the customer will change their minds during this project. You already know you'll make mistakes and have to recover from them. That means you're going to make changes to working code, and will need to ensure your changes didn't break anything.) It's also a small project.
Extreme Programming isn't a good choice for all projects, but it sounds as if it might be for this project. If you look at the twelve practices of XP, most of them seem applicable.
Some of the practices won't apply. You can't "pair program" if you're working by yourself. I don't know how close you'll be to "on-site customer." The call for acceptance testing is one you'll need to deal with no matter what process you follow. (This is not the right setting to discuss 40 hour work weeks, so let's not concentrate on that one.)
On the other hand: Small releases and the planning game will get the most important work done first (i.e., when the schedule slips, it'll be less catastrophic than it might otherwise have been). Automated unit tests can speed development, and they are (XPers hardly ever say this) useful design artifacts in their own right.
Having said that, let me say this. Some of these practices take some time and experience to master. (Personally, I can't yet say I really "get" XP-style automated unit tests. I often run into cases where I can't find "the next test" that leads me in the right direction.) You won't be able to pick up Extreme Programming Explained (Amazon.com, BN.com) today and be a good Extreme Programmer tomorrow. Using a new process, even a good one, is like using a new programming language (even a good one): you'll be slower when you're climbing the learning curve. You may not be able to afford that on this project.
Finally, if you turn the job down, do so in a way that doesn't involve burning any bridges. Perhaps say you don't think anyone could succeed under the specified terms. You may yet be called in later if (when?) the first developer hired can't make it happen.
I guess this means MS will take the "You can't publish benchmarks about.NET" clause out of that EULA.
I guess it means Microsoft will fight New York even harder than Network Associates did. You've forgotten the first commandment of Redmond: Microsoft is never wrong!
Expect this decision to be appealed. How many companies will file amicus curiae ("friend of the court") briefs in support of Network Associates? I expect Microsoft (and Oracle, which I believe has similar clauses) will do so.
Slashdot Mirror
But I'm glad you've kept up.
It's bundled with the iBook but not the TiBook; which makes the purchase of the $200 Microsoft Office.X pretty much mandatory. I know you can buy AppleWorks for $79, but once you've committed to spend that much, the extra $121 for the larger package seems a better investment.
Which seems a shame; from what I can tell, AppleWorks seems pretty full featured, a good way to avoid paying "the Microsoft tax." (They even offer a cross-platform version that runs under both Mac OS and Windows, but only for educational customers.)
Everyone's assuming the appropriate rules here are from copyright law, which allow you to protect the expression of an idea but not the idea itself. That's probably right. It's not the way some big organizations want to play.
In the United States, most major sports leagues (NFL, NBA, NHL, MLB, etc.) believe that they own the rights to real time scores, and can permit or restrict any desired use. I ran into this at a previous job: we could "broadcast" football, basketball, and hockey scores at the end of every "period," and baseball scores at the end of every half inning, but we couldn't send updated broadcasts for every new score. That information needed (so said the leagues) to be licensed, and most of it had been exclusively licensed for the medium (Internet) we were interested in.
Do they have a legal leg to stand on? No. (IANAL.) Are they leaning on a great, big, huge stick with nails driven through it? Apparently.
Here's my take on Dr. Ritchie's position: He's distributed code that was free and open source, without much of a license at all, and with no ideology attached, and it changed the world. He's watched Richard Stallman and others do sort of the same thing; the technology and the impact have been good, and maybe he's not sure the other stuff is as big a deal as people make it out to be.
This doesn't make DMR better than RMS, or worse; they reached similar destinations but took different paths. Some people are bothered by that. Some aren't.
I've dealt with Dr. Ritchie professionally. He is an incredibly open, honest, brilliant, and modest guy; he has a strong commitment to "the right thing" getting done, but without a lot of fuss or noise.
For a minute there, I thought they'd announced a 17" iBook.
Dang.
Okay, an iMac is very cool looking, it's got an LCD screen (possibly 17") instead of a (flat 17") CRT, some models have a GeForce4 MX instead of a GeForce2 MX, the CPUs are usually faster (800 MHz or 1 GHz instead of 700 or 800 MHz) ... and, comparing (sorry) apples to apples, it's hundreds of dollars more expensive than a comparable eBook.
Am I missing something here?
If you make a really good movie, people will show up next time.
If you make a really good movie and then a really bad movie, people will show up at least one more time. (Example: STAR TREKs IV, V, and VI.)
If you make a mediocre movie, fewer people will show up next time. (To some degree, a really bad movie is less harmful, since people hope it's a fluke, and the film makers might try harder afterwards.) Two in a row, even more so.
If you make a movie where I have to turn my brain off in order to ignore the inconsistencies -- if you think shiny things and loud noises are enough to keep me in my seat -- somebody may show up next time, but it won't be me.
They are not objectives of the Free Software movement, whose goal is to convince everyone that all software should be both gratis and libre.
One source of criticism for the Open Source movement is that it concentrates too little on idealism and too much on pragmatism. That's also one source of praise.
Sun: You've licensed Java; you can distribute it, but you can't modify it.
Microsoft: Yes, we can; we're Microsoft.
Judge: Now you have to distribute it.
Microsoft: No, we don't; we're Microsoft.
Microsoft's "move" is to today replace Windows XP Service Pack 1 with a version without a JVM, and in June to also offer a version of the service pack with Sun's JVM. So far as I can tell, even in June, XP users who've already installed the service pack won't be able to get Sun's JVM from Microsoft, unless they re-install SP1 using the new version (if they're even able to do so).
Windows Server 2003, formerly Windows XP Server, is (according to Microsoft) "not impacted by the District Court's order and will include neither the Microsoft Virtual Machine nor Sun's JRE."
Like a lot of people here, I don't get it the point. Cross compilers are for developing for platforms that can't host development tools. When I did cross platform (Windows, Solaris, HP-UX) development, my tools were Vim and CVS plus the native compiler. Which platform would I edit on? Whichever was most convenient that moment.
On the other hand, for those who want to use MinGW for Windows development, check out the GPL Visual-MinGW. Al Stevens had some very nice things to say about it in the December 2002 issue of Dr. Dobb's. (The article isn't online, but the issue's table of contents is here.)
There are some significant licensing differences between MinGW and Cygwin. The Cygwin runtime is GPL (not LGPL!), but can be licensed for non-open use. The MinGW runtime is public domain.
"Never attribute to malice that which is adequately explained by stupidity." --Robert Hanlon ("Hanlon's Razor")
"Windows isn't done until Lotus won't run." --Microsoft Windows developers (circa early 1990s; quoted anecdotally)
This Slashdot article from this morning points to this dramatic page, which shows a similar radar map, archived from about 13:00 to 17:00 UTC. The trail appears at 14:05 UTC, shortly after the breakup, and lingers for the remaining two hours of the loop. (The original poster said it "disappears so suddenly," but I think it's just the end of the loop.) I hacked the URL a little, and watched it last until almost 21:00 UTC, nearly seven hours after the incident.
So what is it? A line of dust-sized particles too light to fall? Some sort of condensation or thermal effect? (There are some other line-shaped artifacts in some frames, but nothing so dramatic.)
Nothing shows up in the live radar map.
P.S.: The ucar.edu page just stopped responding. Slashdot effect?
To call yourself an "engineer" in several of the states in the U.S., you must pass two licensing exams. Texas in particular has been known to come down hard on people who use that title without taking the exams and being a licensed engineer. That's why I call myself a "software developer" instead of a "software engineer" if I can help it.
First, a software engineer must be an engineer. I have a bachelor of science degree in physics and master of science degrees in mathematics and computer science. In most states, I cannot even take the licensing exams and never will be able to unless I go back to college and get a bachelor's degree in some engineering field from an ABET-acredited school. (In some states, anybody can take the exams. Either way, my "liberal arts" degrees don't count for anything. Some other states consider math, physics, and chemistry bachelor's degrees acceptable, but not computer science degrees.) At any rate, the exams cover general engineering: electrical, chemical, civil, mechanical, industrial. The goal is to ensure you're a well rounded engineer.
Second, some states (at the urging of the local professional engineering societies) think any "engineering" effort must have at least one licensed engineer. This is a bigger deal than it might first appear.
Sure, I'd like to see someone who knows civil engineering involved with every non-trivial bridge that's built, and if Union Carbide built a chemical plant next door, I'd like a chemical engineer to be checking things out. (See also below.)
However, sometimes (Texas again) embedded software development projects are considered close enough to "engineering" to require, under law, at least one licensed engineer to be involved. Those civil and chemical engineers are considered qualified; with a master's degree and twenty years of experience, I am not.
There are a handful software professionals who are licensed engineers. (Want to guess what state they're in?)
Having said all that, let me say this. All the traditional engineering fields have universally understood, univerally accepted bodies of knowledge, usual captured as some kind of code (as in "building code"). That's why I feel the way I do about bridges and chemical plants. On the other hand, while most individual software engineers think they have such a body of knowledge, no two agree on what it is. There is an effort to define this; a draft version "is ready for field trials for a period of two years."
Even a school that offers a "software engineering" degree says, "There is no universally accepted definition of software engineering, though there are elements of a forming consensus."
My humble opinion? Engineering disciplines have with good mathematical foundations: here's the equation for the tensile strength of steel, here's the formula for voltage as we increase power. Software development efforts do not have such a foundation. Some attempts have been made to provide one, but they're almost never applied.
P.S.: I do not live or work in Texas.
On my Windows 98 SE box, I now browse with Phoenix almost all the time. I've discovered, though, that some browser downloads Internet Explorer asks me about, Phoenix installs automatically. (Phoenix seems a little too promiscuous about accepting Java, and doesn't remove .class files when it flushes the cache. Check the %WINDIR%/.jpi_cache/ directory structure.)
It's the kind of thing you might expect from a 0.5 release; unfortunately, it's not the kind of thing you should only expect from Microsoft.
XP also calls for "customer on site"; the theory is, it's far quicker to get answers in real time rather than waiting for someone to write a 600 page document.
THIS DOES NOT SCALE UP. You know it, I know it, Kent Beck probably knows it. Some of the other agile development methods try to address this.
I've done a little test-driven development on my own.
Test-driven development seems to call for a series of baby steps, each corresponding to a unit test case. Unfortunately, I wasn't always able to identify "the next baby step"; even if I could pick what I thought was the next unit test, I sometimes found myself spending far too much time, and writing far too much code, for just that next test.
I also sometimes found that "the next test case" already passed. I don't know if I wrote more than I needed to early on, or I picked the wrong next case, or if there's more to all this than I've picked up.
When I was in good TDD mode, I was flying; test, red, code, green, refactor, green, next! It's a very rapid, and very intense, experience. There's a reason XP usually calls for a 40 hour week; by the time you're done with a few hours of this, you are tired! (But you've gotten a lot done.)
I once worked at a start-up where someone started on Monday, and never came back after Wednesday night, leaving a voice mail message that said, "You never told me I was going to have to work with other people!"
You're going to have to work with other people. The better you work with them, the better you work, the better everyone works. (Hugs not required.)
XP breaks the design/coding/testing cycle into very small iterations, each one as big as one automated unit test case. It's a very exploratory style of software development. XP doesn't mandate any high-level design artifacts (though it doesn't forbid them either).
What none of the XP books say is that developing unit tests is a design activity, and the unit tests are design artifacts! Unit tests outline the responsibilites of classes, in the original responsibily-based style of object oriented design.
XP programmers do design on whiteboards, and in their heads. Some of these artifacts are lost. Some would have become obsolete in a hurry. (The unit tests are guaranteed not be obsolete, at least as long as they're passing.)
I'll take that, any day, over a hundred pages of out-of-date UML diagrams.
You should start with the The Color of Magic (Amazon.com, BN.com) and The Light Fantastic (Amazon.com, BN.com), and then probably Equal Rites (Amazon.com, BN.com) and Mort (Amazon.com, BN.com); after that, you can read the other books in the Diskworld series in any order (publication order would be preferred but not required).
Good stuff.
P.S.: Apologies to the rest of the world for pointers to U.S. sites and editions.
If there's literally zero time for anything but unit testing -- if the customer is saying, "you must deliver perfect code in this agressive timeframe" -- then the project is doomed. (Can you put it to them that way?) Find some way to accept the job without being seen as responsible for its inevitable failure.
You can't do "big design up front." I'm sure there's no way you'll get detailed immutable requirements. You're going to need lots of unit tests and lots of automated tests. (If you're description of the other trends is accurate, it's a given the customer will change their minds during this project. You already know you'll make mistakes and have to recover from them. That means you're going to make changes to working code, and will need to ensure your changes didn't break anything.) It's also a small project.
Extreme Programming isn't a good choice for all projects, but it sounds as if it might be for this project. If you look at the twelve practices of XP, most of them seem applicable.
Some of the practices won't apply. You can't "pair program" if you're working by yourself. I don't know how close you'll be to "on-site customer." The call for acceptance testing is one you'll need to deal with no matter what process you follow. (This is not the right setting to discuss 40 hour work weeks, so let's not concentrate on that one.)
On the other hand: Small releases and the planning game will get the most important work done first (i.e., when the schedule slips, it'll be less catastrophic than it might otherwise have been). Automated unit tests can speed development, and they are (XPers hardly ever say this) useful design artifacts in their own right.
Having said that, let me say this. Some of these practices take some time and experience to master. (Personally, I can't yet say I really "get" XP-style automated unit tests. I often run into cases where I can't find "the next test" that leads me in the right direction.) You won't be able to pick up Extreme Programming Explained (Amazon.com, BN.com) today and be a good Extreme Programmer tomorrow. Using a new process, even a good one, is like using a new programming language (even a good one): you'll be slower when you're climbing the learning curve. You may not be able to afford that on this project.
Finally, if you turn the job down, do so in a way that doesn't involve burning any bridges. Perhaps say you don't think anyone could succeed under the specified terms. You may yet be called in later if (when?) the first developer hired can't make it happen.
Good luck!
Expect this decision to be appealed. How many companies will file amicus curiae ("friend of the court") briefs in support of Network Associates? I expect Microsoft (and Oracle, which I believe has similar clauses) will do so.