Funny you mention dealer service for anything other than the battery (which is a dealer-only part that they will not sell you without installation). It's also funny that you can get a Corolla headlight for $80 at the dealer or less than $16 off the shelf at any parts store. There's a reason I didn't compare common regular maintenance; I had assumed those costs would be similar between the two models. Thank you for pointing out yet another way a Prius actually costs more over time.
You and he think he saved money. Just like I ignored the $4000 battery replacement (those batteries have a high-end working life of 1 decade), you're also ignoring that. A new Prius costs $7250 more than a new Corolla; let's find out what the difference is when they're 5 years old. So, let's assume he bought a 5 year old Prius today and I bought a 5 year old Corolla (LE since there is no 2010 L model) today, he'll spend $11793 on a vehicle that gets 50 MPG on average and I'll spend $9279 on a vehicle that gets 29 MPG on average (according to KBB, both cars stock and in "Good" condition). He's going to pay $2514 more for that Prius which, you're right, does cut the difference down by nearly 2/3. So, what's the payoff point? I won't ignore the battery this time.
Average miles driven per year: 13346 - Fuel for Prius: 266.92gal - Fuel for Corolla: 460.21gal
So, the 2010 Prius actually fares quite a bit better against the 2010 Corolla than the comparison between the 2015 miles, the Prius should have this one in the bag, right?
Wrong.
Payoff on that price difference is roughly 3.25 years (a few days longer, actually) and, assuming the Prius' battery holds up for the full 10 years of expected life (note: this is rare), the Prius actually will be ahead of the Corolla at that point. However, at the end of 10 years, when the Prius should be $1353.03 ahead of the Corolla, the $4000 battery needs to be replaced, putting the Corolla back in the lead by $2646.97. It'll take the Prius another 3.5 years to catch up to the Corolla at that point. That all assumes that the electric motors in the Prius last 13.5 years without replacement; remember, this is not common maintenance between the two models, like a headlight, but maintenance that is specific to one model, like the $4000 battery. At any rate, a 5 year old Prius will be 13.5 years old before it catches up, cost-wise, to a 5 year old Corolla bought at the same time; that's an 8.5 year payoff when you actually consider the battery, assuming no other Prius-specific maintenance is necessary in that time. While that is an almost 35% reduction from the original 13 year payoff, it's also unlikely that either vehicle will be kept for that duration. More likely, when the Prius needs a new battery, it'll be traded in for something new; after all, at the 10 year mark, the Prius won't be worth the cost of the battery anymore, anyway.
It does look a bit more favorable when you raise the price of gas to $5, though. The Prius will have a yearly fuel cost of $966.45 less than the corolla at that point, giving it a (pre-battery) payoff time of 2.6 years (plus a handful of hours), putting it $2319.18 ahead of the Corolla at the 10 year mark. Factoring in the battery, the Corolla is actually $1680.52 ahead at the 10 year mark, but the Prius does catch up after roughly another 1.75 years. If gas costs 25% more, the used Prius beats the used Corolla after 6.75 years rather than 8.5. It's still unlikely the Prius will see that new battery at the 10 year mark, though, when it's KBB value will be less than the cost of the battery in the first place.
The economics of the Prius just don't work from a financial perspective. When you consider what goes into producing, and disposing of or recycling, large lithium batteries, the environmental economics don't work either. Especially given the frequency with whic
I'll admit that I didn't RTFA (hey, I know where I am) and wasn't aware that it involved tracking; I can agree with that for sure. Why tracking? Seems like the tax is just an excuse to track, actually; odometer readings should work just as well, if not better. Tracking for this purpose is just idiotic.
That said, the gas tax is intended to pay for roads, so switching to a taxing method that better correlates to one's usage of the roads (as you admit, the current method does not) only makes sense. Why should lawnmower and chainsaw which never see public roads, or my boat and track car which only public roads on a trailer,which is taxed separately, be taxed for road usage? Simple answer: they shouldn't. Likewise, a car idling in my driveway shouldn't be taxed for road usage. Under the current system, all of that is taxed as though it is putting wear and tear on the public roadways; a mileage-based system (using odometer readings and not some idiotic tracking scheme), on the other hand, taxes only the miles driven.
It's still not perfect, as not every mile driven in a registered vehicle will be driven on public roads (which is the issue I think the tracking is meant to address) but it's no worse than what most municipal sewer/water providers do in assuming that every gallon of water dispensed from your faucet ends up in their sewer. Most even have provisions for second, outdoor-only, meters that do not count against your sewage bill; the analog for cars would be my track car, which is unregistered and never drives on public roads.
Now, if the gas tax was just that, a tax on gasoline intended to curb gasoline usage or fund environmental programs, I'd agree with you, the tax should stay where it is. I'll remind you, again, though, that the tax is in place to fund roads. If I buy a Prius and replace its hybrid drive system with a V8, it will use much more gasoline, but it doesn't put any more wear and tear on the roads and thus, for the purpose of a roadway maintenance tax, shouldn't be taxed any more than the stock Prius.
Further, I don't know any hybrid owners who bought the car to save money on gas. Sure, they bought it to use less gas, but that was an environmental concern, not a financial decision. Nobody is buying a Prius (Prius Two, $24200 base, 51MPG city, 48MPG highway, 49.5MPG average) over a Corolla (Corolla L, $16950 base, 28MPG city, 37MPG highway, 32.5MPG average) to save money. Look at it this way: the Prius costs $7250 more out the door, the average American drives 13346 miles per year (men average 16550 while women average 10142, I'm simplifying by splitting it down the middle). The Prius will use 269.62 gallons of fuel to travel that distance while the Corolla will use 410.65 gallons; at a price of $4.00 per gallon, the Prius will have a fuel cost of $1078.48 per year while the Corolla will have a fuel cost of $1642.60 per year. That means the Prius will save the average American $564.12 per year in fuel. That's almost a 13 year payoff, ignoring the $4000.00 battery replacement that will be necessary at least once within that timeframe.
At $5.00 per gallon, the Prius looks a little better I suppose, saving you $705.15 per year in fuel costs. That's still over a 10 year payoff though, again ignoring the $4000 battery replacement.
Anyone whose fuel purchasing decisions are price-based isn't buying a more efficient vehicle anyway, because they can't afford it. so, again, how will cheaper gas lead to less efficient vehicles?
How does it encourage less efficient cars? They aren't making gasoline free, they're just removing a tax from it and taxing the thing that should have been taxed to begin with. That means your lawnmower and boat gas will no longer fund roads, but your miles driven on those roads will. Gas still costs money and less efficient vehicles use more of it, thus costing more, dis-incentivizing their use.
Actually, yeast convert carbohydrates—starches and sugars—to alcohol and carbon dioxide gas. That article is about as plain-english of an explanation as you'll find; and yes, it even confirms that the starches are processed into sugars before being turned into alcohol and CO2. All the yeast can make from a simple sugar (which, aside from starches which the yeast breaks into simple sugars via enzymes, is all yeast can process) is CO2 and alcohol and, since sugar isn't pure carbon, if CO2 is being produced, so it alcohol.
Unless you've discovered a strain of yeast that can transmute matter at the atomic level, in which case you need to apply for some grants to further that line of research.
You nailed it with your last sentence. In fact, I prefer to start with good technical (why/how) documentation and code from that, commenting usage (which eventually translates into user documentation) along the way. With the theoretical and technical documentation out of the way before coding even begins, and the bulk of the user documentation written alongside the code itself (still needing to be compiled into a coherent document and edited, of course), all that's really left is to provide some usage examples, which can be done during final editing of the documentation.
Because the theoretical and technical documentation do not need to follow the program (it happens the other way around in this case), they become much easier to write. Coding becomes easier, as well, because the theoretical and technical documentation define everything (and if it doesn't, it gets kicked back to the author to be fixed while the developer takes a coffee break). That whole process just moves more smoothly and quickly, at that point. Having the developer detail usage in their code comments means the person who best knows how to use the code is the one documenting how to use the code; of course, a technical writer should compile those comments into a coherent document, then edit it. As a final test of that documentation, that technical writer should, while editing the user documentation, write a series of usage examples and have the developer verify that the examples are correct. Any corrections to the examples should result in similar corrections to the documentation, as well.
This seems to reduce the number of revision cycles while, at the same time, ensuring that the documentation and application are in sync.
I always tell my clients, if they're not willing to work with me to write the technical documentation before I begin development, my development quote doubles and only minimal documentation will be provided. I only have one client who chooses that option; they also prefer to pay me to maintain everything, so I guess it's a win-win.
Perhaps he isn't arrogant, but skilled in writing documentation? For him, then, it would not be hard, and never would have been. Ignorant, perhaps, of the fact that it might be hard for others, but not arrogant. The same can be said of coding, as well; I don't find it the lest bit difficult to write good and maintainable code, provided I'm given the time to do so.
That said, in both case it's actually almost impossible, because whoever you're writing the code and/or documentation for wants you on the next project tomorrow.
I'm sorry you can't tell the difference between the larger (and not used much on anything more recent than a PS3 controller) USB-mini and smaller (and user everywhere) USB-micro, but that's a you problem, not a USB problem. Remember, the opposite end of that lightning cable is USB, too; it used to crack me right the fuck up when I would hear someone claim that lightning was faster than USB.
Furthermore, the lightning port is no more or less sturdy than USB-micro. Personally, I've never broken either port, despite having owned more USB-micro devices than I can count over the past decade, and a handful of lightning (read: iOS) devices since that port was released. In fact, I don't know anyone who's broken a USB-micro port (though I did knock one partially loose by dropping something heavy on it as it sat hanging off the edge of a table, something that would have done the same, or worse, to a lightning connector), but I do have a friend who snapped the lightning connector right out of her iPhone. This is in spite of the fact that I know more people who own more USB-micro devices.
I'll concede that you may have better access to lightning cables within your circle of friends than I do within mine (despite my wife and two best friends being iPhone users and myself and my other best friend being iPad users), but that does not change the fact that a USB-micro cable can be had for $1 (literally from the dollar store) while a licensed (e.g. won't make iOS 8 devices complain and possibly refuse to charge) lightning cable can not. You surely could have purchased the correct cable while on your trip; even if you were broke, you could have found enough cash on the side of the road to buy the USB cable you needed, but I doubt you'd have been able to scrape together $5-10 that way for a lightning cable.
Regarding the 30-pin connector, there were plenty of unlicensed 30-pin connectors out there, which Apple didn't make a penny on; that's why the lightning connector includes an authentication chip, the absence of which makes iOS 8 devices complain when an unlicensed cable or device is plugged in. That connector actually was stronger than USB-micro, on top of also being more capable (having analog audio/video and control pins, on top of USB and Firewire). It was a proprietary connector that actually brought something meaningful and useful to the table.
Of course, then there's USB3, which neither the 30-pin nor lightning connector support. Plug either into a USB3 port and it falls back to USB2 speeds (another reason I laugh when I hear someone say lightning is faster than USB). USB-micro "A" doesn't support USB3 speeds either, but will plug into a USB-micro "B" (the wider one with extra pins) port and work with no issues. The design of the lightning connecter prevents that, which is why Apple recently adopted USB-C, rather than try and make that work. Expect the next round of iDevices after the iPhone 6s (which will, of course, feature the lightning port) to ship with USB-C. You know, because lightning is just so much better.
Sadly, it's the "don't worry, your OS will keep you safe" mindset that makes iOS and OSX users easier to deceive. I say this as a user of both platforms, but also as a user who does not subscribe to that mindset.
Both platforms are probably not equally easy to exploit
Consider that the vast majority of Android "malware" consists of games or toy apps that request every permission under the sun and the user has to agree to let that app have those permissions at install time. Now, consider that apps also request permissions on iOS but, rather than listing all the permissions they'll want at install time, they request them the first time they try to use them. It's a user decision in both cases.
both platforms probably do not provide equal returns
All you're likely to get from a phone, in any case, is a contact list, schedule (calendar), and some photos; you can grant full access to all of that on either platform. You can also send mail or text messages from an app on either platform, if the user grants those permissions. Android does allow full filesystem access (again, if granted by the user), but iOS also allows access to stored documents (including iCloud, so not just what's on your phone, which could potentially be worse). Neither platform allows system files, configuration, or application files to be overwritten unless rooted or jailbroken; and Android not only needs to be rooted, but also specifically configured to allow those behaviors and the app granted root access (which is not the default). I'm not positive about iOS but I don't recall seeing any way to manage root privs when I had my jailbroken 3Gs, which would make jailbroken iOS much more vulnerable than rooted Android.
(Obligatory apple users easier to deceive yet wealthier comment here)
I don't know about wealthier; as an Android user with a job, I've bought my unemployed wife her last 3 iPhones. As for easier to deceive, well, I wasn't gonna go there but... One of the two platforms is marketed to people who just don't want to have to give a shit about security. That's not an inherent flaw in the platform so much as it is a flaw in the marketing, though, and it's only the user's fault insofar as they tend to place entirely too much trust in a corporation that places profit over people. Google is no better in the latter regard, but at least they don't do the former; Android users (generally) have no illusions that their devices are any more or less secure than any other computing device.
Android and iOS are both fine platforms. Neither is perfect, neither is as secure as we'd like, but they're the best we've got at this point. I do feel that iOS is somewhat hamstrung by Apple's policies (NFC finally comes to iPhone, but only for Apple Pay? Proprietary connector that brings nothing to the table but the ability to plug in both ways and a new licensing revenue stream for Apple? No, thank you). As a result, will never own another iPhone; I've been using NFC for more than just payments for a few years by now, and think it's great that almost every rechargeable device I buy now uses the same micro-USB cable. Even iOS accessories. It's great, it really is, if I ever find myself needing a charge while I'm out and about; everyone has the cables, everywhere, and they're so cheap and plentiful that people don't mind lending them; that doesn't seem to be the case when my wife's iPhone runs out of juice. Mind you, I love my iPad, but it also doesn't leave the house all that often, so charging is rarely an issue, and none of the other restrictions that bother me when talking about the iPhone (an always-on-me device) seem to apply, either.
This oft-quoted line of complete bullshit is why people think iOS and Apple's walled garden is more secure than any other mobile platform. The reality is that Apple gets a binary to review, just like Google, Microsoft, or Blackberry. Apple and Google actually review the binaries, even; and Google even actually catches some nasties (I'm sure Apple does, as well, but they aren't as transparent about it) and prevents them from entering the Play store. Apple has pulled malware from the iOS store in the past, but has never made any official comment on it, unlike Google, which does leave one wondering... Knowing that malware authors likely submit to both platforms at the same rate, we know how often Google rejects or removes malware from their store (because they publish the statistics), one should expect that Apple's numbers are roughly the same, but are they? If anyone has a link to some official (e.g. from Apple) stats on that, I'd love to see them.
It's a device with an accelerometer, heart rate monitor, and other sensors that would be immensely useful for sleep tracking. Unfortunately, despite being the best equipped for that task, sensor-wise, it's useless for the job simply due to its battery. Sure, the Pebble Time I ordered as an upgrade to my Pebble doesn't have a heart rate monitor on it, but at least I'll be able to wear it every night for sleep tracking and throw it on the charger when I go out to detail my car (or my wife's) on Sunday.
As an added insult to the Apple Watch: When offered an Apple Watch, my wife, an Apple fan who hates hand-me-downs, asked if she could have my old Pebble when the Pebble Time arrives.
You are correct. However, the post I was replying to was about web apps. If you want to complain to someone about getting it wrong, complain to that poster.
This. If everything is done in the client, the application will lag every time anything processor-intensive is done. Likewise, if the client has to call back to the server every time it does anything, the client will lag on high-latency connections or when the server is overloaded. There's a balance there; the trouble is that most developers don't know how to find it.
I think part of the problem is that web app developers seem to fall into one of two camps: Do everything locally for the best chance of availability, or do everything remotely for the best performance. The first camp is almost right, they do achieve better availability doing everything locally, right up to the point where their app becomes unusable due to processing lag (in other words, they're wrong). The second camp is also almost right, they do achieve the best performance in their local development environment, running in a VM on their workstation, where they're the only user; that falls apart the moment they add thousands users and wildly-variable latency between client and server (in other words, they're wrong).
What I prefer to do is provide all capabilities in the client (a-la first-camp), then identify those that cause the application to lag and implement them on the server (a-la second-camp). Once a function exists in both the client and the server, the client can run a job locally and on the server. If the local job finishes first, the client alerts the server and the server-side job is terminated; if the server returns its result first, the local job is terminated. I find that this structure provides the best performance, as well as availability, since the faster resource will always be the one to return the result used; and if the server is unavailable, times out, or returns an error, the application still works. I find that most users are willing to accept occasional slowness during server outages and upgrades, especially when the application is generally very responsive under normal conditions.
That, I'm sure, can be built upon to predict (e.g. based on bandwidth, latency, and local vs server load and performance) which job will finish first and only start the remote job when it will be the clear winner (still starting the local job just in case). That would give you the benefit of reduced server requirements without impacting application performance (unless you take it too far and don't keep any spare compute power online). I haven't run into an instance where this has been necessary or where the savings would be worth the effort (as evident by the number of cancelled jobs compared to completed jobs), but I'm sure such a case exists.
So, any ideas about how to go about "tracking terrorists"?
One need not have a good idea to be able to identify a bad one. In absence of said good idea, the correct action to take is none at all, not carry on with the bad idea because it's all we have. That's how idiots lose limbs cutting down trees and such; it's also how a free and great nation loses that freedom and greatness.
Slashdot Mirror
Funny you mention dealer service for anything other than the battery (which is a dealer-only part that they will not sell you without installation). It's also funny that you can get a Corolla headlight for $80 at the dealer or less than $16 off the shelf at any parts store. There's a reason I didn't compare common regular maintenance; I had assumed those costs would be similar between the two models. Thank you for pointing out yet another way a Prius actually costs more over time.
You and he think he saved money. Just like I ignored the $4000 battery replacement (those batteries have a high-end working life of 1 decade), you're also ignoring that. A new Prius costs $7250 more than a new Corolla; let's find out what the difference is when they're 5 years old. So, let's assume he bought a 5 year old Prius today and I bought a 5 year old Corolla (LE since there is no 2010 L model) today, he'll spend $11793 on a vehicle that gets 50 MPG on average and I'll spend $9279 on a vehicle that gets 29 MPG on average (according to KBB, both cars stock and in "Good" condition). He's going to pay $2514 more for that Prius which, you're right, does cut the difference down by nearly 2/3. So, what's the payoff point? I won't ignore the battery this time.
Average miles driven per year: 13346 - Fuel for Prius: 266.92gal - Fuel for Corolla: 460.21gal
Fuel cost @ $4.00/gal - Prius: $1067.68 - Corolla: $1840.84
Prius fuel cost savings per year: $773.16
So, the 2010 Prius actually fares quite a bit better against the 2010 Corolla than the comparison between the 2015 miles, the Prius should have this one in the bag, right?
Wrong.
Payoff on that price difference is roughly 3.25 years (a few days longer, actually) and, assuming the Prius' battery holds up for the full 10 years of expected life (note: this is rare), the Prius actually will be ahead of the Corolla at that point. However, at the end of 10 years, when the Prius should be $1353.03 ahead of the Corolla, the $4000 battery needs to be replaced, putting the Corolla back in the lead by $2646.97. It'll take the Prius another 3.5 years to catch up to the Corolla at that point. That all assumes that the electric motors in the Prius last 13.5 years without replacement; remember, this is not common maintenance between the two models, like a headlight, but maintenance that is specific to one model, like the $4000 battery. At any rate, a 5 year old Prius will be 13.5 years old before it catches up, cost-wise, to a 5 year old Corolla bought at the same time; that's an 8.5 year payoff when you actually consider the battery, assuming no other Prius-specific maintenance is necessary in that time. While that is an almost 35% reduction from the original 13 year payoff, it's also unlikely that either vehicle will be kept for that duration. More likely, when the Prius needs a new battery, it'll be traded in for something new; after all, at the 10 year mark, the Prius won't be worth the cost of the battery anymore, anyway.
It does look a bit more favorable when you raise the price of gas to $5, though. The Prius will have a yearly fuel cost of $966.45 less than the corolla at that point, giving it a (pre-battery) payoff time of 2.6 years (plus a handful of hours), putting it $2319.18 ahead of the Corolla at the 10 year mark. Factoring in the battery, the Corolla is actually $1680.52 ahead at the 10 year mark, but the Prius does catch up after roughly another 1.75 years. If gas costs 25% more, the used Prius beats the used Corolla after 6.75 years rather than 8.5. It's still unlikely the Prius will see that new battery at the 10 year mark, though, when it's KBB value will be less than the cost of the battery in the first place.
The economics of the Prius just don't work from a financial perspective. When you consider what goes into producing, and disposing of or recycling, large lithium batteries, the environmental economics don't work either. Especially given the frequency with whic
I'll admit that I didn't RTFA (hey, I know where I am) and wasn't aware that it involved tracking; I can agree with that for sure. Why tracking? Seems like the tax is just an excuse to track, actually; odometer readings should work just as well, if not better. Tracking for this purpose is just idiotic.
That said, the gas tax is intended to pay for roads, so switching to a taxing method that better correlates to one's usage of the roads (as you admit, the current method does not) only makes sense. Why should lawnmower and chainsaw which never see public roads, or my boat and track car which only public roads on a trailer,which is taxed separately, be taxed for road usage? Simple answer: they shouldn't. Likewise, a car idling in my driveway shouldn't be taxed for road usage. Under the current system, all of that is taxed as though it is putting wear and tear on the public roadways; a mileage-based system (using odometer readings and not some idiotic tracking scheme), on the other hand, taxes only the miles driven.
It's still not perfect, as not every mile driven in a registered vehicle will be driven on public roads (which is the issue I think the tracking is meant to address) but it's no worse than what most municipal sewer/water providers do in assuming that every gallon of water dispensed from your faucet ends up in their sewer. Most even have provisions for second, outdoor-only, meters that do not count against your sewage bill; the analog for cars would be my track car, which is unregistered and never drives on public roads.
Now, if the gas tax was just that, a tax on gasoline intended to curb gasoline usage or fund environmental programs, I'd agree with you, the tax should stay where it is. I'll remind you, again, though, that the tax is in place to fund roads. If I buy a Prius and replace its hybrid drive system with a V8, it will use much more gasoline, but it doesn't put any more wear and tear on the roads and thus, for the purpose of a roadway maintenance tax, shouldn't be taxed any more than the stock Prius.
Further, I don't know any hybrid owners who bought the car to save money on gas. Sure, they bought it to use less gas, but that was an environmental concern, not a financial decision. Nobody is buying a Prius (Prius Two, $24200 base, 51MPG city, 48MPG highway, 49.5MPG average) over a Corolla (Corolla L, $16950 base, 28MPG city, 37MPG highway, 32.5MPG average) to save money. Look at it this way: the Prius costs $7250 more out the door, the average American drives 13346 miles per year (men average 16550 while women average 10142, I'm simplifying by splitting it down the middle). The Prius will use 269.62 gallons of fuel to travel that distance while the Corolla will use 410.65 gallons; at a price of $4.00 per gallon, the Prius will have a fuel cost of $1078.48 per year while the Corolla will have a fuel cost of $1642.60 per year. That means the Prius will save the average American $564.12 per year in fuel. That's almost a 13 year payoff, ignoring the $4000.00 battery replacement that will be necessary at least once within that timeframe.
At $5.00 per gallon, the Prius looks a little better I suppose, saving you $705.15 per year in fuel costs. That's still over a 10 year payoff though, again ignoring the $4000 battery replacement.
Anyone whose fuel purchasing decisions are price-based isn't buying a more efficient vehicle anyway, because they can't afford it. so, again, how will cheaper gas lead to less efficient vehicles?
How does it encourage less efficient cars? They aren't making gasoline free, they're just removing a tax from it and taxing the thing that should have been taxed to begin with. That means your lawnmower and boat gas will no longer fund roads, but your miles driven on those roads will. Gas still costs money and less efficient vehicles use more of it, thus costing more, dis-incentivizing their use.
Actually, yeast convert carbohydrates—starches and sugars—to alcohol and carbon dioxide gas. That article is about as plain-english of an explanation as you'll find; and yes, it even confirms that the starches are processed into sugars before being turned into alcohol and CO2. All the yeast can make from a simple sugar (which, aside from starches which the yeast breaks into simple sugars via enzymes, is all yeast can process) is CO2 and alcohol and, since sugar isn't pure carbon, if CO2 is being produced, so it alcohol.
Unless you've discovered a strain of yeast that can transmute matter at the atomic level, in which case you need to apply for some grants to further that line of research.
Starches process into sugars. What do you think happens while the bread is rising?
Damn.
Except that alcohol bakes out of the bread while morphine does not.
It'll be the MacBook either way because the article (as per the summary) is about Windows 10 on a MacBook being faster than OSX on a MacBook.
Wash hands, print, test. Transfer is not an issue.
You nailed it with your last sentence. In fact, I prefer to start with good technical (why/how) documentation and code from that, commenting usage (which eventually translates into user documentation) along the way. With the theoretical and technical documentation out of the way before coding even begins, and the bulk of the user documentation written alongside the code itself (still needing to be compiled into a coherent document and edited, of course), all that's really left is to provide some usage examples, which can be done during final editing of the documentation.
Because the theoretical and technical documentation do not need to follow the program (it happens the other way around in this case), they become much easier to write. Coding becomes easier, as well, because the theoretical and technical documentation define everything (and if it doesn't, it gets kicked back to the author to be fixed while the developer takes a coffee break). That whole process just moves more smoothly and quickly, at that point. Having the developer detail usage in their code comments means the person who best knows how to use the code is the one documenting how to use the code; of course, a technical writer should compile those comments into a coherent document, then edit it. As a final test of that documentation, that technical writer should, while editing the user documentation, write a series of usage examples and have the developer verify that the examples are correct. Any corrections to the examples should result in similar corrections to the documentation, as well.
This seems to reduce the number of revision cycles while, at the same time, ensuring that the documentation and application are in sync.
I always tell my clients, if they're not willing to work with me to write the technical documentation before I begin development, my development quote doubles and only minimal documentation will be provided. I only have one client who chooses that option; they also prefer to pay me to maintain everything, so I guess it's a win-win.
Perhaps he isn't arrogant, but skilled in writing documentation? For him, then, it would not be hard, and never would have been. Ignorant, perhaps, of the fact that it might be hard for others, but not arrogant. The same can be said of coding, as well; I don't find it the lest bit difficult to write good and maintainable code, provided I'm given the time to do so.
That said, in both case it's actually almost impossible, because whoever you're writing the code and/or documentation for wants you on the next project tomorrow.
I'm sorry you can't tell the difference between the larger (and not used much on anything more recent than a PS3 controller) USB-mini and smaller (and user everywhere) USB-micro, but that's a you problem, not a USB problem. Remember, the opposite end of that lightning cable is USB, too; it used to crack me right the fuck up when I would hear someone claim that lightning was faster than USB.
Furthermore, the lightning port is no more or less sturdy than USB-micro. Personally, I've never broken either port, despite having owned more USB-micro devices than I can count over the past decade, and a handful of lightning (read: iOS) devices since that port was released. In fact, I don't know anyone who's broken a USB-micro port (though I did knock one partially loose by dropping something heavy on it as it sat hanging off the edge of a table, something that would have done the same, or worse, to a lightning connector), but I do have a friend who snapped the lightning connector right out of her iPhone. This is in spite of the fact that I know more people who own more USB-micro devices.
I'll concede that you may have better access to lightning cables within your circle of friends than I do within mine (despite my wife and two best friends being iPhone users and myself and my other best friend being iPad users), but that does not change the fact that a USB-micro cable can be had for $1 (literally from the dollar store) while a licensed (e.g. won't make iOS 8 devices complain and possibly refuse to charge) lightning cable can not. You surely could have purchased the correct cable while on your trip; even if you were broke, you could have found enough cash on the side of the road to buy the USB cable you needed, but I doubt you'd have been able to scrape together $5-10 that way for a lightning cable.
Regarding the 30-pin connector, there were plenty of unlicensed 30-pin connectors out there, which Apple didn't make a penny on; that's why the lightning connector includes an authentication chip, the absence of which makes iOS 8 devices complain when an unlicensed cable or device is plugged in. That connector actually was stronger than USB-micro, on top of also being more capable (having analog audio/video and control pins, on top of USB and Firewire). It was a proprietary connector that actually brought something meaningful and useful to the table.
Of course, then there's USB3, which neither the 30-pin nor lightning connector support. Plug either into a USB3 port and it falls back to USB2 speeds (another reason I laugh when I hear someone say lightning is faster than USB). USB-micro "A" doesn't support USB3 speeds either, but will plug into a USB-micro "B" (the wider one with extra pins) port and work with no issues. The design of the lightning connecter prevents that, which is why Apple recently adopted USB-C, rather than try and make that work. Expect the next round of iDevices after the iPhone 6s (which will, of course, feature the lightning port) to ship with USB-C. You know, because lightning is just so much better.
Sadly, it's the "don't worry, your OS will keep you safe" mindset that makes iOS and OSX users easier to deceive. I say this as a user of both platforms, but also as a user who does not subscribe to that mindset.
Both platforms are probably not equally easy to exploit
Consider that the vast majority of Android "malware" consists of games or toy apps that request every permission under the sun and the user has to agree to let that app have those permissions at install time. Now, consider that apps also request permissions on iOS but, rather than listing all the permissions they'll want at install time, they request them the first time they try to use them. It's a user decision in both cases.
both platforms probably do not provide equal returns
All you're likely to get from a phone, in any case, is a contact list, schedule (calendar), and some photos; you can grant full access to all of that on either platform. You can also send mail or text messages from an app on either platform, if the user grants those permissions. Android does allow full filesystem access (again, if granted by the user), but iOS also allows access to stored documents (including iCloud, so not just what's on your phone, which could potentially be worse). Neither platform allows system files, configuration, or application files to be overwritten unless rooted or jailbroken; and Android not only needs to be rooted, but also specifically configured to allow those behaviors and the app granted root access (which is not the default). I'm not positive about iOS but I don't recall seeing any way to manage root privs when I had my jailbroken 3Gs, which would make jailbroken iOS much more vulnerable than rooted Android.
(Obligatory apple users easier to deceive yet wealthier comment here)
I don't know about wealthier; as an Android user with a job, I've bought my unemployed wife her last 3 iPhones. As for easier to deceive, well, I wasn't gonna go there but... One of the two platforms is marketed to people who just don't want to have to give a shit about security. That's not an inherent flaw in the platform so much as it is a flaw in the marketing, though, and it's only the user's fault insofar as they tend to place entirely too much trust in a corporation that places profit over people. Google is no better in the latter regard, but at least they don't do the former; Android users (generally) have no illusions that their devices are any more or less secure than any other computing device.
Android and iOS are both fine platforms. Neither is perfect, neither is as secure as we'd like, but they're the best we've got at this point. I do feel that iOS is somewhat hamstrung by Apple's policies (NFC finally comes to iPhone, but only for Apple Pay? Proprietary connector that brings nothing to the table but the ability to plug in both ways and a new licensing revenue stream for Apple? No, thank you). As a result, will never own another iPhone; I've been using NFC for more than just payments for a few years by now, and think it's great that almost every rechargeable device I buy now uses the same micro-USB cable. Even iOS accessories. It's great, it really is, if I ever find myself needing a charge while I'm out and about; everyone has the cables, everywhere, and they're so cheap and plentiful that people don't mind lending them; that doesn't seem to be the case when my wife's iPhone runs out of juice. Mind you, I love my iPad, but it also doesn't leave the house all that often, so charging is rarely an issue, and none of the other restrictions that bother me when talking about the iPhone (an always-on-me device) seem to apply, either.
This oft-quoted line of complete bullshit is why people think iOS and Apple's walled garden is more secure than any other mobile platform. The reality is that Apple gets a binary to review, just like Google, Microsoft, or Blackberry. Apple and Google actually review the binaries, even; and Google even actually catches some nasties (I'm sure Apple does, as well, but they aren't as transparent about it) and prevents them from entering the Play store. Apple has pulled malware from the iOS store in the past, but has never made any official comment on it, unlike Google, which does leave one wondering... Knowing that malware authors likely submit to both platforms at the same rate, we know how often Google rejects or removes malware from their store (because they publish the statistics), one should expect that Apple's numbers are roughly the same, but are they? If anyone has a link to some official (e.g. from Apple) stats on that, I'd love to see them.
It's a device with an accelerometer, heart rate monitor, and other sensors that would be immensely useful for sleep tracking. Unfortunately, despite being the best equipped for that task, sensor-wise, it's useless for the job simply due to its battery. Sure, the Pebble Time I ordered as an upgrade to my Pebble doesn't have a heart rate monitor on it, but at least I'll be able to wear it every night for sleep tracking and throw it on the charger when I go out to detail my car (or my wife's) on Sunday.
As an added insult to the Apple Watch: When offered an Apple Watch, my wife, an Apple fan who hates hand-me-downs, asked if she could have my old Pebble when the Pebble Time arrives.
You are correct. However, the post I was replying to was about web apps. If you want to complain to someone about getting it wrong, complain to that poster.
This. If everything is done in the client, the application will lag every time anything processor-intensive is done. Likewise, if the client has to call back to the server every time it does anything, the client will lag on high-latency connections or when the server is overloaded. There's a balance there; the trouble is that most developers don't know how to find it.
I think part of the problem is that web app developers seem to fall into one of two camps: Do everything locally for the best chance of availability, or do everything remotely for the best performance. The first camp is almost right, they do achieve better availability doing everything locally, right up to the point where their app becomes unusable due to processing lag (in other words, they're wrong). The second camp is also almost right, they do achieve the best performance in their local development environment, running in a VM on their workstation, where they're the only user; that falls apart the moment they add thousands users and wildly-variable latency between client and server (in other words, they're wrong).
What I prefer to do is provide all capabilities in the client (a-la first-camp), then identify those that cause the application to lag and implement them on the server (a-la second-camp). Once a function exists in both the client and the server, the client can run a job locally and on the server. If the local job finishes first, the client alerts the server and the server-side job is terminated; if the server returns its result first, the local job is terminated. I find that this structure provides the best performance, as well as availability, since the faster resource will always be the one to return the result used; and if the server is unavailable, times out, or returns an error, the application still works. I find that most users are willing to accept occasional slowness during server outages and upgrades, especially when the application is generally very responsive under normal conditions.
That, I'm sure, can be built upon to predict (e.g. based on bandwidth, latency, and local vs server load and performance) which job will finish first and only start the remote job when it will be the clear winner (still starting the local job just in case). That would give you the benefit of reduced server requirements without impacting application performance (unless you take it too far and don't keep any spare compute power online). I haven't run into an instance where this has been necessary or where the savings would be worth the effort (as evident by the number of cancelled jobs compared to completed jobs), but I'm sure such a case exists.
Huh, I always thought those f'rs floated there. Learn something new every day.
So, any ideas about how to go about "tracking terrorists"?
One need not have a good idea to be able to identify a bad one. In absence of said good idea, the correct action to take is none at all, not carry on with the bad idea because it's all we have. That's how idiots lose limbs cutting down trees and such; it's also how a free and great nation loses that freedom and greatness.
Oh no.... oh no no no no no no no... just... no.
I dunno, my wife could probably kick your ass.
and the Mental Rift isn't even in the pre-design phase
No, it's well beyond that phase; most users already have one. A huge one.
The *volume* of water changes with phase. Mass does not.
But then, you knew that and were just poking fun at the "everything is because of climate change" folks, right?
$29.95, actually.:(