You dont choose a project for a language, but a language for a project.
If the higher level goal is implementing a particular project for some use, you do the latter. If the higher level goal is learning a particular language by implenting something realistically useful with it, you do the former.
Having both goals at once (which is what seems to have produced the situation in TFA) and trying to satisfy them both without appropriately addressing either is a really bad idea.
So all things considered, this really amounts to an Easter Egg. Most spreadsheets will calculate, graph, and function exactly as they should even using the results from a cell that displays inaccurately in that one case...
You know, some people actually read and use the displayed results from Excel for important purposes, rather than merely feeding them into further calculations, graphs, etc. Where the cell is an ultimate output, this isn't just a harmless display error that doesn't have any functional impact.
An employer has a limited amount of money with which to compensate employees. The exact structure of counting the labor doesn't affect the pay in the long term.
Your analysis is flawed. Without a mandatory overtime requirement, its a lot easier to, say, when there is trouble cut staff, demand that salaried grunts remaining work extra hours without extra compensation, and maintain or even increase executive compensation and bonuses than the same would be with a mandatory overtime requirement. If you couldn't do that kind of stealth pay cut, where you make cuts while trying to keep customers satisfied would naturally change.
"Pay" is not one single undifferentiated pot whose distribution doesn't vary.
When the company hires you as salaried, that time you're 'giving' them is factored into the pay.
But the expected time is often not communicated clearly up front, or creeps over time, resulting in a rate of pay that is, essentially, lower than what you signed on for; even if mandatory overtime provisions didn't change the actual compensation in any job, they'd reduce the ability of employers to deceive about the real exchange being offered, or to alter the bargain over time unilaterally. This would improve the ability of job seekers to make informed decisions about which job offers fit their priorities.
For example -- I would have to create additional unique SQL constraints in the database migration files, in some cases, I have to write out the SQL directly -- bypassing that which is Rails.
Writing out SQL directly is not "bypassing that which is Rails". AWDR makes this pretty clear; the intent of Rails is not to follow the "SQL is evil" mindset, but to abstract and make portable that part of the SQL that can productively be abstracted out and made portable. Now, there are applications that, given how much Rails does abstract, can do without much, if any, direct SQL with Rails (particularly if they avoid database-level constraints), but its not subverting Rails to use direct SQL where it is appropriate for an application.
Then the Model would not only have to run the extraneous SQL statement to check for uniqueness, but also be modified to accomodate the error handling that is going to happen when you violate the database integrity.
If the constraints are added as additional SQL to the migrations as either table constraints or database triggers, I don't think the model has to do anything. Rails built in error handling should fire an exception on a failed update or insert, which should generally happen and be handled in the controller, right? And if you are handcoding in MVC style without Rails, in any language, that's still going to be the case, right? Rails may not add much to this, but it doesn't seem to me that it really fights you in it, either.
I agree, though, that the MySQLcentrism of, apparently, both the applications which spawned Rails and most of the Rails books and tutorials to date tend to give the impression that Rails is hostile to database-level integrity constraints, but I think as a practical matter Rails is more neutral to them (in that it doesn't abstract them into some portable form, but doesn't prevent you from using them). It seems more hostile to tables without simple integer primary keys...
Even worse, there's absolutely nothing there about why Rails didn't work.
Its not all that clear to me that Rails "didn't work", so much as: 1) Rails wasn't necessary because PHP did work, 2) Rails wasn't desirable because the priorities for the project were out of line with the strengths of rails (direct SQL was important to the author's approach, the author had hand-tailored code that did what was necessary and nothing else and wanted to keep it that way, and, perhaps most importantly, 3) The whole idea of complete, all-at-once replacement was disruption that wasn't really desirable.
The article provides nothing useful to anyone looking to build a web site.
Since the problem wasn't with building a web site (the author says he's looking forward to using Rails on a fresh project), but with reimplementing an existing large production website with minimal disruption, that shouldn't be a big surprise.
How do I know if PHP is superior to Rails for my particular application?
Judging from TFA, if you have a large existing production application in PHP that does essentially what you want, its probably a better idea to clean it up bit-by-bit using ideas from Rails than to reimplement in Rails.
For a new project? Well, TFA won't give you much of a clue on that, because that's not something the author has tried Rails for yet.
This is nothing but a senseless rant.
I don't think its a "senseless rant", I think it illustrates something that sometimes gets overlooked in the enthusiasm for the new, shiny thing out there: if you've got something that works, your often better off learning from other approaches and adapting them to improve your existing codebase than adopting something new and rebuilding from scratch. Now, the title of the Slashdot article, which suggests that this is somehow a reason not to use Rails in general, is senseless, but then having poorly-considered titles on Slashdot is hardly something new.
Nothing in the article says anything negative about Rails. Indeed, the author says toward the end, "All that being said, I'm looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning."
TFA really boils down to "If you have a large existing production system that essentially does what you want, and mostly the way you want it, its generally a bad idea to throw it out and start over just so you can use a fancy new tool that takes a completely different approach to the problem domain than the one taken by your existing tool and, more importantly, than the approach you want to take for the project."
Which is also the reason that plenty of large COBOL systems hang around, with bits and pieces in other languages added on and interfaced to them, but the main system left in COBOL and maintained there rather than reimplemented, until changes to the requirements would force a complete reimplementation even if the language didn't change.
I someone forcing you to buy an XO? If not, how is it any less voluntary than giving to any pledge drive that offers to give you something in return for a donation of a specified amount?
The XO-1 is closer to $200. The $100 thing was a price goal when the project was conceived; the important thing was that it was relatively inexpensive and that subsequent versions would focus on maintaining compatibility and reducing the price over adding features.
They will sell the systems here, but only at a double price. And yet, these systems will soon be in other countries at the low prices.
I'm sure if the US Department of Education (or probably even any state Department of Education in the US) wanted to buy them on a 1 per child basis for the entire school-age population of the US (or any state) they'd get the same deal that national ministries of education all over the world are getting. Even though the design specs are driven by the needs of the developing world, the project has never indicated it would reject any government, and there have been discussions, IIRC, with some US states.
The more expensive version is for individual sale which is outside of the core mission of the OLPC project, and useful to the project mainly as a means to subsidize the core mission.
I would like to see at least some of these computers go to American schools.
Then stop whining about OLPC's pricing for individual sale in the US, and work to get your state or federal government to buy into the program for the schools in the US or just your state.
I always wonder why so many people demand raytracing and not photon mapping.
Probably because most people aren't aware of photon mapping, and some of those that are only familiar with it as a feature of "ray tracing" rendering packages, and consider it part of ray tracing.
In the UK, the bachelor's degree in law (either B.A. in Law or LL.B., per the first Wikipedia link), the degree you have to get at Cambridge before a Cambridge M.A. in Law, per your own link, is the degree that qualifies you to practice law.
However, assuming that the copywrite infringement claim fails, then they could probably refile at a later date on the basis of breach of contract.
Usually, filing one lawsuit will forfeit your ability to file a later lawsuit against the same defendant stemming out of the same transaction; you can often pursue claims based on alternative theories in the same case, though there are tactical reasons why you might not want to if one is much stronger legally, such as avoiding confusing the trier of fact.
The graphics we see today are possible only because we can make a special purpose processor that can accelerate them very efficiently. Can the same be done for raytracing?
I think a big point is we're getting really close to the point where it doesn't need to be; realtime raytracing on multicore CPUs without special hardware acceleration is not far off (IIRC, the latest beta of the Free raytracer POV-Ray actually has a pre-programmed path realtime raytracing mode, but its limited to fairly low resolution and not everything you'd need for gaming.)
Most likely the ray traced games of tomorrow will be running on ray tracing accelerators, namely graphics cards.
Eh, why? Raytracing is processor-hungry, but AFAIK its pretty well suited to general purpose CPUs and parallelizes easily; its pretty much an ideal "throw more general purpose cores at the problem" area.
I'd have to say that Mr. Jakeman has serious reading comprehension issues.
I'd say that Mr. Jakeman isn't the one with the problem.
So they didn't just notify a "support droid", they notified Monsoon's lawyers.
Er, no. "On September 11, 2007, through their counsel, Plaintiffs notified Defendant [...]" means that the Plaintiffs' lawyers notifed the Defendant, not that the Plaintiffs notified the Defendant's lawyers.
He doesn't cite a legal basis for that, though. That may only be his opinion, without legal precedent, and could well be overridden by a judge in a case like this.
There is plenty of legal basis for gratuitous licenses in US law. Of course, they are also (whatever the terms on their face) revocable at will by the copyright holder because they aren't, as Moglen notes, contracts, and therefore no one is actually bound by them, they are just a permission that, so long as not revoked, provides a shield against suit for copyright infringement.
So, if a court finds Moglen is right that the GPL is not a contract (and that seems likely), the FSF's ability to paint the GPL as being a safe license to rely on will be compromised.
I thought that copyright law was pretty clear on what a "derived work" is. The GPL does not modify copyright law.
The GPL expressly asserts that particular things constitute parts of the same "work" without the copyright law being clear that that is the case; this is particularly true of the GPL's linking provisions. I don't think that's an issue in this case, but its one of the interesting areas of legal uncertainty in the GPL.
Contracts require bilateral agreement. A distribution license doesn't require your agreement at all --- nobody forces you to agree to it, but it's on offer if you want it. However, if you don't accept it then nothing else will protect you from copyright infringement if you redistribute the work.
Of course, if its a gratuitous license (as the FSF contends, probably correctly) and not a contract, its also revocable at will by the copyright holder, since no one is bound to anything by it, just the copyright holder has no bases to sue for infringement as long as you comply with it. This conflicts, of course, with the FSF's other PR effort with the GPL, trying to convince people, especially businesses, that it's not a risky license compared to traditional contract-based licenses.
What percent of the population keep a number for that long, anyway?
Probably almost everyone who doesn't move outside of a local exchange (that is, excluding people that rotate numbers because they are repeated targets of harrassment); I'd expect probably a sizable majority of people and a slightly smaller majority of phone numbers (as second and additional lines may be more transitory.)
If the Do-Not-Call list were to never expire, eventually it will fill to all available U.S. phone numbers.
It would make some sense to make it so that you registered through your phone service provider, and they pulled the listing of the database if the subscriber discontinued use of the number. It makes more sense than a fixed 5-year period, at any rate.
So is velociraptor going to be announced as the earliest known ancestor of birds?
Probably not; IIRC, there is some evidence the other way around, that is, that Archaeopteryx, generally accepted as the first bird, may be an ancestor of Velociraptor, which would then be a flightless bird.
I don't think that is theory, but instead that quite a lot of theropod dinosaurs (aside from birds, which are theropod dinosaurs and indisputably have feathers) had feathers, and that many that have not been previously recognized as such are actually not just "theropod dinosaurs with feathers", but actually birds (Velociraptor included.)
I wonder why other velociraptor fossils haven't been found with feathers, if all velociraptors had them?
There has been considerable, IIRC, evidence of feathers in velociraptor fossils previously, and evidence of feathers throughout the same family, which there is some reason to believe are actually birds. But feathers don't fossilize really well, and most of the evidence for velociraptor in particular has been indirect indications.
My theory is that the 'raptor wasn't a dinosaur at all. It was just a really big ostrich.
Birds are theropod dinosaurs, and (while it isn't, as far as I know, actually settled), there is, I believe, some currency to the idea that the Dromosauridae (including Velociraptor and pals) are actually birds.
Slashdot Mirror
No doubt because it wasn't a random sample in the first place, so a "margin of error", which reflects the sampling error, would be meaningless.
If the higher level goal is implementing a particular project for some use, you do the latter. If the higher level goal is learning a particular language by implenting something realistically useful with it, you do the former.
Having both goals at once (which is what seems to have produced the situation in TFA) and trying to satisfy them both without appropriately addressing either is a really bad idea.
You know, some people actually read and use the displayed results from Excel for important purposes, rather than merely feeding them into further calculations, graphs, etc. Where the cell is an ultimate output, this isn't just a harmless display error that doesn't have any functional impact.
Your analysis is flawed. Without a mandatory overtime requirement, its a lot easier to, say, when there is trouble cut staff, demand that salaried grunts remaining work extra hours without extra compensation, and maintain or even increase executive compensation and bonuses than the same would be with a mandatory overtime requirement. If you couldn't do that kind of stealth pay cut, where you make cuts while trying to keep customers satisfied would naturally change.
"Pay" is not one single undifferentiated pot whose distribution doesn't vary.
But the expected time is often not communicated clearly up front, or creeps over time, resulting in a rate of pay that is, essentially, lower than what you signed on for; even if mandatory overtime provisions didn't change the actual compensation in any job, they'd reduce the ability of employers to deceive about the real exchange being offered, or to alter the bargain over time unilaterally. This would improve the ability of job seekers to make informed decisions about which job offers fit their priorities.
Writing out SQL directly is not "bypassing that which is Rails". AWDR makes this pretty clear; the intent of Rails is not to follow the "SQL is evil" mindset, but to abstract and make portable that part of the SQL that can productively be abstracted out and made portable. Now, there are applications that, given how much Rails does abstract, can do without much, if any, direct SQL with Rails (particularly if they avoid database-level constraints), but its not subverting Rails to use direct SQL where it is appropriate for an application.
If the constraints are added as additional SQL to the migrations as either table constraints or database triggers, I don't think the model has to do anything. Rails built in error handling should fire an exception on a failed update or insert, which should generally happen and be handled in the controller, right? And if you are handcoding in MVC style without Rails, in any language, that's still going to be the case, right? Rails may not add much to this, but it doesn't seem to me that it really fights you in it, either.
I agree, though, that the MySQLcentrism of, apparently, both the applications which spawned Rails and most of the Rails books and tutorials to date tend to give the impression that Rails is hostile to database-level integrity constraints, but I think as a practical matter Rails is more neutral to them (in that it doesn't abstract them into some portable form, but doesn't prevent you from using them). It seems more hostile to tables without simple integer primary keys...
Its not all that clear to me that Rails "didn't work", so much as:
1) Rails wasn't necessary because PHP did work,
2) Rails wasn't desirable because the priorities for the project were out of line with the strengths of rails (direct SQL was important to the author's approach, the author had hand-tailored code that did what was necessary and nothing else and wanted to keep it that way, and, perhaps most importantly,
3) The whole idea of complete, all-at-once replacement was disruption that wasn't really desirable.
Since the problem wasn't with building a web site (the author says he's looking forward to using Rails on a fresh project), but with reimplementing an existing large production website with minimal disruption, that shouldn't be a big surprise.
Judging from TFA, if you have a large existing production application in PHP that does essentially what you want, its probably a better idea to clean it up bit-by-bit using ideas from Rails than to reimplement in Rails.
For a new project? Well, TFA won't give you much of a clue on that, because that's not something the author has tried Rails for yet.
I don't think its a "senseless rant", I think it illustrates something that sometimes gets overlooked in the enthusiasm for the new, shiny thing out there: if you've got something that works, your often better off learning from other approaches and adapting them to improve your existing codebase than adopting something new and rebuilding from scratch. Now, the title of the Slashdot article, which suggests that this is somehow a reason not to use Rails in general, is senseless, but then having poorly-considered titles on Slashdot is hardly something new.
Nothing in the article says anything negative about Rails. Indeed, the author says toward the end, "All that being said, I'm looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning."
TFA really boils down to "If you have a large existing production system that essentially does what you want, and mostly the way you want it, its generally a bad idea to throw it out and start over just so you can use a fancy new tool that takes a completely different approach to the problem domain than the one taken by your existing tool and, more importantly, than the approach you want to take for the project."
Which is also the reason that plenty of large COBOL systems hang around, with bits and pieces in other languages added on and interfaced to them, but the main system left in COBOL and maintained there rather than reimplemented, until changes to the requirements would force a complete reimplementation even if the language didn't change.
"If it works, don't fix it."
I someone forcing you to buy an XO? If not, how is it any less voluntary than giving to any pledge drive that offers to give you something in return for a donation of a specified amount?
It doesn't.
The XO-1 is closer to $200. The $100 thing was a price goal when the project was conceived; the important thing was that it was relatively inexpensive and that subsequent versions would focus on maintaining compatibility and reducing the price over adding features.
I'm sure if the US Department of Education (or probably even any state Department of Education in the US) wanted to buy them on a 1 per child basis for the entire school-age population of the US (or any state) they'd get the same deal that national ministries of education all over the world are getting. Even though the design specs are driven by the needs of the developing world, the project has never indicated it would reject any government, and there have been discussions, IIRC, with some US states.
The more expensive version is for individual sale which is outside of the core mission of the OLPC project, and useful to the project mainly as a means to subsidize the core mission.
Then stop whining about OLPC's pricing for individual sale in the US, and work to get your state or federal government to buy into the program for the schools in the US or just your state.
Probably because most people aren't aware of photon mapping, and some of those that are only familiar with it as a feature of "ray tracing" rendering packages, and consider it part of ray tracing.
In the UK, the bachelor's degree in law (either B.A. in Law or LL.B., per the first Wikipedia link), the degree you have to get at Cambridge before a Cambridge M.A. in Law, per your own link, is the degree that qualifies you to practice law.
Usually, filing one lawsuit will forfeit your ability to file a later lawsuit against the same defendant stemming out of the same transaction; you can often pursue claims based on alternative theories in the same case, though there are tactical reasons why you might not want to if one is much stronger legally, such as avoiding confusing the trier of fact.
I think a big point is we're getting really close to the point where it doesn't need to be; realtime raytracing on multicore CPUs without special hardware acceleration is not far off (IIRC, the latest beta of the Free raytracer POV-Ray actually has a pre-programmed path realtime raytracing mode, but its limited to fairly low resolution and not everything you'd need for gaming.)
Eh, why? Raytracing is processor-hungry, but AFAIK its pretty well suited to general purpose CPUs and parallelizes easily; its pretty much an ideal "throw more general purpose cores at the problem" area.
I'd say that Mr. Jakeman isn't the one with the problem.
Er, no. "On September 11, 2007, through their counsel, Plaintiffs notified Defendant [...]" means that the Plaintiffs' lawyers notifed the Defendant, not that the Plaintiffs notified the Defendant's lawyers.
There is plenty of legal basis for gratuitous licenses in US law. Of course, they are also (whatever the terms on their face) revocable at will by the copyright holder because they aren't, as Moglen notes, contracts, and therefore no one is actually bound by them, they are just a permission that, so long as not revoked, provides a shield against suit for copyright infringement.
So, if a court finds Moglen is right that the GPL is not a contract (and that seems likely), the FSF's ability to paint the GPL as being a safe license to rely on will be compromised.
The GPL expressly asserts that particular things constitute parts of the same "work" without the copyright law being clear that that is the case; this is particularly true of the GPL's linking provisions. I don't think that's an issue in this case, but its one of the interesting areas of legal uncertainty in the GPL.
Of course, if its a gratuitous license (as the FSF contends, probably correctly) and not a contract, its also revocable at will by the copyright holder, since no one is bound to anything by it, just the copyright holder has no bases to sue for infringement as long as you comply with it. This conflicts, of course, with the FSF's other PR effort with the GPL, trying to convince people, especially businesses, that it's not a risky license compared to traditional contract-based licenses.
Probably almost everyone who doesn't move outside of a local exchange (that is, excluding people that rotate numbers because they are repeated targets of harrassment); I'd expect probably a sizable majority of people and a slightly smaller majority of phone numbers (as second and additional lines may be more transitory.)
It would make some sense to make it so that you registered through your phone service provider, and they pulled the listing of the database if the subscriber discontinued use of the number. It makes more sense than a fixed 5-year period, at any rate.
Probably not; IIRC, there is some evidence the other way around, that is, that Archaeopteryx, generally accepted as the first bird, may be an ancestor of Velociraptor, which would then be a flightless bird.
the suspicion is that all dinosours had feathers.
I don't think that is theory, but instead that quite a lot of theropod dinosaurs (aside from birds, which are theropod dinosaurs and indisputably have feathers) had feathers, and that many that have not been previously recognized as such are actually not just "theropod dinosaurs with feathers", but actually birds (Velociraptor included.)
There has been considerable, IIRC, evidence of feathers in velociraptor fossils previously, and evidence of feathers throughout the same family, which there is some reason to believe are actually birds. But feathers don't fossilize really well, and most of the evidence for velociraptor in particular has been indirect indications.
Birds are theropod dinosaurs, and (while it isn't, as far as I know, actually settled), there is, I believe, some currency to the idea that the Dromosauridae (including Velociraptor and pals) are actually birds.