Debugging is difficult primarily because debuggers do not appear to use any kind of intuition.
Perhaps instead of making the debugger intuitive, you should make your code intuitive.
In particular, you can write unit tests, so that you make sure that your code does what it should. And if that's not enough, each method or function can contain assertions about pre- and post-conditions for the code.
Then instead of just catching the errors when you happen to be looking at something in the debugger, you can catch them all the time.
I'd also like to see you 'not put the bugs in in the first place' if you're adding a complex piece of functionality to a 2,000,000 lines program: I can write perfect 'hello world' code on a napkin, but considering doing it for real work is ludicrous.
If the 2 Mline program already has good unit and functional tests, then it's pretty easy to not put the bugs in, just as long as you do test-driven development for your new code.
Massive debugging efforts are a sign that something is seriously wrong with the development process.
If you don't have another programmer handy, try the practice of Rubber Ducking.
This is where when you are completely stuck, you take a little break. Then you come back, pull a rubber duck out of your drawer, and put it on your desk. Then you turn to it and say, "Rubber duck, here's my problem," and explain your troubles to it, just as you would to a fellow programmer.
About two thirds of the time I try this, I stop half way through and say, "Aha! That's the problem!" And even if the solution doesn't occur to me, the process of explaining the problem makes me go over it in an orderly way, so that I always think of new places to look.
Now, the problem begins when this little program grows. If you try to write big apps with VB you'll fairly soon start hitting its limitations, writing workarounds, having to put up with completely idiotic bugs like project files that break by themselves... and you end with a complete piece of crap.
Amen. If people knew that whenever they needed write a program longer than a page that they should switch away from VB, I'd have no complaints with it. Instead, it is marketed in such a way that it gives amateurs the notion that they're just as good as any professional programmer. It's as if people thought that buying a Tinkertoy kit made them able to build houses.
I don't know how many projects I've seen where someone has knocked together a prototype in some half-baked language like VB. Then people want another feature and another, and nobody is willing to say: "Stop! We must throw this crap out and start again using appropriate tools."
(For the record, I hear that VB.NET is a big improvement over the execrable VB6. Of course, given that all.NET languages seem to be minor syntax variations on Java, maybe that's not too surprising.)
Well, when you combine enough of your small functions/methods together into one big monolith of a program problems tend to surface. What then?
Then you haven't written enough tests. Or you're trying to integrate too much at once.
If you do test-first development and continuous integration (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.
If I run all the tests frequently as I develop and check in often, I rarely need a debugger. If I break a test, I generally know exactly what the problem is.
If I forget to run all the tests and check in, then the automated build box will send me email promptly, so it's still pretty easy to find the problem.
It is essential, like an x-ray / CT-scan / ultrasound is to a surgeon.
Note that the only time you see a surgeon is when something is pretty seriously wrong. Isn't it much better to make sure that things don't go so far wrong that a surgeon is necessary?
A tool will not fix a process problem, no matter HOW easy a tool is to use.
Hmmm... My experience is different.
A good working environment is designed to make good things easy and bad things hard. For example, I write a lot more unit tests when I have a good unit testing framework. I run them a lot more when it's part of my build process. And I do a lot more refactoring when I use a tool that takes care of the boring parts of it.
But I'd agree that no tools can substitute for a responsible human. A bugmaster should be a big help in introducing the tool, especially if the bugmaster is somebody respected by all.
But better still is the team coming together and deciding, "Damnit, we need to track bugs better! We want an easier tool!" Anything imposed above from the managers, especially ones who say things as painfully dumb as, "we ought to crack the whip" is much less likely to succeed than something adopted by consensus.
Amen! Any development shop should have a box that just runs 24x7 checking out the latest code, doing a build, and running all the automated unit tests (written by the programmers) and functional tests (written by QA). Whenever a test fails, the responsible developer should be immediately e-mailed.
Then if you get your developers in the habit of doing test-first development, which gets you circa 100% coverage, your bug counts will drop significantly. I worked intermittently on a high-traffic dynamic website that has had a total of zero downtime and two or three shipped bugs, all minor, after about six man-months of development and nine months in deployment.
Do it nicely, saying that you of course trust the person you're talking to, but it would ease your mind greatly to have everything in writing, blah, blah, blah. But get it in writing.
I know of one recent acquisition where it was promised that everybody who wasn't immediately layed off would get signing bonuses. The execs of the acquired company had negotiated separate contracts that mentioned the signing bonuses. But the regular workers signed a contract that said nothing about that. And funny, a month later, the new parent company cancelled the bonuses.
Is it possible that the hirer tended to filter by certain ways of seeing things?
Anything's possible. But I doubt it. I often differ wildly from my colleagues on the theoretically optimal way to do something.
But we all recognize that the point is to build useful software, and that there are many paths to the same destination. Generally we just pick a path and see how it goes.
When we have serious disagreements, it's generally because we don't have enough data to decide, so we agree to try an experiment to see which works better.
If there is such a concensus, then why are there no good book on OO biz modeling?
Isn't there? I've heard good things about both Agile Modeling and Domain-Driven Design.
But I think that it's mainly a practical skill, so I'm not sure that a book, however good, is much use. There are a lot of books on cooking, but any chef will tell you that no book will substitute for time in the kitchen.
Say, I'm giving up on this thread now. If you're really interested in trying OOP so that you can see what problems it might be good for, then you should have enough to get started. If not, drop by an XP user group in your area, and they'll point you at the modern crop of tools and books.
Really? The article I read was on a book review site, operated by a brand known for being lefty, in a signed article by a regular contributor, published on a continent that by and large finds American's Christian fundamentalists as weird as Afghanistan's Muslim ones. Did you see it somewhere else?
And even if the poor site design fooled you, the guy was not exactly being sneaky about his views. I guess they could label it,
AMERICANS: Caution: The following reporter, like a surprising number of our staff, has been known to think for himself. You may wish to do the same.
But Brits are already accustomed to that in their newspapers, so you can see why they forgot to warn you.
That's fine, I'm just saying that historically, the reporting of the "news" was supposed to be done in a factually and unbiased manner. See above.
Historically? I'll be intrigued to see your references on the history of this. Regardless, you shouldn't confuse having a viewpoint or expressing an opinion with being a biased reporter. They are different.
And if you do think he's made a factual error because he is biased, you should speak up and say what it is. But so far, it seems like you just don't like his viewpoint.
How can the grouping of millions of Americans into one collective group that thinks and feels exactly the same way be considered "factually correct"?
It's called a generalization. We use them because there's not enough space in the newspaper to print the millions of views individually, nor sufficient hours in the day for readers to comprehend them if there were.
Imperfect, sure, but that's what you get when you let humans run around unsupervised.
If you get 20 different people who believe they have "mastered OO" together in a room, they will probably disagree wildly where to use OO and where not to.
Not when I've done it!
Try coming by the next Extreme Programming conference. Or if you're in the bay area, come by the XP user's group.
Certainly, we can have a lot of different opinions on the right way to tackle things. But I've never had a problem getting a team to cohere around a set of choices.
How can this kind of stuff even pretend to be "news"? Is it just because the story is talking about Christians that it gets away with this kind of writing around here?
Yes, you Christian infidels, vastly outnumbered, will soon be rounded up and turned into Soylent Green, just as soon as we finish taunting you. Or not.
Meanwhile, back in reality, you could recognize a few facts:
News need not be free of viewpoint - A journalist friend of mine tells me that 'objective', viewpointless news was more or less a marketing invention of the US wire services, so that the could sell to a broader range of papers. The pusuit of 'objective' news yields mainly hidden biases and stupid writing, where 'balance' consists of quoting people on both sides of the issue. What news should be is honest and free of bias, not utterly without viewpoint.
Other countries do it differently - In the US, the newspaper industry has collapsed into, for the most part, local monopolies obliged to be inoffensive. In London, the home of the article you mention, they have a variety of newspapers, each with its own political viewpoints. The Guardian is known to be pretty lefty.
Not everything printed in a newspaper is news - Columnists, reviewers, pundits and other sorts of experts are generally selected specifically for their opinions. This appears to be just such a piece.
Reading it, I don't see anything factually incorrect, even in the quotes you mention. The Christian far right has been openly gleeful about the election of the current Bush. They indeed see it as an opportunity to push their cultural, religion-driven agenda, and have not been exactly secret about it.
Please note that not all Christians are of the Christian fundy right that the author is describing. I hear that some of them even secretly voted for Al Gore.
But licenses like the GPL are not good for the developers who actually write the code. Those people cannot get paid what they are due.
Due?
When I give a birthday gift to a friend, I do it because I like giving gifts and I am glad to celebrate his or her existence. I don't do it with the expectation that I am due something in return.
Ditto when I give away my professional stock-in-trade, software and advice. The GPL does not come with some sort of implicit invoice attached. Nothing is due me except following the license, although a little gratitude and recognition is nice, too. When I say free, I mean it.
The world doesn't owe anybody a living; once you accept that fact, your life will be much more pleasant.
But just because you have OO accessors does not necessarily mean you know who used those accessors.
Yes, but if somebody is corrupting an object by passing a bad value into an accessor, then my object is poorly written. The responsibility for managing a datum should all be in one place.
Global validation can be forced via database triggers, so it is not a validation issue to compare.
Uh, anything that is Turing-complete can do anything any other Turning Machine can. If you find an OO proponent who says "X can only be done with OO," he's an idiot.
So yes, you can do that with triggers if you like. If that's easier for you, you should it. But if you're doing OO programming, you shouldn't.
But these are not much different than Stored Procedures. (Not that I necessarily recommend such.)
To you, perhaps.
My broader point is that good programmers must master many tools and use them when they are appropriate. Until you've master the OO stuff to the extent that it seems like a reasonable choice for some problems, then its choices will always seem weird to you.
The idea of a database is that *multiple* applications, languages, and paradigms can share the same data without mass copying. (This is a good thing, no?)
In the OO perspective, no, that's not good. The OO notion is that you should think of data and behavior together, not separately. So it's good to provide access to the object (data + behavior), but dangerous to provide universal access to the raw data itself.
But OO wants to wrap the data or state within a single language interface. If that is done, then how is the data shared with multiple applications, languages, and paradigms?
You expose it via some sort of interface, as needed by the situation. There are lots of good solutions to this, from low-level OS stuff to the venerable CORBA to the latest web services fads. The right choice depends on your circumstances.
Also, what kind of 'bug' are you referring to? A bug in the RDBMS engine, or a shop app?
Exactly my point. Since the responsibility for managing a particular datum is not cohesive, it's hard to say where to look. Is it in one of the apps? Is it in some of the code that's been pushed into the database? Is it a bug in the database itself? Or perhaps there are bugs in all of those, interacting in some subtle way. Who knows?
Whereas in good OO designs, all of the manipulation of a given datum goes through the object that contains that datum. If it becomes corrupt, you know where to look.
Then go read The Third Manifesto to learn how much better the relational model is than SQL.
Ah, yes, When I said "relational", I meant the thing that 99% of people think of as a relational database. Sorry for the confusion.
Are there existing products that you feel provide the full power of the relational model? I've never had the opportunity to use a relational DB other than via SQL.
Yes, but what happens when that application becomes applicaions (plural.) Changing a database in that case can have unintended consequences, which is exactly why programmers generally DO NOT get to control database layout (unless of course the database is for a single application, or the company plans to have major IT headaches.)
Then you break things into tiers and have them make requests of one another rather than rummaging around in the raw data.
For example, suppose a previously uncomputerized business decides that the first thing they need is a intranet where they can track the names and addresses of their customers. So you build one.
So then they want to add something to invoice the customers. Since you wrote the contact manager in a clean way, the UI stuff and the domain model were already separate, right? So you just pull the domain model out into its own layer, and now you have two apps talking to the same customer data. Sure, you can use the database as an integration layer. But that's only one option, and rarely the best one, as you are then forced to either a) have duplicate code all over the place for the same sorts of things, or b) start putting code into your database via stored procedures, triggers, and hatnot.
Now we all know that duplicate code is the way to madness and woe. But putting logic in the database isn't much better. Now your database isn't a database, it's an application server in disguise, one with weird proprietary languages, poor tool support, and limited options for scalability.
If you're going to build an application server (which will happen in some form when you go from singular app to plural apps), you might as well do it in a language that all your developers already know, not one that is a mystery to all but the DBA. Then you get the advantages of portability, a wide variety of tools, and a panopoly of ways to scale up as requirements grow.
Can you ensure that all of the data in database A will equal 100% database B? Answer no!
If you don't maintain things properly, that's true. If you don't have good system tests, then moving to a new system is hard, because you are never quite sure that the new system works like the old system.
Fear, as they say, is the mind-killer. For the project I'm working on right now, I'm confident I could migrate it not just to a different database, but to an entirely different database technology (e.g., to LDAP) in short order. Why? Because I have good tests, and I made sure to keep my persistence logic in a single place.
The problem is that developers look at software using a one off design issue, which is correct. But data is a production issue. It is sort of like the engineer who designs the car that cannot be built because of production constraints. In the industry the production constraints determine which car is built. Likewise in the software world the database needs to define what programs can be built, not the other way around.
All production issues should be development issues. Neither the database nor the code should define what gets built; business needs must determine that.
It sounds like you've worked an environment where the developers can escape consequences of their actions. Try doing weekly iterations and monthly releases; the developers will soon be cured of there ignorance about what it takes to put things into production.
Java, for example, has handy built-in stuff for indexing, joins, filtering, and multi-user contention management.
Could you point me at APIs that do that?
Sure.
For indexing, the point of which is to speed finding matches, check out the Java Collections classes. For joins, you just establish the proper relationship between the objects. For multi-user contention management, you wrap things in syncronized blocks.
What if there were better relational factoring tools (if such is even needed)? OO seems to be growing into a self-fullfilling prophecy because all the tools are being built for it instead of other paradigms.
I dunno; I only develop with real tools, not hypothetical ones. It could be that OO is a self-fulfilling prophecy. Or it could be that the reason it didn't live up to its early promise was the lack of good OO-specific tools.
But the current crop of OO refactoring tools have all been developed by single people or small teams, so if you think there's a revolutionary tool that needs to be built, you should take a swing at it.
In that case, keeping everything in RAM in Java objects is hundreds of times faster than fetching from a database.
Even with RAM-caching? (Some vendors are currently building RAM-optimized RDBMS).
You're welcome to try it yourself. Try Prevyalyer's speed tests against a database of your choosing. Let us know how it works.
My observation is that certain tools just seem to map to people's heads better. I find relational to be a more organized and consistent paradigm [...]
And people doing object work find the opposite. I doubt one side is, in any useful sense of the word, wrong about this. The right tool for the job coesn't just depend on the job, it depends on the people doing the job.
But note that the divide isn't as sharp as it seems at first. In practice, people tend to use a mix of models as appropriate. In the OO world, for example, people often use the Command Pattern when a focus on verbs becomes necessary.
Sounds like you are using the DB as *just* persistence, otherwise it would not be that swappable. There is really no way out of that. If you use the *full* potential of a RDBMS, then its functionality would simply NOT be swappable with say XML DB's.
Yes, I am. Although I did make use of some SQLisms when optimizing performance.
We agree: If you use all of an RDBMS's power, it probably won't be much of an OO app. If you really do good object work, you probably won't use all of an RDBMS's power.
I'm willing to use whatever tools it takes to get a client's problem solved. I find that for apps over about 10,000 lines of code, I'm fastest with OO tools. That's especially true when the project will go through many iterations; then the flexibility of OO code, especially using modern refactoring tools, is unmatched.
But if I'm doing something quick and dirty or a little something where needs are stable enough that it will never go past v 1.0, I'm glad to write procedural code that's heavily coupled to an RDBMS.
I do not believe Java makes a better DB than RDBMS.
It doesn't need to be. RDBMSes are undoubtedly a better general-purpose solution for storing, fetching, and manipulating arbitrary data. But 98% of the apps I write perform a few operations on very specific data. For a given application, almost all of the theoretically appealing relational possibilities remain unused in practice. Manually writing the few things that a database would do for me often doesn't outweigh the penalties a RDBMS brings with it.
I find that is especially common for server apps with moderate data sets (under, say, 2 GB). In that case, keeping everything in RAM in Java objects is hundreds of times faster than fetching from a database. For that kind of speed improvement, I'm willing to go to the slight extra effort of populating a java.util.HashMap instead of doing "CREATE INDEX".
The same goes for things where the data just doesn't fit well into the relational style. I'm sure somebody has found a way to cram images, drawings, and HTML structures into ANSI SQL, but I sure wouldn't want to look at the code.
But if somebody wants to run arbitrary queries against a large body of data, I'm always glad to dump the stuff out into an SQL database. Crystal Reports and its cousins are swell when people want to go romping through the data.
then the network databases of the 1960's have made their comeback
And if they have, so what?
As professionals, we should be interested in using the right tools for the job, whatever they might be. The technology of paper is thousands of years old, but if a client comes to me with some overblow set of requirements, I think it's my duty to tell them if they'd be better off with a stack of index cards.
No buzzword or methodology is going to allow you to build a solid data model one column at a time. Been there, saw it tried over and over, saw it fail over and over. Don't care if you listen, don't care if you agree, but you sure as hell won't try it in any instance I manage. In case you weren't listening the first time, YOU CAN'T BUILD A SOLID DATA MODEL ONE COLUMN AT A TIME.
Well, I've done it. Repeatedly. So have others, including the author mentioned in the article that this story is about.
You're right that it can't be done just any old way; if you try it with traditional methods, you'll get flattened. It takes special techniques, carefully applied. Plus a team who are all professionals. For more details, see Martin Fowler's book "Refactoring", and Kent Beck's book "Extreme Programming Explained".
Shout as much as you like, but just because you can't do it doesn't mean it's impossible; it just means you don't know how.
500 requests within a span of a few seconds can bring down some small servers, particularly if the page is dynamically generated./. could be accused of launching a DOS in the name of load testing.
Good point. Better to use a slow-start algorithm on your worker threads so that you can gradually discover the maximum hits/s that the server can handle. Then if that number is lower than the peak expected, the Slashcode can turn on the n% mirroring right away.
The trouble with waiting until users report it is that you are guaranteed to bring down the weak servers. Slashdot is already accused of being a DOS attack tool; they might as well own up to it and try to make it behave a little better.
2. Have a "report dead link" option next to new stories. (Those who abuse this feature can pay in karma.)
You could do even better.
Just before a story goes up, it would be easy to load-test the site. They could hit it with, say, 500 parallel requests.
If it passes that, then the story goes up as normal, but Slashdot checks the site every minute. If performance drops off substantially, then n% of Slashdot readers get a link to the mirror. If the site is stil slow, n is increased until the site is reachable.
Then, n is allowed to decay over time; if it goes too low, the automatic monitoring would bump it up again.
And then for dessert, we can write a peer-to-peer mirroring system, so that Slashdot doesn't have to pay out for the extra bandwidth.
Hmm... This sounds fun. If anybody has the connections to get this incorporated into the Slashcode used on Slashdot, let me know; I'd be glad to work on the monitoring, mirroring, and sharing stuff.
some developers can design very good data models, no one should be doing each other job unless they really, really, really know what they are doing.
The point of object-oriented analysis and design is to define the data model. So yes, any team doing OO work should have a skilled OO A&D person; they are generally called architects.
Beware, though, of self-styled "architects" who are too busy or too important to write code. They are generally useless. Worse, they are good bullshitters, spewing out designs that sound plausible but are hell to implement.
Slashdot Mirror
Debugging is difficult primarily because debuggers do not appear to use any kind of intuition.
Perhaps instead of making the debugger intuitive, you should make your code intuitive.
In particular, you can write unit tests, so that you make sure that your code does what it should. And if that's not enough, each method or function can contain assertions about pre- and post-conditions for the code.
Then instead of just catching the errors when you happen to be looking at something in the debugger, you can catch them all the time.
I'd also like to see you 'not put the bugs in in the first place' if you're adding a complex piece of functionality to a 2,000,000 lines program: I can write perfect 'hello world' code on a napkin, but considering doing it for real work is ludicrous.
If the 2 Mline program already has good unit and functional tests, then it's pretty easy to not put the bugs in, just as long as you do test-driven development for your new code.
Massive debugging efforts are a sign that something is seriously wrong with the development process.
If you don't have another programmer handy, try the practice of Rubber Ducking.
This is where when you are completely stuck, you take a little break. Then you come back, pull a rubber duck out of your drawer, and put it on your desk. Then you turn to it and say, "Rubber duck, here's my problem," and explain your troubles to it, just as you would to a fellow programmer.
About two thirds of the time I try this, I stop half way through and say, "Aha! That's the problem!" And even if the solution doesn't occur to me, the process of explaining the problem makes me go over it in an orderly way, so that I always think of new places to look.
Now, the problem begins when this little program grows. If you try to write big apps with VB you'll fairly soon start hitting its limitations, writing workarounds, having to put up with completely idiotic bugs like project files that break by themselves... and you end with a complete piece of crap.
.NET languages seem to be minor syntax variations on Java, maybe that's not too surprising.)
Amen. If people knew that whenever they needed write a program longer than a page that they should switch away from VB, I'd have no complaints with it. Instead, it is marketed in such a way that it gives amateurs the notion that they're just as good as any professional programmer. It's as if people thought that buying a Tinkertoy kit made them able to build houses.
I don't know how many projects I've seen where someone has knocked together a prototype in some half-baked language like VB. Then people want another feature and another, and nobody is willing to say: "Stop! We must throw this crap out and start again using appropriate tools."
(For the record, I hear that VB.NET is a big improvement over the execrable VB6. Of course, given that all
Well, when you combine enough of your small functions/methods together into one big monolith of a program problems tend to surface. What then?
Then you haven't written enough tests. Or you're trying to integrate too much at once.
If you do test-first development and continuous integration (backed up with good black-box integration testing), then the number of bugs you get should be low. In my experience, that's circa one shipped bug per man-month.
If I run all the tests frequently as I develop and check in often, I rarely need a debugger. If I break a test, I generally know exactly what the problem is.
If I forget to run all the tests and check in, then the automated build box will send me email promptly, so it's still pretty easy to find the problem.
It is essential, like an x-ray / CT-scan / ultrasound is to a surgeon.
Note that the only time you see a surgeon is when something is pretty seriously wrong. Isn't it much better to make sure that things don't go so far wrong that a surgeon is necessary?
A tool will not fix a process problem, no matter HOW easy a tool is to use.
Hmmm... My experience is different.
A good working environment is designed to make good things easy and bad things hard. For example, I write a lot more unit tests when I have a good unit testing framework. I run them a lot more when it's part of my build process. And I do a lot more refactoring when I use a tool that takes care of the boring parts of it.
But I'd agree that no tools can substitute for a responsible human. A bugmaster should be a big help in introducing the tool, especially if the bugmaster is somebody respected by all.
But better still is the team coming together and deciding, "Damnit, we need to track bugs better! We want an easier tool!" Anything imposed above from the managers, especially ones who say things as painfully dumb as, "we ought to crack the whip" is much less likely to succeed than something adopted by consensus.
Have developers write UnitTests
Amen! Any development shop should have a box that just runs 24x7 checking out the latest code, doing a build, and running all the automated unit tests (written by the programmers) and functional tests (written by QA). Whenever a test fails, the responsible developer should be immediately e-mailed.
Then if you get your developers in the habit of doing test-first development, which gets you circa 100% coverage, your bug counts will drop significantly. I worked intermittently on a high-traffic dynamic website that has had a total of zero downtime and two or three shipped bugs, all minor, after about six man-months of development and nine months in deployment.
Get every promise in writing.
Do it nicely, saying that you of course trust the person you're talking to, but it would ease your mind greatly to have everything in writing, blah, blah, blah. But get it in writing.
I know of one recent acquisition where it was promised that everybody who wasn't immediately layed off would get signing bonuses. The execs of the acquired company had negotiated separate contracts that mentioned the signing bonuses. But the regular workers signed a contract that said nothing about that. And funny, a month later, the new parent company cancelled the bonuses.
Is it possible that the hirer tended to filter by certain ways of seeing things?
Anything's possible. But I doubt it. I often differ wildly from my colleagues on the theoretically optimal way to do something.
But we all recognize that the point is to build useful software, and that there are many paths to the same destination. Generally we just pick a path and see how it goes.
When we have serious disagreements, it's generally because we don't have enough data to decide, so we agree to try an experiment to see which works better.
If there is such a concensus, then why are there no good book on OO biz modeling?
Isn't there? I've heard good things about both Agile Modeling and Domain-Driven Design.
But I think that it's mainly a practical skill, so I'm not sure that a book, however good, is much use. There are a lot of books on cooking, but any chef will tell you that no book will substitute for time in the kitchen.
Say, I'm giving up on this thread now. If you're really interested in trying OOP so that you can see what problems it might be good for, then you should have enough to get started. If not, drop by an XP user group in your area, and they'll point you at the modern crop of tools and books.
Really? The article I read was on a book review site, operated by a brand known for being lefty, in a signed article by a regular contributor, published on a continent that by and large finds American's Christian fundamentalists as weird as Afghanistan's Muslim ones. Did you see it somewhere else?
And even if the poor site design fooled you, the guy was not exactly being sneaky about his views. I guess they could label it, But Brits are already accustomed to that in their newspapers, so you can see why they forgot to warn you.
That's fine, I'm just saying that historically, the reporting of the "news" was supposed to be done in a factually and unbiased manner. See above.
Historically? I'll be intrigued to see your references on the history of this. Regardless, you shouldn't confuse having a viewpoint or expressing an opinion with being a biased reporter. They are different.
And if you do think he's made a factual error because he is biased, you should speak up and say what it is. But so far, it seems like you just don't like his viewpoint.
How can the grouping of millions of Americans into one collective group that thinks and feels exactly the same way be considered "factually correct"?
It's called a generalization. We use them because there's not enough space in the newspaper to print the millions of views individually, nor sufficient hours in the day for readers to comprehend them if there were.
Imperfect, sure, but that's what you get when you let humans run around unsupervised.
If you get 20 different people who believe they have "mastered OO" together in a room, they will probably disagree wildly where to use OO and where not to.
Not when I've done it!
Try coming by the next Extreme Programming conference. Or if you're in the bay area, come by the XP user's group.
Certainly, we can have a lot of different opinions on the right way to tackle things. But I've never had a problem getting a team to cohere around a set of choices.
Yes, you Christian infidels, vastly outnumbered, will soon be rounded up and turned into Soylent Green, just as soon as we finish taunting you. Or not.
Meanwhile, back in reality, you could recognize a few facts:
- News need not be free of viewpoint - A journalist friend of mine tells me that 'objective', viewpointless news was more or less a marketing invention of the US wire services, so that the could sell to a broader range of papers. The pusuit of 'objective' news yields mainly hidden biases and stupid writing, where 'balance' consists of quoting people on both sides of the issue. What news should be is honest and free of bias, not utterly without viewpoint.
- Other countries do it differently - In the US, the newspaper industry has collapsed into, for the most part, local monopolies obliged to be inoffensive. In London, the home of the article you mention, they have a variety of newspapers, each with its own political viewpoints. The Guardian is known to be pretty lefty.
- Not everything printed in a newspaper is news - Columnists, reviewers, pundits and other sorts of experts are generally selected specifically for their opinions. This appears to be just such a piece.
Reading it, I don't see anything factually incorrect, even in the quotes you mention. The Christian far right has been openly gleeful about the election of the current Bush. They indeed see it as an opportunity to push their cultural, religion-driven agenda, and have not been exactly secret about it.Please note that not all Christians are of the Christian fundy right that the author is describing. I hear that some of them even secretly voted for Al Gore.
But licenses like the GPL are not good for the developers who actually write the code. Those people cannot get paid what they are due.
Due?
When I give a birthday gift to a friend, I do it because I like giving gifts and I am glad to celebrate his or her existence. I don't do it with the expectation that I am due something in return.
Ditto when I give away my professional stock-in-trade, software and advice. The GPL does not come with some sort of implicit invoice attached. Nothing is due me except following the license, although a little gratitude and recognition is nice, too. When I say free, I mean it.
The world doesn't owe anybody a living; once you accept that fact, your life will be much more pleasant.
But just because you have OO accessors does not necessarily mean you know who used those accessors.
Yes, but if somebody is corrupting an object by passing a bad value into an accessor, then my object is poorly written. The responsibility for managing a datum should all be in one place.
Global validation can be forced via database triggers, so it is not a validation issue to compare.
Uh, anything that is Turing-complete can do anything any other Turning Machine can. If you find an OO proponent who says "X can only be done with OO," he's an idiot.
So yes, you can do that with triggers if you like. If that's easier for you, you should it. But if you're doing OO programming, you shouldn't.
But these are not much different than Stored Procedures. (Not that I necessarily recommend such.)
To you, perhaps.
My broader point is that good programmers must master many tools and use them when they are appropriate. Until you've master the OO stuff to the extent that it seems like a reasonable choice for some problems, then its choices will always seem weird to you.
The idea of a database is that *multiple* applications, languages, and paradigms can share the same data without mass copying. (This is a good thing, no?)
In the OO perspective, no, that's not good. The OO notion is that you should think of data and behavior together, not separately. So it's good to provide access to the object (data + behavior), but dangerous to provide universal access to the raw data itself.
But OO wants to wrap the data or state within a single language interface. If that is done, then how is the data shared with multiple applications, languages, and paradigms?
You expose it via some sort of interface, as needed by the situation. There are lots of good solutions to this, from low-level OS stuff to the venerable CORBA to the latest web services fads. The right choice depends on your circumstances.
Also, what kind of 'bug' are you referring to? A bug in the RDBMS engine, or a shop app?
Exactly my point. Since the responsibility for managing a particular datum is not cohesive, it's hard to say where to look. Is it in one of the apps? Is it in some of the code that's been pushed into the database? Is it a bug in the database itself? Or perhaps there are bugs in all of those, interacting in some subtle way. Who knows?
Whereas in good OO designs, all of the manipulation of a given datum goes through the object that contains that datum. If it becomes corrupt, you know where to look.
Then go read The Third Manifesto to learn how much better the relational model is than SQL.
Ah, yes, When I said "relational", I meant the thing that 99% of people think of as a relational database. Sorry for the confusion.
Are there existing products that you feel provide the full power of the relational model? I've never had the opportunity to use a relational DB other than via SQL.
Yes, but what happens when that application becomes applicaions (plural.) Changing a database in that case can have unintended consequences, which is exactly why programmers generally DO NOT get to control database layout (unless of course the database is for a single application, or the company plans to have major IT headaches.)
Then you break things into tiers and have them make requests of one another rather than rummaging around in the raw data.
For example, suppose a previously uncomputerized business decides that the first thing they need is a intranet where they can track the names and addresses of their customers. So you build one.
So then they want to add something to invoice the customers. Since you wrote the contact manager in a clean way, the UI stuff and the domain model were already separate, right? So you just pull the domain model out into its own layer, and now you have two apps talking to the same customer data.
Sure, you can use the database as an integration layer. But that's only one option, and rarely the best one, as you are then forced to either a) have duplicate code all over the place for the same sorts of things, or b) start putting code into your database via stored procedures, triggers, and hatnot.
Now we all know that duplicate code is the way to madness and woe. But putting logic in the database isn't much better. Now your database isn't a database, it's an application server in disguise, one with weird proprietary languages, poor tool support, and limited options for scalability.
If you're going to build an application server (which will happen in some form when you go from singular app to plural apps), you might as well do it in a language that all your developers already know, not one that is a mystery to all but the DBA. Then you get the advantages of portability, a wide variety of tools, and a panopoly of ways to scale up as requirements grow.
Can you ensure that all of the data in database A will equal 100% database B? Answer no!
If you don't maintain things properly, that's true. If you don't have good system tests, then moving to a new system is hard, because you are never quite sure that the new system works like the old system.
Fear, as they say, is the mind-killer. For the project I'm working on right now, I'm confident I could migrate it not just to a different database, but to an entirely different database technology (e.g., to LDAP) in short order. Why? Because I have good tests, and I made sure to keep my persistence logic in a single place.
The problem is that developers look at software using a one off design issue, which is correct. But data is a production issue. It is sort of like the engineer who designs the car that cannot be built because of production constraints. In the industry the production constraints determine which car is built. Likewise in the software world the database needs to define what programs can be built, not the other way around.
All production issues should be development issues. Neither the database nor the code should define what gets built; business needs must determine that.
It sounds like you've worked an environment where the developers can escape consequences of their actions. Try doing weekly iterations and monthly releases; the developers will soon be cured of there ignorance about what it takes to put things into production.
Sure.
For indexing, the point of which is to speed finding matches, check out the Java Collections classes. For joins, you just establish the proper relationship between the objects. For multi-user contention management, you wrap things in syncronized blocks.
If you need more than the basic stuff that Java provides, check out the page on the Prevayler site where they list various object indexing and query libraries.
I dunno; I only develop with real tools, not hypothetical ones. It could be that OO is a self-fulfilling prophecy. Or it could be that the reason it didn't live up to its early promise was the lack of good OO-specific tools.
But the current crop of OO refactoring tools have all been developed by single people or small teams, so if you think there's a revolutionary tool that needs to be built, you should take a swing at it.
Even with RAM-caching? (Some vendors are currently building RAM-optimized RDBMS).
You're welcome to try it yourself. Try Prevyalyer's speed tests against a database of your choosing. Let us know how it works.
My observation is that certain tools just seem to map to people's heads better. I find relational to be a more organized and consistent paradigm [...]
And people doing object work find the opposite. I doubt one side is, in any useful sense of the word, wrong about this. The right tool for the job coesn't just depend on the job, it depends on the people doing the job.
But note that the divide isn't as sharp as it seems at first. In practice, people tend to use a mix of models as appropriate. In the OO world, for example, people often use the Command Pattern when a focus on verbs becomes necessary.
Sounds like you are using the DB as *just* persistence, otherwise it would not be that swappable. There is really no way out of that. If you use the *full* potential of a RDBMS, then its functionality would simply NOT be swappable with say XML DB's.
Yes, I am. Although I did make use of some SQLisms when optimizing performance.
We agree: If you use all of an RDBMS's power, it probably won't be much of an OO app. If you really do good object work, you probably won't use all of an RDBMS's power.
I'm willing to use whatever tools it takes to get a client's problem solved. I find that for apps over about 10,000 lines of code, I'm fastest with OO tools. That's especially true when the project will go through many iterations; then the flexibility of OO code, especially using modern refactoring tools, is unmatched.
But if I'm doing something quick and dirty or a little something where needs are stable enough that it will never go past v 1.0, I'm glad to write procedural code that's heavily coupled to an RDBMS.
I do not believe Java makes a better DB than RDBMS.
It doesn't need to be. RDBMSes are undoubtedly a better general-purpose solution for storing, fetching, and manipulating arbitrary data. But 98% of the apps I write perform a few operations on very specific data. For a given application, almost all of the theoretically appealing relational possibilities remain unused in practice. Manually writing the few things that a database would do for me often doesn't outweigh the penalties a RDBMS brings with it.
I find that is especially common for server apps with moderate data sets (under, say, 2 GB). In that case, keeping everything in RAM in Java objects is hundreds of times faster than fetching from a database. For that kind of speed improvement, I'm willing to go to the slight extra effort of populating a java.util.HashMap instead of doing "CREATE INDEX".
The same goes for things where the data just doesn't fit well into the relational style. I'm sure somebody has found a way to cram images, drawings, and HTML structures into ANSI SQL, but I sure wouldn't want to look at the code.
But if somebody wants to run arbitrary queries against a large body of data, I'm always glad to dump the stuff out into an SQL database. Crystal Reports and its cousins are swell when people want to go romping through the data.
then the network databases of the 1960's have made their comeback
And if they have, so what?
As professionals, we should be interested in using the right tools for the job, whatever they might be. The technology of paper is thousands of years old, but if a client comes to me with some overblow set of requirements, I think it's my duty to tell them if they'd be better off with a stack of index cards.
No buzzword or methodology is going to allow you to build a solid data model one column at a time. Been there, saw it tried over and over, saw it fail over and over. Don't care if you listen, don't care if you agree, but you sure as hell won't try it in any instance I manage. In case you weren't listening the first time, YOU CAN'T BUILD A SOLID DATA MODEL ONE COLUMN AT A TIME.
Well, I've done it. Repeatedly. So have others, including the author mentioned in the article that this story is about.
You're right that it can't be done just any old way; if you try it with traditional methods, you'll get flattened. It takes special techniques, carefully applied. Plus a team who are all professionals. For more details, see Martin Fowler's book "Refactoring", and Kent Beck's book "Extreme Programming Explained".
Shout as much as you like, but just because you can't do it doesn't mean it's impossible; it just means you don't know how.
500 requests within a span of a few seconds can bring down some small servers, particularly if the page is dynamically generated. /. could be accused of launching a DOS in the name of load testing.
Good point. Better to use a slow-start algorithm on your worker threads so that you can gradually discover the maximum hits/s that the server can handle. Then if that number is lower than the peak expected, the Slashcode can turn on the n% mirroring right away.
The trouble with waiting until users report it is that you are guaranteed to bring down the weak servers. Slashdot is already accused of being a DOS attack tool; they might as well own up to it and try to make it behave a little better.
2. Have a "report dead link" option next to new stories. (Those who abuse this feature can pay in karma.)
You could do even better.
Just before a story goes up, it would be easy to load-test the site. They could hit it with, say, 500 parallel requests.
If it passes that, then the story goes up as normal, but Slashdot checks the site every minute. If performance drops off substantially, then n% of Slashdot readers get a link to the mirror. If the site is stil slow, n is increased until the site is reachable.
Then, n is allowed to decay over time; if it goes too low, the automatic monitoring would bump it up again.
And then for dessert, we can write a peer-to-peer mirroring system, so that Slashdot doesn't have to pay out for the extra bandwidth.
Hmm... This sounds fun. If anybody has the connections to get this incorporated into the Slashcode used on Slashdot, let me know; I'd be glad to work on the monitoring, mirroring, and sharing stuff.
some developers can design very good data models, no one should be doing each other job unless they really, really, really know what they are doing.
The point of object-oriented analysis and design is to define the data model. So yes, any team doing OO work should have a skilled OO A&D person; they are generally called architects.
Beware, though, of self-styled "architects" who are too busy or too important to write code. They are generally useless. Worse, they are good bullshitters, spewing out designs that sound plausible but are hell to implement.