?

Log in

No account? Create an account

Previous Entry | Next Entry

Dear Database Developers:

You know that sometimes my code is contingent on the results that you send me. And you know that clients always want to change label text, so the best practice is for you to send me category IDs.

SO WHY DO YOU MAKE THE CATEGORY ID A GENERATED KEYCODE THAT WILL CHANGE FROM SERVER TO SERVER?

No love,

-The Gneech

Tags:

Comments

( 4 comments — Leave a comment )
hantamouse
Nov. 19th, 2010 10:15 pm (UTC)
From sad experience, I believe "That wasn't in the requirements document" would be the usual response.
laurie_robey
Nov. 19th, 2010 10:55 pm (UTC)
This is Agile. There is no requirements document. ;)
hantamouse
Nov. 19th, 2010 11:46 pm (UTC)
class
CREATE TRIGGER trig_my_fault AFTER UPDATE OF fault ON employee FOR EACH ROW WHEN employee.name = 'myself';
BEGIN
IF :NEW.fault = TRUE THEN
Blamecast('myself');
END IF;
END trig_my_fault;


PROCEDURE blamecast(v_name IN VARCHAR2) IS
PRAGMA AUTONOMOUS_TRANSACTION
v_someone_else number(10);
v_count number(10);
BEGIN
UPDATE employee SET fault = FALSE WHERE employee.name = v_name;
SELECT count(id) INTO v_count FROM employee;
SELECT INTO v_someone_else dbms_random.value(1,vCount) num from dual;
UPDATE employee SET fault = TRUE WHERE ROWNUM = v_someone_else;
COMMIT;
END blamecast;
anthony_lion
Nov. 20th, 2010 02:24 pm (UTC)
Autogenerated labels is a deadly sin to ALL serious programmers.

And as such, it is your DUTY to explain this to the offenders, preferrably using a .50" calibre and a bullhorn...

The rules are simple, really:

1. All labels should be meaningful.
2. GOTO Hell... (Should be self-explanatory... )
3. Always clean up after yourself. (That means 'garbage collection')
3.a. Why not start out by avoiding the mess altogether? (When creating a 'constructor', why not create the 'destructor' at the same time?)
4. Stay on the right side of the fence. (Boundary checking is not just a good idea, it's ESSENTIAL)
5. What have you done today? (Document, document, document.)
6. How low can you go? (Well, short, really. A function/sub/proc that's longer than a sheet of A4/Letter when printed, is probably too long. )
6.a. This doesn't mean that you should obfuscate the code. If it takes someone else more than a minute to figure out what a line does, it's too darn messy.
7. What did you do yesterday? (Backups? Code revisions? )
8. Managers are idiots... Yes, really!
(When doing a large project, feel free to listen to managers, but then forget everything they told you. All they really want are colourful reports. Ask the real users what they want and NEED. Yes, I've seen more than one large project fail because of this one.)
9 The task cometh first, the tools second. (Any project where the tools are picked before the problem is completely defined, will fail somehow)
10. Don't get between me and my tea when coding... Really don't... (This one is personal. But generally, keeping coders in plentiful supply of their favrite drink keeps them happy. Happy coders are less likely to screw with you. And there hasn't been a specification written yet where there wasn't enough leeway to REALLY screw someone over... After all, real coders are artists. They're creative and imaginative, and how you treat them will decide how they use all that creativity.)


Edited at 2010-11-20 02:26 pm (UTC)
( 4 comments — Leave a comment )

Latest Month

August 2019
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Tags

Powered by LiveJournal.com
Designed by Tiffany Chow