Yes, there is a difference between corporate IT and the "real world".
In the corporate IT world, fast and furious coding that produces workable but unmaintainable code will cost more money in the long run. Total Cost of Ownership matters more than deadlines.
In the "real world" it doesn't matter if the stuff blows up in a year and can't be fixed, it will be replaced anyway (either that, or you've moved on to your next startup for those big IPO $$, so it's not your problem anyway) And yes, Time To Market is King.
Yes, it's offtopic, but one of the funniest things I've read in a long time.
For some reason it reminds me of the 99 bottle of beer website. That's not funny, but it uses "print/display the entire lyrics to the 99 bottles of beer song" instead of "Hello World" in languages ranging from COBOL to Befunge to YACC. It's an interesting read, at least.
Here I am, I pour myself the first can of Guiness Draught that I've had in quite a while, all ready to settle down and enjoy a halloween. Then I log onto/.
Re:syntax can look like any language?!
on
Perl 6 Showcase
·
· Score: 1
ummmm.. it can spit out C# code.
Now, C# may be as much of a "standard" language as M$ claims that it is, but so far the only place that I've heard of it being used is in....
Of course, you're right. A well designed system does solve many problems, and you can provide an actual fourth tier that truly is separate from any of the others. And yes, doing so does provide more modularity and scalability. The philosophy of "throw fast multiprocessors and RAID at THE database server" really isn't my favorite solution. If you insist on throwing hardware at the problem, a cluster of app servers really is a more scalable solution. In fact the project that I'm currently working on is structured that way.
I just feel that it is possible to logically isolate the business logic (design ) while physically deploying it with the data store (implentation).
And yes, the reasons to do that include time-to-market. (Valid reasons for doing so do not include cost. Two cheap application servers and one mid-range database server will often outperform one high-range database/app server, depending on where the particular application's bottleneck is.) And yes, there is a tradeoff. That was the point that I was trying to make, even if I did not express it as well as I would have liked. It is a tradeoff, and as long as you get what you want (TTM) and you know what you're paying (scalability and portability) then it's acceptable.
True. Stored procedures and/or triggers are not required to store/retrieve data. They're not even required to meet the requirements of ACID.
But they can be rather useful tools. They can facilitate information hiding, and provide an object-like (keeping some behavior with the data) feel to the application. They can also make management of multiple systems and applications somewhat easier.
Let's say your company decides that the USPS just isn't good enough. The new policy is that all US customers get their shipments via UPS or FedEX. Suddenly all those "PO Box" addresses in the database are no longer valid.
So what do you do? Do you rewrite that legacy order entry application used by division X? As well as the new order entry app used by the rest of the company? (And let's not get into why division X can't use the new app, it's not under your control. Life is unfair. Other people get their way sometime, even if they're idiots. Just deal with it.) What about the new Web interface that the Consumer Technologies department has just released? Let's not forget the software that the sales department uses to give price quotes. And the Customer Service app. How many developers will that take? How long will it take to roll out after QA approves all of the changes? How many desktops, laptops, and servers are affected?
Personally, I'd just rather change one trigger or stored procedure on one or two servers. OK, so the QA people still have to test all of those different apps, but they'd have to anyway. This is still the easiest way to get it done.
Can stored procs and triggers affect performance? Yes. Especially poorly written triggers.
Can stored procs make it more difficult to migrate to another database? Yes, while making it easier to migrate the UI portion of the app to other platforms.
It's a tradeoff. Often it makes more sense to put some (all?) of the business/application logic into the database. It doesn't always make sense. That's a design decision. While designing a system, I'd rather have more tools at my disposal, and pick the best combination, rather than having my hands tied.
OK, this might be redundant, I have/. set to "highest scores first" and haven't read down to the bottom yet, but here goes...
Here is something from my company's coding standard:
When maintaining code, the style of the original code should be retained, even if the style conflicts with the style guidelines in this document.
I REALLY agree with this. After years of maintenance programming, running across code that had been worked on by 10+ people and looks like it, I do this instinctively, and did before I even started this job. But it's nice to see it in writing, even if it is in a document that most of the programmers here never see. It's just a way to make life easier for the next person.
I just wish the previous coders had been as thoughtful!
Screw the web for publishing. It's not free enough, in it's current form, to be revolutionary
Isn't this (sharing of mathematical and scientific information by different people in different countries) exactly why the Web was originally invented?
Try this on for size. It seems to be the way that.NET is meant to be used.
You go to open a document on your desktop. This starts the "desktop" application, which is built from.NET components. Some of these.NET components are built into.NET. Some of these components are custom for the app. Not every one of these components exists on your hard drive, some of them are on various servers run by various companies.
One component might be a M$ component on a M$ server, another one is from the company that produced the application, and resides on their server. Yet another component is one that the application developer licensed the rights to use, and resides on the third party component developer's server.
In fact, some of the components never get to your machine at all, they run on the server and only send back data. (XML of course) Remember, this IS called ".NET" because it provides a distributed, component-based platform for application development. Or to put it another way, "The nework is the machine."
Now what happens when the M$ servers are down? What about the application developer's servers? Or the third party developer's servers? What happens when there is network congestion? Or a backbone goes down? Or you lose your local network connection? What happens when some moron at the application development company forgets to renew the license to use the third party component (or M$ component) and that component stops functioning in your application? (Subscription based licensing == a predictable revenue stream == good stock prices == happy PHB ) Or when you don't renew your license to the application?
You can't access your local document with your "desktop" application, that's what. Unless you want to read the raw binary/XML data with EMACS or something.
Of course, because the document can't be accessed without a network connection in the first place, there's no reason for it to reside on your local hard drive in the first place. After all, if it resides on a server, you can access it from anywhere, can't you? As long as you have access to a.NET enabled machine, you could go to the application development company's website and log in with your username and pull up the document the same as if you were at your home workstation.
unless of course it all ends up with a closed-protocol and closed-source project and they can charge mega-$ for it
Well, what do you think this is?.NET servers running MS Software, on ANY OS that you care to use. Realistically, they'd probably rather you use Windows 2000 (or 2001 or whatever) as your server platform, but if you need to purchase a.NET subscription for every server, (so that you can support your users who just NEED.NET to run their favorite applications) be it Windows (oops!.Net is already included) or Linux, or Sun, or AIX, or... they'll still get their market penetration, profits, and control.
True. Of course all we would know about the M$ product is what we were told in their news releases. We wouldn't know for sure why it was delayed (although this board would be full of speculation)
In this case, we know what the product is (you can download, compile, and test it if you want) We know why it was "delayed" because Linux said it was to fix bugs.
OK, some people get a little too zealous in M$ bashing, but it's not entirely unjustified.
I had a "Package" plan from SW Bell, including caller ID, voicemail, and a few other extras for a fixed price.
Also, back in May I had ordered DSL service pending a line check. Well, they checked the line and it was no-go.
This month I get a huge phone bill, about 3 times the cost of the fixed price package. It turns out that they unbundled the services and charged for them separately. Also, I am due to have DSL charges starting next month (October).
After explaining that 1) Yes, I DID have the bundled service, and 2) No, my bill was ALWAYS well below $150, even if the person to whom I was speaking could not find the records to prove it, and 3) I do not now, nor have I ever had DSL service from them, and 4)getting transferred all over to make sure that I wasn't going to be filled for DSL that I didn't have, I got fed up and decided that it was finally easiest to just cancel all but the most basic local phone service while I do some research to find alternatives. I don't like Verizon any better, but they'll probably my only other alternative in this area.
To add insult to injury, as part of their wonderful voicemail system that you must navigate to speak to a real customer service representative, there is an automated option to opt out of their telemarketing. I chose that. I even confirmed it (You can't simply opt out, you must confirm it) I had done this before, when I set up phone service 6 months ago, but you can never opt out too often, or so I thought. (see below)
Within 3 hours of the initial hour long call to cancel most of my phone service I recieved 2 telemarketing calls from them, both of which said "well, If you just opted out a few hours ago, we must not have gotten the update to the list yet." Yeah, right. They use the hours right after you opt out as a "freebie" window of opportunity to besiege you with telemarketing.
The thing is, if they just hadn't gotten greedy in the first place, I would probably have kept them as my local provider for at least the next year or five.
Oops! I forgot the obligatory almost OT post here, since everyone is posting their favorite drugs of choice I'll go ahead and list mine. Caffiene, nicotine, and alcohol. Preferably the alcohol comes in the form of Guinness, single malt or Chartreuse.
And yes, I do know that the impurities in the nicotine delivery system will kill me quicker than all the rest combined.
I didn't work in a bank, but I did work at a "financial services" company, i.e. most of our clients were banks. They didn't make me pee in a cup but they did a rather thorough criminal and credit check.
Strange...when I worked for a defense contractor they didn't make me pee in a cup either.
It was only when I applied at a company in a boring run of the mill industry that they made me do that. Go figure.
What do you call reading published articles to become better informed, then speaking out in public forums? Complaining? Or getting involved?
I'll grant you, writing to your congressman is probably a bit more effective, but I think that newspapers (well, Web sites) and public squares (well, discussion boards like/.) are part of the tradition of democracy in America. This is part of "getting involved"
I thought this review was to make sure that it wasn't easy for the government to use Carnivore as a catch-all surveilance. In other words, to make sure that the government had to explicitly tell the system to look at a particular person's correspondence. So that they wouldn't be sifting through everybody's email without probable cause.
What's wrong with a technical review of the tools that Law Enforcement uses to make sure that they're not explicitly designed to ignore the "probable cause" clause?
For the sake of argument, I'll pretend you're right. MS is soon to become LEGACY software.
Do you have ANY idea how many companies are running on old COBOL programs? Do you have any idea how many companies are still using MSDOS accounting applications?
Even if all of Windows were to "become LEGACY software" today, that would just mean that we would only have to deal with it for another 20-30 years at least. Probably more.
Beer? IANAL but AFAIK (Don't you just love writing like that?) You are liable if they get drunk and do something that hurts themselves or somebody else.
Slashdot Mirror
In the corporate IT world, fast and furious coding that produces workable but unmaintainable code will cost more money in the long run. Total Cost of Ownership matters more than deadlines.
In the "real world" it doesn't matter if the stuff blows up in a year and can't be fixed, it will be replaced anyway (either that, or you've moved on to your next startup for those big IPO $$, so it's not your problem anyway) And yes, Time To Market is King.
I'm curious. Does Babelfish ever get slashdotted when this happens?
For some reason it reminds me of the 99 bottle of beer website. That's not funny, but it uses "print/display the entire lyrics to the 99 bottles of beer song" instead of "Hello World" in languages ranging from COBOL to Befunge to YACC. It's an interesting read, at least.
Here I am, I pour myself the first can of Guiness Draught that I've had in quite a while, all ready to settle down and enjoy a halloween. Then I log onto /.
Now, C# may be as much of a "standard" language as M$ claims that it is, but so far the only place that I've heard of it being used is in....
You guessed it, .Net
I just feel that it is possible to logically isolate the business logic (design ) while physically deploying it with the data store (implentation).
And yes, the reasons to do that include time-to-market. (Valid reasons for doing so do not include cost. Two cheap application servers and one mid-range database server will often outperform one high-range database/app server, depending on where the particular application's bottleneck is.) And yes, there is a tradeoff. That was the point that I was trying to make, even if I did not express it as well as I would have liked. It is a tradeoff, and as long as you get what you want (TTM) and you know what you're paying (scalability and portability) then it's acceptable.
But they can be rather useful tools. They can facilitate information hiding, and provide an object-like (keeping some behavior with the data) feel to the application. They can also make management of multiple systems and applications somewhat easier.
Let's say your company decides that the USPS just isn't good enough. The new policy is that all US customers get their shipments via UPS or FedEX. Suddenly all those "PO Box" addresses in the database are no longer valid.
So what do you do? Do you rewrite that legacy order entry application used by division X? As well as the new order entry app used by the rest of the company? (And let's not get into why division X can't use the new app, it's not under your control. Life is unfair. Other people get their way sometime, even if they're idiots. Just deal with it.) What about the new Web interface that the Consumer Technologies department has just released? Let's not forget the software that the sales department uses to give price quotes. And the Customer Service app. How many developers will that take? How long will it take to roll out after QA approves all of the changes? How many desktops, laptops, and servers are affected?
Personally, I'd just rather change one trigger or stored procedure on one or two servers. OK, so the QA people still have to test all of those different apps, but they'd have to anyway. This is still the easiest way to get it done.
Can stored procs and triggers affect performance? Yes. Especially poorly written triggers.
Can stored procs make it more difficult to migrate to another database? Yes, while making it easier to migrate the UI portion of the app to other platforms.
It's a tradeoff. Often it makes more sense to put some (all?) of the business/application logic into the database. It doesn't always make sense. That's a design decision. While designing a system, I'd rather have more tools at my disposal, and pick the best combination, rather than having my hands tied.
Here is something from my company's coding standard: When maintaining code, the style of the original code should be retained, even if the style conflicts with the style guidelines in this document. I REALLY agree with this. After years of maintenance programming, running across code that had been worked on by 10+ people and looks like it, I do this instinctively, and did before I even started this job. But it's nice to see it in writing, even if it is in a document that most of the programmers here never see. It's just a way to make life easier for the next person.
I just wish the previous coders had been as thoughtful!
I don't know. However Echelon does it, I guess.
Isn't this (sharing of mathematical and scientific information by different people in different countries) exactly why the Web was originally invented?
Where are my moderator points when I need them?
You go to open a document on your desktop. This starts the "desktop" application, which is built from .NET components. Some of these .NET components are built into .NET. Some of these components are custom for the app. Not every one of these components exists on your hard drive, some of them are on various servers run by various companies.
One component might be a M$ component on a M$ server, another one is from the company that produced the application, and resides on their server. Yet another component is one that the application developer licensed the rights to use, and resides on the third party component developer's server.
In fact, some of the components never get to your machine at all, they run on the server and only send back data. (XML of course) Remember, this IS called ".NET" because it provides a distributed, component-based platform for application development. Or to put it another way, "The nework is the machine."
Now what happens when the M$ servers are down? What about the application developer's servers? Or the third party developer's servers? What happens when there is network congestion? Or a backbone goes down? Or you lose your local network connection? What happens when some moron at the application development company forgets to renew the license to use the third party component (or M$ component) and that component stops functioning in your application? (Subscription based licensing == a predictable revenue stream == good stock prices == happy PHB ) Or when you don't renew your license to the application?
You can't access your local document with your "desktop" application, that's what. Unless you want to read the raw binary/XML data with EMACS or something.
Of course, because the document can't be accessed without a network connection in the first place, there's no reason for it to reside on your local hard drive in the first place. After all, if it resides on a server, you can access it from anywhere, can't you? As long as you have access to a .NET enabled machine, you could go to the application development company's website and log in with your username and pull up the document the same as if you were at your home workstation.
Of course there's no way that this could happen.
Well, what do you think this is? .NET servers running MS Software, on ANY OS that you care to use. Realistically, they'd probably rather you use Windows 2000 (or 2001 or whatever) as your server platform, but if you need to purchase a .NET subscription for every server, (so that you can support your users who just NEED .NET to run their favorite applications) be it Windows (oops! .Net is already included) or Linux, or Sun, or AIX, or ... they'll still get their market penetration, profits, and control.
Just in case you're really not a troll, it's "I Am Not A Lawyer"
see this /. article
Are you really that humor impaired, or was that one of the worst trolls I've seen in a while?
In this case, we know what the product is (you can download, compile, and test it if you want) We know why it was "delayed" because Linux said it was to fix bugs.
OK, some people get a little too zealous in M$ bashing, but it's not entirely unjustified.
Also, back in May I had ordered DSL service pending a line check. Well, they checked the line and it was no-go.
This month I get a huge phone bill, about 3 times the cost of the fixed price package. It turns out that they unbundled the services and charged for them separately. Also, I am due to have DSL charges starting next month (October).
After explaining that 1) Yes, I DID have the bundled service, and 2) No, my bill was ALWAYS well below $150, even if the person to whom I was speaking could not find the records to prove it, and 3) I do not now, nor have I ever had DSL service from them, and 4)getting transferred all over to make sure that I wasn't going to be filled for DSL that I didn't have, I got fed up and decided that it was finally easiest to just cancel all but the most basic local phone service while I do some research to find alternatives. I don't like Verizon any better, but they'll probably my only other alternative in this area.
To add insult to injury, as part of their wonderful voicemail system that you must navigate to speak to a real customer service representative, there is an automated option to opt out of their telemarketing. I chose that. I even confirmed it (You can't simply opt out, you must confirm it) I had done this before, when I set up phone service 6 months ago, but you can never opt out too often, or so I thought. (see below)
Within 3 hours of the initial hour long call to cancel most of my phone service I recieved 2 telemarketing calls from them, both of which said "well, If you just opted out a few hours ago, we must not have gotten the update to the list yet." Yeah, right. They use the hours right after you opt out as a "freebie" window of opportunity to besiege you with telemarketing.
The thing is, if they just hadn't gotten greedy in the first place, I would probably have kept them as my local provider for at least the next year or five.
And yes, I do know that the impurities in the nicotine delivery system will kill me quicker than all the rest combined.
Strange...when I worked for a defense contractor they didn't make me pee in a cup either.
It was only when I applied at a company in a boring run of the mill industry that they made me do that. Go figure.
What do you call reading published articles to become better informed, then speaking out in public forums? Complaining? Or getting involved?
I'll grant you, writing to your congressman is probably a bit more effective, but I think that newspapers (well, Web sites) and public squares (well, discussion boards like /.) are part of the tradition of democracy in America. This is part of "getting involved"
ARGH! I burned all my mod points. Otherwise I'd mod this up.
I thought this review was to make sure that it wasn't easy for the government to use Carnivore as a catch-all surveilance. In other words, to make sure that the government had to explicitly tell the system to look at a particular person's correspondence. So that they wouldn't be sifting through everybody's email without probable cause.
What's wrong with a technical review of the tools that Law Enforcement uses to make sure that they're not explicitly designed to ignore the "probable cause" clause?
Do you have ANY idea how many companies are running on old COBOL programs? Do you have any idea how many companies are still using MSDOS accounting applications?
Even if all of Windows were to "become LEGACY software" today, that would just mean that we would only have to deal with it for another 20-30 years at least. Probably more.
Beer? IANAL but AFAIK (Don't you just love writing like that?) You are liable if they get drunk and do something that hurts themselves or somebody else.