tofumatt

That's a good point and something I haven't thought too far into yet. For now I'd say "no updates that introduce API breakage without notice/semver chnage". But if it's more intricate than that we should discuss it as an issue :-)

It would limit its abilities to do things going forward, like integrate with Firefox's Web IDE. We'd like to, in the future, allow you to package your web app and push it directly to the simulator from a recroom command, so we wanted to make it more than just a set of yeoman templates.

That's really good to hear.

I think you're right about it being like Google's Web Starter Kit. The WSK feels a bit more sparse and less idiomatic than recroom, but it's definitely in the same vein. I haven't checked it out since it was announced a few months back though, so maybe it's grown since then.

I'd love to see people do that to recroom -- add what they think is missing. Pull requests are definitely welcome. My aim is to take the headache out of decisions like "Which framework/tool do I use?" so you can get to writing code if, like me, you don't really care which tool you use as long as it works well.

I know Grunt a bit better, but as I explore Gulp I like it a lot. In the future we may switch, but I'd need the Gulpfile to do everything the Grunt one does.

I have seen some invalidstateerrors on this for some folks. I'm looking into it, sorry! :-/

This is certainly the biggest reason. In the future maybe we can use ember-cli and integrate more with them.

Ember does a LOT of what I want recroom to be able to do, but I'm okay using something that works better right now over using bleeding edge Ember stuff that may be more idiomatic.

Of course, as more people contribute to and use recroom we'll evaluate changing out components. If I picked the wrong thing I hope people will correct it and make this thing better ^_^

You're right on the money. I think people who already know their tools well and have a system that works are covered and are NOT the target audience.

In the future I'd like to sort of ween new users into using recroom by abstracting away a lot of things (we are largely proxying to other commands in grunt/yeoman right now, but the user doesn't need to know these tools to use recroom at a very basic level).

But for me, I feel like an intermediate/experienced developer who has just always wanted an end-to-end idiomatic way to write apps without me knowing all the tools inside-out. I'm hoping recroom will be that most of all, so you're right :-)

Fair enough, I've asked the contributors/users what they think and am open to making the change for 1.0: https://github.com/mozilla/localForage/issues/219

When this was written, iOS 8 was unannounced and folks generally just used localStorage for cross-browser storage. IndexedDB isn't as high-level as some folks would like, and key-value is handy for many apps/sites.

Even with iOS 8's support for IndexedDB, there are edge cases in different browsers localForage handles, and it handles storage of Blob data and TypedArrays transparently too, which is handy.

Thanks for pointing this out; I've filed an issue to add them: https://github.com/mozilla/localForage/issues/218

It uses Promises and callbacks, though you're right it doesn't use node-style. It's not a node library and I frankly dislike needing to supply error as a first arg, as strictly speaking it's optional and just adds cruft.

I had a few folks mention this in the early stages of library development but it hasn't come up since.

You could easily add your own backend relatively easily (the API is easy to copy), though it's not really "optimized" for that yet. It's designed with offline storage for JS in mind though, so the library itself likely won't support remote calls.

I believe the aim is to have email providers be able to auth your persona email instead of Mozilla, but Mozilla exists as a sort of polyfill if the provider (eg. hotmail.com, gmail.com, your-custom-domain.net) doesn't do persona yet.

Also, yes: people can still choose crummy passwords. Personally, I don't think the appeal is in better security; it's convenience of single sign-on without it being tied to a. identity or b. Facebook (or twitter or google or whatever other service that harvests my data).

If you're looking to do remote work because you're sick of your current 9-5, you shouldn't look to remote work to fix anything.

I worked anywhere from 30%-50% a week remote at my last gig and it still requires maintaining somewhat regular hours (you still have colleagues) and a routine. I now work remotely save for trips to the Head Office every once in awhile. You still need a routine because you have other colleagues you need to interface with, at least sometimes in real-time.

If you want to set your own hours and do your own thing, start freelancing or start your own business. My ability to work remotely was an asset when I started at my new job, but if I phrased it like you did ("I don't wanna wear nice closes and drive") it would make me sound more like a sloth than a good remote worker.

