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).

I ask you that you go into it with an open mind. Agile stuff has been treated as an overhyped bogeyman (look at all the posts here) and understandably many of us geeks are very cautious to approach it. However, if you pull the layers of hype and bullshit away, you recognize that it's just a different mindset that guides the work. This mindset happens to work a lot better with people and software (I am now convinced of this).

I'm hoping that you have a good instructor for training. But also, I am hoping that you have access to that instructor for questions afterwards, because that's really the most useful part. Every kind of training I've seen presents idealized examples to some degree, but a smart instructor will be able to tell you how you can work your situation.

For example, for varied skill sets, once you make up your team, try to take on a mix of stories (simplified use cases) that *approximately* reflects the skills breakdown. For example, if you have only two people that can touch your matrix code, take only on one or two matrix-work-intensive stories per sprint. After all, you have to be realistic.

(However, maybe a third person on your team would like to learn this matrix code. By sitting that person down with the matrix code expert and going through several dev tasks together, that person may learn something and may pick up these skills. Sure, it will feel slower at first, but now you have greater versatility in your team.)

If you are primarily doing fixes, then just reflect that in your wording of the stories. For example, we had to do some work to improve the startup performance of our product. We came up with stories that said, "As an administrator, I want my server to restart in less than X seconds." When we did some loose estimates, we realized that this was too much work to fit into a one-week sprint. So we split it into "As an administrator, I want my server to restart in less than X seconds, on Windows" and "... on Linux." This is because after doing some investigation, we realized that there was a lot of different work to be done for Windows vs Linux. This is not a perfect split of user stories (you want to keep such platform details out as much as possible), but that's OK. Do what works for you.

I have resolved to myself that, if I can help it, I am never again going to work at a place that does old-school waterfall. My team right now is in the middle of a transition to a Scrum-esque approach. We are running into plenty of problems, our team members have varied skills and some are much more versatile than others (Etc etc). However, it's already a better situation than what we had before.

So far, I am enjoying working off a prioritized product backlog, concentrating on getting smaller features DONE DONE, working in short iterations (2 weeks), and having the team who is fairly open to "let's change it if it doesn't work".

For one, many times before, spend months nailing down a long list of requirements, estimating the whole freaking thing, arguing between product management and engineering, cutting things to try to fit a set of features into some deadline (based on start-of-project estimates). Our product management would fight to keep certain things in that were important but not that important (because they did not want them to get dropped until the next release, that was many many months away). The developers (including me) would sit there, pulling estimates out of our collective ass for a ton of features, with barely any information for some of them.

Then we'd write extensive software requirement specifications (SRS) based on what was agreed to be implemented. The QA would go off to write test cases based on those SRSs. Of course, the use cases in these requirements were too detailed in some respects and not detailed enough in others, and completely missing the boat in yet other aspects. But, since they were signed off as "complete", we spent the rest of the project following what was agreed upon in the beginning instead of adjusting to the new process.

NOW, with the new process, we only estimate maybe 2-3 months of work, and even those we do loosely, using relative sizing (this thing is way harder than this other thing, this other thing is much easier, etc), without doing detailed task breakdowns. We only do detailed task breakdowns for stories (think of them as simplified use cases) for the next two weeks. Those task breakdowns are pretty detailed (we try to split tasks until they can be done in a day or less), but, again, we only do it for 2 weeks worth (every 2 weeks). This spreads out the pain.

So the benefit is that we only take on the most important work first. We can only do so much stuff in the next 2 weeks or two months. So all this detailed planning happens only for the most important things that the product management cares about. Every 2 weeks, the product management can reshuffle priorities and that's ok! No problem, we'll take on whatever is required next.

Developers are liking this because they don't spend weeks and months estimating everything under the sun. Product management is liking this because they can shuffle things around as market conditions change or other information comes to light.

ALSO, focusing on done done done. We used to have this "code complete" date. So some features took way longer to get done (often due to unexpected technical problems... sounds familiar?) and some were quicker than expected. Since one or two people would be working on each feature over the period of 6 weeks or longer, and even then, they only had to report some progress over those weeks. The "code complete" (or "feature complete") date was the date by which all features needed to be finished. Then we'd test and fix any bugs.

So, of course, what happens is that if the feature had technical issues, some coders would rush to check in code without writing enough tests or really even just testing it enough. Often, they would compromise design just to get it in by the date. So often, we'd have poor, half-baked code checked in by this "code complete" date. Now, testing afterwards starts revealing issues. Sometimes, the issues require a design adjustment, but now it's too late to make that design adjustment because we are in this "endgame."

Of course, you can make an argument that a better developer would not call a feature complete without sufficient testing. This better developer should've gone to the manager and said "this can't be done by the deadline" and let the management deal with that. The reality is that in a typical larger corporation, we have a lot of not-so-better developers, who are content on just cranking out something that qualifies as "coded" by this "code complete" date.

SO, by focusing the team on having smaller features be really "done" AND demonstrable by the end of the iterations really forces any issues to the surface. The feature has to be fully tested and work or it's not done. Oh shit, we have technical issues that add work and means we can't finish functional tests for this sprint? Well, no functional tests, then it's not done. OK, so that comes up right away (or at the latest by the end of the sprint) and we can then deal with it by readjusting stories, tasks, etc (and everyone realizes that this is OK).

By talking about the process and how everything went every 2 weeks, we have a chance for people to complain. Because all agile processes encourage adjustment and feedback, you can try things one way for a sprint or another way.

Of course, all of this requires management and coworkers open to change. You will find that most are open to it.

The problem is that now you're at the mercy of the cop. Not sure how they are where you live, but between me and my friends here in good old Massachusetts, we have been illegally searched by a pissed off statie, many times pulled over for bullshit reasons (were not the ones speeding, were not the ones peeling out in a nearby parking lot).

Do you ever play a little much with the radio in your car, looking too long trying to dial in a specific radio frequency? OK, so that's an instance of distracted driving that's as bad as typing a text message for the same 10 seconds, for the same basic reason that you are not paying attention to the road. Have you been involved in a really intense conversation (fighting with your girlfriend, e.g.) while driving and were deep in that instead of thinking about what's around you?

Have you ever spent too long starting at the windshield-mounted GPS screen trying to figure out just where the hell it's telling you to go? Distracted driving. Have you spent too long fishing around in your car for that gadget or sandwich or whatever else you were trying to get?

Anyways, distracted driving is a driver's mindset. You are either aware of the fact that you are not looking at the road when you do certain things and then you do your best to NOT do those things. Or you are not aware and you do other dumb things, in addition to texting.

So what now? I am sitting at a red stoplight, which I know takes at least a minute to switch. I can't take 10 seconds to text someone that I'll be late? It's perfectly safe and the worst thing is that I'll get honked at if the light turns green before I pay attention. I have made a thoughtful, careful choice. Yet according to the law, I am as bad as a drunk driver. Fuck yeah America!

  In my opinion, it would've been more effective to start education campaigns and enforcing extensively a simple moving violation ticket. Nobody wants to get a moving violation because your insurance rates start going up (no matter whether you were ticketed for a 5mph over or running a red light). With enforcement and public education, you would've had much higher impact than by declaring that you can face a 15 year jail sentence.

The only people who are truly happy about this are the lawyers who are about to get a lot more business than DUI defense.

Traffic fatalities rates have actually been steadily going down in the recent years and are lowest they ever were. I think this is mostly due to better cars (for example, stability control reduces accidents by about 30%, we have better tires, fewer old cars on the road that can't make a good evasive maneuver).