Slashdot

Recently, someone(s) in the ./ crowd moderated some comments of mine on a thread -1 troll...three times. I wasn't trolling, so I take it by this action that I hit a nerve with a telling point.
My comments were to the effect that when prosecuting a teenager for 'hacking' on decades-old security flaws, the company that didn't fix the flaws should ALSO be held responsible. (Sorry for the shout, I wanted to be sure that you understood I wasn't letting the script kiddie off)
Looking back at it, I realize this was actually a multiple.
a> The false dichotomy of who's to blame, and
b> the strawman that computers are hard to secure, therefore, security problems should be prosecuted on the basis that the intruder is solely to blame, and
c> Companies can be held responsible by lawsuits.
The truth is, phone companies allow phreaking to occur cuz it is easier to prosecute than fix. Phreaking used to be as easy as playing sounds into the mouthpiece of a pay phone. Allowing the flaw to exist for decades shows the company would rather use criminal records to ruin people than use a little more engineering to prevent nuisance losses.
Companies require motivation beyond just loss versus cost to fix. The human cost outside the company's balance sheet requires greater consideration than company profits. Lawsuits don't fix this.
The story of David and Goliath is in the bible because David took such a risk, and winning was (literally) such a long shot. So it is with lawsuits by individuals against big bizniz. It is unreasonable to expect every individual harmed by a company's (in)actions to have David's courage.
I'm putting this here cuz I really don't want any more unreasonable damage to my karma - the troll moderations were unwarranted.
I've never been down-trolled on ./ before, I thot I was being ignored.

Not sure why I'm writing this, but here goes.
When I was ten or so, I had an electric train set. I also had 4 older sisters who were (are) smarter than me. They loved to play tricks on the mugwump (as I was tagged). One sister (unnamed cuz they're all guilty) managed to convince me that:
a> electricity always flows in a circuit, like battery pole to pole, thru the flashlite bulb, etc;
b> The electric cord for the train's transformer had TWO prongs, and required a circuit also (I think you can see where this is going)...
c> Therefore, if I touched only one prong while plugging it in, I wouldn't get shocked.
Just so you know, in case you're ever drawing a comic or something, it feels like "BIZZB BIZZB BIZZZB BIZZB ...", not "ZAPPPPPPP".
On a trip to visit relatives, sis was at her finest. Aunt Marie had gotten a big porch swing, big enuf for all 6 kids. Of course, when grownups weren't around, it was only big enuf for one at a time (or two, in the case of the twins). I got up early in the AM (I was 12 or so), and was swinging away, chewing a big piece of grass like I'd seen my uncle do the day before (I thot it looked cool).
Sis wanted swing. Rules of the house: Whoever gets it first, wins, and others MUST wait without complaint (or suffer Mom's wrath). She loitered for a few minutes, obviously trying to figger out how to evict me from the swing. Finally, she said "If you keep eating that grass, you're gonna turn green."
OK, I was 12ish, but not totally stupid, and said so, she wasn't gonna fool me. She added "If you spit, you'll see you're already turning green on the inside!"
I did, and sure enuf, my spit was green, I was turning greeeen...."MAAWWWWMMMMM!!!!!!" I went running inside, and Sis got the swing.

I've recently been writing unit test code at work, for work, based on preliminary experience with thuds. It's going a lot smoother at work than with thuds, and it took me a while to realize why:
I don't control requirements of the code I write at work, so I do almost no "rethinking" ("inline design refactoring") while writing the unit test code for the product at work.
I should note that I'm writing test code for product that has already been 90% completed. Due to the overall complexity of the product, writing test code was simpler than writing unit test plans and scripts and then doing and tracking them. I know the unit test code should be written first with agile development, but I don't control the software development lifecycle process at work.
The unit test design thinking/rethinking process with work code goes like this:

• The unit test code is hard to write, so is the test that I'm writing too complex or is it the product code I'm trying to test?
• If the test is too complex, simplify test, rethinking done.
• else look at the product code: is the product code in too big a chunk? (nearly always, "yes")
  • then refactor product code into smaller chunks
• else is the product code too complex? (only sometimes "yes")
  • then refactor product code into simpler chunks
• else am I vague on the requirements of the product code? Surprisingly since I wrote this code myself, the answer to this is sometimes "yes".
  • then relook at the assembler that I am rewriting to gain greater insight into requirements, then refactor product design and code accordingly.
• Refactor/redesign unit test and write code for unit test

With thuds, when I run into a difficulty with the test code, I rethink too much. That is, I rethink these topics:

• The unit test code is hard to write, (so see above list up to but not including "am I vague on the requirements....")
• Am I vague on the requirements of the thud code? If so, then
  • rethink the requirements I am coding to
  • CHANGE product requirements
  • and "refactor" (actually, "change") product design and code.
• Since thud's unit test requirements have changed, redesign and recode the unit tests, including some that are done already.

Now that I realize that I was doing this, I understand somewhat what was happening. I stopped liking the thuds project fairly quickly, because of this and the display problem (see next journal post). I'll change my ways. I will be re-starting the thud project soon, and will begin updating this log of my explorations into XP.

Thuds has been delayed, but not discarded. I'll update when I can. Complicated and boring work and home situations are the cause - I don't have as much free time. If anyone cared, sorry, but I will get back to it - probably in the next two weeks or so. Here's where it is:
> I've simplified/sped up process a bit, by conglomming more work into each iteration.
> I've failed to successfully develop the habit of "test first, always", but am still "testing first, mostly". Mainly, it's hard to figure out where to draw the line on what to write tests for. I've come up with a sort of fuzzy definition, that I need to work into a more formal spec. Basically, if it takes longer to write the test code than to bench check for a bug condition, then I skip the test code. Formalizing this will be: Any skipped test condition will be documented in the design spec as a manual test step. Importantly, this is to be used only to skip stuff that is too simple to test for, not to skip complicated tests cuz I just wanna get on with it. The complicated tests are where the money is - starting to write a complex test forces me to rethink the function, and usually, to break it up or simplify it.
> Thuds have a world now, but all they do is stand there in it and grow old and die. Sad.

Design
Thuds are a standard linked list, and this will use only the routine methods for calloc, free, adding and removing things from linked lists.
Unit Test Plan

• Add, get_first, remove a thud. Possible errors:
  • Create doesn't
  • get_first() returns null or invalid. (Invalid will likely crash the program).
  • Destroy doesn't, or it doesn't null the pointer provided.
  • Count of thuds doesn't go to 1 then to 0.
• Add a bunch of thuds, then remove all of them in an arbitrary order. Possible errors are:
  • All of the above, plus:
  • relink in forward or reverse order fails or disagrees as to the order or content.
  • First and/or last links incorrect.
  • Destroyed thud still accessible.

Review:
Aug/05/2006 - 4 hours. This is more like it. I ran thru a normal (for me) coding session, had the usual number of whoopsies (bugs I'm familiar with that are little more than typos). It took longer to code the tests than the product; I'm sure it's cuz I'm well familiar with linked lists, and less with tests for linked lists that I intend to keep around in working order forever.