Slashdot Mirror
Whopping-Big Data Theft At U.C. Berkeley
aceta writes "An intruder penetrated a research computer at U.C. Berkeley in August and had access to names, social security numbers and other data for 1.4 million Californians participating in a state social program. CNET calls it the worst intrusion U.C. Berkeley has experienced. SecurityFocus additional details: the hacker used a known vulnerability, and state officials have yanked the university's research access to the data because of the breach. The victims were all receiving or providing at-home care under a state program to help the elderly and disabled. The FBI is investigating."
All about programming, in the strictest sense of the word
... writing code, of course! Error messages make us less productive. Don't fall into the trap. Ignore them.
Ignore messages
Compilers, operating systems, etc. generate error messages designed only to be read by their creators (maybe to justify their salaries). Precious time is wasted reading these messages; time that could be better spent
As for warning messages, ignoring them makes you feel like a professional programmer who's not scared of computers. What better way of showing one's experience as a programmer than delivering a program that generates dozens, no, hundreds of warning messages when it compiles without its author feeling the slightest bit concerned? Everyone can see that you're an experienced, laid-back programmer who is too busy to waste time on drivel.
Don't stop to think
Let's not kid ourselves here. What are we building? A program. What is the only thing that really matters in a program? Code. What really works? Code. Why use outdated resources like pencils, pens or paper? You are a paid-up member of the SMS generation; you don't make a fool of yourself writing time-consuming syllables, right? Then, stop messing around thinking about nothing when there's so much code to write.
You should never stop coding. We all know that error messages are an unacceptable interruption, a pointless obstacle as we go about our work. So what do you do if you get a compiler error message? As you should know by now, reading and understanding it is just not an option.
You can try making some random change to the source code. You never know, you might pull the wool over the compiler's eyes. But if this doesn't work, don't waste any more time. NO, don't be tempted by trying to read the message or understanding it. Just keep churning out code - that's the only way of finishing off this horrendous assignment. You'll get to sort the error out later on. And as we all know, errors tend to disappear by themselves if they're ignored. At the end of the day you'll compile, you'll run, and even if you had tested (not that you needed to) you'd have seen that everything was OK.
If the code compiles but does something wrong, it doesn't really matter; sort it out later, when it's finished. Anyway, you might get lucky and find out that the lecturers have changed the assignment outline and that it fits in with your program after all. So don't take the risk of fixing programs that seem to be off track - you might be wasting your time. I don't want any trouble
If your program contains a bug that crops up every now and again, it will be difficult to find and it won't probably show up during the exam demo. Maybe it will disappear by itself. Don't worry. But if the bug comes up again and again, change things at random until it disappears. We've already said that pausing for thought is not an option. If you decide to get rid of the bug - simply because the urge takes you - just write the same code in different ways. Maybe the problem will disappear; something you'll have achieved without 1) understanding what caused it, and 2) having to stop writing code. Clearly, this is the most professional approach.
Don't compile on a regular basis, don't tiptoe your way forward. You're a professional and professionals take giant steps. Write thousands of lines of code first and leave the compiling for later; it will be far more entertaining and worthwhile to look for compiling errors.
The same rule applies for runtime errors. If you try to keep your program correct as it grows, it will be too easy to pinpoint a new bug. Only cowards do that. A real programmer writes the entire program and then digests it whole like a boa constrictor. Looking for a bug hidden in the last 10,000 lines is exciting but if there are only 10 or 20 lines, well, what fun is there in that?
And... why use debuggers? It's up to the lecturer to look for your bugs. Programming errors are the except