fwenzel

Thank you for asking! That depends on the role - some of them have specific subject matter requirements listed in the job descriptions (for instance a deep knowledge of computational geometry), though not all.

Hard to answer that as I lack your exact frame of reference.

Generally, employees of Mozilla Corp. are paid (and managed) to contribute to specific aspects of the Mozilla project. Sounds confusing, but essentially, imagine there is a new feature for Firefox browser's rendering code that needs implemented -- it's open source so technically anyone can submit a patch, but Mozilla-the-legal-entity may opt to hire and pay you to fix it (and many more after that).

You are then a professional software engineer working for someone who would like to reach a certain goal (such as: A new release of Firefox!) and gives you money to help them achieve it.

Edit: For disclosure, I should have mentioned that I work at Mozilla.

We do and have offered the ability to choose your search provider freely for years, and that is not going to change.

Technically, a not-for-profit taxable subsidiary. (That makes a difference because the company purpose of Mozilla Corporation is still not to make money/raise shareholder value, despite the fact this it is fully taxable like any other company).

That's great feedback thank you. I've copied this into an Issue on recroom: https://github.com/mozilla/recroom/issues/35

There's a time and a place for both. The reasons frameworks (and so many of them) exist is because there are many problems you would otherwise have to solve over and over again, rather than focusing on the actual problems you app is supposed to solve.

However, that's not an excuse to avoid learning about the problems that frameworks and libraries solve, altogether.

recroom uses bower for package management at this point. Like many other parts of the picture, the "market" surrounding package management is in flux (there's also npm, for instance), so we'll monitor what's going on there. But for now, bower seems like a great choice for developers.

Also, it enables the modular aspect of recroom, that you can add/replace pieces you want, so package management is definitely vital.

You're right! recroom works well with WebIDE. You build your app and can then use WebIDE (and even the Ember Inspector Firefox add-on) to debug your app, for instance in the Firefox OS Simulator.

Future plans of ours include having recroom (and really, any toolchain; this is not a privilege we only want Mozilla projects to have) integrate even more smoothly with the WebIDE, with more direct integration points like "pre-push hooks".

That's actually where a large group of developers fall as well. You have the total beginners, who realistically won't build an app that has tests, or use a framework to sort out their models and views etc. They just need a HTML, CSS, JS file and some comments and can throw together something simple.

On the other end of the spectrum, you have the experts, who have evaluated a dozen frameworks of their own, know why they like gulp more than broccoli, and really just need an API reference to know what's possible, and off they go.

And in the middle of all this you have the huge group of developers who would really like to have some more help, even if only to help them make decisions of their own and eventually get them over the hump to expert-level. That's the group this is targeted at.

If you make a client-side app with it and figure out you don't like certain pieces of the toolbelt, you can replace them on the spot (they're loosely coupled). If at some point you're so advanced you want to replace it all, fantastic! You don't need our help anymore :)

Yes the whole space moves quickly. The current choice in tools in the recroom "tool belt" is not meant to be unchangeably set in stone. FWIW, Ember CLI is an interesting piece that would connect well to the core Ember framework as well.

Yeah you're right. The grunt piece is definitely one that is not set in stone. Ember-CLI is exciting and we've started working closely with the Ember folks to monitor it and see if and when this should become another piece of the recroom puzzle.

They can also lean towards rejecting almost any challenge entered by a system like this one. Conveniently, where I live, if you enter your argument by mail you are waiving your right to a trial, and they won't even reply to you unless you win (in which case you get some money back and it's obvious you won).

You are technically right but you're missing one thing: The parking authority here has an easy time to prove that you've ostensibly parked against the rules. Say, if the curb paint was faded, all they have to show is a map showing where you parked and how that's a special area. Done.

Suddenly it's up to you as the defendant to prove that that wasn't the case.

Outside of completely bogus tickets, proving that they were technically allowed to write the ticket is a trivial affair for the authorities.

I think you are on the right path: If you're making an app exclusively for Firefox OS, wrapping it in Cordova is not the path I would take.

However, if you're also planning on submitting it to the iOS app store, then making a Cordova app is useful.

Similarly, if you already have a Cordova app that you submitted to iOS and Android's stores, then you are now able to turn it also into a Firefox OS app fairly easily without having to fork your entire project.

I am not sure why Norvig omits president Obama. That said, "[mtg]a" does match him, so at least Munroe tries.

Frémont still matches "[rn]t", so the problem persists regardless of this spelling.

This is not my home turf, but this is beautiful and exciting. Is your ajaxy frontend in a state worth open sourcing?

S3 is actually not that cheap. I have well over 100 GB of data to back up (and that's not even a full backup by any means, just the stuff I don't want to lose and can't get back by redownloading and reinstalling things), which racks up a significant bill on S3. CrashPlan isn't cheap either but the cheapest ones of the bunch, so I use them instead. Actually getting the data back in the case of disaster would take a while but I could certainly restore the most important things first, then backfill the rest as I go.

I made a Firefox add-on that automatically scrapes the GIFs on Meatspace as they come in:

https://github.com/fwenzel/refrigerateur

(Early version! Feedback and contributions welcome!)

seems doable :)

In that case an x-calendar element is conceivable. In fact, the date picker could use that as its content.

Luckily, Brick is open source, so you can file an Issue about it, and if you're interested, even submit a pull request yourself.

No. I am just seeing a difference between occupation and having troops from foreign allies stationed on one's soil. If all non-local troops are "occupation" in your book, then I guess the US are occupying South Korea also? And Italy? And Israel?

{{citation-needed}}

Slowly? They have been closing US military facilities in Germany for decades.

Yeah, point taken. Not every company hires recruiters, let alone good ones.

Yeah sounds like shuffling the result set before running might add a bit more spice to this.

Sure. gkoberger transformed that statement into "can you detect if it has been running for an unreasonable amount of time". Not possible in advance, but certainly detectable in hindsight. Just, perhaps, not in JS.

Fair; also, it's called an 'ineffective' sort, and if you tested it, it'd become effective (not efficient, of course). So, good point!

Do you test the result, or just hope if it runs, it actually worked?

Beautiful, beautiful!