Link to Original Source
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Link to Original Source
Link to Original Source
Exactly. I watched a documentary recently on the LHC, and one of the scenes showed a physicist explaining to a lay audience what the multi-billion dollar effort was all about. One of the questions from the audience (who self-identified as an economist) was what was the economic benefits from knowing about all those particles or discovering the Higgs boson.
The response from the scientist was - "nothing". There is no economic benefit from spending all that money and doing that research. On the other hand, when they were discovered, radio waves weren't called radio waves - they were just a new form of radiation.
The major issue being you'd have to be near a deployment center, I imagine the only Amazon deployment centers in Canada are in Toronto and Ottawa.
Initially that will be true. But its possible that as this develops, the drones could take off and deliver from the shipping container that is travelling down the highway. IOW, you would be having a mobile (mini) warehouse that gets close enough to whereever you are to have the drones complete the delivery over the last few miles. After delivery, the drones would return back to the new location of the truck, which has continued down the highway....
Its generally the complexity of the requirements that makes something big or small. You're right - cost may not mean "big". For example, specialist skills like SAP or the latest buzzword technology can drive up the cost because its costs more to staff those developers. In general though, the more complex the requirements, the more it costs to develop the application.
Building an application server requires a different skillset and mindset than building an application does. Being a specialist in a product / technology is a wonderful achievement, and will make you very good at implementing designs. However, putting together the design and looking at the bigger pictures and making sure that the system works well together, and addresses maintainability, scalability, performance constraints, and reliability concerns requires the mindset and skill of an architect. Most small projects don't require an architect. When you get work at an enterprise level - when building an application costs (development costs only - not deployment, hosting, or operational costs) million+ dollars, you need an architect, and thats where an exclusively specialist team often doesn't deliver what the customer needs.
To draw an analogy, one can have a jam session with a handful of musicians, without requiring a conductor. But if you have hundreds of musicians (like an orchestra does), a conductor is required to deliver a quality performance.
Why is this relevant to your post? Simply put, it is easy to work without EJB's or other aspects of JEE and implement everything a servlet container. But when it gets to big applications, and you are architecting an application, JEE makes it so much easier to deliver quality.
There was a great episode of Bullshit which focussed on the organic food vs non-organic food topic. It turns out that most of the (superior) taste difference that people claim for organic food is psychological. For a single banana cut into half, if one piece is labelled "organic" and the other is not, people would report a better taste for the "organic" half. Now granted that Penn & Teller weren't producing a scientifically peer reviewed experiment, it still is an interesting data point. For my part, I don't see any difference whatsoever between organic and non-organic, other than that the organic stuff seems to spoil faster.
Yes, the view looks great through those rose-tinted glasses. I did all those unsafe things you mentioned, but there is a big difference between doing all those things and what the Chinese are proposing. The only one who took the risk was me. If I screwed up, only I suffered. The consequences of failure in this grand scheme being concocted are not limited to China alone, and if we all take the risk, then we should all have a say in this endeavor, and we should all benefit from it.
This is somewhat like the BP oil spill. The spill may have occurred outside of US territorial waters, but it sure as hell impacted the US. And the US will certainly want a say in what oil companies do when drilling offshore, because of the fiasco we witnessed.
I get the humour, but the tower of Babel was supposed to have been located in Mesopotamia - i.e modern Iraq
Yes, Airbnb is a service that doesn't provide any value (why do they exist, again?), but thats not the problem here. Even if they did provide verification of the renter, it would still be stupid to rent out ones apartment exposing private and personal information to some stranger. In this case, the landlord realized that her identity was at risk because the place had been comprehensively trashed. A smarter thief would have simply noted down all the personal data would letting the landlord suspect anything. And because the identity theft using this data could happen many months later, it would be difficult to pin this down to a specific renter.
There is no escaping the fact that landlords like this need a reality check. Maybe the world is filled with people who do and want to do the right thing, but why would you take a risk like this assuming that no bad apples would come in contact with you?
She didn't _prove_ him wrong. You can walk across a busy highway, and by some miracle escape being hit by a vehicle. That doesn't prove that everyone who told you that you are doing something stupid was wrong.
Maybe this is your experience, having come from working on applications that serve mom and pop shops, but don't assume that your experience is the same as everyone else's. Mine is the opposite of yours. Most applications are engineered for maintainability and very often, when compromises are made in shipping things out the door, it is often the function points that are left on the floor, rather than shipping function points backed by unmaintainable code.
The only exceptions to this that I have seen have been in shops which are so small that the development team lacks an architect who can enforce this discipline, and you have a team consisting of prima donnas. I'm not saying that small teams can't deliver good code. Just that most of the screwups that I've seen come from small teams operating without any discipline (and they typically lack the discipline because they think they are small enough to operate in that mode).
You are mostly correct, though you didn't mention the key word: control system. The patent that the Wright Brothers file was not for the shape of the plane, or the engine they used, but for the control systems that let them control the pitch, yaw, and roll of the aircraft. Indeed, controlling the aircraft in stable flight by defining parameters like pitch, yaw, and roll was a key insight of theirs. All their competitors weren't able to achieve stable flight because they were still guessing their way around how to keep their aircraft up and steady, and didn't really have a solution that let them control the aircraft.
With respect to your comment that this is a logical fallacy - its not so. The pitot tubes have been for the past two years the #1 reason put forward as the cause - by a wide margin. There have been no alternative theories so widely championed. Go back through the news articles and see for yourself. If you find that too difficult, you can use the wikipedia page on this disaster (look at the page history).
And if one did flip this around, one would be wrong. The characteristic of a common failure mechanism is that it is common. As such, it gets addressed by virtue of its repeated occurrence during repeated tests. If it does not occur frequently, then it simply isn't common.
I don't understand what you are trying to say here. You seem to be conceding that this was a commonly occurring failure, and don't dispute that this wasn't fixed (i.e it was ignored), so why am I wrong?
Not quite free fall. My back of the envelope calcuations (38000 feet in 3 mins 30 secs) shows that assuming constant acceleration, the descent acceleration would have been approx