I agree--grand parent's assertion of "standardized interfaces they will be slower in achieving greater emissions and fuel efficiency" is complete bullshit. Citation needed like never fucking before.
I know cars and I like modern cars. I don't do well with carburetors. Give me a fuel-injected, electronically controlled system all day long. Give me a modern ECU that will automatically adjust for barometric pressure and ambient temperature. Give me an ECU that will give me good fuel efficiency and emissions. I race my car, but I do not remove my catalytic converter.
They don't want to expose the dealer interface for reprogramming a car's mileage, VIN inside the ECU or new keys w/o having the two existing keys. That's the entire extent of the security concern with the exposure of this information.
Otherwise, if my car is malfunctioning and I want to diagnose why it's not running right, I am all too often hampered or screwed without the dealer tools.
Simple example first: my car developed a knock in a cylinder. To find out whether it's a valve or a rod bearing or piston-slap, I have only one option: disconnect the ignition connector and the fuel connector, start the car, shut it off, etc repeat for each cylinder. However, the dealer can simply go into a menu and trigger an ON_1/OFF_1 (from 1 to 4) for each cylinder, doing the same thing electronically, faster and safer.
Complex scenario: diagnosing catalytic converter failure (which is very emissions relevant!) If the car is running rough or is down on power, especially top-end power, it's possible that this might be caused by a catalytic converter. However, many other things could also be wrong to cause this. The best you gonna do as a DIYer right now (for a 2004+ Mazda, in my case) is to wait until the computer throws a check engine light complaining of cat converter inefficiency. However, your situation might be right on the threshold of the rather-generous factory allowance for catalytic converter performance. The dealer can simply pull up a page of emission stats the the car tracks, which lists catalytic converter efficiency. If it's near the bottom of the range, especially for a car with lower mileage, then you have a dying converter. You can monitor this setting over time as well (E.g. over two weeks) and see if it degrades. Having access to this information can save you non-trivial dollars in gas mileage (e.g. highway can drop from 30mpg to 24mpg easily), fouled up spark plugs and (albeit small) risk of engine damage. Since most modern cars run spark plugs capable of long term replacement intervals, such as 60K miles, you risk fouling up an expensive set of plugs.
This is the simple stuff too. Troubleshooting your ABS system? You get nothing other than an ABS light. Could it be a tear in wiring to an ABS sensor? If you are crafty, you can solder that up cleanly yourself for pennies. Could it be air in the brake lines that got into the ABS module? Bleed the air for the cost of a half liter of brake fluid ($10). If a wheel speed sensor shat the bed, that's a $75 repair. If the ABS module shat the bed, well that's much more expensive. Going to the dealer to find out what the ABS light is all about? You will get slapped with a $90 (1 hr labor) diagnostic fee. As a car enthusiast and an engineer, I don't like paying $90 for 5 minutes of diagnostics. What if you go to your local repair shop for the same problem? If they can't read the ABS code, they will have to spend time going down the list of possible things that could go wrong. E.g. all 4 wheel sensors and wiring would have to be inspected (hope the tear is not obvious or not a failed wire inside a connector, where it's not visible!), brakes bled just in case, parts possibly replaced unnecessarily (on a hunch for a common problem). The pure waste in labor that an independent shop has to do wastes the shop's time and your money.
The starter always confirms the starting car's number at the starting line. So if someone gets into the wrong grid spot, it doesn't matter because their car number would be still correct at the starting line. If someone is driving someone else's car and doesn't inform timing appropriateyl, then you would have that problem anyway.
Reruns are not an issue because they are just like regular runs, except done again for a special reason. Cars still line up at the starting line in a certain order to run a re-run.
Double-driver cars are not an issue with sequencing--with any other solution, the club needs to know which driver is at the starting line.
The order that's the same is the order of cars that have been launched from the starting line, not the order of cars lining up for that line.
It doesn't, because at that point, the car that spun is considered a "DNF." The car that spun can be instructed to not to trip the timing lights and if they do, it can be fixed.
In autocross, cars are not allowed to pas each other. If someone spins and the car behind gets too close (within 10 seconds), it gets red-flagged and gets a re-run.
I autocross and I've been thinking about the same problem. I even thought about writing my own free software and building plans for off-the-shelf/cheap-to-make transponders ($1200 for a wireless transmitter unit? jesus).
The problem is that if a car doesn't finish and misses the timing mark--the software shoudl just let you to fix it up. You should be able to say "this car didn't finish" (has a missing tick) or "ignore this tick" (some corner worker tripped the lights accidentally). Then it shoudl be able to just recalculate the times affected. It seems so simple to me, I am baffled that it hasn't been implemented.
All the cars starts in the same order, all the numbers are known at hte start time and cars never pass each other. So you have always same-sequence travel of cars. All you need to do is fix occassional lacks of ticks or extra ticks. No need to re-run the cars.
Verizon/AT&T probably do not keep historical data, even if they can pinpoint my location at law enforcement's request.
The problem is that we have traffic laws with unrealistic speed limits in this country, towns that will raise revenue through ticket writing and red light cameras, all now with access to your OnStar data without your consent or a warrant. Drivers that go with the flow of traffic are safer due to a smaller speed differential--but your insurance company may be glad to force you to do 65 on a road designed for 75mph in the 70's (MassPike) or 55 on a newly widened 3-lane widely-divided highway (rt 3 Greater Boston).
towns shorten yellow lights to get more red light tickets--increase in rear-end accidents be damned. Wouldn't it be nice to corroborate that data with the onstar gps log?
Unless the TFA is talking about SFTP (which it isn't), there is no reason to laud anything positive about FTP. Other than it was a straightforward protocol and it served us well, back in the day.
This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.
Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.
Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?
Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.
That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.
Problem is, object-oriented programming is useful when it is applied on an as-needed basis.
Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.
So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.
There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.
WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.
I don't know whether you've gotten caught up in the UML/"design lots of patterns"/"writing code is for suckers" hoopla of the late 90's early 2000's--as if you didn't, you'll have a much easier time learning state of the art in development, while being able to apply enough experience from your younger days. (Consider everything that has to do with J2EE Enterprise Java of early 2000's as an example of what not to do.)
If you want to become current, you are going to need to learn to do:
1) Test-driven development 2) Write clean, expressive code (with much less need for comments and documentation) 3) Object-oriented design, as used to solve actual problems (not just putting functions into classes) 4) Design for what you need now or in the immediate future and refactor only as needs change 5) The Do Not Repeat Yourself principle. No duplication or copy/pasting.
The best advice I give to any starting out developer these days is to read Robert Martin's book Clean Code. It distills the wisdom of many an experienced programmer into a clear, well-explained format. It's Java-centric, but principles apply everywhere. Read it and see why separation of concerns is good, why keeping your functions at the same level of abstraction is good, why the single responsibility principle is good.
That book is the first book that explained to me properly why I should give a crap about the Law of Demeter. That law has been around since 1987 and yet I rarely came across anything but explanations with sterile, academic examples. Yet, "Clean Code" showed me why it's bad in closer-to-home terms AND, best of all, instantly provided a rewritten version that didn't violate the law and was clearly better.
One important point: it's not the languages you know, it's whether you know how to code well, design well and analyze problems well. All languages are just tools.
Modern development has finally stopped pissing over code and began respecting code. Gone are the days of trying to make UML diagrams generate Java (Model-Driven Architecture seems to have successfully passed us by without doing too much damage). In the web apps world, I think Ruby on Rails exemplifies latest thinking in software engineering, namely the thinking of "less code = better" and how to add abstraction layers without imposing code overhead in your application (e.g. convention over configuration).
"home screen is just an app," "keyboard is just an app" -- don't care. Don't care to install any OS version I want. Don't care to install a different home screen. That's not usability, that's just a pain in my neck.
Widgets are probably cool, but for multitasking, quoth Larry Page: "software running in the background that just sort of exhausts the battery quickly."
For me usability is not caring about anything like how many apps are open or whether anything's draining my battery. I just want to do things and care as little as possible about anything other than the thing I'm doing. With the iPhone, I don't ever think about closing any apps. My friend, who has a PocketPC phone, is always compulsively tries to close the browser on my iPhone before putting it away and I always tell her "it doesn't matter, just hit the sleep button." You don't have to exit out of anything, you don't have to close anything, there are no trojans that can stay running in the background. It's nice.
3) Upgradability:
That's nice. And you can swap multiple MicroSD cards, which, while a pain, can come in handy if use your phone in different enough sitautions.
4) Flexibility:
That's nice too. However, in general, I have been very happy with the choice of apps on the Apple app store and they do a lot of different things. I haven't felt the need to get a different browser--I quite like what comes with the phone.
The new sensor is bigger now, maintaining the same pixel size.
So you get more megapixels due to a larger sensor AND you get better sensitivity due to backside illumination.
I have a DSLR for quality pictures... for the rest, social situations and what not, 5 megapixels is plenty good and better low light performance just might make this good enough to obviate the need for a separate point & shoot camera.
I'd love to see some HTC Evo 8MP vs iPhone 4 5MP camera quality comparisons.
Bullshit back on you. False comparison. Lacking features != a crappy product. It just means a product that does less. First iPhone OS version didn't have exchange integration or copy/paste, but what was there worked well and was designed to work well. In fact, until Apple was convinced that it could do copy/paste well, it didn't release that feature. That's just not biting off more than you can chew.
There's a gulf of difference between shipping something that's limited in functionality to something that is crappy. Have you ever used the PocketPC PDAs back in the day? I've used a Palm OS-based Handspring and a PocketPC Dell Axim, and let me tell you, the Handspring, with its limited feature set and a slow CPU, did the core PDA things (calendar, todo) a lot better than the Axim. The Axim felt slow (despite a several times faster CPU) and it was harder to work with the calendar (more taps to do things, weird options I didn't need). I hated using it and wrote off PocketPC after that (which is why I never bought a Treo with Windows). That's what "shipping crap" means.
I think you're naive in putting down the iPad (or any Android or WebOS tablet) as a cheap device that's not fit for real work. How much horsepower do you think you really need? Do you need multi-GHZ processors to run bloated apps on top of Windows? These tablets run lean apps that are optimized for these "cheap devices"--and they certainly don't feel any slower. The fact is my Palm Handspring felt faster and snappier to use than a PocketPC Axim I had, despite the latter having four-five times as fast a processor.
With all the Slashdot bitching and moaning about how bloated apps have become these days, you should be happy that a cheap device can run web browsing, word processing and photo editing software at what feels like full desktop speeds.
Are you serious? How is this different from any other digital transfer method? And how could this possibly plug the analog hole? As long as you gots a speaker and a microphone or an analog transfer of audio (e.g. to your headphones), you have the whole. Tell me, is this going to do away with headphones?
Paint that eats asphalt? Please, paint did not let the asphalt breathe and soak in water, which caused in issues in the winter. Should they have known that? Yes, but apparently it's a new technology. If they didn't use it, you would've been complaining that Taxachusetts is still using decades-old paint technology, instead of this newfangled thermoplastic paint that's working so great in Texas.
The acquisition FAQ says that they are excited to work on new webmail interfaces.
However, I just don't get that spirit of insight and innovation from the Opera team or the Fastmail team. I don't think they really have the chops to look past gmail and think about what the next best e-mail experience is. I feel that they will forever be constrained by the old-school thinking of the underlying protocols.
I agree. One of Fastmail's big draws was its lightweight, fast-loading, reasonable web interface. Sadly, that interface has stagnated and is barely keeping up.
I don't do local e-mail clients anymore (other than my smartphone). For any desktop e-mail needs, it's the web browser. So a lot of the value is in the web browser.
For example, Gmail had autosave way-way before Fastmail (to protect against browser crashes). Fastmail, as a commerical e-mail provider, should've been jumping on copying that, to match their web interface with those of the free competitors. Sadly, they didn't and that says a lot about what the company's vision is and what it isn't.
Their spam filtering is very good, but not as good as Gmail's. Yeah, I can define custom rules via Sieve, which was a fun novelty until I got tired of writing the rules by hand. At some point, e-mail becomes that damn thing that has to work and you want to spend less time tinkering and more time doing other, more interesting things.
There really is very little keeping me at Fastmail now and this acquisition makes me think twice about switching away. I have a $35/yr top-notch account.
"92% of these medical debtors had medical debts over $5000, or 10% of pretax family income. The rest met criteria for medical bankruptcy because they had lost significant income due to illness or mortgaged a home to pay medical bills. Most medical debtors were well educated, owned homes, and had middle-class occupations. Three quarters had health insurance."
So while the medical debt is not necessarily sky-high, losing your job due to illness means that you are screwed on all your debts. Car, house, etc.
Also, further down: "Out-of-pocket medical costs averaged $17,943 for all medically bankrupt families"... this means that these families successfully paid A LOT of money (~$13K) before declaring bankruptcy and ending up in an average of ~$5K of medical debt. These are not the people that ran up huge consumer debts and declared bankruptcy. These are the people that paid every bill until they just had no money left.
The TFA misses the point by miles. It's a false dichotomy.
All these "free-thinkers", artists, musicians creative professionals, etc, are trying to get shit done with minimum distractions. They couldn't give two shits if the software was FOSS or written by enslaved monkeys. They are trying to accomplish a project on a deadline or write the music when feeling inspired. The last thing on their mind is the computer.
The article is basically complaining that people who just want a car from A to B are choosing numb, non-sporty Toyota Camry automatics to commute to work. Why oh why won't they choose a little sports car with a shift stick, so they could experience the joy of carving out every corner and onramp with the control of a manual transmission?
Oh yeah, those people just want to get from A to B. It must be a cult!
This pre-history is fairly entertaining in that it exposes the low-effort groupthink of these tech bloggers/pundits/opinionators. The limited imagination is evident by most just putting together the iPod and the iPhone in the most obvious of ways: click wheel iPod with phone dialing functionality. Oh wait, how do you dial? Let's propose a slideout keyboard, yeah, that's it! And half those interface mockups look like a PocketPC screenshot with an Aqua theme.
Imagine if Apple did actually put out such an iPod + clickwheel + keypad combo, behaving like an iPod + dialing features or behaving like a PocketPC/Windows Mobile phone of the era. It would be a flop in comparison to how well the iPhone actually sold.
The moral of the story is that it takes critical thinking to truly innovate (that, and a massive design effort that's focused on user experience and not a feature list).
Slashdot Mirror
I agree--grand parent's assertion of "standardized interfaces they will be slower in achieving greater emissions and fuel efficiency" is complete bullshit. Citation needed like never fucking before.
I know cars and I like modern cars. I don't do well with carburetors. Give me a fuel-injected, electronically controlled system all day long. Give me a modern ECU that will automatically adjust for barometric pressure and ambient temperature. Give me an ECU that will give me good fuel efficiency and emissions. I race my car, but I do not remove my catalytic converter.
They don't want to expose the dealer interface for reprogramming a car's mileage, VIN inside the ECU or new keys w/o having the two existing keys. That's the entire extent of the security concern with the exposure of this information.
Otherwise, if my car is malfunctioning and I want to diagnose why it's not running right, I am all too often hampered or screwed without the dealer tools.
Simple example first: my car developed a knock in a cylinder. To find out whether it's a valve or a rod bearing or piston-slap, I have only one option: disconnect the ignition connector and the fuel connector, start the car, shut it off, etc repeat for each cylinder. However, the dealer can simply go into a menu and trigger an ON_1/OFF_1 (from 1 to 4) for each cylinder, doing the same thing electronically, faster and safer.
Complex scenario: diagnosing catalytic converter failure (which is very emissions relevant!) If the car is running rough or is down on power, especially top-end power, it's possible that this might be caused by a catalytic converter. However, many other things could also be wrong to cause this. The best you gonna do as a DIYer right now (for a 2004+ Mazda, in my case) is to wait until the computer throws a check engine light complaining of cat converter inefficiency. However, your situation might be right on the threshold of the rather-generous factory allowance for catalytic converter performance. The dealer can simply pull up a page of emission stats the the car tracks, which lists catalytic converter efficiency. If it's near the bottom of the range, especially for a car with lower mileage, then you have a dying converter. You can monitor this setting over time as well (E.g. over two weeks) and see if it degrades. Having access to this information can save you non-trivial dollars in gas mileage (e.g. highway can drop from 30mpg to 24mpg easily), fouled up spark plugs and (albeit small) risk of engine damage. Since most modern cars run spark plugs capable of long term replacement intervals, such as 60K miles, you risk fouling up an expensive set of plugs.
This is the simple stuff too. Troubleshooting your ABS system? You get nothing other than an ABS light. Could it be a tear in wiring to an ABS sensor? If you are crafty, you can solder that up cleanly yourself for pennies. Could it be air in the brake lines that got into the ABS module? Bleed the air for the cost of a half liter of brake fluid ($10). If a wheel speed sensor shat the bed, that's a $75 repair. If the ABS module shat the bed, well that's much more expensive. Going to the dealer to find out what the ABS light is all about? You will get slapped with a $90 (1 hr labor) diagnostic fee. As a car enthusiast and an engineer, I don't like paying $90 for 5 minutes of diagnostics. What if you go to your local repair shop for the same problem? If they can't read the ABS code, they will have to spend time going down the list of possible things that could go wrong. E.g. all 4 wheel sensors and wiring would have to be inspected (hope the tear is not obvious or not a failed wire inside a connector, where it's not visible!), brakes bled just in case, parts possibly replaced unnecessarily (on a hunch for a common problem). The pure waste in labor that an independent shop has to do wastes the shop's time and your money.
The starter always confirms the starting car's number at the starting line. So if someone gets into the wrong grid spot, it doesn't matter because their car number would be still correct at the starting line. If someone is driving someone else's car and doesn't inform timing appropriateyl, then you would have that problem anyway.
Reruns are not an issue because they are just like regular runs, except done again for a special reason. Cars still line up at the starting line in a certain order to run a re-run.
Double-driver cars are not an issue with sequencing--with any other solution, the club needs to know which driver is at the starting line.
The order that's the same is the order of cars that have been launched from the starting line, not the order of cars lining up for that line.
It doesn't, because at that point, the car that spun is considered a "DNF." The car that spun can be instructed to not to trip the timing lights and if they do, it can be fixed.
In autocross, cars are not allowed to pas each other. If someone spins and the car behind gets too close (within 10 seconds), it gets red-flagged and gets a re-run.
I autocross and I've been thinking about the same problem. I even thought about writing my own free software and building plans for off-the-shelf/cheap-to-make transponders ($1200 for a wireless transmitter unit? jesus).
The problem is that if a car doesn't finish and misses the timing mark--the software shoudl just let you to fix it up. You should be able to say "this car didn't finish" (has a missing tick) or "ignore this tick" (some corner worker tripped the lights accidentally). Then it shoudl be able to just recalculate the times affected. It seems so simple to me, I am baffled that it hasn't been implemented.
All the cars starts in the same order, all the numbers are known at hte start time and cars never pass each other. So you have always same-sequence travel of cars. All you need to do is fix occassional lacks of ticks or extra ticks. No need to re-run the cars.
Verizon/AT&T probably do not keep historical data, even if they can pinpoint my location at law enforcement's request.
The problem is that we have traffic laws with unrealistic speed limits in this country, towns that will raise revenue through ticket writing and red light cameras, all now with access to your OnStar data without your consent or a warrant. Drivers that go with the flow of traffic are safer due to a smaller speed differential--but your insurance company may be glad to force you to do 65 on a road designed for 75mph in the 70's (MassPike) or 55 on a newly widened 3-lane widely-divided highway (rt 3 Greater Boston).
towns shorten yellow lights to get more red light tickets--increase in rear-end accidents be damned. Wouldn't it be nice to corroborate that data with the onstar gps log?
Shh, Slashdot heads might explode.
Unless the TFA is talking about SFTP (which it isn't), there is no reason to laud anything positive about FTP. Other than it was a straightforward protocol and it served us well, back in the day.
Oops, accidental A/C post
This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.
Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.
Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?
Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.
That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.
Problem is, object-oriented programming is useful when it is applied on an as-needed basis.
Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.
So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.
There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.
WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.
I don't know whether you've gotten caught up in the UML/"design lots of patterns"/"writing code is for suckers" hoopla of the late 90's early 2000's--as if you didn't, you'll have a much easier time learning state of the art in development, while being able to apply enough experience from your younger days. (Consider everything that has to do with J2EE Enterprise Java of early 2000's as an example of what not to do.)
If you want to become current, you are going to need to learn to do:
1) Test-driven development
2) Write clean, expressive code (with much less need for comments and documentation)
3) Object-oriented design, as used to solve actual problems (not just putting functions into classes)
4) Design for what you need now or in the immediate future and refactor only as needs change
5) The Do Not Repeat Yourself principle. No duplication or copy/pasting.
The best advice I give to any starting out developer these days is to read Robert Martin's book Clean Code. It distills the wisdom of many an experienced programmer into a clear, well-explained format. It's Java-centric, but principles apply everywhere. Read it and see why separation of concerns is good, why keeping your functions at the same level of abstraction is good, why the single responsibility principle is good.
That book is the first book that explained to me properly why I should give a crap about the Law of Demeter. That law has been around since 1987 and yet I rarely came across anything but explanations with sterile, academic examples. Yet, "Clean Code" showed me why it's bad in closer-to-home terms AND, best of all, instantly provided a rewritten version that didn't violate the law and was clearly better.
One important point: it's not the languages you know, it's whether you know how to code well, design well and analyze problems well. All languages are just tools.
Modern development has finally stopped pissing over code and began respecting code. Gone are the days of trying to make UML diagrams generate Java (Model-Driven Architecture seems to have successfully passed us by without doing too much damage). In the web apps world, I think Ruby on Rails exemplifies latest thinking in software engineering, namely the thinking of "less code = better" and how to add abstraction layers without imposing code overhead in your application (e.g. convention over configuration).
Just because something is easier to use and works right without having to FK with it, doesn't mean it sucks for the advanced user.
No, if you return it, you are not obligated to the contract.
1) Standards & development:
You're right.
2) Usability:
"home screen is just an app," "keyboard is just an app" -- don't care. Don't care to install any OS version I want. Don't care to install a different home screen. That's not usability, that's just a pain in my neck.
Widgets are probably cool, but for multitasking, quoth Larry Page: "software running in the background that just sort of exhausts the battery quickly."
For me usability is not caring about anything like how many apps are open or whether anything's draining my battery. I just want to do things and care as little as possible about anything other than the thing I'm doing. With the iPhone, I don't ever think about closing any apps. My friend, who has a PocketPC phone, is always compulsively tries to close the browser on my iPhone before putting it away and I always tell her "it doesn't matter, just hit the sleep button." You don't have to exit out of anything, you don't have to close anything, there are no trojans that can stay running in the background. It's nice.
3) Upgradability:
That's nice. And you can swap multiple MicroSD cards, which, while a pain, can come in handy if use your phone in different enough sitautions.
4) Flexibility:
That's nice too. However, in general, I have been very happy with the choice of apps on the Apple app store and they do a lot of different things. I haven't felt the need to get a different browser--I quite like what comes with the phone.
The new sensor is bigger now, maintaining the same pixel size.
So you get more megapixels due to a larger sensor AND you get better sensitivity due to backside illumination.
I have a DSLR for quality pictures... for the rest, social situations and what not, 5 megapixels is plenty good and better low light performance just might make this good enough to obviate the need for a separate point & shoot camera.
I'd love to see some HTC Evo 8MP vs iPhone 4 5MP camera quality comparisons.
Bullshit back on you. False comparison. Lacking features != a crappy product. It just means a product that does less. First iPhone OS version didn't have exchange integration or copy/paste, but what was there worked well and was designed to work well. In fact, until Apple was convinced that it could do copy/paste well, it didn't release that feature. That's just not biting off more than you can chew.
There's a gulf of difference between shipping something that's limited in functionality to something that is crappy. Have you ever used the PocketPC PDAs back in the day? I've used a Palm OS-based Handspring and a PocketPC Dell Axim, and let me tell you, the Handspring, with its limited feature set and a slow CPU, did the core PDA things (calendar, todo) a lot better than the Axim. The Axim felt slow (despite a several times faster CPU) and it was harder to work with the calendar (more taps to do things, weird options I didn't need). I hated using it and wrote off PocketPC after that (which is why I never bought a Treo with Windows). That's what "shipping crap" means.
I think you're naive in putting down the iPad (or any Android or WebOS tablet) as a cheap device that's not fit for real work. How much horsepower do you think you really need? Do you need multi-GHZ processors to run bloated apps on top of Windows? These tablets run lean apps that are optimized for these "cheap devices"--and they certainly don't feel any slower. The fact is my Palm Handspring felt faster and snappier to use than a PocketPC Axim I had, despite the latter having four-five times as fast a processor.
With all the Slashdot bitching and moaning about how bloated apps have become these days, you should be happy that a cheap device can run web browsing, word processing and photo editing software at what feels like full desktop speeds.
Open source player to be someone's bitch?
Are you serious? How is this different from any other digital transfer method? And how could this possibly plug the analog hole? As long as you gots a speaker and a microphone or an analog transfer of audio (e.g. to your headphones), you have the whole. Tell me, is this going to do away with headphones?
Paint that eats asphalt? Please, paint did not let the asphalt breathe and soak in water, which caused in issues in the winter. Should they have known that? Yes, but apparently it's a new technology. If they didn't use it, you would've been complaining that Taxachusetts is still using decades-old paint technology, instead of this newfangled thermoplastic paint that's working so great in Texas.
http://wbztv.com/curious/white.paint.lines.2.1021788.html
So yeah, now they will have to repave Rt 24 earlier than scheduled (and it was already scheduled for repaving).
The acquisition FAQ says that they are excited to work on new webmail interfaces.
However, I just don't get that spirit of insight and innovation from the Opera team or the Fastmail team. I don't think they really have the chops to look past gmail and think about what the next best e-mail experience is. I feel that they will forever be constrained by the old-school thinking of the underlying protocols.
I agree. One of Fastmail's big draws was its lightweight, fast-loading, reasonable web interface. Sadly, that interface has stagnated and is barely keeping up.
I don't do local e-mail clients anymore (other than my smartphone). For any desktop e-mail needs, it's the web browser. So a lot of the value is in the web browser.
For example, Gmail had autosave way-way before Fastmail (to protect against browser crashes). Fastmail, as a commerical e-mail provider, should've been jumping on copying that, to match their web interface with those of the free competitors. Sadly, they didn't and that says a lot about what the company's vision is and what it isn't.
Their spam filtering is very good, but not as good as Gmail's. Yeah, I can define custom rules via Sieve, which was a fun novelty until I got tired of writing the rules by hand. At some point, e-mail becomes that damn thing that has to work and you want to spend less time tinkering and more time doing other, more interesting things.
There really is very little keeping me at Fastmail now and this acquisition makes me think twice about switching away. I have a $35/yr top-notch account.
Exactly! Slapping Android on a tablet is an easy answer and easy answers to hard problems never sold well.
Here's a study: http://download.journals.elsevierhealth.com/pdfs/journals/0002-9343/PIIS0002934309004045.pdf ("Medical Bankruptcy in the United States, 2007: Results of a National Study")
"92% of these medical debtors had medical debts over $5000, or 10% of pretax family income. The rest met criteria for medical bankruptcy because they had lost significant income due to illness or mortgaged a home to pay medical bills. Most medical debtors were well educated, owned homes, and had middle-class occupations. Three quarters had health insurance."
So while the medical debt is not necessarily sky-high, losing your job due to illness means that you are screwed on all your debts. Car, house, etc.
Also, further down: "Out-of-pocket medical costs averaged $17,943 for all medically bankrupt families" ... this means that these families successfully paid A LOT of money (~$13K) before declaring bankruptcy and ending up in an average of ~$5K of medical debt. These are not the people that ran up huge consumer debts and declared bankruptcy. These are the people that paid every bill until they just had no money left.
The TFA misses the point by miles. It's a false dichotomy.
All these "free-thinkers", artists, musicians creative professionals, etc, are trying to get shit done with minimum distractions. They couldn't give two shits if the software was FOSS or written by enslaved monkeys. They are trying to accomplish a project on a deadline or write the music when feeling inspired. The last thing on their mind is the computer.
The article is basically complaining that people who just want a car from A to B are choosing numb, non-sporty Toyota Camry automatics to commute to work. Why oh why won't they choose a little sports car with a shift stick, so they could experience the joy of carving out every corner and onramp with the control of a manual transmission?
Oh yeah, those people just want to get from A to B. It must be a cult!
This pre-history is fairly entertaining in that it exposes the low-effort groupthink of these tech bloggers/pundits/opinionators. The limited imagination is evident by most just putting together the iPod and the iPhone in the most obvious of ways: click wheel iPod with phone dialing functionality. Oh wait, how do you dial? Let's propose a slideout keyboard, yeah, that's it! And half those interface mockups look like a PocketPC screenshot with an Aqua theme.
Imagine if Apple did actually put out such an iPod + clickwheel + keypad combo, behaving like an iPod + dialing features or behaving like a PocketPC/Windows Mobile phone of the era. It would be a flop in comparison to how well the iPhone actually sold.
The moral of the story is that it takes critical thinking to truly innovate (that, and a massive design effort that's focused on user experience and not a feature list).