|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
  Now I am the master | 
Posted - 5/20/2008 1:40:23 AM | Further progress on the laser-R2-D2 mod project. I mounted the laser and toggle switch successfully, and rebuilt the R2 unit more or less successfully. It still works properly (woohoo!) but the head has lost its full range of motion, and the laser stopped firing after a few particularly nasty head-turn-glitch incidents. I suspect that the laser wiring isn't slack enough and has fouled up the works in some way.
This means that I have to dismantle the damn thing again and take care of the wire slack and resolder the laser leads so it fires properly. But at least I know the theory works properly. For about thirty glorious seconds, I had the laser firing and the R2 roaming around the floor of the apartment.
Speaking of the floor, it's a hazardous mess right now - littered with screws, washers, and little shavings of plastic and metal from the rather brute-force methods I used to get everything to fit nicely.
I also inhaled more melting plastic during the fabrication process of the "concealment hatch", which sits on top of the laser switch and hides the fact that there's an ugly modification underneath. It'll be a heck of a race to see if I finish this project before I die from all the toxic crap I've introduced into my body.
Photos and a proper documentation of the procedure will be posted when I get it done.... in other words, don't hold your breath. (Or, actually, do hold your breath - the plastic fumes are still a bit rich.)
| |
| Giblets round 3 - redux | |
Posted - 5/7/2008 10:32:54 AM | If you haven't already, take a moment to read the Brain giblets round 3 entry, including the comments.
The idea was brought up of using comments rather than actual function call stubs, and then exploiting IDE tools like global find or Visual Studio's Task List to locate and flesh out those comments at a later date.
This isn't a particularly bad idea, per se, but it misses the spirit of what I was trying to suggest. There are a few major shortcomings to this approach:
- It doesn't integrate with test-driven development. Function stubs can be set up for TDD immediately. Moreover, you can adjust the tests of the calling code to expect (or not expect) the stubbed function to work. This provides close support for regression testing and other quality-control measures.
- Commenting scales poorly - suppose we have 1 function that gets stubbed in, and 200 calls to that function. That's 200 replacements we have to edit into the code; if we'd used a function stub, we'd simply have to write the function.
- Using comments still places the burden of updates on the client calling code, rather than the called code.
This last point is really the Big One, so I'll spend the rest of the entry digging into why it's such an important (but subtle) distinction.
First, to clarify: this goes back a bit to the scaling issue. Let's take a look again at our hypothetical function, which is called 200-or-so times. If we use comments, we have 200 locations that have to be updated. If we format our comments intelligently, we can automate the replacement process. However, that actually introduces more work than just stubbing in a fake call.
Here's some examples to illustrate what I mean:
void DoFoo()
{
Baz();
ALittleBitOfQuux();
}
void DoFoo()
{
Baz();
ALittleBitOfQuux();
Xorph(0.2);
}
void Xorph(float percentage)
{
}
Using the commenting method has some problems. First, there is nothing ensuring that all stubs are consistent. Using the stub method is superior because we can exploit the compiler to make sure everyone treats the interface the same.
Secondly, the commenting method introduces the overhead of the search/replace step. There's really no need to add this extra work, since we can just write the stub calls the first time and be done with it.
Lastly, since the comments are not using the compiler to enforce a consistent interface, we can't find potential problems in the interface until later. Suppose we comment-stub our 200 calls to Xorph, expecting to use a floating-point percentage value. Later, when we implement Xorph, we discover that some calls really should be an integer scalar from 0 to 1000.
If we had used the code stub method, we would have learned this sooner, and introduced an overload for Xorph to properly handle the two different cases. However, with the commenting method, we're screwed. We literally will have to go back through every case to make sure it uses the proper call (float or integral). Now we're worse off than when we started - because, as you hopefully recall, the original problem was that we wanted to avoid going back through all the Xorph client code in the future!
In closing, I'll revisit the Big Point from earlier: using stub code rather than comments shifts the burden of effort very significantly. Instead of each client call being a separate focus point, we divert all of the focus directly into the stubbed module itself. This concentrates the amount of effort and work we have to do into a single location. And, as I talked about earlier, the smaller chunks of information you have to keep in your mind at once, the better your code will be.
So hopefully that clears up why I specifically suggested what I did, rather than using comments. Thanks to everyone who dropped in for the discussion; it's always great to see feedback 
| |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | | | | | 1 | 2 | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
