|
in reply to Programming is combat
I pretty much agree with everything you wrote--but would I buy the book? Probably not. It would be like me buying a book on how to tie my shoes.
Not that I always, or even regularly followed all those tenents when I was in the position to have to. I intended to, but we all know about good intetions. Then again, I haven't worn shoes with laces for 20+ years either.
The problem with this type of book is you need public track record for it to be of great interest. If Carlos Ghosn wrote a "how to manage..." book, people would probably cough up and read it.
With respect to Train as you fight. That's another way of saying "practice makes perfect". For applicability in perl, I suggest it could be translated into stuff like 'code your throw aways and one offs the same way you should code your production apps'. Always indent properly. Pass parameters to/from subs instead of using globals. etc.
Most people write more one-offs than they do production apps and if you get into the habit of using bad practices in your one-offs, the temptation to skip the good techniques in your production apps when time is pressing (Isn't it always!), just becomes to strong.
If a soldier trains as if it were real, he is more likely to react in the correct way when the chips are down.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
|
Re^2: Programming is combat
by brian_d_foy (Abbot) on Jul 08, 2004 at 17:24 UTC
|
Oh, no one is going to buy the book. I starting collecting these sorts of books because they show up on the remaindered racks at book stores. This is only a fantasy of mine because it would suck away a lot of free time and get me nothing that I could use to pay rent.
For me, "train as you fight" shows up mostly as a t directory. When I am good about this (and I am not always that good), I at least create tests to ensure the code compiles and the pod is valid. When I get over that little hump, adding other tests is easy: I already have the t directory and am using "make test".
--
brian d foy <bdfoy@cpan.org>
| [reply] |
|
|
I'm still to be, and don't expect to be, convinced of the value of \t directory and Test:* modules.
Don't misread that. I'm strong on tests and testing. It is the only tool short of suck-it-and-see that we yet have for trying to establish the quality of the code we produce.
The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code. You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.
In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.
Design by contract shows great potential (IMO). I had hoped that something similar would be integral to P6, but I haven't seen any signs of it. I'm hoping that the (proper) macro facility will allow this to be added in fairly short shrift after the fact. Time will tell.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
| [reply] |
|
|
DBC is integral to Perl 6. If you google for "design by contract apocalypse perl", you'll discover that it's even been mentioned in discussions here on PM.
| [reply] |
|
|
|
|
|
|
|
|
|
|
The problem with those modules and the \t directory is that they rely on tests external to the code. Out of site, out of mind. Tests should be integral with the code where they may be maintained along with the code
Test::Inline?
You also might find the idea of Zero Button Testing appealing.
Personally, I find having the code and the tests in the same document gets in the way of reading the code and interferes with refactoring, but YMMV.
You can have all the tests in the world but if they are testing the wrong things they are little more than overhead.
Doctor, it hurts when I do that :-)
In an ideal world, the tests would be generated automatically by the compiler thereby removing the possibility of the tests and the code becoming out of sync, but that is still a ways off.
I see people asking for this sort of functionality a lot and it confuses me. I must be misunderstanding what you mean since, on the face of it, what you're requesting seems to be impossible. How would the magic test producer know what the code should do.
Design by contract shows great potential (IMO)
Interestingly enough DBC used to be my preferred design methodology, before I discovered TDD (Eiffel is still one of my favourite languages). Because you're dealing with concrete data rather than an abstract contract I find it much easier to incrementally develop code with tests.
| [reply] |
|
|
|
|
Re^2: Programming is combat
by DBAugie (Beadle) on Mar 23, 2008 at 12:58 UTC
|
With respect to Train as you fight. That's another way of saying "practice makes perfect".
With respect, the complete maxim was taught to me as "Train as you fight, fight as you train." If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear. If your training prescribes that you must use a checklist to launch the alert fighter, then you must use the checklist when the klaxon goes off.
Relate this to programming: - Your program, application, or system must pass security certification and accreditation. So don't build your work with hard-coded, plain-text passwords.
- Your work is going to have to meet the standards of Sarbanes-Oxley, plan for it and program accordingly.
- QA testers are going to evaluate your work against requirements, write code that satisfies requirements.
For those of you old enough to remember Sgt Rock and his Howlin' Commandos, "Nuff said" | [reply] |
|
|
Hm. I don't think the analogy holds very well.
If you expect to engage in combat in full chemical protective gear, you must train in full chemical protective gear.
Not all fighting is done wearing NBC suits, and as sure as hell, not all training is. Sure, they train under those conditions so as to have experienced them, but I doubt it makes up more than 2 or 3% of their total.
Security.
The app I wrote to index the ingredients in my sisters recipes has hard coded credentials. If hackers crack it, I hope they enjoy her profiterole recipe as much as I do.
Choosing what to not to expend effort securing is as important as securing those things need it.
I'd be interested to hear your solution to the problem of supplying credentials to your DB apps? (Assuming that they can't be entered manually every time. Eg. Web apps?)
Sarbanes-Oxley
Doesn't affect me (note my handle). But from what I scanned on wikipedia, it probably rarely affects programmers in general, being aimed at corporate/legal processes rather than programming in general. I can see how for example it might be desirable to have an MIS suite provide hooks for auditing, but a good auditor would probably ignore that on the basis that they can be as bogus as the glossy company brochure.
Requirements
Can't argue directly against what you say, but I see little correspondance between that and military practices and doctrines.
Then again, maybe I can argue against it. Requirements (and plans) are a fine starting point, but in all but the most repetitious of projects, they change. In common parlance, "the best laid plans of mice and men", or as the military would have it. "No plan survives the first encounter with the enemy."
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
