... a plan that involves phasing out versions of Microsoft's Office productivity suite deployed in the state's executive branch agencies
Actually, the plan does not necessarily involve phasing out anything. As the parent post suggests, Microsoft can continue to be a contender by modifying Office to support open document formats.
Once large companies and governments realize that they can get along just fine without Microsoft products, it will be even harder to get them back on the crack, so to speak.
This is why Microsoft is fighting this tooth and nail.
(I've always said if you want an explanation of their marketing strategy, ask the crack man.)
They are mortally afraid of people discovering that they do have choices.
I agree with the parent that MS will probably come around eventually, but I think they'll be dragged into the future kicjing and screaming.
You didn't actually tell us whether you have any other data base experience. In general, when you're setting out to use an RDBMS (whether it's Oracle, DB/2, Sybase, PostgreSQL, whatever), there are two areas to tackle:
A general understanding of how and why relational databases work.
The specifics of how to use your particular platform.
(To put it into a more purely programming context, you might think of the first as like what you might find in Knuth's Art of Computer Programming, and the second as like Kernighan & Ritchie's The C Programming Language.)
It's been a while since I used Oracle, so I can't really give you any current recommendations for no. 2. (O'Reilly has some offerings in this category that, in their early editions, were pretty decent.)
For no. 1, though, I suggest you pick up a copy of A Guide to the SQL Standard, by Chris Date and Hugh Darwen.
Date is one of the "pioneers" of relational data bases, and this book is a good reference to the "why" of how they work.
I hope that Microsoft can pay more attention to implementing the cryptographic functions correctly than they have at times in the past. Bruce Schneier has a note in his Crypto-Gramnewsletter
for February 2005 on a flaw in MS's implementation of RC4:
One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext -- and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.
...
Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake....
He cites a
paper
by Hongjun Wu, as well as a
report of an earlier (1999) MS crypto vulnerability.
Perhaps Halliburton should demand the government choose it to reconstruct New Orleans using Halliburton...
Actually, Halliburton doesn't need to demand anything -- their friends in the administration take care of that for them. They've already been given a contract for the reconstruction of some Navy facilities, as reported in the
Houston Chronicle:
The Navy has hired Houston-based Halliburton Co. to restore electric power, repair roofs and remove debris at three naval facilities in Mississippi damaged by Hurricane Katrina.
You'll note that this was reported on September 1. People were still suffering without food and water; but hey, first things first.
OSRM will assess both the risk of the software in use and the individual company, before passing on the risk to the appropriate insurance company on the Lloyds market. OSRM expects to announce the first customers this Fall, and will initially charge organizations $60 per server.
As the article summary indicates, OSRM is going to be the US agent for the insurance.
Some arrangement like this was more or less inevitable if OSRM's insurance concept was going to work.
OSRM itself almost certainly doesn't have the resources (read, deep pockets) to underwrite the coverage.
I've done IT budgeting for a couple of decades in several different firms, ranging in size from 30 to about 5000 employees, and I think using these percentage or $/employee formulas is an excellent way to perform a surgical strike on your foot. Here's how I approach it, in broad terms:
FIGURE OUT WHAT YOU SPEND MONEY FOR
You can use a previous budget, or actual expenditure figures, plus a "wish list" of new stuff. The point is just to make sure you have a complete list of the things you're going to need to pay for.
(Some of this will depend on how your firm accounts for things: for example, does the IT budget need to include imputed costs for office space. Talk to your financial guy.)
ESTABLISH ESTIMATION METHODS
For each category of expense, figure out a sensible way to estimate the cost. Some categories (e.g., salary + benefits for current employees, maintenance contracts) will be easy. Others (e.g., new development projects) will be more problematic.
CALCULATE ESTIMATES FOR EACH CATEGORY
Apply the methods you identified in step 2, and include an appropriate risk contingency -- more uncertain, difficult to forecast items get a higher contingency amount.
COMMUNICATE
The most important step. The budget should not just be thrown out as pearls before swine -- it's vital that you document, and that people understand, the estimation basis (as in Step 2) for the budget estimates. (This will defuse a lot of arguments. It may also uncover some land mines: "Gee, how much of this is for the new office we're planning" -- and forgot to tell you about.)
Finally, especially if people in your firm aren't used to a formal budget process (which is sometimes the case in small firms), be careful of two fundamental (and very stupid!) budget fallacies:
Putting money into the budget does not (or, at least, should not) guarantee that it will be spent.
Taking money out of the budget emphatically does not guarantee that it will not be spent.
(You may think I'm belaboring the obvious, but I assure you I have seen these two crop up many times.)
I've implemented a couple of database applications across multiple geographical locations (in "Wall Street" contexts), and I think the one thing that you must be sure of is that you really understand all the ways in which the data is used in and impacts the real-world business.
You mention that this is for an accounting application. You suggest a scheme with local databases that periodically send updates to the central facility. If the books and records are in a strict hierarchy (each node is contained in exactly one "higher" node), this can work fine for some purposes, like financial reporting.
In the situations I worked on, people initially agreed that this sort of setup would be fine. However, as we dug a little deeper, we realized it wouldn't work, because financial reporting wasn't the only real need. In the context of an investment bank, the capacity to take risk is a (finite) asset, and the amount of capacity that's available at any time is a function of all the trades that have been done anywhere -- since everything is ultimately reflected back to the parent's accounts. Had we not realized that, we would have built a fine system that we would have started rebuilding as soon as we'd finished it (cf. There's never time to do it right, but always time to do it over).
I won't belabor things like redundancy, backups, and so on; I assume you have taken careful thought for those.
Finally, IMO, the trickiest thing to get right in a distributed DB system is maintaining the referential and logical integrity of the database. I personally know of one well-known DB vendor's initial replication solution (names omitted to protect the guilty) that had a subtle but potentially very serious logical flaw. Moral: do your own homework.
I think one reason that companies resist releasing specs is that, in common with many folks, they don't have a very clear understanding of what it is they're trying to secure, and why. (See Bruce Schneier's excellent book, Beyond Fear, for lots of examples of this sort of thing.) In addition, some PHB types are probably mesmerized by visions of "IP profit" sugarplums planted in their heads by legal types.
I can't resist adding another reason from personal experience. Some years ago, I took a new job as an IT manager at a financial services company. (Names are omitted to protect the guilty.) One of the branch offices was developing a new trading system for international derivative securities. I thought that was quite interesting, and asked to see the data base schema (derivatives being sort of a specialty of mine).
I got a lot of run-around, and was told it was highly confidential since "if someone sees the design, he'll be able to figure out our trading strategy." ME thinks, "This must be some data base."
I eventually got a copy. They were right to keep it confidential: anyone who saw it and knew anything about the business would have realized immediately that they didn't know what the fuck they were doing (apart from spending money like a bunch of drunken sailors).
We closed that operation a few weeks later.
My little-used ones are in my wallet, too. Old ones that I might need are written on a card that's locked in my (physical) office safe.
Having draconian polcies against writing down passwords will most likely result in people choosing really poor, easily guessed passwords.
It's overall security that matters, not how you get there.
Incidentally, Bruce Schneier has said that he keeps passwords written down in his wallet.
(Aside: there is a very funny chapter called something like "Feynman, the genius safecracker" in RF's book,
Surely You're Joking, Mr. Feynman,
which relates to this quite well.)
I could have put that better. When I said copy protection "died", I didn't mean that it disappeared entirely, but that enough alternatives developed that it wasn't really a big factor anymore. And it usually wasn't a factor at all for large customers. Even today, corporate customers for MS Windows do not have to deal with product activation -- that's why those are the license keys that get "pirated".
I do agree that the legal / legislative angle is troubling, but that's a problem that only has a political solution.
I have thought this whole lawsuit was a crock since very shortly after it was filed, and that it was all about manipulating the stock price so that the insiders could sell.
SCO's management claimed that the stock sales (which you can find on their Form 4 filings with the
SEC) were part of a pre-arranged sale plan that had absolutely nothing to do with the litigation. The sale plan was filed two months before the lawsuit was filed. That sure seems plausible to me.
The mindset of the people that develop these things must be very strange. Do they think that people have to buy their stuff?
Let's do a thought experiment. Suppose the crack man, having a local monopoly, develops a new form of the drug that requires one of his fancy hi-tech crack pipes. Do you suppose that all the addicts will just pay the extra money indefinitely, so he can get richer?
That another dealer might not be tempted to offer an alternative?
Those of us who are old enough will remember "copy protected" software from the early days of the PC.
That died a well-deserved death before too long, because it was only effective for giving legitimate customers a pain in the ass.
So even though you "secured" your system, it's still vunerable because as long as you have anything in your whitelist (especially mozilla.org or the defaults), you're vunerable.
No, I'm not. Your point about the whitelist is correct, but I'm not depending on the whitelist, except during those very limited intervals when I have "Allow web sites to install software" turned on (and when I always type in the URL by hand).
Actually, the point of my original (beginning of this thread) post was that leaving the "... install software" option enabled all the time was not a good idea on general principles.
OK, that's fair enough, I guess. I can certainly see how a non-technical user could get bitten by this.
When I install any new piece of software, the first thing I do (before connecting to the Internet) is to go into Edit / Preferences or the equivalent, and disable everything like this that's visible. (Even though, in this case, I have only official Moz sites in the whitelist.)
I guess I've been doing systems admin too long. Colour me paranoid.
Speaking from a system developer's perspective, there are two techniques that I think are not used enough:
Use Configuration Files / Tables Intelligently
Sometimes applications that need to process data from a variety of sources can be made much easier by spending a bit of time designing configuration resources. This can include designing "little languages", incorporating tools like lex and yacc.
Example: We once had to build a system to process real-time market data feeds from a variety of sources. The sources sometimes changed the format of their feeds, and we had to add new sources semi-regularly. Fortunately, there was a great deal of logical commanality among the sources. We wrote a little language which could be used to describe a source, then processed that to generate the server configuration tables automatically. That meant quicker turnaround and fewer errors with many fewer code tweaks.
Use Existing Tools
There is no need to re-invent the functionality of a packaged application that you already have.
Example: We had to generate transaction confirmations in a variety of forms, depending on factors like existing/new customer, applicable law, type of transaction, etc. The data was all in a database, but the text pieces got changed fairly frequently, since it was a new business area. We used a database extract program together with mail/merge in a commercial word processor (WordPerfect on Unix) to generate the documents. That gave much quicker development (no need to write formatting / text manipulation stuff), with the added advantage that the end product was a directly-printable document that could be easily edited by hand in case of last-minute changes.
This ID card will NOT make you any safer in any way whatsoever.
I entirely agree. First of all, it is worth remembering that almost all of the 9/11 terrorists had valid, DMV-issued IDs.
There is nothing that I can see in this bill that is going to fix that.
It will also screw up the effort in some states to give limited driver's licenses to (possibly) illegal immigrants, in the interest of seeing that they actually know how to drive, have insurance, and so on. Since, statistically, your chances of dying in an auto accident are much higher than in a terrorist incident, I don't think this is a trivial concern.
Second, the whole concept of checking IDs against a list in order to fly is stupid. If we know who the suspects are, it would be much more efficient to spend the resources investigating what they're doing. Does anyone actually believe that potential terrorists are so dumb that they'll not try flying before they do the real thing? Or that they might not consider just blowing up a shopping center or a sports stadium?
These data are worth billions upon billions and they won't be sitting idly in some database in DC doing nothing.
Even assuming I trusted the government 100% not to misuse this data, one class of people to whom it would be very valuable are identity thieves.
I suppose the argument will be that the database is so secure it can't be hacked.
In the gym in question, it's clear that this isn't being done to heighten security; it's just to keep people from having to drag a gym id around. Also, it's much faster to slam your thumb on a pad than to hold out a card for someone to scan.
It's not clear to me that this is being done to keep people from needing their gym ID, although that is one possible reason. But it does at least address the first question that ought to be asked: what is the problem we are trying to solve here?
Not having to carry the ID is one possibility. Another might be to prevent people from buying one membership to be used by, for example, five roommates. I suppose it's also possible that they want to protect against some sort of identity theft, but I have to say that I think the demand for phony gym IDs for Rocky River OH might be, um, limited.
If the goal is to allow people to come to the gym without their card, I'd think it would likely be easier and cheaper to just store their photos in the membership data base (which they presumably have, since the fingerprint info has to go somewhere). If the goal is to prevent multiple people using one membership, have the desk people look at the picture on the card. It really should not be beyond the wit of man to accomplish this. (At my gym, they take the card when you enter, and return it when you leave.)
I wouldn't worry so much about security technology as about the strong likelihood that the people that run the place ran out of clues sometime during the Reagan administration.
Apart from trying to hire "trustworthy" people, are there any other bright ideas that Slashdot readers might have in this regard to help prevent such theft from workplace?
I think the core difficulty here is that you think you have a technology problem, when what you have is a management problem.
If you rule out hiring trustworthy people, and fostering an atmosphere that earns their trust, then you are just wasting your time.
Think about this: do you think that putting in time clocks would make physicians (let's say) work harder ?
You also need to think about what it is that you are actually trying to protect. One defect (among many) of the term "intellectual property" is that it leads people to think by analogy with actual (tangible) property.
If your IP is in software, what are you trying to protect: the typing of the code, or the ideas the code embodies?
If it is the latter, you can't open your employees' skulls and remove the ideas from them.
I worked in, and managed, an investment management firm, where it was a truism that our most important assets walked out the door every night.
You have to run the business so that people want to work there; so that they have fun, find the work and their environment interesting, and believe that they will be fairly compensated (financially and otherwise).
It isn't necessarily easy, but then that's what you get paid for.
To add to the list I would also highly recommend "How the mind works" by Stephen Pinker
I'll strongly second that recommendation. Pinker's book is very informative, and he is a wonderful writer as well as an accomplished scientist -- I'd put him in the same class as Richard Dawkins.
Other worthwhile books by Pinker in this area include The Language Instinct and The Blank Slate.
There's a huge difference between 95% of firms not delivering a project ontime, and 95% of all projects being late.
That is for sure. Let's think first about the process of estimating the time required for a project. If these estimates are unbiased, then they are by definition as likely to be optimistic as pessimistic.
Now I don't necessarily believe that, even if unbiased estimates are produced, they are what is given to the "customer". Prudence (what the cynical would call CYA) dictates that some margin for estimation error be built into the schedule for a project, just as in the project budget. At the very least, the project manager needs to make sure that the customer understands the difference between an estimated time and a "contractually guaranteed" time.
There are probably two opposing things at work: one is prudence, and the other is the desire to sell the customer, which can lead to what someone (Ed Yourdon ?) called "the most optimistic value that is not demonstrably impossible."
Personally, I'd be suspicious that organizations that never have late projects are just better at padding their estimates.
Plenty of nerds are unbearable when they're right, and others just don't like what they hear.
I don't think we really disagree, but I think you're conflating a couple of different things. I should have also quoted this from a bit further along in the article:
We could bear any amount of nerdiness if someone was truly smart. What we couldn't stand were people with a lot of attitude. But most of those weren't truly smart, so our third test was largely a restatement of the first.
The Mensa member I mentioned wasn't actually all that smart -- that's precisely why he was so annoying.
People that are really smart (RMS is certainly an example) sometimes do annoy people by challenging things, but those challenges are based on a substantive argument.
(And often, the people that get most annoyed are those that are themselves not exactly the sharpest knives in the drawer.)
What I was talking about, and what I think the original author was talking about, is people who want you to accept everything they say because they are "smart".
When nerds are unbearable it's usually because they're trying too hard to seem smart. But the smarter they are, the less pressure they feel to act smart. So as a rule you can recognize genuinely smart people by their ability to say things like "I don't know," "Maybe you're right," and "I don't understand x well enough."
This paragraph is one that some PHBs could study to their benefit. I once was associated (fortunately only in a consulting capacity) with a start-up boss who hired, as his marketing person, one of the most obnoxious people I have ever met. He (marketing guy) was constantly mentioning that he was a member of Mensa. For some odd reason, this did not go over too well with potential customers.
When someone makes a point of telling me how honest he is, I make sure to count my fingers after we shake hands. My reaction to people who tell me how smart they are is similar.
The client is currently available for Windows XP, 2000, ME, and 98.
I've been doing SETI@home for a while now, and was pleased to see the announcement of this in the press.
I was less pleased when I went to the
web site, and found out that (as it says above) the only client was for Windows.
Since I use only Linux these days, I guess that leaves me out.
I hope that with IBM's involvement, and stated committment to Linux, this will change soon. I sent them a note, using the "Contact Us" form on the web site, and would encourage others to do the same.
(Incidentally, I've been running SETI@home initially on Windows, now on Linux, using the command-line client in both cases. I find I get ~50% more work units/time with Linux, and less impact on interactive use of the machine.)
Tinkertoys and Legos are really good choices, as is an Erector Set (do they still make those ?). Also, when I was young, we had a set of large (roughly shoebox-sized) corrugated cardboard blocks; they were sturdy enough to sit on, make forts with, etc.
The toys I remember playing with most were the ones that left some room for the imagination.
For more active toys: trikes and bikes, and, if you live in the right climate, a Flexible Flyer sled.
Slashdot Mirror
Actually, the plan does not necessarily involve phasing out anything. As the parent post suggests, Microsoft can continue to be a contender by modifying Office to support open document formats.
Once large companies and governments realize that they can get along just fine without Microsoft products, it will be even harder to get them back on the crack, so to speak.
This is why Microsoft is fighting this tooth and nail. (I've always said if you want an explanation of their marketing strategy, ask the crack man.) They are mortally afraid of people discovering that they do have choices. I agree with the parent that MS will probably come around eventually, but I think they'll be dragged into the future kicjing and screaming.
- A general understanding of how and why relational databases work.
- The specifics of how to use your particular platform.
(To put it into a more purely programming context, you might think of the first as like what you might find in Knuth's Art of Computer Programming, and the second as like Kernighan & Ritchie's The C Programming Language.)It's been a while since I used Oracle, so I can't really give you any current recommendations for no. 2. (O'Reilly has some offerings in this category that, in their early editions, were pretty decent.) For no. 1, though, I suggest you pick up a copy of A Guide to the SQL Standard, by Chris Date and Hugh Darwen. Date is one of the "pioneers" of relational data bases, and this book is a good reference to the "why" of how they work.
Actually, Halliburton doesn't need to demand anything -- their friends in the administration take care of that for them. They've already been given a contract for the reconstruction of some Navy facilities, as reported in the Houston Chronicle :
You'll note that this was reported on September 1. People were still suffering without food and water; but hey, first things first.OSRM will assess both the risk of the software in use and the individual company, before passing on the risk to the appropriate insurance company on the Lloyds market. OSRM expects to announce the first customers this Fall, and will initially charge organizations $60 per server.
As the article summary indicates, OSRM is going to be the US agent for the insurance. Some arrangement like this was more or less inevitable if OSRM's insurance concept was going to work. OSRM itself almost certainly doesn't have the resources (read, deep pockets) to underwrite the coverage.
-
FIGURE OUT WHAT YOU SPEND MONEY FOR
-
ESTABLISH ESTIMATION METHODS
-
CALCULATE ESTIMATES FOR EACH CATEGORY
-
COMMUNICATE
Finally, especially if people in your firm aren't used to a formal budget process (which is sometimes the case in small firms), be careful of two fundamental (and very stupid!) budget fallacies:You can use a previous budget, or actual expenditure figures, plus a "wish list" of new stuff. The point is just to make sure you have a complete list of the things you're going to need to pay for. (Some of this will depend on how your firm accounts for things: for example, does the IT budget need to include imputed costs for office space. Talk to your financial guy.)
For each category of expense, figure out a sensible way to estimate the cost. Some categories (e.g., salary + benefits for current employees, maintenance contracts) will be easy. Others (e.g., new development projects) will be more problematic.
Apply the methods you identified in step 2, and include an appropriate risk contingency -- more uncertain, difficult to forecast items get a higher contingency amount.
The most important step. The budget should not just be thrown out as pearls before swine -- it's vital that you document, and that people understand, the estimation basis (as in Step 2) for the budget estimates. (This will defuse a lot of arguments. It may also uncover some land mines: "Gee, how much of this is for the new office we're planning" -- and forgot to tell you about.)
-
Putting money into the budget does not (or, at least, should not) guarantee that it will be spent.
-
Taking money out of the budget emphatically does not guarantee that it will not be spent.
(You may think I'm belaboring the obvious, but I assure you I have seen these two crop up many times.)You mention that this is for an accounting application. You suggest a scheme with local databases that periodically send updates to the central facility. If the books and records are in a strict hierarchy (each node is contained in exactly one "higher" node), this can work fine for some purposes, like financial reporting.
In the situations I worked on, people initially agreed that this sort of setup would be fine. However, as we dug a little deeper, we realized it wouldn't work, because financial reporting wasn't the only real need. In the context of an investment bank, the capacity to take risk is a (finite) asset, and the amount of capacity that's available at any time is a function of all the trades that have been done anywhere -- since everything is ultimately reflected back to the parent's accounts. Had we not realized that, we would have built a fine system that we would have started rebuilding as soon as we'd finished it (cf. There's never time to do it right, but always time to do it over).
I won't belabor things like redundancy, backups, and so on; I assume you have taken careful thought for those.
Finally, IMO, the trickiest thing to get right in a distributed DB system is maintaining the referential and logical integrity of the database. I personally know of one well-known DB vendor's initial replication solution (names omitted to protect the guilty) that had a subtle but potentially very serious logical flaw. Moral: do your own homework.
I can't resist adding another reason from personal experience. Some years ago, I took a new job as an IT manager at a financial services company. (Names are omitted to protect the guilty.) One of the branch offices was developing a new trading system for international derivative securities. I thought that was quite interesting, and asked to see the data base schema (derivatives being sort of a specialty of mine).
I got a lot of run-around, and was told it was highly confidential since "if someone sees the design, he'll be able to figure out our trading strategy." ME thinks, "This must be some data base."
I eventually got a copy. They were right to keep it confidential: anyone who saw it and knew anything about the business would have realized immediately that they didn't know what the fuck they were doing (apart from spending money like a bunch of drunken sailors). We closed that operation a few weeks later.
Having draconian polcies against writing down passwords will most likely result in people choosing really poor, easily guessed passwords. It's overall security that matters, not how you get there.
Incidentally, Bruce Schneier has said that he keeps passwords written down in his wallet.
(Aside: there is a very funny chapter called something like "Feynman, the genius safecracker" in RF's book, Surely You're Joking, Mr. Feynman, which relates to this quite well.)
I do agree that the legal / legislative angle is troubling, but that's a problem that only has a political solution.
SCO's management claimed that the stock sales (which you can find on their Form 4 filings with the SEC) were part of a pre-arranged sale plan that had absolutely nothing to do with the litigation. The sale plan was filed two months before the lawsuit was filed. That sure seems plausible to me.
I really hope someone nails these slimeballs.
(P.S. I've posted several notes on /. about this;
here's one from back in June 2003.)
Let's do a thought experiment. Suppose the crack man, having a local monopoly, develops a new form of the drug that requires one of his fancy hi-tech crack pipes. Do you suppose that all the addicts will just pay the extra money indefinitely, so he can get richer? That another dealer might not be tempted to offer an alternative?
Those of us who are old enough will remember "copy protected" software from the early days of the PC. That died a well-deserved death before too long, because it was only effective for giving legitimate customers a pain in the ass.
No, I'm not. Your point about the whitelist is correct, but I'm not depending on the whitelist, except during those very limited intervals when I have "Allow web sites to install software" turned on (and when I always type in the URL by hand).
Actually, the point of my original (beginning of this thread) post was that leaving the " ... install software" option enabled all the time was not a good idea on general principles.
When I install any new piece of software, the first thing I do (before connecting to the Internet) is to go into Edit / Preferences or the equivalent, and disable everything like this that's visible. (Even though, in this case, I have only official Moz sites in the whitelist.)
I guess I've been doing systems admin too long. Colour me paranoid.
Disable JavaScript, or disable the "Allow web sites to install software" option [Tools - Options - Web Features].
Why would anyone run routinely with "Allow web sites to install software" enabled ?
Use Configuration Files / Tables Intelligently
Sometimes applications that need to process data from a variety of sources can be made much easier by spending a bit of time designing configuration resources. This can include designing "little languages", incorporating tools like lex and yacc.
Example: We once had to build a system to process real-time market data feeds from a variety of sources. The sources sometimes changed the format of their feeds, and we had to add new sources semi-regularly. Fortunately, there was a great deal of logical commanality among the sources. We wrote a little language which could be used to describe a source, then processed that to generate the server configuration tables automatically. That meant quicker turnaround and fewer errors with many fewer code tweaks.
Use Existing Tools
There is no need to re-invent the functionality of a packaged application that you already have.
Example: We had to generate transaction confirmations in a variety of forms, depending on factors like existing/new customer, applicable law, type of transaction, etc. The data was all in a database, but the text pieces got changed fairly frequently, since it was a new business area. We used a database extract program together with mail/merge in a commercial word processor (WordPerfect on Unix) to generate the documents. That gave much quicker development (no need to write formatting / text manipulation stuff), with the added advantage that the end product was a directly-printable document that could be easily edited by hand in case of last-minute changes.
I entirely agree. First of all, it is worth remembering that almost all of the 9/11 terrorists had valid, DMV-issued IDs. There is nothing that I can see in this bill that is going to fix that. It will also screw up the effort in some states to give limited driver's licenses to (possibly) illegal immigrants, in the interest of seeing that they actually know how to drive, have insurance, and so on. Since, statistically, your chances of dying in an auto accident are much higher than in a terrorist incident, I don't think this is a trivial concern.
Second, the whole concept of checking IDs against a list in order to fly is stupid. If we know who the suspects are, it would be much more efficient to spend the resources investigating what they're doing. Does anyone actually believe that potential terrorists are so dumb that they'll not try flying before they do the real thing? Or that they might not consider just blowing up a shopping center or a sports stadium?
These data are worth billions upon billions and they won't be sitting idly in some database in DC doing nothing.
Even assuming I trusted the government 100% not to misuse this data, one class of people to whom it would be very valuable are identity thieves. I suppose the argument will be that the database is so secure it can't be hacked.
Right.
It's not clear to me that this is being done to keep people from needing their gym ID, although that is one possible reason. But it does at least address the first question that ought to be asked: what is the problem we are trying to solve here?
Not having to carry the ID is one possibility. Another might be to prevent people from buying one membership to be used by, for example, five roommates. I suppose it's also possible that they want to protect against some sort of identity theft, but I have to say that I think the demand for phony gym IDs for Rocky River OH might be, um, limited.
If the goal is to allow people to come to the gym without their card, I'd think it would likely be easier and cheaper to just store their photos in the membership data base (which they presumably have, since the fingerprint info has to go somewhere). If the goal is to prevent multiple people using one membership, have the desk people look at the picture on the card. It really should not be beyond the wit of man to accomplish this. (At my gym, they take the card when you enter, and return it when you leave.)
I wouldn't worry so much about security technology as about the strong likelihood that the people that run the place ran out of clues sometime during the Reagan administration.
I think the core difficulty here is that you think you have a technology problem, when what you have is a management problem. If you rule out hiring trustworthy people, and fostering an atmosphere that earns their trust, then you are just wasting your time. Think about this: do you think that putting in time clocks would make physicians (let's say) work harder ?
You also need to think about what it is that you are actually trying to protect. One defect (among many) of the term "intellectual property" is that it leads people to think by analogy with actual (tangible) property. If your IP is in software, what are you trying to protect: the typing of the code, or the ideas the code embodies? If it is the latter, you can't open your employees' skulls and remove the ideas from them.
I worked in, and managed, an investment management firm, where it was a truism that our most important assets walked out the door every night. You have to run the business so that people want to work there; so that they have fun, find the work and their environment interesting, and believe that they will be fairly compensated (financially and otherwise). It isn't necessarily easy, but then that's what you get paid for.
I'll strongly second that recommendation. Pinker's book is very informative, and he is a wonderful writer as well as an accomplished scientist -- I'd put him in the same class as Richard Dawkins.
Other worthwhile books by Pinker in this area include The Language Instinct and The Blank Slate.
That is for sure. Let's think first about the process of estimating the time required for a project. If these estimates are unbiased, then they are by definition as likely to be optimistic as pessimistic.
Now I don't necessarily believe that, even if unbiased estimates are produced, they are what is given to the "customer". Prudence (what the cynical would call CYA) dictates that some margin for estimation error be built into the schedule for a project, just as in the project budget. At the very least, the project manager needs to make sure that the customer understands the difference between an estimated time and a "contractually guaranteed" time.
There are probably two opposing things at work: one is prudence, and the other is the desire to sell the customer, which can lead to what someone (Ed Yourdon ?) called "the most optimistic value that is not demonstrably impossible."
Personally, I'd be suspicious that organizations that never have late projects are just better at padding their estimates.
I don't think we really disagree, but I think you're conflating a couple of different things. I should have also quoted this from a bit further along in the article:
We could bear any amount of nerdiness if someone was truly smart. What we couldn't stand were people with a lot of attitude. But most of those weren't truly smart, so our third test was largely a restatement of the first.
The Mensa member I mentioned wasn't actually all that smart -- that's precisely why he was so annoying. People that are really smart (RMS is certainly an example) sometimes do annoy people by challenging things, but those challenges are based on a substantive argument. (And often, the people that get most annoyed are those that are themselves not exactly the sharpest knives in the drawer.) What I was talking about, and what I think the original author was talking about, is people who want you to accept everything they say because they are "smart".
When nerds are unbearable it's usually because they're trying too hard to seem smart. But the smarter they are, the less pressure they feel to act smart. So as a rule you can recognize genuinely smart people by their ability to say things like "I don't know," "Maybe you're right," and "I don't understand x well enough."
This paragraph is one that some PHBs could study to their benefit. I once was associated (fortunately only in a consulting capacity) with a start-up boss who hired, as his marketing person, one of the most obnoxious people I have ever met. He (marketing guy) was constantly mentioning that he was a member of Mensa. For some odd reason, this did not go over too well with potential customers.
When someone makes a point of telling me how honest he is, I make sure to count my fingers after we shake hands. My reaction to people who tell me how smart they are is similar.
I've been doing SETI@home for a while now, and was pleased to see the announcement of this in the press. I was less pleased when I went to the web site, and found out that (as it says above) the only client was for Windows. Since I use only Linux these days, I guess that leaves me out.
I hope that with IBM's involvement, and stated committment to Linux, this will change soon. I sent them a note, using the "Contact Us" form on the web site, and would encourage others to do the same.
(Incidentally, I've been running SETI@home initially on Windows, now on Linux, using the command-line client in both cases. I find I get ~50% more work units/time with Linux, and less impact on interactive use of the machine.)
The toys I remember playing with most were the ones that left some room for the imagination.
For more active toys: trikes and bikes, and, if you live in the right climate, a Flexible Flyer sled.