And if you work remote, you best be getting out and dressed up at least a day a week anyway. Interaction is REALLY important and you'll go crazy if you don't get out and see people.

Have you ever worked remotely?

Jason is a designer by trade, and is routinely involved with the design of 37signals' products. In the same vein, DHH is a partner in the company, but still writes code (as I understand it).

Ironically, I believe Tweetie 2 used to, before Twitter bought it. It allowed a lot of advanced customization.

Really? Most of the standard web dev stuff (Ruby, PHP, Apache, etc.) comes out of the box and works quite well, and if you need either specialized versions of things (rvm, virtualenv, custom Apache, etc.) or stuff that doesn't come with OS X (lighttpd, node.js, etc.) wouldn't it be installed in /usr/local?

I don't think this will break many web dev tools. Unless you mean stuff like Sequel Pro or TextMate; even then, I can't imagine most apps won't make the transition smoothly.

They're offering users who probably just want to use Twitter easy/quick access to an alternative client so they can get back to tweeting. Given that the app they used to use was banned for privacy violations, the fact that it's the official app is probably a good thing in terms of trust.

Fingerprints will grow back unless you get down to dermal layers of skin and that will hurt quite a bit. Permanently removing your prints is a more involved process than this, but it's certainly a cute idea.

There's Sparrow Lite, an ad-supported free version that's set to release in the Mac App Store but hasn't been approved yet.

Seems they're working on a non-Mac App Store version too. http://blog.sparrowmailapp.com/post/3197243085/sparrow-1-0-i...

37signals has an extensive API built around all their apps with tonnes of 3rd-party native apps for desktop and mobile. If there isn't a native app for your platform, go write one and stop complaining.

And arguing that a web app isn't useful as _a freaking web app_ on your mobile is a little wild to me. There may be deficiencies in areas like file uploads on mobiles, but largely, you interact with Basecamp through a browser on your desktop. Why doesn't a mobile work well? (I've used many iOS Basecamp clients and none were better than the mobile version launched today by 37s).

I love native apps too, and I'm glad that 37signals encourages their existence by providing a solid, well-documented API. And while they do ship some native apps, I totally buy them building really awesome web apps on the desktop, and now on mobiles.

Plus the cost of the cellphone and all the replacements for the cellphone your kid is bound to use.

I'm single and only have a cell, but my friends with kids inform me that landline for a family is the way to go. I see the logic in their argument.

Family households, especially ones with kids who aren't old enough to have a cellphone but need to use a phone. If you have a five and seven year-old in your house, a $30/month landline might make more sense than two cellphones that would never leave the house anyway.

My 2010 MINI (BMW-made) has the same deal, and you could use the stats it gives you (kilometres until empty, average kilometres/litre, and actual tank size in litres) to calculate what's left in your tank, but why not just add it to the displays that already exist?

I also notice European cars (Audi, BMW, MINI, Saab, even VW etc.) tend to be more accurate and linear than American/Japanese vehicles. But that's just me.

Apple will not prevent ad-hoc app distribution on the Mac; doing so would prevent Adobe from releasing Creative Suite on the Mac because of their non-App Store-compatible licensing.

Won't happen. Or if it does, easy: time to leave the Mac.

A touchscreen that docks to a keyboard eh? Have you seen the iPad keyboard dock? Aside from lack of mouse (which would be marginally useful in iOS, if at all), that's what an iPad + keyboard dock is.

Compaq and some others made resistive tablets like you might be getting at a decade ago and one of the biggest problems was that they all ran Windows XP and were underpowered, so you just got a smaller, heavier, less capable Windows box you could draw on.

The presentation is there to convince you to use their script. I think more OSS libraries and software should convey such an attitude; I'm way more inclined to use software when the authors tell me that it's awesome and why.

This is really cool. Hope you can deal with the legal issues, because I would use this for sure.

Fragmentation, in this case, is the result of an unmanageable amount of choices. There's a happy medium here, and I don't think the number of different Android handsets is anywhere near it.

There's something about the word "sync" that implies, y'know, a sync. I said no to contact sync when I installed Facebook for iPhone and that was that -- no problem.