Spooky action at a distance is only spooky if one assumes distance is real and not an emergent property of a projected/holographic universe. In the same way in a computer simulation/game...
Perhaps the entire Universe runs on Hillary's home server. No wonder the 'ghazi committee is so determined.
As I mentioned nearby, many languages don't support any money-friendly types.
Using integers or self-rolled "number string" libraries carry their own risks, both machine and human.
I've used Double before many times for money without problems. The trick is to round the values to 2 decimals before and after every multiplication or division, and before saving.
Or to keep it simple: "round all values before and after any math".
One can make four wrapper functions: add_dollar(), subtract_dollar(), multiply_dollar(), and divide_dollar(). Example:
function multiply_dollar(d1, d2) {
places = 2;
r1 = round(d1, places);
r2 = round(d2, places);
result = r1 * r2;
result = round(result, places);
return(result); }
I see such for assembly being somewhat of a help because assembly op-codes are usually cryptic. But anybody qualified to alter the code should learn the op-codes anyhow.
It does underscore the point though that the existence of comments/documentation and the usefulness of comments/documentation can be two very different things.
I bet the contract required that every subroutine be commented, but said nothing of quality of comments.
Some PHB probably noticed this AFTER the code was written and took advantage of the poor contract wording, telling somebody to write an automated commenter.
"Coupling" is a vague concept, I have found out. Specific "types" of coupling could be called code patterns, but coupling as a general concept is vague (as currently described by authors).
As far as function/method size, in my opinion "it depends". If it's quite short or quite long, at least pause to ask "why" and consider alternatives. But don't force every one to be 20 lines out of some ritual habit.
My "best" shorter methods tend to be called many times. They often consolidate commonly-found domain idioms into a simpler concept.
We still don't have #&@!% flying cars, but we do have nifty tablets to read USA Today on, unlike the flick's paper version.
Hover-boards? Well, kind of, if you count big and noisy. 3D pop-out sharks? Well, kind of, if you are at the right spot (although automated eye position tracking is improving).
One is weighing the cost of slower code reading against naming collision risk here. The slower reading is a constant but small "tax", while the name collision is a relatively rare but notable event when it does occur. I'm not convinced the average longer run cost of name collisions is greater than the average longer run reading "tax".
Perhaps a compromise is order: dh_vndr_id or dhous_vndr_id.
Maybe your shop's language or coding style increases the risk of name collisions more than average. If you have a large code base, you probably want context, name-space, and/or class qualifiers anyhow.
Variable and object naming, and commenting is an art-form that takes experience to do well. Here's a few practical guidelines I've learned follow:
1. Think of newspaper headlines when commenting. Don't make somebody read the whole article to know what the article is about.
2. Comment the "odd" stuff, not the obvious stuff infer-able from function name etc.
3. Goldilocks Rule: Names both too long and too short can be bad.
4. The more frequent a name is used, the shorter it should be. Use comments at declaration to give the full name. Example of a variable that may be used often:
var dhv_id;// Department of Housing vendor ID
If it's used often, I'd rather have an abbreviation than see DeptOfHousingVendorID all over the code, making it long and "wrappy".
5. Everybody has their own preference, but you have to target the "average" developer (future unknown reader) to make code future-friendly.
Just because we generally support the prez doesn't mean we agree with everything he does. That's an unrealistic expectation: we vote for a representative, not individual initiatives.
Maybe there is a legitimate security reason to keep the details of this stuff secret: it's obviously dangerous in the wrong hands. Unfortunately we cannot directly tell if the secrecy is justified because it's still secret.
Let's hope our system of checks and balances works to ensure there is a reasonable review and consensus on this.
Also, I believe her office had a separate "special" system for classified messages. This is not the "regular" server for non-classified info. However, the details are classified, for obvious reasons.
I am nearly 50....[they asked] "Tell me about a time you worked with younger people and what the challenges were"
I've heard that kind of questioning back even when I was in my early 40's, in multiple interviews. IT runs in dog-years or something.
Companies often don't value experience because they cannot "see" the benefits of it. Most of the managers are short-term thinkers and the 60-hour code-monkey mentality gets you quicker short-term results in the latest IT fad.
However, if you care about 5 years out or more, than experience can make a huge difference. I started pointing that out in interviews and gave examples. Some didn't seem to care, and those are probably managers who expect to be promoted etc. within 5 years and don't give a fudge about the long term.
But some did seem to care, especially those burnt by hit-and-run coding/design.
The US corporate world is generally a short-term world, for good or bad, and in that environment, experience is not as valued. That's just the way it is.
But you seem to be talking about changes in developer behavior and design approach. That complicates the hardware-centric comparison. As far as existing and typical programs (as currently done), C-compiled programs usually beat their competitors.
Good! Maybe AT&T will finally use the system to realize we are sick and tired of their telemarketing calls and that we hate their slimy guts for their billing gimmicks.
Right now they seem clueless, as if a bunch of PHB's in a room stick a wet finger in.....the air to make a GUESS that we like being annoyed and that annoying us somehow makes them more profitable.
Robots couldn't do worse than the current marketing idiots there. Hell, give chimps a try also.
Slashdot Mirror
Perhaps the entire Universe runs on Hillary's home server. No wonder the 'ghazi committee is so determined.
They were ALL told to do that because they had no email backup server. The IT chief said so.
And as the law is written, it does NOT say the archiving has to be fail-proof. Even paper copies get eaten by rats or soiled by plumbing leaks.
Laws rarely define such contingencies. They are written by lawyers and politicians, NOT disaster recovery or prevention experts.
Adding such details into law could really bloat them up, and Republicans seem to repeatedly complain about the size of laws.
GOP wants contradictory things because they are not logical. (True, few politicians are.)
As I mentioned nearby, many languages don't support any money-friendly types.
Using integers or self-rolled "number string" libraries carry their own risks, both machine and human.
I've used Double before many times for money without problems. The trick is to round the values to 2 decimals before and after every multiplication or division, and before saving.
Or to keep it simple: "round all values before and after any math".
One can make four wrapper functions: add_dollar(), subtract_dollar(), multiply_dollar(), and divide_dollar(). Example:
I see such for assembly being somewhat of a help because assembly op-codes are usually cryptic. But anybody qualified to alter the code should learn the op-codes anyhow.
It does underscore the point though that the existence of comments/documentation and the usefulness of comments/documentation can be two very different things.
I bet the contract required that every subroutine be commented, but said nothing of quality of comments.
Some PHB probably noticed this AFTER the code was written and took advantage of the poor contract wording, telling somebody to write an automated commenter.
A bunch of code Monkees
"Coupling" is a vague concept, I have found out. Specific "types" of coupling could be called code patterns, but coupling as a general concept is vague (as currently described by authors).
As far as function/method size, in my opinion "it depends". If it's quite short or quite long, at least pause to ask "why" and consider alternatives. But don't force every one to be 20 lines out of some ritual habit.
My "best" shorter methods tend to be called many times. They often consolidate commonly-found domain idioms into a simpler concept.
We still don't have #&@!% flying cars, but we do have nifty tablets to read USA Today on, unlike the flick's paper version.
Hover-boards? Well, kind of, if you count big and noisy. 3D pop-out sharks? Well, kind of, if you are at the right spot (although automated eye position tracking is improving).
I did the math, and got -22x faster. I'll pass on it, Thank You.
I don't know how many times I've written comments similar to:
One is weighing the cost of slower code reading against naming collision risk here. The slower reading is a constant but small "tax", while the name collision is a relatively rare but notable event when it does occur. I'm not convinced the average longer run cost of name collisions is greater than the average longer run reading "tax".
Perhaps a compromise is order: dh_vndr_id or dhous_vndr_id.
Maybe your shop's language or coding style increases the risk of name collisions more than average. If you have a large code base, you probably want context, name-space, and/or class qualifiers anyhow.
Many languages don't offer money-friendly types. If one is careful about rounding at the right time, one can live with Double for smaller amounts.
I meant real newspapers, not tabloids :-)
(Do they still make those?)
get_off_my_lawn(exclamation);
Hungarian notation (HN) is controversial. If the variable's name is a sufficient clue to the type, I'd consider skipping HN.
For example, "lineCount" is pretty obviously an integer, and invoiceAmt (or invoiceAmount) is obviously a monetary value (typically "double").
I like to use "isX" for booleans, such as "isGood" for a quality check flag, or "isFinished" for a loop flag.
They both have their trade-offs and it's probably a close call either way if done smartly.
So, how does shooting make you feel?
Variable and object naming, and commenting is an art-form that takes experience to do well. Here's a few practical guidelines I've learned follow:
1. Think of newspaper headlines when commenting. Don't make somebody read the whole article to know what the article is about.
2. Comment the "odd" stuff, not the obvious stuff infer-able from function name etc.
3. Goldilocks Rule: Names both too long and too short can be bad.
4. The more frequent a name is used, the shorter it should be. Use comments at declaration to give the full name. Example of a variable that may be used often:
var dhv_id; // Department of Housing vendor ID
If it's used often, I'd rather have an abbreviation than see DeptOfHousingVendorID all over the code, making it long and "wrappy".
5. Everybody has their own preference, but you have to target the "average" developer (future unknown reader) to make code future-friendly.
Here.
"Oh, I remember now. You wet your finger and quickly stick it into this little socket here..."
Just because we generally support the prez doesn't mean we agree with everything he does. That's an unrealistic expectation: we vote for a representative, not individual initiatives.
Maybe there is a legitimate security reason to keep the details of this stuff secret: it's obviously dangerous in the wrong hands. Unfortunately we cannot directly tell if the secrecy is justified because it's still secret.
Let's hope our system of checks and balances works to ensure there is a reasonable review and consensus on this.
Correction, "Mrs. C", not H.
Also, I believe her office had a separate "special" system for classified messages. This is not the "regular" server for non-classified info. However, the details are classified, for obvious reasons.
Any off-the-shelf service or system is probably quite vulnerable to large-state-sponsored hacking.
And this includes "generic" gov't servers not designed for storing secrets (such as the one Mrs. H "should have used").
I've heard that kind of questioning back even when I was in my early 40's, in multiple interviews. IT runs in dog-years or something.
Companies often don't value experience because they cannot "see" the benefits of it. Most of the managers are short-term thinkers and the 60-hour code-monkey mentality gets you quicker short-term results in the latest IT fad.
However, if you care about 5 years out or more, than experience can make a huge difference. I started pointing that out in interviews and gave examples. Some didn't seem to care, and those are probably managers who expect to be promoted etc. within 5 years and don't give a fudge about the long term.
But some did seem to care, especially those burnt by hit-and-run coding/design.
The US corporate world is generally a short-term world, for good or bad, and in that environment, experience is not as valued. That's just the way it is.
Oh no, Putin's after Fluffy the Kitten again!
But you seem to be talking about changes in developer behavior and design approach. That complicates the hardware-centric comparison. As far as existing and typical programs (as currently done), C-compiled programs usually beat their competitors.
Good! Maybe AT&T will finally use the system to realize we are sick and tired of their telemarketing calls and that we hate their slimy guts for their billing gimmicks.
Right now they seem clueless, as if a bunch of PHB's in a room stick a wet finger in.....the air to make a GUESS that we like being annoyed and that annoying us somehow makes them more profitable.
Robots couldn't do worse than the current marketing idiots there. Hell, give chimps a try also.