I maintain a few dozen projects myself and have contributed to some big projects.
I agree posting a good issue report is a problem. I also think that any missing information can be requested by the developers and I'd rather have an incomplete issue report than no issue report at all. I guess it depends on the type of users; my projects and contributions usually focus on developer tools.
I understand the desire for quality issue reports and quality pull requests, but every added restriction will ensure some people just won't bother.
There's nothing stopping V8 from doing the same dick-move. But right now, Node.JS's language effectively IS whatever V8 is. If Node.js can set their own language standards and block syntax outside that standard, it would make swapping engines a total non-issue.
Does it matter? If ChakraCore's language support for JavaScript covers 100% of V8's language support, no more no less, they can integrate it in Node.js just let the user decide which is better in which situation.
The main issue is this language compatibility. Node.js would need to define the language syntax they officially support, possibly defined by just taking most of V8's language support, and would have to get a binding commitment that the other one will stay in line within a reasonable time and not enable any additional language features.
If the two start to deviate in any significant way, it'll be Embrace, Extend & Extinguish all over again.
The key complains are mostly complaints about common behavior of other users.
1. Ability to force issue submitters to supply more data. 2. Some alternative to +1 issue comment overload. 3. Some way to block pull requests or issues submissions that don't fit certain guidelines.
I strongly disagree with 1 and 3, as they're likely to stop some people from submitting things at all by making it harder to do so. I too have had crappy issues and sloppy pull requests submitted. I'd rather have those and start working with the person taking the effort to submit them, than have none at all.
Maybe not, but the reviewers' ass is on the line for bugs found that his review should have caught. Skim over reviews too many times and it's bye bye. Doing a bad job should have consequences. Though I admit that might not work in smaller organisations.
The percentage of women in IT (about 26%) is higher than the percentage of women in politics (about 22%). Remember that next time a politician claims "a long historic discrimination in the areas of gender".
If a corporation is publically traded, it has a legal requirement to have it's shareholders' interests as it's goal. Customers' interests will only be fulfilled if it happens to coincide with shareholders' interests.
Won't Sony be causing brand confusion by naming their brand after a well established term in their field of business? Now all of a sudden, when people are talking/writing about "Let's Play", readers won't be able to tell whether they're talking about the fun free thing or the undoubtedly evil Sony thing.
The driver ofcourse. That is to say, the person who instructs the car to start the automatic parking, regardless of whether that person is or is not inside the car.
A practical case I have once enountered is a database that tallies API usage for billing purposes and rate limiting. It's a single table with simple inserts (so no transactions, no updates and no deletes ever) And if every once in a while an insert fails, it's not really a big deal; at the very worst, a few customers would pay about $0.00001 less.
With a full SQL database, on the other hand, the worst case would be having to invest thousands of dollars in a server and still not being able to cope with the traffic.
So the solution would be to put most of the data in a normal SQL database, but move some of these high-frequency statistics tables to a non-SQL solution.
Same here w/r MongoDB. I get that for high-traffic websites need a better scalable solutions than the traditional databases, and I get that you have to sacrifice some of the features of those traditional databases to do so. But... MongoDB is pretty much the worst possible way of doing this. Just compare it to other alternatives to traditional databases. I just can't find any reason to ever use MongoDB, and I've even made an effort to try and find reasons. There are alternatives that are better in every single way (I prefer Cassandra myself, but it's not the only one out there). And even than; these solutions are only for the absolute most high-traffic sites out there. ~99.99% of projects are better off using an SQL database. And even if you really want to use a NoSQL database, it only makes sense for a few select use-cases, not your entire database.
As for Oracle; I think it's actually a pretty good (though incredibly overpriced) database. PL/SQL has it's place (like similar languages in other databases), but not as it's commonly used by a long shot. If your PL/SQL is not part of same version control repository as the source code that uses it, you're probably doing it wrong.
Just take the judges' credit card and personal information, use it to buy loads of expensive stuff, narcotics and subscriptions to perverse sex sites, then after the judge is done dealing with the credit card company to get the situation corrected just say "no harm done".
Slashdot Mirror
I maintain a few dozen projects myself and have contributed to some big projects.
I agree posting a good issue report is a problem. I also think that any missing information can be requested by the developers and I'd rather have an incomplete issue report than no issue report at all. I guess it depends on the type of users; my projects and contributions usually focus on developer tools.
I understand the desire for quality issue reports and quality pull requests, but every added restriction will ensure some people just won't bother.
There's nothing stopping V8 from doing the same dick-move.
But right now, Node.JS's language effectively IS whatever V8 is.
If Node.js can set their own language standards and block syntax outside that standard, it would make swapping engines a total non-issue.
Does it matter? If ChakraCore's language support for JavaScript covers 100% of V8's language support, no more no less, they can integrate it in Node.js just let the user decide which is better in which situation.
The main issue is this language compatibility. Node.js would need to define the language syntax they officially support, possibly defined by just taking most of V8's language support, and would have to get a binding commitment that the other one will stay in line within a reasonable time and not enable any additional language features.
If the two start to deviate in any significant way, it'll be Embrace, Extend & Extinguish all over again.
The key complains are mostly complaints about common behavior of other users.
1. Ability to force issue submitters to supply more data.
2. Some alternative to +1 issue comment overload.
3. Some way to block pull requests or issues submissions that don't fit certain guidelines.
I strongly disagree with 1 and 3, as they're likely to stop some people from submitting things at all by making it harder to do so.
I too have had crappy issues and sloppy pull requests submitted. I'd rather have those and start working with the person taking the effort to submit them, than have none at all.
2 has some validity to it, for large projects.
I guess if you crank out a 100 per hour, all green is somewhat to be expected.
Maybe not, but the reviewers' ass is on the line for bugs found that his review should have caught.
Skim over reviews too many times and it's bye bye.
Doing a bad job should have consequences.
Though I admit that might not work in smaller organisations.
You prefer peer review or test-driven?
It's pretty easy to require formal sign-offs by reviewers.
In fact, that is how it's done in most mature IT organizations.
Simple.
Start an corporate organisation.
Give it some random name like "Linux foundation".
Boom! Fake community organisation.
They don't have any power beyond that of any other individual contributer.
But... but... but... this evil-bit WILL work, honestly!
Leaks
You keep using that word. I do not think it means what you think it means.
Now your just making stuff up.
The percentage of women in IT (about 26%) is higher than the percentage of women in politics (about 22%).
Remember that next time a politician claims "a long historic discrimination in the areas of gender".
That explains why you're still posting.
If a corporation is publically traded, it has a legal requirement to have it's shareholders' interests as it's goal.
Customers' interests will only be fulfilled if it happens to coincide with shareholders' interests.
Long story short; we don't see many musicians of his caliber today and we didn't see many back then either.
I've always wanted to be able to control traffic lights.
First they wanted to backdoor all encryption, now they've got a fully-backdoored encryption and it's still not good enough.
{anything} is the only viable path to {anything}
Is wrong by definition.
Doctor Who's work on the onion planet of Spinthoz was limited to an unofficial visit, which means there were no welcome protocols involved.
http://tardis.wikia.com/wiki/O...
Won't Sony be causing brand confusion by naming their brand after a well established term in their field of business?
Now all of a sudden, when people are talking/writing about "Let's Play", readers won't be able to tell whether they're talking about the fun free thing or the undoubtedly evil Sony thing.
The driver ofcourse.
That is to say, the person who instructs the car to start the automatic parking, regardless of whether that person is or is not inside the car.
A practical case I have once enountered is a database that tallies API usage for billing purposes and rate limiting.
It's a single table with simple inserts (so no transactions, no updates and no deletes ever)
And if every once in a while an insert fails, it's not really a big deal; at the very worst, a few customers would pay about $0.00001 less.
With a full SQL database, on the other hand, the worst case would be having to invest thousands of dollars in a server and still not being able to cope with the traffic.
So the solution would be to put most of the data in a normal SQL database, but move some of these high-frequency statistics tables to a non-SQL solution.
Not every data storage needs ACID.
Same here w/r MongoDB.
I get that for high-traffic websites need a better scalable solutions than the traditional databases, and I get that you have to sacrifice some of the features of those traditional databases to do so.
But... MongoDB is pretty much the worst possible way of doing this. Just compare it to other alternatives to traditional databases. I just can't find any reason to ever use MongoDB, and I've even made an effort to try and find reasons. There are alternatives that are better in every single way (I prefer Cassandra myself, but it's not the only one out there).
And even than; these solutions are only for the absolute most high-traffic sites out there. ~99.99% of projects are better off using an SQL database. And even if you really want to use a NoSQL database, it only makes sense for a few select use-cases, not your entire database.
As for Oracle; I think it's actually a pretty good (though incredibly overpriced) database. PL/SQL has it's place (like similar languages in other databases), but not as it's commonly used by a long shot. If your PL/SQL is not part of same version control repository as the source code that uses it, you're probably doing it wrong.
Just take the judges' credit card and personal information, use it to buy loads of expensive stuff, narcotics and subscriptions to perverse sex sites, then after the judge is done dealing with the credit card company to get the situation corrected just say "no harm done".