I believe that PostgreSQL could see substantially more market penetration if there was a readily downloadable Windows distribution of it, with an installer, running as a service, no dependency on cygwin, perhaps a basic GUI tool, etc.
With MVCC, writers don't block readers and readers don't block writers. Both are important, and both are not true with a locking-based database, no matter how clever its lock manager, hints, etc.
MS SQL Server is quite good... except in applications that really benefit from MVCC - applications where heavy updates are going on at the same time as long-running queries. I've found that a good portion of the apps I write, do this, because my customers like to get real time business intelligence data. With such apps in SQL Server, you either:
* replicate to a reporting DB, and tell users their queries don't reflect current data, but data 30 minutes old or whatever.
* run large queries with dirty reads. Yeah, that's what I want, to give up ACID properties.
* watch updates grind to a halt as queries lock lots of rows / pages, because the SQL Server team thinks that's a good way to get a stable read. I suppose it is, except for MVCC...
Interbase also has MVCC by the way, as do a few other DMBSs that I don't recall at the moment.
SQL Server people sometimes brush off the MVCC issue, pointing out that if all your queries are well indexed, they go fast enough that it doesn't block that much. That's helpful for many apps (where with good tuning, queries can all run fast), but there are also queries which simply need to read lots of data, because of what they fundamentally are doing and even with tuning they will take many seconds to run.
Writing tests first is a terrible idea; you definately should not do it that way. See my post above:-)
But seriously, I find that overall, I produce correct, working, maintainable, solid code faster by working test-first than otherwise. You might find that it doesn't suit you. If so, then don't do it. However it is certainly of considerable value to some teams, and if you are interested in seeing how that could be true, the most thorough treatment I know of is in a recently published book on the subject:
I've had very good results with XP-ish techniques. On some projects I use just a handful of the XP practices; on others, nearly 100% of them. I've used all of the practices enough to understand them, and have found that the XP community has an unusual concentration of effective, smart people.
Yet I have little interest in XP-sucks-XP-rocks flamewars. In fact, because of the good results I've had, I'd really much prefer if my competitors decide that XP is a terrible idea, pair programming is insane, writing tests first is totally backwards, integrating every few weeks is plenty often, and changing requirements are a nightmare. It would suit me just fine if my competitors reject XP completely.
So please, if you're curious about XP, forget about it. There's nothing to see here, please move along.
Mailman does not qualify for the criteria in the initial posting, with its silly unsubscribe process.
It also has limited support for announce-only lists, a kind of list I happen to need.
I also prefer web-based tools for subscribe/unsubscribe; in the modern era of users with widely varying technical ability, relying on people to figure out how to send email commands is unwise (for a large list).
1) If you are looking for commercial suppose for an open source product, why would you choose one where it's not available? That seems pretty silly, as does the related point in the original posting.
2) 10 Years is a long time in the software business. What are the chances that the product will exist in something resembling its current form in 10 years? Obviously there is some software that has a very long life, but the great majority of it does not. Assuming the commercial vendor still exists in 10 years and hasn't merged / split / dropped the product, will they still have anyone working there to support the very old software?
Lots of people are doing it, especially for development.
It's really a rather good way to go. Jboss for development will keep your cycle fast and keep your code very close to the specs (as it should be); then if you want to deploy to something else, it will be relatively painless.
If you take the amount of money that it costs to set up WAS or WL on a cluster, counting the support contracts etc., divide it by two, then wave it at the JBoss people, you are likely to get extremely intensive hands-on help from the people who wrote the code you are having trouble with.
His leaving is described as "fired" and "officially a termination". I think to most people, "termination" implies that the company got rid of the employee.
The last two times I resigned from a job, the HR people, forms, etc. described the event as "termination". I find that interesting... going back over their records, I wonder if they see themselves as "terminating" 100% of the people who stop working there, even if 90% of the time it was the employee who decided to go elsewhere, not the employer getting rid of someone.
I also had very good results with Covad and SpeakEasy until I moved. I also had to call 2-3 times to get them to stop charging me. They eventually did, and properly credited everything back.
I asked the rep why they were so bad at this, while they seem to be pretty good at everything else. I was told that their customer service efforts were being crushed under hordes of new customers, who were switching their Covad service to SpeakEasy as man other Covad-affiliated DSL ISPs were going out of business.
While I agree that abiding by FAA regs while flying is wise, I'm not convinced at all of the technical merit here. It seems to me that if airplane electronics were so fragile that the very low power RF from an 802.11b transmitter or cell phone could affect them in any way, they'd be dropping out of the sky everywhere.
Perhaps the ad campgaign is not the people in the bars; perhaps the actual ad campaign is the free publicity in the WSJ, on Slashdot, and hundreds of other places.
I use my VCR in the same way about; setting the is a waste of time, it would enable a feature I don't use anyway. However, apparently people who design devices don't like it when users don't want to use all the features, like the clock. So they do things like this:
* Make 12:00 blink annoyingly on the VCR, so you end up with setting it or leaving the VCR on (with a tape in) to get it to not do that.
* Going even farther, the folks who design GE microwave ovens feel so strongly that the clock is an important feature that they device cannot be used at all for its main purpose, without first setting the clock (time/date) which has nothing to do with that purpose.
Why not use two hard drives, and a bit of cleverness in the software to write the incoming data stream to one while the user is viewing a stream on the other? This seems cheaper than custom hard drives, and preserves the ability to keep upgrading the capabilities by going to new commodity hard drives as biggers ones continue to get cheaper.
I see there are responses about a cygwin PostgreSQL, and one that arrived on CD for Windows from somewhere. I already knew that if I would work at it I could dig up a port to Windows somewhere. To be more specific about what would make it more popular:
* It would need to not require cygwin (though I do like and use cygwin myself) and not feel like a port; it would need to be standalone and feel like a native windows product. For example, with a little admin app, and running out of the box as an NT service.
* It would need to be promoted and downloadable right there with the unix/linux PostgreSQL.
Of course the PostGreSQL people are free to support platforms however they like however they like. These are just suggestions for things that could lead to wider use.
I think that Postgresql would be rather more popular if there was a Windows version available with an obvious download of a setup.exe or whatever. There are a great number of developers who run Windows on the desktop but who have various Unix or Linux options for deployment, and DBMSs that can run on either are much easier to try out, to develop with, etc. Examples: Oracle, MySQL, Interbase, many others.
Maybe I'm missing something, but here is how it looks to me, a very occassional EBay user:
If you enter the actual maximum amount you are willing to pay, you would not have to worry about a "sniper", because you would only be outbid by someone who was willing to pay more than you... in which case you lose, which exactly what you want to happen in that situation. "sniping" is possible because people enter, for example $250 as their max, when they would actually we billing to pay $275, and someone else comes in at the last minute and offers $252 or whatever.
It's worse than that, actually. Once XP became so overloaded, and for other reasons, a lot of Extreme Programming related stuff has been broaded in to the family of "Agile" methodologies. So the word Agile appears where XP might have appeared.
Now, of course, Microsoft is using the word Agile regularly in adveritisng.
Ugh. Maybe the XP community should embrace a new name for it. Call it "Fred". Of course, MS could come out with a replacement for MS Bob with that name:-)
Actually, Java is a great example of that... there are multiple implementations of the JVM available, and at least some of them (for example, the IBM ones) generally work very well.
HR is worried because someone might have agreed to pay a fee if you are hired.
But I wonder how far back "previously" goes?
If it means "ever in recorded history", they could run out of experienced applicants, in an area with an active recruiter community and a small group of large employers.
What attribute of code makes it "refactorable", other than the things that make it good? To me, these are exactly the same thing, but I am open to hearing about some aspect of code that's important to refactorability but not otherwise important.
I'm not quite sure what "refactorable" means, but I want my code to be like this:
* Good Cohesion
* Low Coupling
* No Duplication
It seems to me that the point of refactoring is often to make the code be this way. I don't think code has to already be good to refactor it, though mediocre code is clearly easier to work with than terrible code.
Slashdot Mirror
I believe that PostgreSQL could see substantially more market penetration if there was a readily downloadable Windows distribution of it, with an installer, running as a service, no dependency on cygwin, perhaps a basic GUI tool, etc.
With MVCC, writers don't block readers and readers don't block writers. Both are important, and both are not true with a locking-based database, no matter how clever its lock manager, hints, etc.
MS SQL Server is quite good... except in applications that really benefit from MVCC - applications where heavy updates are going on at the same time as long-running queries. I've found that a good portion of the apps I write, do this, because my customers like to get real time business intelligence data. With such apps in SQL Server, you either:
* replicate to a reporting DB, and tell users their queries don't reflect current data, but data 30 minutes old or whatever.
* run large queries with dirty reads. Yeah, that's what I want, to give up ACID properties.
* watch updates grind to a halt as queries lock lots of rows / pages, because the SQL Server team thinks that's a good way to get a stable read. I suppose it is, except for MVCC...
Interbase also has MVCC by the way, as do a few other DMBSs that I don't recall at the moment.
SQL Server people sometimes brush off the MVCC issue, pointing out that if all your queries are well indexed, they go fast enough that it doesn't block that much. That's helpful for many apps (where with good tuning, queries can all run fast), but there are also queries which simply need to read lots of data, because of what they fundamentally are doing and even with tuning they will take many seconds to run.
Writing tests first is a terrible idea; you definately should not do it that way. See my post above :-)
3 21 146530
But seriously, I find that overall, I produce correct, working, maintainable, solid code faster by working test-first than otherwise. You might find that it doesn't suit you. If so, then don't do it. However it is certainly of considerable value to some teams, and if you are interested in seeing how that could be true, the most thorough treatment I know of is in a recently published book on the subject:
http://www.amazon.com/exec/obidos/tg/detail/-/0
I've had very good results with XP-ish techniques. On some projects I use just a handful of the XP practices; on others, nearly 100% of them. I've used all of the practices enough to understand them, and have found that the XP community has an unusual concentration of effective, smart people.
Yet I have little interest in XP-sucks-XP-rocks flamewars. In fact, because of the good results I've had, I'd really much prefer if my competitors decide that XP is a terrible idea, pair programming is insane, writing tests first is totally backwards, integrating every few weeks is plenty often, and changing requirements are a nightmare. It would suit me just fine if my competitors reject XP completely.
So please, if you're curious about XP, forget about it. There's nothing to see here, please move along.
Mailman does not qualify for the criteria in the initial posting, with its silly unsubscribe process.
It also has limited support for announce-only lists, a kind of list I happen to need.
I also prefer web-based tools for subscribe/unsubscribe; in the modern era of users with widely varying technical ability, relying on people to figure out how to send email commands is unwise (for a large list).
1) If you are looking for commercial suppose for an open source product, why would you choose one where it's not available? That seems pretty silly, as does the related point in the original posting.
2) 10 Years is a long time in the software business. What are the chances that the product will exist in something resembling its current form in 10 years? Obviously there is some software that has a very long life, but the great majority of it does not. Assuming the commercial vendor still exists in 10 years and hasn't merged / split / dropped the product, will they still have anyone working there to support the very old software?
How do we know that this extra-monthly-cost radio will remain commercial-free?
Remember when cable TV didn't have commercials? Now it has about as many as broadcast, and costs a lot more per month also.
Lots of people are doing it, especially for development.
It's really a rather good way to go. Jboss for development will keep your cycle fast and keep your code very close to the specs (as it should be); then if you want to deploy to something else, it will be relatively painless.
Maybe you probably weren't paying enough. A top-notch BEA Weblogic consultant able to make the thing really sing, could cost well over that figure.
If you take the amount of money that it costs to set up WAS or WL on a cluster, counting the support contracts etc., divide it by two, then wave it at the JBoss people, you are likely to get extremely intensive hands-on help from the people who wrote the code you are having trouble with.
His leaving is described as "fired" and "officially a termination". I think to most people, "termination" implies that the company got rid of the employee.
The last two times I resigned from a job, the HR people, forms, etc. described the event as "termination". I find that interesting... going back over their records, I wonder if they see themselves as "terminating" 100% of the people who stop working there, even if 90% of the time it was the employee who decided to go elsewhere, not the employer getting rid of someone.
I also had very good results with Covad and SpeakEasy until I moved. I also had to call 2-3 times to get them to stop charging me. They eventually did, and properly credited everything back.
I asked the rep why they were so bad at this, while they seem to be pretty good at everything else. I was told that their customer service efforts were being crushed under hordes of new customers, who were switching their Covad service to SpeakEasy as man other Covad-affiliated DSL ISPs were going out of business.
While I agree that abiding by FAA regs while flying is wise, I'm not convinced at all of the technical merit here. It seems to me that if airplane electronics were so fragile that the very low power RF from an 802.11b transmitter or cell phone could affect them in any way, they'd be dropping out of the sky everywhere.
Perhaps the ad campgaign is not the people in the bars; perhaps the actual ad campaign is the free publicity in the WSJ, on Slashdot, and hundreds of other places.
I use my VCR in the same way about; setting the is a waste of time, it would enable a feature I don't use anyway. However, apparently people who design devices don't like it when users don't want to use all the features, like the clock. So they do things like this:
* Make 12:00 blink annoyingly on the VCR, so you end up with setting it or leaving the VCR on (with a tape in) to get it to not do that.
* Going even farther, the folks who design GE microwave ovens feel so strongly that the clock is an important feature that they device cannot be used at all for its main purpose, without first setting the clock (time/date) which has nothing to do with that purpose.
Why not use two hard drives, and a bit of cleverness in the software to write the incoming data stream to one while the user is viewing a stream on the other? This seems cheaper than custom hard drives, and preserves the ability to keep upgrading the capabilities by going to new commodity hard drives as biggers ones continue to get cheaper.
I see there are responses about a cygwin PostgreSQL, and one that arrived on CD for Windows from somewhere. I already knew that if I would work at it I could dig up a port to Windows somewhere. To be more specific about what would make it more popular:
* It would need to not require cygwin (though I do like and use cygwin myself) and not feel like a port; it would need to be standalone and feel like a native windows product. For example, with a little admin app, and running out of the box as an NT service.
* It would need to be promoted and downloadable right there with the unix/linux PostgreSQL.
Of course the PostGreSQL people are free to support platforms however they like however they like. These are just suggestions for things that could lead to wider use.
I think that Postgresql would be rather more popular if there was a Windows version available with an obvious download of a setup.exe or whatever. There are a great number of developers who run Windows on the desktop but who have various Unix or Linux options for deployment, and DBMSs that can run on either are much easier to try out, to develop with, etc. Examples: Oracle, MySQL, Interbase, many others.
Maybe I'm missing something, but here is how it looks to me, a very occassional EBay user:
If you enter the actual maximum amount you are willing to pay, you would not have to worry about a "sniper", because you would only be outbid by someone who was willing to pay more than you... in which case you lose, which exactly what you want to happen in that situation. "sniping" is possible because people enter, for example $250 as their max, when they would actually we billing to pay $275, and someone else comes in at the last minute and offers $252 or whatever.
It's worse than that, actually. Once XP became so overloaded, and for other reasons, a lot of Extreme Programming related stuff has been broaded in to the family of "Agile" methodologies. So the word Agile appears where XP might have appeared.
:-)
Now, of course, Microsoft is using the word Agile regularly in adveritisng.
Ugh. Maybe the XP community should embrace a new name for it. Call it "Fred". Of course, MS could come out with a replacement for MS Bob with that name
Actually, Java is a great example of that... there are multiple implementations of the JVM available, and at least some of them (for example, the IBM ones) generally work very well.
HR is worried because someone might have agreed to pay a fee if you are hired.
But I wonder how far back "previously" goes?
If it means "ever in recorded history", they could run out of experienced applicants, in an area with an active recruiter community and a small group of large employers.
What attribute of code makes it "refactorable", other than the things that make it good? To me, these are exactly the same thing, but I am open to hearing about some aspect of code that's important to refactorability but not otherwise important.
I'm not quite sure what "refactorable" means, but I want my code to be like this:
* Good Cohesion
* Low Coupling
* No Duplication
It seems to me that the point of refactoring is often to make the code be this way. I don't think code has to already be good to refactor it, though mediocre code is clearly easier to work with than terrible code.