Interesting. Having just gotten in iPhone (after 4 years of WM devices), I didn't realize I wasn't multi-tasking. When I switched to another program, and then, back I was right where I was.
Many well-designed iPhone apps do a good job of saving and restoring state when you switch away, which isn't anything like multitasking, its just, well, intelligently designed save and restore. Also, some of Apples bundled apps -- the iPod app notably -- can be run in the background (the iPhone multitasks just fine, its just one of many features that Apple doesn't allow third-party apps to use.)
The constant need to apply temporary fixes that end up becoming permanent are fast pushing many IT infrastructures beyond repair. Much of the blame falls on the products IT has to deal with.
Well, sure, IT departments place the blame there. The problem, though, is not so much with the products that IT "has to deal with" as with the fact that IT departments either actively choose the penny-wise-but-pount-foolish course of action of applying band-aids rather than dealing with problems properly in the first place, or because -- when the decision is not theirs -- they simply fail to properly advise the units that are making decisions of the cost and consequence of such a short-sighted approach.
When IT units don't take responsibility for assuring the quality of the IT infrastructure, surprisingly enough, the IT infrastructure, over time, becomes an unstable house of cards, with the IT unit pointing fingers everywhere else.
And yet breaking this 'vicious cycle of bad ideas and worse implementations' by wiping the slate clean is no easy task. Especially when the need for kludges isn't apparent until the software is in the process of being implemented. 'Generally it's too late to change course at that point.'
If your process -- whether its for development or procurement -- doesn't discover holes before it is too late to do anything but apply "temporary" workarounds, then your process is broken, and you need to fix it so you catch problems when you can more effectively address them.
If your process leaves those interim workarounds fixes in place once they are established without initiating and following through on a permanent resolution, then, again, your process is broken and needs fixed.
You don't fix the problems with your infrastructure that have resulted from your broken processes by "wiping the slate clean" on your infrastructure and starting over. You fix the problems by, first, improving your processes so your attempts to address the holes you've built into your infrastructure don't create two more holes for every one you fix, then by attacking the holes themselves.
If you try to through the whole thing out because its junk -- blaming the situation on the environment and the infrastructure without addressing your process -- then:
(a) you'll waste time redoing work that has already been done, and (b) you'll probably make just as many mistakes rebuilding the infrastructure from scratch as you made building it the first time, whether they are the same or different mistakes.
Magical thinking like "wipe the slate clean" doesn't fix problems. Problems are fixed by identifying them and attacking them directly.
Do the companies really think there's that much value in having so many channels?
No, they think there is value in having exactly the channels you want, and virtually no cost in having extra channels. For a few well defined interest groups with large customer basis, they can do that fairly well without lots of extra channels (where "exactly the channels you want" are "every sports channel imaginable" or "every Spanish-language channel imaginable"), for everyone else -- since its simpler to have standardized packages -- its easier to just rely on bigger bundles.
A reason that copyright extends past death is to discourage murder to get access to copyrighted material.
Since the date is controlled by death, murder still gets access to the material sooner, while a simple fixed term -- which is what existed before the "life plus X" -- model neatly avoids any incentive to murder.
Its more plausible to say that "a transparently false justification for a substantial fixed term beyond the death of the author is to reduce the incentive to murder an author to get access to the copyrighted material."
The rest of the world also has devices that work for them and does what they want their phones to do.
For a large majority of people, that device is the iPhone.
Only if you take a rather...interesting...view of what constitutes a "majority", much less a "large majority". iPhone is #3 globally in the smartphone market, and #3 in the US, as well. Globally, Symbian is way ahead of everyone, RIM is next, and iPhone is close behind RIM; in the US, RIM is ahead, Android is #2, and iPhone is #3.
Just in a related note, if I fail to show up for a doctor or dentist appointment there is Always a charge and has been for some time
That's because the doctor makes you agree to that term before they agree to enter into a business relationship with you.
If you have failed to exercise your option to refuse to enter into a business arrangement when the terms are unsuitable, the corrective measure is to terminate the unsatisfactory business arrangement. Cable TV is hardly a life necessity, and -- monopoly or not -- cable TV companies can hardly make a profit if consumers simply decide that the service provided isn't worth the hastle.
Hence, the cable exodus being discussed in this thread.
I used to work for a cable company (a major one, I might add), and I had that unfortunate conversation with lots of customers.
What's ironic is that this usually took place in areas where the company I worked for used some local contractors. In areas where the company hired directly, I only heard praise of the technicians, and their punctuality.
Supposedly it's supposed to be better for businesses to hire locally, but from my experience, the local contractors were lazy fucktards.
Hiring directly in the area and hiring local contractors in the area are both "hiring locally".
If the company's oversight of its contractors is less effective than its oversight of its employees, then it should be expected that places where it relies on contractors will be less well served than places where it relies on employees to perform similar work. I suspect that this -- differences in degree of accountability -- is more the problem than local contractors being lazier than anyone else.
This is complete and utter BS and really needs to be stopped. My suggestion - if they fail to show in the required window, for Any reason, they are liable to you for a days pay at whatever your current rate is.
Well, that's not something you can implement yourself, nor is it necessary. Just simply adopt this rule:
If they fail to show up in the agreed window, for any reason, call and cancel your service, and explain the reason.
Neither of those (changes in platform paradigm or changes in programming language/style) typically requires a big-bang rewrite, and if it is avoidable, you are usually better off doing incremental rewrites than big-bang, particularly in critical production systems. For instance, on any multitier networked application, a paradigm shift for the backend implementation can usually be handled piecemeal by putting the old-style implementation behind a facade using the new paradigm, which proxies to the old implementation for the functions that have not been reimplemented.
Piecemeal replacement for programming language changes is, of course, even more obvious how to do.
Joel's position contradicts a paper I read years ago in an IEEE software journal that basically said you needed to plan on rewriting your application about every 7 years or have it collapse on you.
Does it, though? You can completely replace a system every seven years without ever replacing the whole system from scratch if you are doing fairly frequent replacement of components. "You shouldn't ever replace a system all at once" and "you should plan to completely replace a system every 7 years" aren't contradictory positions.
There's no reason for a browser to throw up nasty error dialogs when it encounters a self-signed certificate.
Yes, there is. The entire point of signing certificates is that they provide a chain of certification back to something you have chosen to trust (the CA model has problems in really providing this, too, but that's the theory.) A certificate provided in-band that isn't signed by a trusted entity from whom you have received a certificate by reliable means out-of-band with the immediate communication doesn't provide authentication, and encryption without authentication is meaningless.
You ought to be able to import trusted-but-unsigned certificates yourself, but the UI or it really needs to not encourage them being first transferred with a page that they are being used to sign. The only way such certs are useful is if they are exchanged out-of-band through a trusted channel (face-to-face, for instance) that allows the relying user to verify identity without relying on a trusted third party.
It means MITM attacks are more unlikely, but your data is still in Google's hand.
Well, yeah, the queries you actively send to Google are in Google's hands.
The privacy benefit is directly linked to the security benefit, in that people other than the one to whom you are choosing to give your data to provide you with a service don't have quite as easy access to it in transit.
Privacy doesn't mean no one has your information, it means that only the people you choose to give your information to have it.
The link to WUBI is is somewhat inappropriate: WUBI is an installer that installs Linux in a file hosted on a Windows filesystem using something that works as a Windows installer (and creating a Windows uninstaller for the Linux installation.) But it doesn't run Linux under Windows.
So if you want a Linux under Windows distribution to talk about running under WINE what you really want is more Portable Ubuntu Remix, not WUBI.
Are you kidding me? They have MS style weight in the web market.
No, they don't. In the thing they dominate -- online searches (which isn't a market, because its not something that is sold) -- their share, while substantial at ~70%, isn't as great as Microsoft's desktop OS share (which is a market).
As far as markets, they have a majority of search advertising (but, again, substantially less than Microsoft has very desktop OSes), a large minority of online advertising, a large minority of mobile advertising, and a tiny fraction of total advertising. I think there is a good case to be made that different advertising forms are true substitutes and that the relevant market from an antitrust perspective is total advertising, but even if its not, there is no market they dominate in anything like the way Microsoft dominates the desktop OS or Office Suite markets.
It seems to me, though, that there is no merger/acquisition that the government won't approve if it's Google.
There are very few mergers/acquisitions that the government even investigates for antitrust concerns, no matter who is involved, and even fewer that they reject.
So Google's not at all special in that regard.
Almost the complete opposite of MS.
How so? Microsoft buys companies all the time without the government blocking them.
You're a level of indirection down from what I was talking about. I was referring not to the REST API (which is indeed a nice one, though isn't initial uploading -i.e. resource creation- supposed to be handled through POST, not PUT?)
Not necessarily. There's a temptation to view the GET/PUT/POST/DELETE set of HTTP verbs as having a 1:1 mapping to CRUD actions, but they really don't. GET and DELETE in HTTP do map cleanly to READ and DELETE in CRUD, but PUT really is the equivalent of either a CREATE or a replacing UPDATE on a particular named resource, while POST is a special kind of create (creating a new resource subordinate to a named collection resource which will determine the name of the newly created resource.)
If you are creating a new resource whose intended name (URL) you know, PUT makes sense. If you are creating a new resource and don't care about its name, just that it is a child of a particular collection resource, POST makes sense.
The space shuttle isn't a current electric vehicle offering from Tesla.
A story about Tesla, an electric vehicle manufacturer, announcing plans to build a "more affordable" electric vehicle has a pretty clear comparison communicated in it.
the ironic thing is this is all a matter of how people feel about a given company. if it was Ballmer who said this about a new microsoft product, or Jobs about a new apple product, with a laughably inflated idea of "affordable", people would be all over it.
No, its really about people's ability to understand English, not their feelings about a company. I'm mostly neutral on Tesla -- even the Model S is out of the range that I am interested in, the Nissan LEAF is much more interesting, though the development partnership Tesla announced with Toyota might yield interesting fruit.
OTOH, I recognize that there is a difference between saying something is "more affordable" (which is always a comparison to something else) and saying that it is "affordable", and something need not be "affordable" by any reasonable absolute standard to be "more affordable" than the particular thing that it is being compared to.
While the blurb is -technically- refering to the cost of tesla's previous product, by referencing the current state of the economy it is infering that this product is a good fit for people with reduced financial means
Which it may well be, especially if those people with "reduced financial means" would have been in the market for a Tesla Roadster before those means were reduced.
"Reduced" doesn't say anything about what something was reduced from. Nothing in the blurb suggests that the Model S is priced in a way that makes it accessible to the average purchaser, only that it is within the range of far more people than the Roadster.
The only nonintuitive thing is the name "bucket", which might be better called "zone" or "filesystem".
It might be better to call it "bucket", if one of your biggest target audiences was, say, developers already using and familiar with Amazon S3, a popular existing service in the same space that calls the same thing a "bucket" rather than a "zone" or "filesystem".
In the really real world, 1.8 TDI Golfs get better mileage than any Prius.
If you used the same kind of engine and drive system on a Golf-sized vehicle and a Prius-sized vehicle (whether both TDI or both hybrid), with similar performance, you'd expect the Golf sized vehicle to get better gas mileage, because the Golf is a smaller car with less passenger and payload capacity.
Its like claiming TDI's are crap because the original Honda Insight hybrid got much better gas mileage than the Golf, and wrong for exactly the same reason.
Well, actually its wrong for an additional reason, since in addition to the apples-to-oranges comparison, the 1.8 TDI Golf actually gets worse city, highway, and overall mileage than even the 2nd Gen Prius, much less the 3rd Gen.
And that doesn't even get into the Lupo with 1.6 BlueTec diesel... which we can't have here because it won't pass federal crash test requirements.
A hybrid that wasn't also engineered to meet federal crash test requirements would also get better gas mileage than one that was engineered to do so. Again, apples-to-oranges.
Parallel hybrids are a really dumb idea and nobody has brought us a plug-in series hybrid yet. Enter: Nissan LEAF, to actually change the game.
Leaf is interesting, and for some uses it is a great vehicle and will probably have some success. The infrastructure isn't there for all-electric vehicles to work for everyone (though Nissan is working hard to get better infrastructure in some key markets.)
Leaf may well be the wedge that drives wider acceptance of electric vehicles and spurs infrastructure.
Of course this is why the Cash for Clunkers idea was ridiculous. If people had been required to upgrade to 40mpg or higher, then it would have been good, but going from 20 to 25mpg is nothing. The increased fuel efficiency does NOT make up for the ~50,000 miles worth of manufacturing energy wasted to destroy a perfectly working vehicle.
Um, Cash for Clunkers wasn't intended to improve the environment in the short run. It was principally an economic stimulus program designed to stimulate demand for manufacturing activity. It was secondarily a longer-run economic program designed to reduce the growth in demand specifically for oil (and particularly oil imports.) It was tertiarily an environmental program designed to prevent the immediate economic conditions at the time it was adopted from leading to the discontinuation of the more fuel-efficient of existing models and producing a gap in the availability of such vehicles that would persist even after the recovery that was (perhaps overly optimistically) expected to come fairly soon after the crisis that was occurring.
You left off labor costs in California in general and the Bay Area in particular.
There are a lot of out of work auto workers from the NUMMI plant (the one that Tesla bought and is going to used) that GM closed earlier this year that still live in the immediate area -- much more than Tesla is going to initially employ when reopening the plant.
"flagging economy" "more affordable" "sell for $49,900"
one of these things is not like the others... ?
True, "flagging economy" is a description of the economic climate, while the other two "more affordable" (compared to Tesla's existing electric offerings) and "sell for $49,900" are descriptions of the price of the Model S. So the first is not like the other two.
Looked at a different way, "flagging economy" and "more affordable" are fuzzy and subjective, while "sell for $49,900" is concrete, so the last is not like the other two.
Most likely, the point you are trying to make has nothing to do with the one thing being not like the other two, and you are trying to be cute and suggest that $49,900 is inconsistent with "more affordable". But $49,900 is clearly "more affordable" -- more affordable, that is, than Tesla's existing products, the $101,000 base price Roadster and the $128,500 base price Roadster Sport.
This looks like a nice low-level API for doing really interesting and complicated things. Unfortunately, they neglected to include a high-level API to deal with what will be by far the most common use cases.
Its a REST API using common patterns used by other cloud storage systems like Amazon S3; there are plenty of higher-level APIs and even end-user applications designed to use these kind of storage backends, and with the low-level API available, it should be fairly simple for developers who already built the high-level APIs and end-user applications for other cloud storage systems to include Google Storage for Developers as a backend for those products.
Sure, it's not so difficult to implement an upload_file(filepointer, uri) function with this, but given the huge proportion of developers using this library that are going to need exactly this sort of function, do we really need all of them reinventing the wheel?
I'm not actually convinced that a huge proportion of the developers using this service are going to need that sort of function. I would imagine its mostly targetted at developers of cloud-based web applications that are not going to generally do a lot of direct access to the local filesystem either at the client end or the application server end.
The correct suffix for a measurement in micrograms is the Greek letter Mu (like a u)g.
mcg is standard in medicine, and is important handwritten prescriptions since a handwritten script "m" and a handwritten Greek mu can be virtually indistinguishable, while script "mcg" is far more distinct from "mg", see, e.g., here.
Slashdot Mirror
Many well-designed iPhone apps do a good job of saving and restoring state when you switch away, which isn't anything like multitasking, its just, well, intelligently designed save and restore. Also, some of Apples bundled apps -- the iPod app notably -- can be run in the background (the iPhone multitasks just fine, its just one of many features that Apple doesn't allow third-party apps to use.)
Well, sure, IT departments place the blame there. The problem, though, is not so much with the products that IT "has to deal with" as with the fact that IT departments either actively choose the penny-wise-but-pount-foolish course of action of applying band-aids rather than dealing with problems properly in the first place, or because -- when the decision is not theirs -- they simply fail to properly advise the units that are making decisions of the cost and consequence of such a short-sighted approach.
When IT units don't take responsibility for assuring the quality of the IT infrastructure, surprisingly enough, the IT infrastructure, over time, becomes an unstable house of cards, with the IT unit pointing fingers everywhere else.
If your process -- whether its for development or procurement -- doesn't discover holes before it is too late to do anything but apply "temporary" workarounds, then your process is broken, and you need to fix it so you catch problems when you can more effectively address them.
If your process leaves those interim workarounds fixes in place once they are established without initiating and following through on a permanent resolution, then, again, your process is broken and needs fixed.
You don't fix the problems with your infrastructure that have resulted from your broken processes by "wiping the slate clean" on your infrastructure and starting over. You fix the problems by, first, improving your processes so your attempts to address the holes you've built into your infrastructure don't create two more holes for every one you fix, then by attacking the holes themselves.
If you try to through the whole thing out because its junk -- blaming the situation on the environment and the infrastructure without addressing your process -- then:
(a) you'll waste time redoing work that has already been done, and
(b) you'll probably make just as many mistakes rebuilding the infrastructure from scratch as you made building it the first time, whether they are the same or different mistakes.
Magical thinking like "wipe the slate clean" doesn't fix problems. Problems are fixed by identifying them and attacking them directly.
No, they think there is value in having exactly the channels you want, and virtually no cost in having extra channels. For a few well defined interest groups with large customer basis, they can do that fairly well without lots of extra channels (where "exactly the channels you want" are "every sports channel imaginable" or "every Spanish-language channel imaginable"), for everyone else -- since its simpler to have standardized packages -- its easier to just rely on bigger bundles.
Since the date is controlled by death, murder still gets access to the material sooner, while a simple fixed term -- which is what existed before the "life plus X" -- model neatly avoids any incentive to murder.
Its more plausible to say that "a transparently false justification for a substantial fixed term beyond the death of the author is to reduce the incentive to murder an author to get access to the copyrighted material."
Only if you take a rather...interesting...view of what constitutes a "majority", much less a "large majority". iPhone is #3 globally in the smartphone market, and #3 in the US, as well. Globally, Symbian is way ahead of everyone, RIM is next, and iPhone is close behind RIM; in the US, RIM is ahead, Android is #2, and iPhone is #3.
That's because the doctor makes you agree to that term before they agree to enter into a business relationship with you.
If you have failed to exercise your option to refuse to enter into a business arrangement when the terms are unsuitable, the corrective measure is to terminate the unsatisfactory business arrangement. Cable TV is hardly a life necessity, and -- monopoly or not -- cable TV companies can hardly make a profit if consumers simply decide that the service provided isn't worth the hastle.
Hence, the cable exodus being discussed in this thread.
In related research, researchers have found that 11- and 12-year olds who master calculus develop better math skills than those who do not.
Hiring directly in the area and hiring local contractors in the area are both "hiring locally".
If the company's oversight of its contractors is less effective than its oversight of its employees, then it should be expected that places where it relies on contractors will be less well served than places where it relies on employees to perform similar work. I suspect that this -- differences in degree of accountability -- is more the problem than local contractors being lazier than anyone else.
Well, that's not something you can implement yourself, nor is it necessary. Just simply adopt this rule:
If they fail to show up in the agreed window, for any reason, call and cancel your service, and explain the reason.
Neither of those (changes in platform paradigm or changes in programming language/style) typically requires a big-bang rewrite, and if it is avoidable, you are usually better off doing incremental rewrites than big-bang, particularly in critical production systems. For instance, on any multitier networked application, a paradigm shift for the backend implementation can usually be handled piecemeal by putting the old-style implementation behind a facade using the new paradigm, which proxies to the old implementation for the functions that have not been reimplemented.
Piecemeal replacement for programming language changes is, of course, even more obvious how to do.
Does it, though? You can completely replace a system every seven years without ever replacing the whole system from scratch if you are doing fairly frequent replacement of components. "You shouldn't ever replace a system all at once" and "you should plan to completely replace a system every 7 years" aren't contradictory positions.
Yes, there is. The entire point of signing certificates is that they provide a chain of certification back to something you have chosen to trust (the CA model has problems in really providing this, too, but that's the theory.) A certificate provided in-band that isn't signed by a trusted entity from whom you have received a certificate by reliable means out-of-band with the immediate communication doesn't provide authentication, and encryption without authentication is meaningless.
You ought to be able to import trusted-but-unsigned certificates yourself, but the UI or it really needs to not encourage them being first transferred with a page that they are being used to sign. The only way such certs are useful is if they are exchanged out-of-band through a trusted channel (face-to-face, for instance) that allows the relying user to verify identity without relying on a trusted third party.
Well, yeah, the queries you actively send to Google are in Google's hands.
The privacy benefit is directly linked to the security benefit, in that people other than the one to whom you are choosing to give your data to provide you with a service don't have quite as easy access to it in transit.
Privacy doesn't mean no one has your information, it means that only the people you choose to give your information to have it.
The link to WUBI is is somewhat inappropriate: WUBI is an installer that installs Linux in a file hosted on a Windows filesystem using something that works as a Windows installer (and creating a Windows uninstaller for the Linux installation.) But it doesn't run Linux under Windows.
So if you want a Linux under Windows distribution to talk about running under WINE what you really want is more Portable Ubuntu Remix, not WUBI.
No, they don't. In the thing they dominate -- online searches (which isn't a market, because its not something that is sold) -- their share, while substantial at ~70%, isn't as great as Microsoft's desktop OS share (which is a market).
As far as markets, they have a majority of search advertising (but, again, substantially less than Microsoft has very desktop OSes), a large minority of online advertising, a large minority of mobile advertising, and a tiny fraction of total advertising. I think there is a good case to be made that different advertising forms are true substitutes and that the relevant market from an antitrust perspective is total advertising, but even if its not, there is no market they dominate in anything like the way Microsoft dominates the desktop OS or Office Suite markets.
There are very few mergers/acquisitions that the government even investigates for antitrust concerns, no matter who is involved, and even fewer that they reject.
So Google's not at all special in that regard.
How so? Microsoft buys companies all the time without the government blocking them.
Not necessarily. There's a temptation to view the GET/PUT/POST/DELETE set of HTTP verbs as having a 1:1 mapping to CRUD actions, but they really don't. GET and DELETE in HTTP do map cleanly to READ and DELETE in CRUD, but PUT really is the equivalent of either a CREATE or a replacing UPDATE on a particular named resource, while POST is a special kind of create (creating a new resource subordinate to a named collection resource which will determine the name of the newly created resource.)
If you are creating a new resource whose intended name (URL) you know, PUT makes sense. If you are creating a new resource and don't care about its name, just that it is a child of a particular collection resource, POST makes sense.
The space shuttle isn't a current electric vehicle offering from Tesla.
A story about Tesla, an electric vehicle manufacturer, announcing plans to build a "more affordable" electric vehicle has a pretty clear comparison communicated in it.
No, its really about people's ability to understand English, not their feelings about a company. I'm mostly neutral on Tesla -- even the Model S is out of the range that I am interested in, the Nissan LEAF is much more interesting, though the development partnership Tesla announced with Toyota might yield interesting fruit.
OTOH, I recognize that there is a difference between saying something is "more affordable" (which is always a comparison to something else) and saying that it is "affordable", and something need not be "affordable" by any reasonable absolute standard to be "more affordable" than the particular thing that it is being compared to.
Which it may well be, especially if those people with "reduced financial means" would have been in the market for a Tesla Roadster before those means were reduced.
"Reduced" doesn't say anything about what something was reduced from. Nothing in the blurb suggests that the Model S is priced in a way that makes it accessible to the average purchaser, only that it is within the range of far more people than the Roadster.
It might be better to call it "bucket", if one of your biggest target audiences was, say, developers already using and familiar with Amazon S3, a popular existing service in the same space that calls the same thing a "bucket" rather than a "zone" or "filesystem".
If you used the same kind of engine and drive system on a Golf-sized vehicle and a Prius-sized vehicle (whether both TDI or both hybrid), with similar performance, you'd expect the Golf sized vehicle to get better gas mileage, because the Golf is a smaller car with less passenger and payload capacity.
Its like claiming TDI's are crap because the original Honda Insight hybrid got much better gas mileage than the Golf, and wrong for exactly the same reason.
Well, actually its wrong for an additional reason, since in addition to the apples-to-oranges comparison, the 1.8 TDI Golf actually gets worse city, highway, and overall mileage than even the 2nd Gen Prius, much less the 3rd Gen.
A hybrid that wasn't also engineered to meet federal crash test requirements would also get better gas mileage than one that was engineered to do so. Again, apples-to-oranges.
Leaf is interesting, and for some uses it is a great vehicle and will probably have some success. The infrastructure isn't there for all-electric vehicles to work for everyone (though Nissan is working hard to get better infrastructure in some key markets.)
Leaf may well be the wedge that drives wider acceptance of electric vehicles and spurs infrastructure.
Um, Cash for Clunkers wasn't intended to improve the environment in the short run. It was principally an economic stimulus program designed to stimulate demand for manufacturing activity. It was secondarily a longer-run economic program designed to reduce the growth in demand specifically for oil (and particularly oil imports.) It was tertiarily an environmental program designed to prevent the immediate economic conditions at the time it was adopted from leading to the discontinuation of the more fuel-efficient of existing models and producing a gap in the availability of such vehicles that would persist even after the recovery that was (perhaps overly optimistically) expected to come fairly soon after the crisis that was occurring.
There are a lot of out of work auto workers from the NUMMI plant (the one that Tesla bought and is going to used) that GM closed earlier this year that still live in the immediate area -- much more than Tesla is going to initially employ when reopening the plant.
True, "flagging economy" is a description of the economic climate, while the other two "more affordable" (compared to Tesla's existing electric offerings) and "sell for $49,900" are descriptions of the price of the Model S. So the first is not like the other two.
Looked at a different way, "flagging economy" and "more affordable" are fuzzy and subjective, while "sell for $49,900" is concrete, so the last is not like the other two.
Most likely, the point you are trying to make has nothing to do with the one thing being not like the other two, and you are trying to be cute and suggest that $49,900 is inconsistent with "more affordable". But $49,900 is clearly "more affordable" -- more affordable, that is, than Tesla's existing products, the $101,000 base price Roadster and the $128,500 base price Roadster Sport.
Its a REST API using common patterns used by other cloud storage systems like Amazon S3; there are plenty of higher-level APIs and even end-user applications designed to use these kind of storage backends, and with the low-level API available, it should be fairly simple for developers who already built the high-level APIs and end-user applications for other cloud storage systems to include Google Storage for Developers as a backend for those products.
I'm not actually convinced that a huge proportion of the developers using this service are going to need that sort of function. I would imagine its mostly targetted at developers of cloud-based web applications that are not going to generally do a lot of direct access to the local filesystem either at the client end or the application server end.
mcg is standard in medicine, and is important handwritten prescriptions since a handwritten script "m" and a handwritten Greek mu can be virtually indistinguishable, while script "mcg" is far more distinct from "mg", see, e.g., here.