or how the hell are you Director of IT without any background in DB design.
Anyone who has taken the first couple years of a Computer Science degree, should have a handful of expensive books on their bookshelf collecting dust.
Bullshit. I did, in fact, encounter database design in my coursework, but in a senior year elective. I've since taken an interest in relational theory, and I'm doubtful of the coverage of relational theory in undergraduate coursework.
Many CS academics view RDBMSs as an afterthought. I think it's because the industry is settled on SQL, and because SQL is pretty ugly as languages go, most academics don't want to get familiar with any relational theory. Unfortunately, most IT folks also skim over relational theory because they don't want to be tarred as being "purists."
If the OP is interested in that, CJ Date's Introduction to Database Systems is an outstanding book to learn the theory. Much of the book may be overkill, but the first third of it is broadly relevant, especially in clearly explaining basic theory and practice, and dispelling some very persistent myths.
My advice is to take some DB courses at your local university or online. If you don't have the prerequisites for those, I would argue you have no business trying to do this work yourself, and to hire a Computer Science Grad. They are a dime a dozen now, and will likely be happy just to have a job in his field when he graduates.
There is so much flatly wrong information about databases that many courses are pretty suspect. Most CS grads don't have much useful experience with databases and are about as useful as any code monkey.
I think their "90% dead-weight rule" is really a misnomer as you could probably claim that 90% of Google's indexing is never read but we all know that it's the potential that data holds that makes it so valuable and necessary.
Another problem is figuring out _why_ data isn't used before archiving it. Is it not useful, or are the tools not in place to use it?
If companies decide that the x% least used data will be shoved away in the attic, then "x% of data isn't useful" becomes a self-fulfilling prophecy.
Users will be looking at these abiguos contacs and not be able to figure out which way to insert their batteries.
(No it doesn't help that any way will do if the user doesn't know it.)
Yup, and I hope to God that any company using this tech will be smart enough to put a + and - in their compartment, and not rely on a logo that only a fraction of the people who read geek blogs will recognize. The logo also doesn't give any clue, to my mind at least, that you can put batteries in either direction.
All you've really got to go on is the weird looking terminals.
It rather raises the bar from unusable to barely usable
The real problem with LaTeX, IMHO, is the overabundance of misleading documentation scattered over the web, and the older packages that are buggy and terrible. 95% of problems I've had were due to using an old package or following some how-to that was outdated.
If you get a full TeXlive install, only use the newest packages and spend time studying the outstanding documentation on CTAN, LaTeX becomes a whole lot easier.
I like LyX, but (unless this has changed in the last year or so) there's virtually no support for defining your own commands or environments. To me, that's the biggest draw of *TeX. I know it's not a simple feature to implement, and it's impressive what you can do with LyX without it, but coming from LaTeX it's a big step down.
What about TeX stopping to use this unreadable syntax and moving to xml?
If TeX is unreadable, XML is unwritable and unreadable. At any rate, TeX itself is low-level, and when you use a package like LaTeX it becomes far more user-friendly.
Seriously? And is this company you worked for still in existence? If so, do you still work as a consultant, or are you now internal IT somewhere? I don't mean to be attacking, but most of the time we go to market simply because we lack the experience in-house to help the business figure out what they need.
I should expand on that: I was talking about long term wants and needs. They would present us with some short term requirements, and we made them a good website, but there was no follow-up.
No, they're not in existence. I went back to college a few months later and they were liquidated not long after that. This was '97, the whole Interwebs thing was pretty new, and the company owner decided it was the wave of the future. She poured money into it and neglected the best paying accounts, the combination of which broke the company.
In my real job, yup, still doing contract work, this time with a much more experienced firm, and we do real requirements and documentation. We take a much more active role in our contracts, taking their very vague specs and working with them to translate them into something that's actually useful. But it could be shelved, or another contract may fail, or it might never be maintained properly. In a nutshell, you can make a great sprocket and then find that no one's allocated funds for a flange and so the whole thing doesn't work.
they didn't know what they wanted or needed, and it certainly wasn't our job to figure it out.
Erm, as far as I'm concerned, that's exactly your job. Its what a requirements capture is for.
Heheh, local government, small business... there was no requirements process or any of that. I has done about a year of college, and was the only person who vaguely understood those crazy computers.
I feel quite offended by this attitude of yours - you're the expert. If I went to an architect and asked for a floating house, it would be his job to tell me that that's not what I really want, and to work with me on something more appropriate, rather taking the money and running away before my wife gets home.
What's wrong with a floating house? There are entire cities that are built on floating foundations due to lack of decent bedrock.
It's not like this stuff is obviously a bad idea. All of it makes sense in the short term. But these agencies have no bottom line, so they don't have a basis with which to plan for the future.
I hope you enjoyed the coke you snorted off hooker's cracks with my tax money.
RIght, you totally missed the part where I said "local government" and "small business."
As a web designer / developer I am always bewildered by the obscene costs I hear for government websites, especially given their terribly below level of quality and usefulness.
People with government contracts must really milk it for all it's worth.
I worked for a small company that did a website for a local government agency years ago, around '97 I think. They wanted all kinds of bells and whistles so they could go to their bosses and show them what an awesome web site they had. It was designed far more to please government insiders than to be useful to taxpayers.
I don't think we were milking them, rather, they didn't know what they wanted or needed, and it certainly wasn't our job to figure it out. They also didn't have any plan, really, to maintain it or scale it up or have it go anywhere. From going on to six years working in or around the government, that's just how they do stuff.
And consumers pass them on to employers... And employers pass them on to customers... and so on. I think that noone, in reality, pays taxes.
For a typical middle class schlub, if you get to work at 9am, take 11:30 to 12:00 for lunch and call it quits at 5:30pm, pretty much your morning goes to the government. Trust me, you really are paying taxes, every fucking day.
The reason I say corporations don't pay taxes is because only actual people pay taxes, corporations don't pay taxes because they don't actually exist. The people who associate to form the corporation, though, certainly do pay taxes.
Any increased costs may be passed on to the consumer, but not always.
That's why I said "consumers and investors". Since you seem rather skeptical of corporations, riddle me this: when they magically "absorb" these increased burdens, do you think it's going to be due to some brilliant synergy discovered by an intrepid MBA, or do you think they just worked it into the next round of nickel and diming everyone on the bottom of the food chain?
And even then, since they exist entirely at the grace of tax payers, they should have no right to any amount of privacy.
Really? People don't have an inalienable right to the freedom of association?
The point here is that people will drive in a manner that is neither safe for themselves or others on the road because they can and because they think it is ok without understanding why it isn't.
You're saying some people ignore all these useful rules or never bother to learn them. And you want to lower the speed limit for everyone because of them. This is in spite of the fact that you don't even believe the people who drive dangerously will obey the speed limits.
So you've started with 15% of the drivers who just naturally won't drive safely, and you're setting bullshit speed limits that the 80% of reasonably good drivers will ignore.
Messiness is not a bug, it's a feature. It both allows you to witness that the victim really is dead and, as an added bonus, doesn't hide the reality of what's being done at an execution behind the illusion of a mere medical procedure.
It turns it into a spectacle. If you throw gore and blood into people's faces, you're assuming that they'll shrink from the horror of it. Through most of human history, people have behaved the exact opposite way.
If you don't have a stomach to watch blood splatter from a severed neck, you shouldn't have anything to do with executions. In fact we should televise each and every execution and see how many people are still "though on crime" when they see just what they're voting for.
That illogic works both ways. If you can't stomach personally witnessing an entire family being brutally murdered by a psychopath, you shouldn't have anything to do with restricting executions.
Near future, perhaps not. But what if you could take your iPhone/AndroidPhone version 15 and set it on your desk next to a a pair of monitors, keyboard and fancy speakers and this FuturePhone would detect the devices.
I'd still probably have problems with the wireless keyboard / mouse wigging out periodically, having to change batteries. That is, unless physics changes its mind about the intrinsic wonkiness of wireless. Worse, anywhere there are free keyboards and monitors to use, someone will try to install a sniffer on them.
Our best athletes play football, baseball and basketball and our third-tier athletes still manage to hold their own in the World Cup.
Of course, you never know who was truly better in soccer because a 1-0 game can't be considered to be anything but dumb luck. Really, can you really prove that in a soccer game they don't just kick the ball back and forth endlessly until someone happens to be lined up for that one shot?
Parameterized SQL, or prepared statements, completely prevent SQL injection attacks. They might also speed things up in some circumstances. Why not simply use them exclusively?
I question the need for SQL. Can't we have a simple OO query system? We don't need to write strings of TCL to interact with GUI components.
I've never seen a complex GUI that could come back to the same state it was in when you pulled the plug on it. Nor have I ever seen a complex GUI that could run for years without having to be restarted. To my knowledge, every major operating system has a function to force kill a hung GUI.
SQL (or any system that tries to be as expressive as the relational model) isn't so important for queries as it is for declarative integrity.
If you don't have declarative integrity, you can't centralize your integrity checks. Then you wind up having to reimplement integrity checks through every application.
The typical enterprise scenario is that you have a live data source and when business rules change your schema has to change to reflect that, so you need to be able to update your integrity checks. It's virtually impossible to update live applications simultaneously to honor new integrity checks and guarantee the state of the data store. That's even if you limit yourself to using only thin-clients.
If your integrity checks are centralized in the DBMS, you can have an outdated or buggy client that doesn't know about a new check and it will simply fail with an error message rather than corrupting the state of the database. When your live data represents actual property, this is a major requirement.
Slashdot Mirror
or how the hell are you Director of IT without any background in DB design.
Anyone who has taken the first couple years of a Computer Science degree, should have a handful of expensive books on their bookshelf collecting dust.
Bullshit. I did, in fact, encounter database design in my coursework, but in a senior year elective. I've since taken an interest in relational theory, and I'm doubtful of the coverage of relational theory in undergraduate coursework.
Many CS academics view RDBMSs as an afterthought. I think it's because the industry is settled on SQL, and because SQL is pretty ugly as languages go, most academics don't want to get familiar with any relational theory. Unfortunately, most IT folks also skim over relational theory because they don't want to be tarred as being "purists."
If the OP is interested in that, CJ Date's Introduction to Database Systems is an outstanding book to learn the theory. Much of the book may be overkill, but the first third of it is broadly relevant, especially in clearly explaining basic theory and practice, and dispelling some very persistent myths.
My advice is to take some DB courses at your local university or online. If you don't have the prerequisites for those, I would argue you have no business trying to do this work yourself, and to hire a Computer Science Grad. They are a dime a dozen now, and will likely be happy just to have a job in his field when he graduates.
There is so much flatly wrong information about databases that many courses are pretty suspect. Most CS grads don't have much useful experience with databases and are about as useful as any code monkey.
Only a small part of the human brain is active at any given time, but you just try to think without the rest of it...
I'll bet I'd still get credit card offers.
Wow, this percentage is the same as /. articles!
Much more than 90%. When it comes to uselessness, /. has a rock solid 5 9's methodology.
I think their "90% dead-weight rule" is really a misnomer as you could probably claim that 90% of Google's indexing is never read but we all know that it's the potential that data holds that makes it so valuable and necessary.
Another problem is figuring out _why_ data isn't used before archiving it. Is it not useful, or are the tools not in place to use it?
If companies decide that the x% least used data will be shoved away in the attic, then "x% of data isn't useful" becomes a self-fulfilling prophecy.
Now I want to paste a bitchin' meat car together.
Users will be looking at these abiguos contacs and not be able to figure out which way to insert their batteries.
(No it doesn't help that any way will do if the user doesn't know it.)
Yup, and I hope to God that any company using this tech will be smart enough to put a + and - in their compartment, and not rely on a logo that only a fraction of the people who read geek blogs will recognize. The logo also doesn't give any clue, to my mind at least, that you can put batteries in either direction.
All you've really got to go on is the weird looking terminals.
It rather raises the bar from unusable to barely usable
The real problem with LaTeX, IMHO, is the overabundance of misleading documentation scattered over the web, and the older packages that are buggy and terrible. 95% of problems I've had were due to using an old package or following some how-to that was outdated.
If you get a full TeXlive install, only use the newest packages and spend time studying the outstanding documentation on CTAN, LaTeX becomes a whole lot easier.
I like LyX, but (unless this has changed in the last year or so) there's virtually no support for defining your own commands or environments. To me, that's the biggest draw of *TeX. I know it's not a simple feature to implement, and it's impressive what you can do with LyX without it, but coming from LaTeX it's a big step down.
What about TeX stopping to use this unreadable syntax and moving to xml?
If TeX is unreadable, XML is unwritable and unreadable. At any rate, TeX itself is low-level, and when you use a package like LaTeX it becomes far more user-friendly.
and it certainly wasn't our job to figure it out.
Seriously? And is this company you worked for still in existence? If so, do you still work as a consultant, or are you now internal IT somewhere? I don't mean to be attacking, but most of the time we go to market simply because we lack the experience in-house to help the business figure out what they need.
I should expand on that: I was talking about long term wants and needs. They would present us with some short term requirements, and we made them a good website, but there was no follow-up.
No, they're not in existence. I went back to college a few months later and they were liquidated not long after that. This was '97, the whole Interwebs thing was pretty new, and the company owner decided it was the wave of the future. She poured money into it and neglected the best paying accounts, the combination of which broke the company.
In my real job, yup, still doing contract work, this time with a much more experienced firm, and we do real requirements and documentation. We take a much more active role in our contracts, taking their very vague specs and working with them to translate them into something that's actually useful. But it could be shelved, or another contract may fail, or it might never be maintained properly. In a nutshell, you can make a great sprocket and then find that no one's allocated funds for a flange and so the whole thing doesn't work.
they didn't know what they wanted or needed, and it certainly wasn't our job to figure it out.
Erm, as far as I'm concerned, that's exactly your job. Its what a requirements capture is for.
Heheh, local government, small business... there was no requirements process or any of that. I has done about a year of college, and was the only person who vaguely understood those crazy computers.
I feel quite offended by this attitude of yours - you're the expert. If I went to an architect and asked for a floating house, it would be his job to tell me that that's not what I really want, and to work with me on something more appropriate, rather taking the money and running away before my wife gets home.
What's wrong with a floating house? There are entire cities that are built on floating foundations due to lack of decent bedrock.
It's not like this stuff is obviously a bad idea. All of it makes sense in the short term. But these agencies have no bottom line, so they don't have a basis with which to plan for the future.
I hope you enjoyed the coke you snorted off hooker's cracks with my tax money.
RIght, you totally missed the part where I said "local government" and "small business."
As a web designer / developer I am always bewildered by the obscene costs I hear for government websites, especially given their terribly below level of quality and usefulness.
People with government contracts must really milk it for all it's worth.
I worked for a small company that did a website for a local government agency years ago, around '97 I think. They wanted all kinds of bells and whistles so they could go to their bosses and show them what an awesome web site they had. It was designed far more to please government insiders than to be useful to taxpayers.
I don't think we were milking them, rather, they didn't know what they wanted or needed, and it certainly wasn't our job to figure it out. They also didn't have any plan, really, to maintain it or scale it up or have it go anywhere. From going on to six years working in or around the government, that's just how they do stuff.
And consumers pass them on to employers... And employers pass them on to customers... and so on. I think that noone, in reality, pays taxes.
For a typical middle class schlub, if you get to work at 9am, take 11:30 to 12:00 for lunch and call it quits at 5:30pm, pretty much your morning goes to the government. Trust me, you really are paying taxes, every fucking day.
The reason I say corporations don't pay taxes is because only actual people pay taxes, corporations don't pay taxes because they don't actually exist. The people who associate to form the corporation, though, certainly do pay taxes.
Any increased costs may be passed on to the consumer, but not always.
That's why I said "consumers and investors". Since you seem rather skeptical of corporations, riddle me this: when they magically "absorb" these increased burdens, do you think it's going to be due to some brilliant synergy discovered by an intrepid MBA, or do you think they just worked it into the next round of nickel and diming everyone on the bottom of the food chain?
And even then, since they exist entirely at the grace of tax payers, they should have no right to any amount of privacy.
Really? People don't have an inalienable right to the freedom of association?
In the past, Amazon has argued that it should not have to help support public services in states in which it has no physical presence.
I'm having trouble seeing exactly why this is relevant, other than innuendo.
Another reason it's irrelevant: corporations don't pay taxes, they just pass them on to consumers and investors.
The point here is that people will drive in a manner that is neither safe for themselves or others on the road because they can and because they think it is ok without understanding why it isn't.
You're saying some people ignore all these useful rules or never bother to learn them. And you want to lower the speed limit for everyone because of them. This is in spite of the fact that you don't even believe the people who drive dangerously will obey the speed limits.
So you've started with 15% of the drivers who just naturally won't drive safely, and you're setting bullshit speed limits that the 80% of reasonably good drivers will ignore.
How has this improved the situation?
Messiness is not a bug, it's a feature. It both allows you to witness that the victim really is dead and, as an added bonus, doesn't hide the reality of what's being done at an execution behind the illusion of a mere medical procedure.
It turns it into a spectacle. If you throw gore and blood into people's faces, you're assuming that they'll shrink from the horror of it. Through most of human history, people have behaved the exact opposite way.
If you don't have a stomach to watch blood splatter from a severed neck, you shouldn't have anything to do with executions. In fact we should televise each and every execution and see how many people are still "though on crime" when they see just what they're voting for.
That illogic works both ways. If you can't stomach personally witnessing an entire family being brutally murdered by a psychopath, you shouldn't have anything to do with restricting executions.
Geez, it seems like I was just upgraded to 5 last week.
At least it's out of beta...
Near future, perhaps not. But what if you could take your iPhone/AndroidPhone version 15 and set it on your desk next to a a pair of monitors, keyboard and fancy speakers and this FuturePhone would detect the devices.
I'd still probably have problems with the wireless keyboard / mouse wigging out periodically, having to change batteries. That is, unless physics changes its mind about the intrinsic wonkiness of wireless. Worse, anywhere there are free keyboards and monitors to use, someone will try to install a sniffer on them.
Our best athletes play football, baseball and basketball and our third-tier athletes still manage to hold their own in the World Cup.
Of course, you never know who was truly better in soccer because a 1-0 game can't be considered to be anything but dumb luck. Really, can you really prove that in a soccer game they don't just kick the ball back and forth endlessly until someone happens to be lined up for that one shot?
Allow a single, Unicode-enabled field of "unlimited" length (let's say 4 kilobytes) which represents "name".
Two fundamental questions:
1. How do you represent this name on an invoice?
2. And how can phone support look up individuals, and greet them on the phone?
Remember, the point of this is to do some kind of transaction with customers.
You can easily disable this feature. It's opt-in. Disable it by not opting in. See? Wasn't that easy?
You know what's easier? I will never buy an HP again because the fact that they are even *offering* it is just completely insane.
So I am simply opting out of HP altogether.
Use a bidet? Though, personally, I'd still want some paper to finish up.
So if something is poorly made it justifies theft? In that case I'll go steal an American car.
You can try, but you may be shot by an American firearm.
Parameterized SQL, or prepared statements, completely prevent SQL injection attacks. They might also speed things up in some circumstances. Why not simply use them exclusively?
I question the need for SQL. Can't we have a simple OO query system? We don't need to write strings of TCL to interact with GUI components.
I've never seen a complex GUI that could come back to the same state it was in when you pulled the plug on it. Nor have I ever seen a complex GUI that could run for years without having to be restarted. To my knowledge, every major operating system has a function to force kill a hung GUI.
SQL (or any system that tries to be as expressive as the relational model) isn't so important for queries as it is for declarative integrity.
If you don't have declarative integrity, you can't centralize your integrity checks. Then you wind up having to reimplement integrity checks through every application.
The typical enterprise scenario is that you have a live data source and when business rules change your schema has to change to reflect that, so you need to be able to update your integrity checks. It's virtually impossible to update live applications simultaneously to honor new integrity checks and guarantee the state of the data store. That's even if you limit yourself to using only thin-clients.
If your integrity checks are centralized in the DBMS, you can have an outdated or buggy client that doesn't know about a new check and it will simply fail with an error message rather than corrupting the state of the database. When your live data represents actual property, this is a major requirement.