If it's not repeatable and reproducible, is it really testing? Or is it *critique*?
It seems to me there are two kinds of testing. On one hand there are the many variants of smoke testing ("plug it in and see if smoke comes out"). On the other hand, there is the kind of testing that involves carrying out a plan where each step has success and failure criteria that have to be checked off in order for the software to pass.
Developers can't smoke test their own work effectively because of the human cognitive bias toward seeing the expected result. They could probably execute a well-designed test plan, although you'd still prefer someone more independent. As for designing the test plan itself, if you've ever tried to write a comprehensive test plan, it's a big, mind-numbing job.
I believe that in an ideal world the foundation of the test plan would be laid when the system is conceived (non-functional requirements, use-cases).Naturally you'd stipulate that the acceptance test for each task in a use case be performed a representative user under representative conditions. You wouldn't have a web form designer do that test because he knows where all the necessary widgets are tucked away. And throughout the planning, design and implementation of the system, before you started to do *anything* you'd devise a test for success.
But I happen know that in the real world that most people only start thinking about testing as the delivery date approaches -- at least until they've got burned.
Also, note that just because one particular non-extended-range electric vehicle does not meet your particular driving requirements does not mean it is a useless endeavour, or even that it will fail in market at all.
I'll add another point: most households have more than one car, and very few ever face situation where two family members have to take *different* 300+ mile trips on the same day.
So if electric has any advantages at all in day to day driving, then one electric and one ICE car in a two-car family is for all practical purposes just as versatile as two ICE cars. Sure, once in a blue moon you'll want two ICE cars. But *more* than once in a blue moon one of those ICE cars will in the shop having it's complicated and temperamental engine, transmission or exhaust system repaired.
It's probable that most two car houses with one ICE car and one EV with at least a 200 mile range have no cause to feel range anxiety.
Well, at least they grant *you* the dignity of a stereotype. I'm from Massachusetts. When Republicans bash us,they just say our name in a funny, nasal voice, as if people are supposed to know why. It's like they can't even be bothered to try.
So if you want bash MA, let me show you how to do it:: "People from Massachusetts are like America's version of the French. They think they're better than everybody, but nobody else can see why."
See that you guys? You want to insinuate (suggest without actually coming out and saying it) that Bay Staters are patronizing (PAY-TRUH-NEYE-ZING).
I don't think so. I especially DON'T think that "green" means "non-toxic to humans who handle it carelessly".
It seems to me that a "green" anything is something whose production, use, and disposal does not use up environmental capital faster than the biosphere replaces it. Alternatively, you can think of it as something whose entire life-cycle, cradle to grave, does not disturb any environmental equilibria except possibly on a highly localized scale (i.e. the footprint of the production facility).
Perhaps the best way to think of green technology is that it contributes to our species' ability to live within its means. That means natural resources, not dollars. Nature doesn't care how we shift dollars around; that's really just an internal control mechanism. It does "care" if we take fish out of the sea faster than they can reproduce, or if we discharge substances into a river faster than the natural processes can absorb and use them. The substances in question might well be "natural" materials like sewage. Discharged into a creek fast enough to alter that stream's chemistry, even *pure distilled water* might reasonably be regarded as a pollutant. It's not just the toxicity to *us* that matters in these cases; it's the damage to functioning ecosystems. "Pollutant" is a *role* a substance plays in certain circumstances, not a fixed category of substances.
DDT does not function as a pollutant when used in domestic (in-house) applications. Nor is it particularly toxic to humans. Used in agriculture or mosquito control it is a serious pollutant because of an important aspect of the way the DDT molecule interacts with the environment: ecosystems have not evolved to use DDT or any of the substances it breaks down into. So DDT and its by-products accumulate in the environment faster than the environment can transform them into benign substances; fast enough that they bio-accumulate up the food chain. The animals at the apex of the food chain are not at all sensitive to the ambient quantities of DDT byproducts in the environment, but the concentration of those by-products is far higher in the animals they predate upon.
So how does hydrazine stack up? Well, unlike DDT hydrazine *is* created and consumed by natural biological processes -- ubiquitous ones at that. It is produced by yeasts, fungi and bacteria as they digest ammonia. Therefore it is *likely* that the environment can process occasional releases of hydrazine, or even continual releases of a diluted streams of hydrazine. Of course given that hydrazine in modest concentrations is acutely toxic, any process involving it should to be examined closely and designed to be environmentally and occupationally safe. Likewise, the materials from which hydrazine is synthesized have similar properties of being ubiquitous in low levels in natural environmental processes. Some of those materials pose occupational and environmental risks, but only if handled carelessly. With reasonable care, it should be possible to produce and use hydrazine responsibly.
So hydrazine looks potentially quite "green" to me. What we have to be wary of is the possibility of adopting a *pseudo-green* alternative to hydrazine, one that might be less acutely toxic to humans while posing a greater risk of environmental damage.
In fairness to Dr. Monnett's reputation, if you cite the story that he was suspended in July, you should also note that the suspension was lifted several weeks later. Also in the name of fairness you should note that the reason he could not substantiate his observations to the IG's investigators (as reported in the article) is that they'd seized his papers. When those papers were returned the interview notes and other supporting evidence was found in them.
To all appearances this investigation is petering out, if it is not dead already. But let us grant that this is not necessarily the case. If so, *we don't know* the ultimate outcome. But should the investigation ultimately *exonerate* Dr. Monnett and Mr. Gleason, should their work be completely *vindicated*, the damage to their reputation is already done, and through means from which they could not possibly have defended themselves.
You cannot hold up an investigation, especially one with such political implications, as prima facie evidence of guilt. That's just commons sense. It *used* to be called "common decency". Even if the accusations that have been floated are proved true -- an event that seems increasingly unlikely -- the reckless use of the existence of an investigation to sully these men's reputations is repugnant to me. *Anybody* can manufacture an accusation. And any accusation of serious wrongdoing should be investigated. But it is that very necessity which makes the abuse of an investigation's mere *existence* for political ends an intolerable threat to individual liberty.
The loudnesswar has killed virtually anything on a digital medium, resulting in a worse quality masters. Far worse than compressed phonogram recordings in the past.
I recently purchased the MP3 of the original Broadway class album of Hair, which was record on May 6 1968. I could not believe how good these tracks sounded. Dynamic range was a big part of that. It's like we've forgotten that a piece of music can get louder and softer. The vocalists' performances really benefited from having that range to work with.
I wonder whether the reason so many pop songs vocals are so overwrought, but only come out sounding like near-beer blues is that without the dimension of loudness to work with, vocalists have to rely more on ornamental notes or manipulating the timbre of their voice.
I lived through this. Apple got rejected from the enterprise market because (a) they had no interest in competing with cheap commodity hardware and (b) they acted as though they were doing their IT department advocates more than enough favors by letting them buy Apple stuff in the first place. They had an unnerving habit of pulling the rug out from under you too. God help you if you invested Apple's A/UX Unix (which was technically superb).
Apple's "corporate DNA" has always destined it for the consumer market.
As for their networking support, it was superb for the time. The only drawback was the implementation of LocalTalk over RS 422; it was a bus topology like thinnet but slower and without positive locking connectors. You can't compare Apple's built-in networking to Windows 3, because Windows 3 didn't have any. If you compare it to Novell, Novell had better file serving, directory services and scalability. Apple had better practically everything else, including UI (of course), P2P and service discovery.
As for VB, it was a primitive era in 1994 when the patent was filed. VB 3, the first version with the Jet engine, had only come out the year before and VB code monkeys were excited about the datagrid control. In any case you have no idea what I'm talking about. Applescript is an object oriented inter-application communication system. It makes no sense to compare it to VB (you want to look at HyperCard for that); it makes more sense to compare it to something like CORBA or SOAP, only it provided a standard scripting language in addition to a networkable common object model (AppleEvents). On the whole it was very similar to Javascript and DOM, only able to control things other than web browsers.
Don't get me wrong. I'm *not* a fan of Apple the company. I swore I'd never develop for another Apple platform again (although iOS is tempting) because of Apple indifference to developers and enterprise managers. But Apple sure has made some products that were ahead of their time.
When you aren't using your robot, it sits in a packing crate somewhere. When you aren't using your horse, you have to feed him, exercise him, and muck out his stables.
Don't underestimate the difficulty of maintaining a lot of draft animals. Back in the pre-gasoline days forage was a severe limiting factor in maintaining operations. In the New Jersey campaigns 1776-1777, General Howe lost the "hearts and minds" of the American colonists, and thus arguably the war, because of the pressure finding forage put on his forces.
Well, looking at his patent claims, it's a lot more like he's patented the use of something like Applescript to let a browser control an external application. In fact in 1994 this was quite common in the Apple world, Applescript being introduced in 1991. In fact I think quite a few people were viewing medical imagery and multimedia (remember when that was a buzzword?) stored in "databases" like FileMaker and (ugh) 4th Dimension. It was commonplace stuff in the Apple environment while the Microsoft-centric world was still banging the Windows 3 rocks together (remember Windows for Workgroups?).
The web, however, was not commonplace in 1994, so he may well have been the first to file for the use of this technique with a browser. However the technique was so commonplace it would be hard to imagine that it was *original*, especially if he used a browser with the necessary IPC mechanisms built-in. Why else *would* they developers have made an Applescript-aware brower *but* to interact with other programs? If they wrote the browser themselves, then they might have a claim that an IPC-aware browser was a novel thing.
In any case, unless I'm mistaken the patent doesn't describe built-in multi-media capabilities, or multi-media capabilities through plug-ins. It covers controlling an external program with a browser.
I wish this guy success though. As you suggest, this will gore enough oxen that somebody with money will care that the system is broken.
A priori the question might be a lot trickier than you are representing. Given the inherent dangers of the enterprise and the complexity of the system involved, there were probably at any given time some plausibly fatal scenarios. You can't launch a system like that with a standard of "provably safe". If you didn't put a positive face on the data, the system might *never* launch. Arguably a determination to launch in the absence of compelling evidence of likely failure represents an implicit acceptance of risk.
Look at the overall safety record of the Space Shuttle. Would *you* accept a ride into space at those odds? If everyone involved would accept that failure rate rather than have the program scratched, the program was safe enough from a risk/benefit standpoint.
After the fact, shooting the messenger for being right is just plain stupid and irresponsible. It serves no purpose at all.
Stop building narratives like "I'm an X type of guy trying to do Y." That's bound to increase your frustration with what are most likely going to be the normal road bumps in learning to do things differently. Think "different tools and methods for different jobs."
Instead of asking "how do I make working in toy language like Javascript tolerable for *real* programmer like me," you should be asking "how do the very best Javascript programmers do what they do?"
And don't think of yourself as "dyed in the wool" anything. Think of yourself as a versatile person who likes learning about new ways of doing things, because you've got a *lot* more to learn than just the Javascript *language* if you want to actually *use* Javascript. You've got to learn about DOM and CSS and HTTP and web application architecture and security. Once you learn about those things and learn how to actually do something useful with Javascript, you'll be in a much better position to make an *informed* critique the design of the language, popular libraries and frameworks like JQuery, and common Javascript idioms. It makes no sense to approach mastering the whole Javascript ecosystem with preconceived notions about its shortcomings. You aren't qualified to judge yet.
Learning a new kind of tool means learning new kinds of skills and strategies. Some aspects of the tool will seem like major problems with the tool until those good habits become second nature. For example novice Java programmers tend to create code that allocates unnecessary strings inside loops, when they should be using a StringBuilder. The result is the programmer thinks that it's Java that's slow, when it's really their ignorance of efficient Java programming idioms that's to blame.
I have read the patent. It's not long. The only claims that have any possible relevance to the Nest device are pretty much described verbatim in the abstract. Other than that, the claims are commonplace stuff like using gears or belts to drive a potentiometer shaft which encodes the dial's position. That's older than the hills. The patent is padded out somewhat with all the different things you could stick on the stationary part (indicator lights, buzzers, bi-metal thermometers, company logos), but none of that is essential. There's a moving part and a stationary part, and the stationary part may or may not have stuff on it.
What is described in the patent is a user interface in which a digital thermostat mimics the operation of an analog thermostat. In the device as described, the position of a rotating dial on the outside of the chassis set some value. Judging from the pictures the Nest UI doesn't work that way. It is more like a jog-dial in which the direction of motion controls moves the value up and down; the absolute rotation is irrelevant.
The only way to stretch this patent to cover the Nest device would be to grant Honeywell exclusive rights to any UI in which a rotation part encloses a stationary one, regardless of the mechanism or mode of operation. In other words, Honeywell is claiming a patent on a visual design.
And we probably should have some provision for mandatory licensing, if we're going to grant patents like this one:
A thermostat having a thermostat housing and a rotatable selector disposed on the thermostat housing. The rotatable selector adapted to have a range of rotatable positions, where a desired parameter value is identified by the position of the rotatable selector along the range of rotatable positions. The rotatable selector rotates about a rotation axis. A non-rotating member or element, which may at least partially overlap the rotatable selector, may be fixed relative to the thermostat housing via one or more support member(s). The one or more support member(s) may be laterally displaced relative to the rotation axis of the rotatable selector. The non-rotatable member or element may include, for example, a display, a button, an indicator light, a noise making device, a logo, a temperature indicator, and/or any other suitable device or component, as desired.
[US Patent 7159789].
So what is the invention here? A rotating selector that "rotates about a rotation axis?" What else would it rotate about? A rotating selector that can be used to set a desired parameter by rotatable position? How else would a rotating selector be used? A thermostat where the the temperature setting input is "disposed on" the housing?
What they're describing here isn't a mechanism, it's a *design*.
The reason this guy hasn't been able to get a job for several years is that he doesn't want to network.
He's antisocial and he can't get a job? Cry me a river.
I once worked for a well-intentioned liberal boss who was big on diversity. He wanted a distribution of Asians, African-Americans, LGBT people, and ethnicities working for him, but except for me he hired everyone out of the same graduate department at the same university, and everyone (except me) were the children of middle class professional parents.
As for this guy I'm talking about, I think interviewers probably had the same reaction you did -- this guy's anti-social. He's not. He's *differently* social. He maybe isn't so strong on reading body language, but he's very good at *hearing what is actually said*. That'd bring real diversity to a team.
I'm going to give you three compelling reasons why you should at least extend the courtesy of an interview to any highly experienced engineers who apply for a position you're hiring for.
(1) You don't know what the engineer wants. He might not be looking for so much money. And older workers are more stable, saving you the costs of hiring. If he insists on more money than you've budgeted, all you have to do is tell him you aren't going that high and he'll withdraw.
(2) People who can't do the job are never a bargain. Of course you know that. But people who have proven they can do the job are nearly always a bargain. There's an enormous gap between the most capable workers and the average worker, and somebody with a track record is a known quantity.
(3) If the engineer is over forty, and you eliminate him on the basis of his experience, you have just committed a violation of federal law and opened your company up to an expensive discrimination lawsuit. You heard that right, all you white-male victims of reverse discrimination out there: when you hit forty you're officially in a protected class, just like a disabled African-American/Latino married woman veteran.
In fact, roeguard, by discussing your candidate screening philosophy here you've committed an indiscretion. If somebody managed to trace back your Slashdot user name to your identity it could come back to haunt you. It's not likely to happen, but unless you're speaking anonymously there's only one safe thing to say about why you don't hire certain candidates: "We had many outstanding applicants and it was a shame we couldn't interview/hire them all."
I recently met an engineer who developed the architecture and led the design of several widely deployed electronic systems. I don't want to mention the names (so as not to embarrass anyone) but they're systems that generate a quarter billion dollars in revenue annually and which you've almost certainly heard of.
*He* can't get a job, because of his age and (ironically) because his resume is so impressive. People are afraid to hire him.
Now to be fair this guy pretty much radiates "engineer". He comes across as gruff, cynical and impatient, and he dresses a little oddly. He might have some tendency towards Asperger's; he listens intently to what is said but doesn't seem to be aware of body language. But still, even considering that, this shows that the fond belief engineers have that a track record of success will magically open doors for them in their career is baloney. This guy built more than one "better mousetrap", and he can't even get a job interview.
The reason this guy hasn't been able to get a job for several years is that he doesn't want to network. He sees shmoozing as a stupid waste of time, because it's not how *he* would hire someone to do a job. But at his career stage it's the *only* way he'll get another job, because otherwise his resume will only land on the desk of people who see his ability and experience as a threat. He's got to hit the cocktail party circuit -- events where tech entrepreneurs hang out -- because *that's* where he'll find people eager to bring someone like him on board.
Personally, I see no reason why supporting a wider variety of handsets would have anything to do with crashing.
In the desktop OS world, of course, there was the issue of buggy drivers. Neither the OS developer nor the computer's manufacturer had any control over what you stuck in a PCI slot. But you don't have this problem with handsets,where you only plug things in through generic interfaces like Bluetooth. You don't have third party driver writers doing direct memory access, executing invalid or privileged CPU instructions, and all that kind of stuff. So you'd expect a mobile operating systems to be quite stable, unless the handset manufacturer is incompetent. And in general I have found mobile OSs to be extremely stable.
So crashing is more likely to be the fault of programmers, typically making assumptions that the app can always obtain some resource or another. Still, I have found crashes on mobile apps to be less common than on desktop apps, why I don't know for sure. What is a more common with mobile apps is inconsistent responsiveness. That is very annoying, because responsiveness is pretty much the raison d'etre for modern touchscreen interfaces.
Let me summarize more succinctly: people are selfish bastards. Lawyers are merely the instrument with which they make use of the coercive power of the state to act like selfish bastards. Large corporations are like people, but with even fewer scruples and a lot more power and money.
Bad apps crash -- sure. But *worse* apps may appear to keep working while storing up later trouble for the user.
Whenever I see a list of software fault types with "crash bug" at the apex, I cringe. When I led a software team, I had to de-program developers who were trained that crashing is the worst possible thing an app can do. It isn't. There are many worse ones, such as leading a user to trust false data, exposing sensitive information, and losing or corrupting a user's work. The worse thing about a crash in the absence of data loss or long recovery time is that it undermines user confidence. It's often possible for a well-architected app to crash (due to programming faults of course) with no serious implications for the user.
Crashing per se isn't a problem. It's a *symptom*. This is important! I've caught developers "fixing crash bugs" without addressing the real problems: failure to program defensively around unexpected conditions like bad input or inability to secure resources like memory or file references. I've seen super-general exception handlers buried way down on the stack which catch every possible exception and quietly attempt to restore the semblance of operation, even though they can't possibly know whether the application is in a consistent state, or whether it is holding orphaned resources. Programmers do this because they've been inculcated with the false notion that crashes per se are terrible things. This leads to hiding the symptoms errors rather than fixing the errors themselves. Hiding the cause of a crash increases the probability of faulty information, loss of data, and shipping a release with serious defects.
So don't treat crashing as a problem, but as an alert signal. A crash in itself is benign, an honest recognition of failure if you will.
Sure. Cheapness, reliability, serviceability, *plus a willingness to take casualties* is a hard combination to beat.
Anyhow, the Indian choice of the Dassault sounds like a smart move to me. You have to look at who they're up against. If the cheaper aircraft is superior to anything the PAF has, why gild the lily with a more expensive, harder to maintain one? India might reasonably be concerned with serviceability and reliability of bleeding edge technologies in the F-35 they don't really need to win a war with Pakistan. Since they're looking for a multi-role aircraft, being able to keep more aircraft ready to fly would have a big impact on every aspect of a war.
I suspect that the bit about not trusting the US was an afterthought. If the IAF thought the F-35 had capabilities they actually needed to win a war against Pakistan, that surely would have outweighed any concern about the US withholding parts. That the choice reminds everyone India isn't a US client state is just a political bonus.
Well, we're talking past each other. I was responding to the lack of epistemological justification in drawing broad and overarching inferences about societies from events like mob looting. I just don't think you can draw the conclusion that if looting happens in event a of Culture A, but not in event b of Culture B, that it's automatically because the people in Culture B are virtuous and those in A are not. I certainly don't think you can impute an opinion to *everyone* in a society from the actions of a few.
I agree personal responsibility is important, but I have less faith in it than you do. As far as bushido is concerned -- beware of anyone's depiction of their personal value and virtuousness. Especially anyone who rules by force. There are always exceptional individuals who step up and embody the ideals of their society, but it's far more common for people to adopt the image and not change their behavior very much.
See my other post for at least one citation. I could find others, but I think we should characterize the degree of our disagreement first.
I agree that social norms played a part in containing looting after the tsunami in Japan. I agree that social deviancy probably played a part in initiation of looting -- it's probably always a contributing factor. I agree that urgent necessity also initiated some looting. And I agree that major looting events did not nucleate around these occurrences. Where I disagree is with the idea that individual Japanese people are somehow culturally inoculated against mob behavior per se. If you look at earlier periods of Japanese history you see that Japanese people are capable of all the good and ill that the rest of humanity is.
It is respect for and confidence in local authorities that seems to be the biggest factor in how quickly mobs form and how soon they go out of control. So one naturally expects looting to be more likely when an oppressive regime is overthrown by an alien power than when a natural disaster strikes an economically advanced democracy. Belief in authority can certainly be culturally inculcated, but there are limits.
So I'd say that Japan is culturally resistant to the *formation* of mobs, and that relatively prosperous, stable democracies are in general poor incubators of mobs.
Now let's circle back the argument I am trying to make here: You can't draw broad inferences about the values and attitudes of entire societies from the behavior of mobs. The one conclusion you can draw is that for a certain segment of that society, trust and respect for authority has broken down.
That's about the shape of it. The anthropologist I was talking about described people who didn't have electricity in their neighborhoods returning electric appliances they'd looted. Obviously they had no intention of *using them*. As for *selling them*, the fact they risked being arrested by returning goods voluntarily suggests an unusual degree of honesty. But if they were honest folk, why did they loot in the first place?
They looted because *honesty* is a rational value, and they weren't acting rationally.
I'm not suggesting all looters everywhere are just good people in bad circumstances. I'm just saying you shouldn't overestimate the rationality of people in a mob, or ascribe the mob's behavior exclusively to the values of the surrounding culture, or even the individual members.
Slashdot Mirror
... is not obligated to supply phenomena that fit neatly into our preconceived ontological categories.
It is quite possible that any possible definition of life either includes things we don't think of as "alive" or excludes things we do.
If it's not repeatable and reproducible, is it really testing? Or is it *critique*?
It seems to me there are two kinds of testing. On one hand there are the many variants of smoke testing ("plug it in and see if smoke comes out"). On the other hand, there is the kind of testing that involves carrying out a plan where each step has success and failure criteria that have to be checked off in order for the software to pass.
Developers can't smoke test their own work effectively because of the human cognitive bias toward seeing the expected result. They could probably execute a well-designed test plan, although you'd still prefer someone more independent. As for designing the test plan itself, if you've ever tried to write a comprehensive test plan, it's a big, mind-numbing job.
I believe that in an ideal world the foundation of the test plan would be laid when the system is conceived (non-functional requirements, use-cases).Naturally you'd stipulate that the acceptance test for each task in a use case be performed a representative user under representative conditions. You wouldn't have a web form designer do that test because he knows where all the necessary widgets are tucked away. And throughout the planning, design and implementation of the system, before you started to do *anything* you'd devise a test for success.
But I happen know that in the real world that most people only start thinking about testing as the delivery date approaches -- at least until they've got burned.
Also, note that just because one particular non-extended-range electric vehicle does not meet your particular driving requirements does not mean it is a useless endeavour, or even that it will fail in market at all.
I'll add another point: most households have more than one car, and very few ever face situation where two family members have to take *different* 300+ mile trips on the same day.
So if electric has any advantages at all in day to day driving, then one electric and one ICE car in a two-car family is for all practical purposes just as versatile as two ICE cars. Sure, once in a blue moon you'll want two ICE cars. But *more* than once in a blue moon one of those ICE cars will in the shop having it's complicated and temperamental engine, transmission or exhaust system repaired.
It's probable that most two car houses with one ICE car and one EV with at least a 200 mile range have no cause to feel range anxiety.
Well, at least they grant *you* the dignity of a stereotype. I'm from Massachusetts. When Republicans bash us,they just say our name in a funny, nasal voice, as if people are supposed to know why. It's like they can't even be bothered to try.
So if you want bash MA, let me show you how to do it:: "People from Massachusetts are like America's version of the French. They think they're better than everybody, but nobody else can see why."
See that you guys? You want to insinuate (suggest without actually coming out and saying it) that Bay Staters are patronizing (PAY-TRUH-NEYE-ZING).
I don't think so. I especially DON'T think that "green" means "non-toxic to humans who handle it carelessly".
It seems to me that a "green" anything is something whose production, use, and disposal does not use up environmental capital faster than the biosphere replaces it. Alternatively, you can think of it as something whose entire life-cycle, cradle to grave, does not disturb any environmental equilibria except possibly on a highly localized scale (i.e. the footprint of the production facility).
Perhaps the best way to think of green technology is that it contributes to our species' ability to live within its means. That means natural resources, not dollars. Nature doesn't care how we shift dollars around; that's really just an internal control mechanism. It does "care" if we take fish out of the sea faster than they can reproduce, or if we discharge substances into a river faster than the natural processes can absorb and use them. The substances in question might well be "natural" materials like sewage. Discharged into a creek fast enough to alter that stream's chemistry, even *pure distilled water* might reasonably be regarded as a pollutant. It's not just the toxicity to *us* that matters in these cases; it's the damage to functioning ecosystems. "Pollutant" is a *role* a substance plays in certain circumstances, not a fixed category of substances.
DDT does not function as a pollutant when used in domestic (in-house) applications. Nor is it particularly toxic to humans. Used in agriculture or mosquito control it is a serious pollutant because of an important aspect of the way the DDT molecule interacts with the environment: ecosystems have not evolved to use DDT or any of the substances it breaks down into. So DDT and its by-products accumulate in the environment faster than the environment can transform them into benign substances; fast enough that they bio-accumulate up the food chain. The animals at the apex of the food chain are not at all sensitive to the ambient quantities of DDT byproducts in the environment, but the concentration of those by-products is far higher in the animals they predate upon.
So how does hydrazine stack up? Well, unlike DDT hydrazine *is* created and consumed by natural biological processes -- ubiquitous ones at that. It is produced by yeasts, fungi and bacteria as they digest ammonia. Therefore it is *likely* that the environment can process occasional releases of hydrazine, or even continual releases of a diluted streams of hydrazine. Of course given that hydrazine in modest concentrations is acutely toxic, any process involving it should to be examined closely and designed to be environmentally and occupationally safe. Likewise, the materials from which hydrazine is synthesized have similar properties of being ubiquitous in low levels in natural environmental processes. Some of those materials pose occupational and environmental risks, but only if handled carelessly. With reasonable care, it should be possible to produce and use hydrazine responsibly.
So hydrazine looks potentially quite "green" to me. What we have to be wary of is the possibility of adopting a *pseudo-green* alternative to hydrazine, one that might be less acutely toxic to humans while posing a greater risk of environmental damage.
In fairness to Dr. Monnett's reputation, if you cite the story that he was suspended in July, you should also note that the suspension was lifted several weeks later. Also in the name of fairness you should note that the reason he could not substantiate his observations to the IG's investigators (as reported in the article) is that they'd seized his papers. When those papers were returned the interview notes and other supporting evidence was found in them.
To all appearances this investigation is petering out, if it is not dead already. But let us grant that this is not necessarily the case. If so, *we don't know* the ultimate outcome. But should the investigation ultimately *exonerate* Dr. Monnett and Mr. Gleason, should their work be completely *vindicated*, the damage to their reputation is already done, and through means from which they could not possibly have defended themselves.
You cannot hold up an investigation, especially one with such political implications, as prima facie evidence of guilt. That's just commons sense. It *used* to be called "common decency". Even if the accusations that have been floated are proved true -- an event that seems increasingly unlikely -- the reckless use of the existence of an investigation to sully these men's reputations is repugnant to me. *Anybody* can manufacture an accusation. And any accusation of serious wrongdoing should be investigated. But it is that very necessity which makes the abuse of an investigation's mere *existence* for political ends an intolerable threat to individual liberty.
The loudnesswar has killed virtually anything on a digital medium, resulting in a worse quality masters. Far worse than compressed phonogram recordings in the past.
I recently purchased the MP3 of the original Broadway class album of Hair, which was record on May 6 1968. I could not believe how good these tracks sounded. Dynamic range was a big part of that. It's like we've forgotten that a piece of music can get louder and softer. The vocalists' performances really benefited from having that range to work with.
I wonder whether the reason so many pop songs vocals are so overwrought, but only come out sounding like near-beer blues is that without the dimension of loudness to work with, vocalists have to rely more on ornamental notes or manipulating the timbre of their voice.
I lived through this. Apple got rejected from the enterprise market because (a) they had no interest in competing with cheap commodity hardware and (b) they acted as though they were doing their IT department advocates more than enough favors by letting them buy Apple stuff in the first place. They had an unnerving habit of pulling the rug out from under you too. God help you if you invested Apple's A/UX Unix (which was technically superb).
Apple's "corporate DNA" has always destined it for the consumer market.
As for their networking support, it was superb for the time. The only drawback was the implementation of LocalTalk over RS 422; it was a bus topology like thinnet but slower and without positive locking connectors. You can't compare Apple's built-in networking to Windows 3, because Windows 3 didn't have any. If you compare it to Novell, Novell had better file serving, directory services and scalability. Apple had better practically everything else, including UI (of course), P2P and service discovery.
As for VB, it was a primitive era in 1994 when the patent was filed. VB 3, the first version with the Jet engine, had only come out the year before and VB code monkeys were excited about the datagrid control. In any case you have no idea what I'm talking about. Applescript is an object oriented inter-application communication system. It makes no sense to compare it to VB (you want to look at HyperCard for that); it makes more sense to compare it to something like CORBA or SOAP, only it provided a standard scripting language in addition to a networkable common object model (AppleEvents). On the whole it was very similar to Javascript and DOM, only able to control things other than web browsers.
Don't get me wrong. I'm *not* a fan of Apple the company. I swore I'd never develop for another Apple platform again (although iOS is tempting) because of Apple indifference to developers and enterprise managers. But Apple sure has made some products that were ahead of their time.
Especially in this case, where the "Post MegaUpload Era" isn't even three weeks old.
That's almost five months in dog years.
When you aren't using your robot, it sits in a packing crate somewhere. When you aren't using your horse, you have to feed him, exercise him, and muck out his stables.
Don't underestimate the difficulty of maintaining a lot of draft animals. Back in the pre-gasoline days forage was a severe limiting factor in maintaining operations. In the New Jersey campaigns 1776-1777, General Howe lost the "hearts and minds" of the American colonists, and thus arguably the war, because of the pressure finding forage put on his forces.
Well, looking at his patent claims, it's a lot more like he's patented the use of something like Applescript to let a browser control an external application. In fact in 1994 this was quite common in the Apple world, Applescript being introduced in 1991. In fact I think quite a few people were viewing medical imagery and multimedia (remember when that was a buzzword?) stored in "databases" like FileMaker and (ugh) 4th Dimension. It was commonplace stuff in the Apple environment while the Microsoft-centric world was still banging the Windows 3 rocks together (remember Windows for Workgroups?).
The web, however, was not commonplace in 1994, so he may well have been the first to file for the use of this technique with a browser. However the technique was so commonplace it would be hard to imagine that it was *original*, especially if he used a browser with the necessary IPC mechanisms built-in. Why else *would* they developers have made an Applescript-aware brower *but* to interact with other programs? If they wrote the browser themselves, then they might have a claim that an IPC-aware browser was a novel thing.
In any case, unless I'm mistaken the patent doesn't describe built-in multi-media capabilities, or multi-media capabilities through plug-ins. It covers controlling an external program with a browser.
I wish this guy success though. As you suggest, this will gore enough oxen that somebody with money will care that the system is broken.
A priori the question might be a lot trickier than you are representing. Given the inherent dangers of the enterprise and the complexity of the system involved, there were probably at any given time some plausibly fatal scenarios. You can't launch a system like that with a standard of "provably safe". If you didn't put a positive face on the data, the system might *never* launch. Arguably a determination to launch in the absence of compelling evidence of likely failure represents an implicit acceptance of risk.
Look at the overall safety record of the Space Shuttle. Would *you* accept a ride into space at those odds? If everyone involved would accept that failure rate rather than have the program scratched, the program was safe enough from a risk/benefit standpoint.
After the fact, shooting the messenger for being right is just plain stupid and irresponsible. It serves no purpose at all.
Stop building narratives like "I'm an X type of guy trying to do Y." That's bound to increase your frustration with what are most likely going to be the normal road bumps in learning to do things differently. Think "different tools and methods for different jobs."
Instead of asking "how do I make working in toy language like Javascript tolerable for *real* programmer like me," you should be asking "how do the very best Javascript programmers do what they do?"
And don't think of yourself as "dyed in the wool" anything. Think of yourself as a versatile person who likes learning about new ways of doing things, because you've got a *lot* more to learn than just the Javascript *language* if you want to actually *use* Javascript. You've got to learn about DOM and CSS and HTTP and web application architecture and security. Once you learn about those things and learn how to actually do something useful with Javascript, you'll be in a much better position to make an *informed* critique the design of the language, popular libraries and frameworks like JQuery, and common Javascript idioms. It makes no sense to approach mastering the whole Javascript ecosystem with preconceived notions about its shortcomings. You aren't qualified to judge yet.
Learning a new kind of tool means learning new kinds of skills and strategies. Some aspects of the tool will seem like major problems with the tool until those good habits become second nature. For example novice Java programmers tend to create code that allocates unnecessary strings inside loops, when they should be using a StringBuilder. The result is the programmer thinks that it's Java that's slow, when it's really their ignorance of efficient Java programming idioms that's to blame.
I have read the patent. It's not long. The only claims that have any possible relevance to the Nest device are pretty much described verbatim in the abstract. Other than that, the claims are commonplace stuff like using gears or belts to drive a potentiometer shaft which encodes the dial's position. That's older than the hills. The patent is padded out somewhat with all the different things you could stick on the stationary part (indicator lights, buzzers, bi-metal thermometers, company logos), but none of that is essential. There's a moving part and a stationary part, and the stationary part may or may not have stuff on it.
What is described in the patent is a user interface in which a digital thermostat mimics the operation of an analog thermostat. In the device as described, the position of a rotating dial on the outside of the chassis set some value. Judging from the pictures the Nest UI doesn't work that way. It is more like a jog-dial in which the direction of motion controls moves the value up and down; the absolute rotation is irrelevant.
The only way to stretch this patent to cover the Nest device would be to grant Honeywell exclusive rights to any UI in which a rotation part encloses a stationary one, regardless of the mechanism or mode of operation. In other words, Honeywell is claiming a patent on a visual design.
And we probably should have some provision for mandatory licensing, if we're going to grant patents like this one:
A thermostat having a thermostat housing and a rotatable selector disposed on the thermostat housing. The rotatable selector adapted to have a range of rotatable positions, where a desired parameter value is identified by the position of the rotatable selector along the range of rotatable positions. The rotatable selector rotates about a rotation axis. A non-rotating member or element, which may at least partially overlap the rotatable selector, may be fixed relative to the thermostat housing via one or more support member(s). The one or more support member(s) may be laterally displaced relative to the rotation axis of the rotatable selector. The non-rotatable member or element may include, for example, a display, a button, an indicator light, a noise making device, a logo, a temperature indicator, and/or any other suitable device or component, as desired.
[US Patent 7159789].
So what is the invention here? A rotating selector that "rotates about a rotation axis?" What else would it rotate about? A rotating selector that can be used to set a desired parameter by rotatable position? How else would a rotating selector be used? A thermostat where the the temperature setting input is "disposed on" the housing?
What they're describing here isn't a mechanism, it's a *design*.
The reason this guy hasn't been able to get a job for several years is that he doesn't want to network.
He's antisocial and he can't get a job? Cry me a river.
I once worked for a well-intentioned liberal boss who was big on diversity. He wanted a distribution of Asians, African-Americans, LGBT people, and ethnicities working for him, but except for me he hired everyone out of the same graduate department at the same university, and everyone (except me) were the children of middle class professional parents.
As for this guy I'm talking about, I think interviewers probably had the same reaction you did -- this guy's anti-social. He's not. He's *differently* social. He maybe isn't so strong on reading body language, but he's very good at *hearing what is actually said*. That'd bring real diversity to a team.
I'm going to give you three compelling reasons why you should at least extend the courtesy of an interview to any highly experienced engineers who apply for a position you're hiring for.
(1) You don't know what the engineer wants. He might not be looking for so much money. And older workers are more stable, saving you the costs of hiring. If he insists on more money than you've budgeted, all you have to do is tell him you aren't going that high and he'll withdraw.
(2) People who can't do the job are never a bargain. Of course you know that. But people who have proven they can do the job are nearly always a bargain. There's an enormous gap between the most capable workers and the average worker, and somebody with a track record is a known quantity.
(3) If the engineer is over forty, and you eliminate him on the basis of his experience, you have just committed a violation of federal law and opened your company up to an expensive discrimination lawsuit. You heard that right, all you white-male victims of reverse discrimination out there: when you hit forty you're officially in a protected class, just like a disabled African-American/Latino married woman veteran.
In fact, roeguard, by discussing your candidate screening philosophy here you've committed an indiscretion. If somebody managed to trace back your Slashdot user name to your identity it could come back to haunt you. It's not likely to happen, but unless you're speaking anonymously there's only one safe thing to say about why you don't hire certain candidates: "We had many outstanding applicants and it was a shame we couldn't interview/hire them all."
I recently met an engineer who developed the architecture and led the design of several widely deployed electronic systems. I don't want to mention the names (so as not to embarrass anyone) but they're systems that generate a quarter billion dollars in revenue annually and which you've almost certainly heard of.
*He* can't get a job, because of his age and (ironically) because his resume is so impressive. People are afraid to hire him.
Now to be fair this guy pretty much radiates "engineer". He comes across as gruff, cynical and impatient, and he dresses a little oddly. He might have some tendency towards Asperger's; he listens intently to what is said but doesn't seem to be aware of body language. But still, even considering that, this shows that the fond belief engineers have that a track record of success will magically open doors for them in their career is baloney. This guy built more than one "better mousetrap", and he can't even get a job interview.
The reason this guy hasn't been able to get a job for several years is that he doesn't want to network. He sees shmoozing as a stupid waste of time, because it's not how *he* would hire someone to do a job. But at his career stage it's the *only* way he'll get another job, because otherwise his resume will only land on the desk of people who see his ability and experience as a threat. He's got to hit the cocktail party circuit -- events where tech entrepreneurs hang out -- because *that's* where he'll find people eager to bring someone like him on board.
Personally, I see no reason why supporting a wider variety of handsets would have anything to do with crashing.
In the desktop OS world, of course, there was the issue of buggy drivers. Neither the OS developer nor the computer's manufacturer had any control over what you stuck in a PCI slot. But you don't have this problem with handsets,where you only plug things in through generic interfaces like Bluetooth. You don't have third party driver writers doing direct memory access, executing invalid or privileged CPU instructions, and all that kind of stuff. So you'd expect a mobile operating systems to be quite stable, unless the handset manufacturer is incompetent. And in general I have found mobile OSs to be extremely stable.
So crashing is more likely to be the fault of programmers, typically making assumptions that the app can always obtain some resource or another. Still, I have found crashes on mobile apps to be less common than on desktop apps, why I don't know for sure. What is a more common with mobile apps is inconsistent responsiveness. That is very annoying, because responsiveness is pretty much the raison d'etre for modern touchscreen interfaces.
Let me summarise as simply as possible:
Let me summarize more succinctly: people are selfish bastards. Lawyers are merely the instrument with which they make use of the coercive power of the state to act like selfish bastards. Large corporations are like people, but with even fewer scruples and a lot more power and money.
Bad apps crash -- sure. But *worse* apps may appear to keep working while storing up later trouble for the user.
Whenever I see a list of software fault types with "crash bug" at the apex, I cringe. When I led a software team, I had to de-program developers who were trained that crashing is the worst possible thing an app can do. It isn't. There are many worse ones, such as leading a user to trust false data, exposing sensitive information, and losing or corrupting a user's work. The worse thing about a crash in the absence of data loss or long recovery time is that it undermines user confidence. It's often possible for a well-architected app to crash (due to programming faults of course) with no serious implications for the user.
Crashing per se isn't a problem. It's a *symptom*. This is important! I've caught developers "fixing crash bugs" without addressing the real problems: failure to program defensively around unexpected conditions like bad input or inability to secure resources like memory or file references. I've seen super-general exception handlers buried way down on the stack which catch every possible exception and quietly attempt to restore the semblance of operation, even though they can't possibly know whether the application is in a consistent state, or whether it is holding orphaned resources. Programmers do this because they've been inculcated with the false notion that crashes per se are terrible things. This leads to hiding the symptoms errors rather than fixing the errors themselves. Hiding the cause of a crash increases the probability of faulty information, loss of data, and shipping a release with serious defects.
So don't treat crashing as a problem, but as an alert signal. A crash in itself is benign, an honest recognition of failure if you will.
Sure. Cheapness, reliability, serviceability, *plus a willingness to take casualties* is a hard combination to beat.
Anyhow, the Indian choice of the Dassault sounds like a smart move to me. You have to look at who they're up against. If the cheaper aircraft is superior to anything the PAF has, why gild the lily with a more expensive, harder to maintain one? India might reasonably be concerned with serviceability and reliability of bleeding edge technologies in the F-35 they don't really need to win a war with Pakistan. Since they're looking for a multi-role aircraft, being able to keep more aircraft ready to fly would have a big impact on every aspect of a war.
I suspect that the bit about not trusting the US was an afterthought. If the IAF thought the F-35 had capabilities they actually needed to win a war against Pakistan, that surely would have outweighed any concern about the US withholding parts. That the choice reminds everyone India isn't a US client state is just a political bonus.
Well, we're talking past each other. I was responding to the lack of epistemological justification in drawing broad and overarching inferences about societies from events like mob looting. I just don't think you can draw the conclusion that if looting happens in event a of Culture A, but not in event b of Culture B, that it's automatically because the people in Culture B are virtuous and those in A are not. I certainly don't think you can impute an opinion to *everyone* in a society from the actions of a few.
I agree personal responsibility is important, but I have less faith in it than you do. As far as bushido is concerned -- beware of anyone's depiction of their personal value and virtuousness. Especially anyone who rules by force. There are always exceptional individuals who step up and embody the ideals of their society, but it's far more common for people to adopt the image and not change their behavior very much.
See my other post for at least one citation. I could find others, but I think we should characterize the degree of our disagreement first.
I agree that social norms played a part in containing looting after the tsunami in Japan. I agree that social deviancy probably played a part in initiation of looting -- it's probably always a contributing factor. I agree that urgent necessity also initiated some looting. And I agree that major looting events did not nucleate around these occurrences. Where I disagree is with the idea that individual Japanese people are somehow culturally inoculated against mob behavior per se. If you look at earlier periods of Japanese history you see that Japanese people are capable of all the good and ill that the rest of humanity is.
It is respect for and confidence in local authorities that seems to be the biggest factor in how quickly mobs form and how soon they go out of control. So one naturally expects looting to be more likely when an oppressive regime is overthrown by an alien power than when a natural disaster strikes an economically advanced democracy. Belief in authority can certainly be culturally inculcated, but there are limits.
So I'd say that Japan is culturally resistant to the *formation* of mobs, and that relatively prosperous, stable democracies are in general poor incubators of mobs.
Now let's circle back the argument I am trying to make here: You can't draw broad inferences about the values and attitudes of entire societies from the behavior of mobs. The one conclusion you can draw is that for a certain segment of that society, trust and respect for authority has broken down.
That's about the shape of it. The anthropologist I was talking about described people who didn't have electricity in their neighborhoods returning electric appliances they'd looted. Obviously they had no intention of *using them*. As for *selling them*, the fact they risked being arrested by returning goods voluntarily suggests an unusual degree of honesty. But if they were honest folk, why did they loot in the first place?
They looted because *honesty* is a rational value, and they weren't acting rationally.
I'm not suggesting all looters everywhere are just good people in bad circumstances. I'm just saying you shouldn't overestimate the rationality of people in a mob, or ascribe the mob's behavior exclusively to the values of the surrounding culture, or even the individual members.