Gravatite and I like to code Combsort when we're learning a new language. Combsort a very simple modification to bubblesort that makes it competative with Quicksort but without quite as much complexity -- it's good for those rare occasions where you have to hand-code a sort and don't need all the fuss of quicksort.
You might try reading the David Feintuch's "Midshipman's Hope" series. It's a grittier, darker, more believable world than the Honor Harrington series. It's not all happy-happy joy-joy blow-up-the-aliens, yet there is high adventure and enough of a dose enough of hope that it's not "literature" a la 1984, On The Beach, etc. Very good read.
Way back in the day, I had a 1k SRAM that I had abused in every which way possible. It ended up in my TRS-80 to give it lowercase. It mostly worked, but the way it mostly worked was really cool:
A funny thing about my TRS-80, something different from any other one you've ever seen, is that when you first turned it on, you would only see funny characters on the screen. I mean things like a circle with a dot in it, or a greek letter... that kind of stuff. Then the characters would slowly start to flicker, and then you could see that they were trying to be regular characters, and then they were mostly regular characters with just a faint image of the funny character, and then finally, a minute later, the regular characters you expected were on the screen, the funny characters having faded to black. It was really a neat effect, but not one I got on purpose. What happened is that I had hacked an extra memory chip into the video memory to get upper and lowercase. To save money, the designers had put only seven bits of memory into the video memory (seven chips, each one having 1024 bits), and what they gave up was lowercase and special characters (they could have kept lowercase and special characters, but instead allowed graphics with some really bit pixels). But the character encoder that turned the video memory bits into bits on the monitor could handle lowercase, and I read an article that showed how to piggyback another memory chip onto the video memory to get lowercase, and so I decided to do that. It just so happened that I had one of these chips around, but it's one I had abused -- I used it for experiments. Among other things, it got sucked through a vacuum cleaner once, but I had unbent the pins and kept it. And that's the chip that went into my TRS-80. But it turns out that it just wouldn't work cold because of the abuse I had given it. Once it got warm then it worked just fine, and that's why my computer needed a minute to warm up before you could see regular characters on the screen.
NCI link is good science, not gov't oppression.
on
Web 'Rules' Changing?
·
· Score: 2, Informative
The
"New Rules for us to follow" aren't for us (they're for the National Cancer Institute), and they're not rules. They're not even guidelines in the corporate sense (where "guideline" is a synonym for "rule."). As stated here (the bold text is from the site):
This site does not represent NCI's official Web design guidelines or standards. Rather, it is a resource to help you identify what Web design and usability research/findings are available and how they apply to your Web site.
It's remarkable that each guideline has a "strength of evidence" icon showing whether the guideline has no evidence, or is based one expert opinion, or on usability tests, or on hypothesis testing. It's refreshing to see science in web design. The site is follows its own guidelines and has advice that could improve many web sites.
So, although the title of the link is inflammatory, the link itself is gold.
There are domains where squeezing every last cycle out of the code matters. Many of us no longer work in those domains. Most of the code I've written in the last 4 years was developed and executed in an environment with essentially unlimited cycles, memory, and disk. The only exception was one project that got database bound, and compiler optimization won't help that.
For programmers who are no longer resource limited, using a language that optimizes for the human rather than the computer is a good idea. A language with garbage collection, low syntactic sugar, functional constructs like closures, and no separate compile phase make for happy code and happy programmers.
An interesting benefit of working in a humane language is that it can becomes easier to use a better algorithm. Many algorithms depend upon data structures that are difficult to implement in the land of DIY memory management, but a breeze in a more humane language. This can make a solution in the apparently unoptimal language outperform the solution in the optimal language. Of course, we *could* go faster using C or C++, but only if we have the extra time it takes to write the code.
Don't optimize for the computer unless the computer is the critical constraint. And, even then, only optimize the part that is the actual constraint.
Otherwise, optimize for the human. We're more important than the computer these days.
Template specialization is a nice hammer to have in your toolbox.
It's worth mentioning that it's probably better, when not in an artificial example, to just use the std::string class. Do that, and the original template function works fine without specialization.
How hard would it be to build a personal wayback machine? A modified proxy, perhaps, that would keep a snapshot of every version of every page you ever visited. Then it wouldn't matter if something got removed from the web. Anything I saw at least once, I could see again.
Sure, it'd gobble up storage, but storage is cheap.
If enough people ran personal wayback machines, it'd be harder for someone to unpublish something.
There's not enough detail in the article to even say "gee whiz." Could it be that these guys haven't published yet, and wanted to generate some pre-publication buzz without giving away anything?
Right. They got through it, but I think someone allowed them to use foolish design numbers. It's foolish to design for the average if an above-average number causes disaster. From the article:
The best guess of Alyeska's seismic experts was that in a magnitude 8 earthquake -- the largest expected -- the ground could shift up to 30 feet, but the average would be 10 feet, along the fault. Alyeska engineers designed for a number in middle.
"We doubled the average and said, 'Let's design it for 20 feet,'" said Lloyd Cluff, a consultant on the pipeline and manager of the geosciences department for California-based utility Pacific Gas and Electric.
The quake that struck was a 7.9, nearly the design maximum. I think they got lucky that the pipe only moved 20 feet, not the 30 that they estimated it could move in the event of a 8.0.
I can't see doubling the average as good engineering practice, especially if doubling the average doesn't get you outside the expected maximum range of movement. I think they were allowed to use unconservative numbers, and they got away with it (for which I'm glad).
I hope you are able to ignore all of the silly suggestions to donote to charities, upgrade workstations, and give non-cash gifts.
Donating to a charity in someone's behalf is one of those anti-gifts. It's a gift that isn't a gift. It says, "Here's some cash but you can't have it." And if you chose the charity, you're saying "And I won't even let you pick where it goes." Lovely sentiment.
Upgrading a workstation is, as someone else pointed out, like buying your wife a vacuum cleaner. Keeping workstations fast and efficient is in *your* best interest, and I'll bet you get to write-off the depreciation. It's another anti-gift.
I believe those who say they really appreciate non-cash gifts, but not everyone does. Do you really want to roll the dice? I've sure received a lot of stuff that just missed the mark. Let your employees get something they want, not something the boss wants. Besides, I have a suspicion that a gift large enough to be a decent bonus is probably taxable anyhow. A gift that costs cash to receive would be a huge anti-gift.
Cash is king. It says, "Thanks for all the hard work, and sorry about the chunk the tax man takes (can't help that), and I know you'll make good use of this."
Reliability isn't always everything, at least for me. I host my own site because I like using odd languages on the server side. Just try to find someone who'll let you run Ruby and Python CGI scripts. There are a few cutting edge hosting services that have heard of Python, but nobody seems to know what Ruby is. And even if they have, what about tomorrow when I decide that my Apache needs mod-lisp or mod-brainfuck or whatever?
For me, it's about learning and experimenting as much as it's about reliability.
Of course, my site is up nearly all the time anyhow. Yeah, once every six months something happens (fan goes out, etc.) and the site is down for half a day while I deal with it. I don't do anything fancy for reliability, either. My floppy-based router just keeps working, and the server has a 2nd hard drive that I do backups to. I've got a closet full of parts I can whip up another server with if need be. Oh, and I've got a pile of these cheapo Belkin UPS's that a local hardware store sold for $15 or $20 each. So even though mine is truly a closet operation, I'm not convinced my reliability would be any better if someone else were hosting my site.
I only get 144k (18,000 feet away from the switch, darn it), but my bandwidth is mine to do what I want with. No filters, no restrictions.
The only burp I've ever had with them is that they switched my IP once without telling me, and had no record of it when I called. *That* was annoying, but their phone support was quick and accurate, as always. I only wish I'd have known so I could have put my DNS records on a short leash beforehand.
Re:EJB is REALLY Bitter
on
Bitter EJB
·
· Score: 1
There, that's "Hello World!" in three real-world languages in the space of Java's one.
Ruby, especially, is more OO than Java, so it doesn't follow that a language being OO requires that it also be syntactically noisy. All a language needs is to consider the needs of the human using it to be more important than the needs of the language designer.
After a few years of doing Java I started to wonder aloud if its raison d'etre was to cause people to need E10000 boxes. So much horsepower for so little gain. Why do we need EJB's? To be able to scale, especially through distributed processing. Why do we need distributed processing? Because all of the horsepower needed to run the large frameworks built on Java make the web site too slow or fragile to run on one box. It starts to get a bit circular after a while.
Sound enclosures have been around a while, but usually for noisier things. A company I worked for purchased a sound deadening box like this for a client's noisy dot-matrix printer in the early 90's.
Here's something I wanted to bring up but didn't put in the original article (it's too editorial). Check out the email that SpaceRef received from the paper's author (in color on page 1). Here's an excerpt:
The opinions expressed in the leaked copy were solely that of the author prior to editing and feedback. Based on the feedback received in the intervening period since the first draft, several of the major concerns were addressed in subsequent drafts and others are in the process of being addressed. The author regrets the inadvertent leak of this document and disassociates himself from any interpretations related to this draft. The goal of this work was to take the devil's advocate position so crucial to the program following the STS-107 accident in order to improve life science research as a whole.
Perhaps the paper really is a "devil's advocate" position, purposefully exaggerating its arguments to elicit thought. But I have to wonder. I've worked at many places where management's desire to shape reality causes them to pressure authors to "reconsider," "take the broad view," "think of the big picture," or otherwise water down their statements. The Columbia Accident Investigation Board found plenty of evidence of management's desire to ignore reality; it's not a stretch to imagine the email being a direct result of management pressure upon the author (and perhaps a bit of a "I am so very doomed" feeling when he learned that his paper was on the web).
Decreased muscle strength and endurance, muscle atrophy, and delayed muscle repair
Loss of red blood cell mass, loss of hemoglobin mass, and loss of plasma volume
Transient reduction in white blood cells
Behavioral and psychological problems (it's not easy living in a can).
Motion sickness
These will all need to be solved for any long missions like a trip to Mars using chemical propulsion; that's what I thought the stated goal of ISS Life Sciences is.
because conciousness is not really fixed on any one place in space or even time. Folks who can demonstrate those abilities...
What folk? Who's willing to step up to the plate and prove it?
It's all very nice to say that we have a nice theory explaing why the stuff doesn't work when examined by scientists, but that's just a dodge invented by people who'd like to deceive themselves or others.
...the guy [James Randi] apparantly works to discredit any possible psychic, as if he had a million dollars on the line or something.;)
Not technically his money; it belongs to the foundation he started.
I guess he does discredit psychics, if you count "ok, prove it and I'll give you money." It seems to me that the psychics do fine discrediting themselves without his help. He just enjoys pointing them out.
Right. And living in cities in bad because we have made it bad. We plan them to be unliveable. Orson Scott Card wrote a pretty nice essay describing city planning sins:
Excellent points. I was a solitary creature as well when I was younger, and never would have tried pair programming. Oddly, I seem to have grown a few social neurons and find it to work pretty well most of the time. I now pair program most of the time when I'm working.
1. I'm antisocial. I definitely do NOT want to hang around with some other programmer day in, day out.
Oh, for sure. Some people can do this, and some can't (and some that can't, change) That's just people, and it's no problem. Methods should always adapt to people, not people to methods.
2. Pair programming basically means that one person is actually coding while the other harasses him, making him explain every little thing he's doing.
In my experience, it doesn't take long before the watcher knows what's going on. There are usually periods of silence, a minute here, two there, when stuff is happening and both are happy with how it is going (so no reason to say anything).
One of the things we've found is that if the driver has to explain everything to the back-seater, either the wrong person is driving (it's easier to teach someone something when they have to understand you before fingers move on the keys), or the pair is badly mismatched. Not every expert has the patience to teach, and pairing such an expert with a novice can be very frustrating for both.
Besides, if your pair is harassing you too much, you should give him the keyboard and let it be his turn.
3. While I'm on the subject, I need peace and quiet to think.
I do too. I like going for a walk outside while I think. XP doesn't make people stop being people; we just have to take care to make the work situation fit the people.
One of the little suprises for me has been that some of the occasions where I need deep thought are taken care of when my partner sees an easy solution. I think it's a very tiny version of many minds making any problem shallow (or however that goes). Deep thought is still needed, of course, so we invent rituals to make sure we still get it when we need it. Fortunately, your partner is a detachable pod.
Why is only one person coding at a time, and why doesn't anyone think the second person is mostly being wasted?
Really, two people are coding. Just one is typing. My partner catches bug, sees things, and remembers things I forgot.
Laurie Williams's study at NCSU divided her classes into a control group (individuals) and a pair group. Strangely, programmer hours do not double when pair programming. Instead, a pair that has learned to work together seems to take about 2/3 of the time to do the work that a single programmer did. That still seems inefficient until you look at bug counts, which are much lower with pairs. Her paired students were submitting working code more often than the individual students.
Look for the chart of tests passed on page 6, and the graph of time spent on page 7. You'll see that it took a few projects for the pairs to come together. Learning to work together isn't instantaneous, so any organizing trying pair programming should be prepared for decreased productivity for a while (fortunately, the bug count starts to decrease a little right away, so you get *something* for your pain while you're waiting for the team to learn how to pair effectively).
It seems to work that way in the commercial projects I've done, too. But it's not for every project, and not for every programmer (and neither is RUP, or patterns, or OOP, or functional programming, or any other buzzword).
I worked with Gravatite on this. He did the part where we got OpenOffice to print from the command line; I did the XML munging. It would have been hard, but of course we cheated:)
First we configured OpenOffice so that it saved our report templates in friendlier XML format, not all on one line (uncheck Tools -> Options -> Load/Save -> General/Size Optimization for XML Format).
Next, we didn't actually parse the XML. We unzipped the zips, then did a simple regex search & replace to get data into the report. For example, we might replace "|date|" with "2003-03-01". For the parts of the report that had a variable number of rows, we used an OpenOffice table, which makes a pretty regular structure; that makes it very easy to find a row and duplicate it without actually having to parse the XML for real.
Then we'd zip it all back up and feed it to OpenOffice to print.
I've enjoyed some success using index cards for this. I tried whiteboards, spreadsheets, and web pages, but index cards worked best. I think it's because they're physical. They're visceral.
Here's how it worked for my boss and I:
For each task, write it on an index card. Scribble an estimate in the corner (ie, "3 days"). If the estimate is uncertain, write it in uncertain terms ("2 to 10 days"). If you don't know, write that.
Don't skip the estimates -- they're important! Without them, your boss has no idea what the cost of a task is, and can't make good decisions.
Now hand the cards back to your boss and let him sort them. I suspect that being able to handle them and sort them is important -- the boss I did this with really seemed to enjoy seeing the tasks and ordering them by priority.
Now is a good time to discuss scheduling issues. "Ok, I like that order. If I add up the estimates, I see that the integration task won't even be started until 2 weeks from now, but I heard Jerry say it needs to actually be done by then. Should we rearrange some tasks to make that happen?"
Bring done cards to your boss and explain anything interesting that he needs to know. "That one took a day extra, but good news -- that other card that ought to have took 5 days took 3. Our lucky week! And we need to talk about my estimate on the database thingie, it's going to take longer. Is it still important even if it costs longer?"
Your boss will periodically come to you an insert cards into your stack.
The beauty of this is that it's your boss deciding what doesn't get done, not you. And bosses really like making decisions like that... it's what they're made for!
Yes, 142% faster" means that the second test finished before it started.
First test: 4:59 = 291 seconds
Second test: 2:00 = 120 seconds
141% of 291 seconds is 410 seconds (omitting the loose change)
That means that the second test was 410 seconds faster than its original 291 seconds, yielding a net time of -119 seconds. The second test completed about 2 minutes before it started. That's fast!
The only way I can get 141% out of the test times is to divide 120 seconds -- the time for the first test -- by 411 seconds, the combined time of both tests. That's silly.
Never mind that the tests compared apples and oranges. They didn't any meaningful math, either.
Slashdot Mirror
Gravatite and I like to code Combsort when we're learning a new language. Combsort a very simple modification to bubblesort that makes it competative with Quicksort but without quite as much complexity -- it's good for those rare occasions where you have to hand-code a sort and don't need all the fuss of quicksort.
I've done combsort in about a dozen dozen languages, and Gravatite has done it in a few more languages, including postscript.
You might try reading the David Feintuch's "Midshipman's Hope" series. It's a grittier, darker, more believable world than the Honor Harrington series. It's not all happy-happy joy-joy blow-up-the-aliens, yet there is high adventure and enough of a dose enough of hope that it's not "literature" a la 1984, On The Beach, etc. Very good read.
Way back in the day, I had a 1k SRAM that I had abused in every which way possible. It ended up in my TRS-80 to give it lowercase. It mostly worked, but the way it mostly worked was really cool:
A funny thing about my TRS-80, something different from any other one you've ever seen, is that when you first turned it on, you would only see funny characters on the screen. I mean things like a circle with a dot in it, or a greek letter... that kind of stuff. Then the characters would slowly start to flicker, and then you could see that they were trying to be regular characters, and then they were mostly regular characters with just a faint image of the funny character, and then finally, a minute later, the regular characters you expected were on the screen, the funny characters having faded to black. It was really a neat effect, but not one I got on purpose. What happened is that I had hacked an extra memory chip into the video memory to get upper and lowercase. To save money, the designers had put only seven bits of memory into the video memory (seven chips, each one having 1024 bits), and what they gave up was lowercase and special characters (they could have kept lowercase and special characters, but instead allowed graphics with some really bit pixels). But the character encoder that turned the video memory bits into bits on the monitor could handle lowercase, and I read an article that showed how to piggyback another memory chip onto the video memory to get lowercase, and so I decided to do that. It just so happened that I had one of these chips around, but it's one I had abused -- I used it for experiments. Among other things, it got sucked through a vacuum cleaner once, but I had unbent the pins and kept it. And that's the chip that went into my TRS-80. But it turns out that it just wouldn't work cold because of the abuse I had given it. Once it got warm then it worked just fine, and that's why my computer needed a minute to warm up before you could see regular characters on the screen.
The "New Rules for us to follow" aren't for us (they're for the National Cancer Institute), and they're not rules. They're not even guidelines in the corporate sense (where "guideline" is a synonym for "rule."). As stated here (the bold text is from the site):
It's remarkable that each guideline has a "strength of evidence" icon showing whether the guideline has no evidence, or is based one expert opinion, or on usability tests, or on hypothesis testing. It's refreshing to see science in web design. The site is follows its own guidelines and has advice that could improve many web sites.
So, although the title of the link is inflammatory, the link itself is gold.
There are domains where squeezing every last cycle out of the code matters. Many of us no longer work in those domains. Most of the code I've written in the last 4 years was developed and executed in an environment with essentially unlimited cycles, memory, and disk. The only exception was one project that got database bound, and compiler optimization won't help that.
For programmers who are no longer resource limited, using a language that optimizes for the human rather than the computer is a good idea. A language with garbage collection, low syntactic sugar, functional constructs like closures, and no separate compile phase make for happy code and happy programmers.
An interesting benefit of working in a humane language is that it can becomes easier to use a better algorithm. Many algorithms depend upon data structures that are difficult to implement in the land of DIY memory management, but a breeze in a more humane language. This can make a solution in the apparently unoptimal language outperform the solution in the optimal language. Of course, we *could* go faster using C or C++, but only if we have the extra time it takes to write the code.
Don't optimize for the computer unless the computer is the critical constraint. And, even then, only optimize the part that is the actual constraint.
Otherwise, optimize for the human. We're more important than the computer these days.
Template specialization is a nice hammer to have in your toolbox. It's worth mentioning that it's probably better, when not in an artificial example, to just use the std::string class. Do that, and the original template function works fine without specialization.
How hard would it be to build a personal wayback machine? A modified proxy, perhaps, that would keep a snapshot of every version of every page you ever visited. Then it wouldn't matter if something got removed from the web. Anything I saw at least once, I could see again.
Sure, it'd gobble up storage, but storage is cheap.
If enough people ran personal wayback machines, it'd be harder for someone to unpublish something.
There's not enough detail in the article to even say "gee whiz." Could it be that these guys haven't published yet, and wanted to generate some pre-publication buzz without giving away anything?
The quake that struck was a 7.9, nearly the design maximum. I think they got lucky that the pipe only moved 20 feet, not the 30 that they estimated it could move in the event of a 8.0.
I can't see doubling the average as good engineering practice, especially if doubling the average doesn't get you outside the expected maximum range of movement. I think they were allowed to use unconservative numbers, and they got away with it (for which I'm glad).
Would you give your girlfriend cash for her birthday?
Nope. But employees are not girlfriends.
I hope you are able to ignore all of the silly suggestions to donote to charities, upgrade workstations, and give non-cash gifts.
Donating to a charity in someone's behalf is one of those anti-gifts. It's a gift that isn't a gift. It says, "Here's some cash but you can't have it." And if you chose the charity, you're saying "And I won't even let you pick where it goes." Lovely sentiment.
Upgrading a workstation is, as someone else pointed out, like buying your wife a vacuum cleaner. Keeping workstations fast and efficient is in *your* best interest, and I'll bet you get to write-off the depreciation. It's another anti-gift.
I believe those who say they really appreciate non-cash gifts, but not everyone does. Do you really want to roll the dice? I've sure received a lot of stuff that just missed the mark. Let your employees get something they want, not something the boss wants. Besides, I have a suspicion that a gift large enough to be a decent bonus is probably taxable anyhow. A gift that costs cash to receive would be a huge anti-gift.
Cash is king. It says, "Thanks for all the hard work, and sorry about the chunk the tax man takes (can't help that), and I know you'll make good use of this."
Reliability isn't always everything, at least for me. I host my own site because I like using odd languages on the server side. Just try to find someone who'll let you run Ruby and Python CGI scripts. There are a few cutting edge hosting services that have heard of Python, but nobody seems to know what Ruby is. And even if they have, what about tomorrow when I decide that my Apache needs mod-lisp or mod-brainfuck or whatever?
For me, it's about learning and experimenting as much as it's about reliability.
Of course, my site is up nearly all the time anyhow. Yeah, once every six months something happens (fan goes out, etc.) and the site is down for half a day while I deal with it. I don't do anything fancy for reliability, either. My floppy-based router just keeps working, and the server has a 2nd hard drive that I do backups to. I've got a closet full of parts I can whip up another server with if need be. Oh, and I've got a pile of these cheapo Belkin UPS's that a local hardware store sold for $15 or $20 each. So even though mine is truly a closet operation, I'm not convinced my reliability would be any better if someone else were hosting my site.
Agreed. I also like Speakeasy.
I only get 144k (18,000 feet away from the switch, darn it), but my bandwidth is mine to do what I want with. No filters, no restrictions.
The only burp I've ever had with them is that they switched my IP once without telling me, and had no record of it when I called. *That* was annoying, but their phone support was quick and accurate, as always. I only wish I'd have known so I could have put my DNS records on a short leash beforehand.
Thank you for showing Java's dark side so well.
./hello.py
./hello.rb
./hello.pl
Contrast all of that noise with Python:
$ cat hello.py
#!/usr/bin/python
print "Hello World!"
$
Hello World!
Or with Ruby:
$ cat hello.rb
#!/usr/bin/ruby
puts "Hello World!"
$
Hello World!
Or with Perl:
$ cat hello.pl
#!/usr/bin/perl
print "Hello World!\n";
$
Hello World!
There, that's "Hello World!" in three real-world languages in the space of Java's one.
Ruby, especially, is more OO than Java, so it doesn't follow that a language being OO requires that it also be syntactically noisy. All a language needs is to consider the needs of the human using it to be more important than the needs of the language designer.
After a few years of doing Java I started to wonder aloud if its raison d'etre was to cause people to need E10000 boxes. So much horsepower for so little gain. Why do we need EJB's? To be able to scale, especially through distributed processing. Why do we need distributed processing? Because all of the horsepower needed to run the large frameworks built on Java make the web site too slow or fragile to run on one box. It starts to get a bit circular after a while.
Sound enclosures have been around a while, but usually for noisier things. A company I worked for purchased a sound deadening box like this for a client's noisy dot-matrix printer in the early 90's.
Here's someone making sound deadening boxes for G4's (a favorite of AV types, I guess).
Here's something I wanted to bring up but didn't put in the original article (it's too editorial). Check out the email that SpaceRef received from the paper's author (in color on page 1). Here's an excerpt:
Perhaps the paper really is a "devil's advocate" position, purposefully exaggerating its arguments to elicit thought. But I have to wonder. I've worked at many places where management's desire to shape reality causes them to pressure authors to "reconsider," "take the broad view," "think of the big picture," or otherwise water down their statements. The Columbia Accident Investigation Board found plenty of evidence of management's desire to ignore reality; it's not a stretch to imagine the email being a direct result of management pressure upon the author (and perhaps a bit of a "I am so very doomed" feeling when he learned that his paper was on the web).
What do they need to research?
The effects of microgravity include:
These will all need to be solved for any long missions like a trip to Mars using chemical propulsion; that's what I thought the stated goal of ISS Life Sciences is.
(More info here)
No, they don't.
because conciousness is not really fixed on any one place in space or even time. Folks who can demonstrate those abilities...
What folk? Who's willing to step up to the plate and prove it?
It's all very nice to say that we have a nice theory explaing why the stuff doesn't work when examined by scientists, but that's just a dodge invented by people who'd like to deceive themselves or others.
Not technically his money; it belongs to the foundation he started.
I guess he does discredit psychics, if you count "ok, prove it and I'll give you money." It seems to me that the psychics do fine discrediting themselves without his help. He just enjoys pointing them out.
Right. And living in cities in bad because we have made it bad. We plan them to be unliveable. Orson Scott Card wrote a pretty nice essay describing city planning sins:
Death by Government
Microsoft is really missing out on a great use for their slogan:
"Microsoft Diaper -- Where do you want to go today?"
Excellent points. I was a solitary creature as well when I was younger, and never would have tried pair programming. Oddly, I seem to have grown a few social neurons and find it to work pretty well most of the time. I now pair program most of the time when I'm working.
Oh, for sure. Some people can do this, and some can't (and some that can't, change) That's just people, and it's no problem. Methods should always adapt to people, not people to methods.
In my experience, it doesn't take long before the watcher knows what's going on. There are usually periods of silence, a minute here, two there, when stuff is happening and both are happy with how it is going (so no reason to say anything).
One of the things we've found is that if the driver has to explain everything to the back-seater, either the wrong person is driving (it's easier to teach someone something when they have to understand you before fingers move on the keys), or the pair is badly mismatched. Not every expert has the patience to teach, and pairing such an expert with a novice can be very frustrating for both.
Besides, if your pair is harassing you too much, you should give him the keyboard and let it be his turn.
I do too. I like going for a walk outside while I think. XP doesn't make people stop being people; we just have to take care to make the work situation fit the people.
One of the little suprises for me has been that some of the occasions where I need deep thought are taken care of when my partner sees an easy solution. I think it's a very tiny version of many minds making any problem shallow (or however that goes). Deep thought is still needed, of course, so we invent rituals to make sure we still get it when we need it. Fortunately, your partner is a detachable pod.
Really, two people are coding. Just one is typing. My partner catches bug, sees things, and remembers things I forgot.
Laurie Williams's study at NCSU divided her classes into a control group (individuals) and a pair group. Strangely, programmer hours do not double when pair programming. Instead, a pair that has learned to work together seems to take about 2/3 of the time to do the work that a single programmer did. That still seems inefficient until you look at bug counts, which are much lower with pairs. Her paired students were submitting working code more often than the individual students.
Look for the chart of tests passed on page 6, and the graph of time spent on page 7. You'll see that it took a few projects for the pairs to come together. Learning to work together isn't instantaneous, so any organizing trying pair programming should be prepared for decreased productivity for a while (fortunately, the bug count starts to decrease a little right away, so you get *something* for your pain while you're waiting for the team to learn how to pair effectively).
It seems to work that way in the commercial projects I've done, too. But it's not for every project, and not for every programmer (and neither is RUP, or patterns, or OOP, or functional programming, or any other buzzword).
Wayne ConradI worked with Gravatite on this. He did the part where we got OpenOffice to print from the command line; I did the XML munging. It would have been hard, but of course we cheated :)
First we configured OpenOffice so that it saved our report templates in friendlier XML format, not all on one line (uncheck Tools -> Options -> Load/Save -> General/Size Optimization for XML Format).
Next, we didn't actually parse the XML. We unzipped the zips, then did a simple regex search & replace to get data into the report. For example, we might replace "|date|" with "2003-03-01". For the parts of the report that had a variable number of rows, we used an OpenOffice table, which makes a pretty regular structure; that makes it very easy to find a row and duplicate it without actually having to parse the XML for real.
Then we'd zip it all back up and feed it to OpenOffice to print.
Cheating is good for you (tastes good, too).
I've enjoyed some success using index cards for this. I tried whiteboards, spreadsheets, and web pages, but index cards worked best. I think it's because they're physical. They're visceral.
Here's how it worked for my boss and I:
For each task, write it on an index card. Scribble an estimate in the corner (ie, "3 days"). If the estimate is uncertain, write it in uncertain terms ("2 to 10 days"). If you don't know, write that.
Don't skip the estimates -- they're important! Without them, your boss has no idea what the cost of a task is, and can't make good decisions.
Now hand the cards back to your boss and let him sort them. I suspect that being able to handle them and sort them is important -- the boss I did this with really seemed to enjoy seeing the tasks and ordering them by priority.
Now is a good time to discuss scheduling issues. "Ok, I like that order. If I add up the estimates, I see that the integration task won't even be started until 2 weeks from now, but I heard Jerry say it needs to actually be done by then. Should we rearrange some tasks to make that happen?"
Bring done cards to your boss and explain anything interesting that he needs to know. "That one took a day extra, but good news -- that other card that ought to have took 5 days took 3. Our lucky week! And we need to talk about my estimate on the database thingie, it's going to take longer. Is it still important even if it costs longer?"
Your boss will periodically come to you an insert cards into your stack.
The beauty of this is that it's your boss deciding what doesn't get done, not you. And bosses really like making decisions like that... it's what they're made for!
Yes, 142% faster" means that the second test finished before it started.
141% of 291 seconds is 410 seconds (omitting the loose change)
That means that the second test was 410 seconds faster than its original 291 seconds, yielding a net time of -119 seconds. The second test completed about 2 minutes before it started. That's fast!
The only way I can get 141% out of the test times is to divide 120 seconds -- the time for the first test -- by 411 seconds, the combined time of both tests. That's silly.
Never mind that the tests compared apples and oranges. They didn't any meaningful math, either.