A mod might remove it if enough people flag it. I think it's still interesting as an example of a new type of fraud, though. The site's been up since January of this year and Amazon and the actual owner of this brand don't seem to care. It's also the third result on Google for me for "Staub Cookware".
I don't think this is actually created by the company that owns the brand, Zwilling J.A. Henckels. I think someone managed to get this domain and generated this page (rather quickly, it looks like) to try and make money via Amazon affiliate links. Interesting new strategy.
That's Bonappetit for you. All of their videos of this nature have wildly unqualified folks. One of them featured Alex Delaney who I think was the editor in chief's assistant before he became drinks editor. I'm sure the guy cooks, but they lost my respect when they put him in a video about "Pro chefs". (I didn't watch this one, sorry, but I hope he's not in it)
No no no no, it is absolutely necessary to salt the different components that go into a dish. Many things will absorb salt during the cooking process. Salt can also draw water out of an item which will change the way it cooks as well, for example with eggplant. You need to be constantly checking the salt level while cooking to ensure your final product is not just salty enough but salted throughout the dish and not just on the outer layer. This is especially true with proteins, all of which need to be salted in advance in order to get proper penetration.
Re your comment about olive oil, an extra virgin olive oil has flavor and it would be pointless to roast with it, but you absolutely need oil while cooking food as it's a thermal interface between your pan or your oven air and your food. Of course there are finishing oils that tend to be something with a lot of flavor like EVOO, sesame oil, or an e.g. rosemary infused olive oil, but most oil needs to be added during cooking.
If you only have six people, maybe :] But we're commenting on a post that's talking about the best time to introduce an OKR process. At my company we don't have an "API guy" and an "Android app guy", we have 30 or so different teams that my team interfaces with in a company with thousands of engineers. We can't just "thrash it out" on Slack at a company of this size.
You need to try and think about what things look like when the company is much, much larger.
No, they are completely different things. Real time chat doesn't make people feel like they understand the overall goals of an organization. If someone says in Slack "we really need to get x done because the customers want it" and other people decide to talk about StackOverflow's hilarious April fools day joke for 5 minutes, some are going to miss that "we really need to get x done".
Your OKRs put that sort of thing in one place. The process to determine what the OKRs are ensure that everyone's on the same page about the objectives. People in an organization want to feel like they know what they're working towards. When they don't they get stressed out and unproductive.
Nobody said you aren't allowed to share it, I simply disagree with you. As I said, I use a very similar pattern in a large project; I've used new/this/prototypal style OOP in other projects; and I prefer the traditional new/this/prototypal style.
I lead a somewhat large (~10000 sloc) project which uses the module pattern everywhere. I think the best argument against the module pattern is the difficulty of debugging. I can no longer just pop open a console and inspect objects.
Responses to your individual points:
>> * you cannot use previous OOP experience
While unfortunate I believe this is largely unavoidable. Javascript's object system is not 'classical' inheritance. The module pattern, however, is also not 'classical' inheritance. Regardless of OOP technique, the New Javascript Programmer must learn about the object system.
>> * there are MANY ways to do OOP using prototypes
There are also many forms of the module pattern. You just showed me another one I hadn't seen before. Then there's immediately invoking function expressions, which some people like to do like this
(function () { var exports = {}; return exports; })());
and others like to do like this
!function() { var private = 4; return { getPrivate: function () { return private; }; }();
>> * 'this' has different meanings depending on context
Can't argue against this one.
>> * prototypes make existing objects unreliable -> requires prior knowledge about libraries and APIs (leaky abstraction)
I'm not sure I see the argument here.
>> * building an object with prototypes requires far more mental steps: ..
I'm not sure you really need to know about all of these things.. but sure, prototypal inheritance is confusing to those with a 'classical' background.
As for the advantages:
>> * conforms to established industry and business standards in OOP
I don't see why prototypal inheritance does not. If you look at CoffeeScript, it even appears classical.
>> * requires less knowledge about language details
I have to disagree here. Explaining object literals and immediately invoking functions and closure isn't all that easy.
>> * very transparent, no sugar code or libs required
That's true.
>> * neat code
There's no reason why new/this/prototypal code can't be neat!
>> * design patterns blah blah
There's no reason why new/this/prototypal code can't do design patterns!
>> * protection against corruption
I've never seen this as an issue in practice, but my code isn't running in the browser. Unless you're talking about protection from other programmers, in which case, I would quote Guido van Rossum.
>> * no this, that or self variables
Could be a good thing or a bad thing. This means that you have to know what's public and what isn't, rather than it being explicit. I rather like it when things are explicit.
Sometimes we sacrifice a little simplicity for a little flexibility or a little efficiency. Sometimes it's worth it, sometimes it isn't.
That's because "override the 'general' toString() function" doesn't make sense. This is a method. It must be overriden for a particular class of objects.
The first part of your example is due to the conversion between primitives and objects for method calls. It has little to do with prototypal inheritance.
Then, you override the method on an instance of String. When you set toString to null, of course, the call to toString fails.
Lastly, you override it on the prototype of String, which will apply to all String objects. Why is this an unexpected error? toString is on the prototype, because it's defined on the class, not the instance. I'm not sure what the confusion is here.
Well, it'll toss all of your templates into a convenient object, rather then having to do _.template($('#thing')). Still, doing the templating fully on the client seems a little wasteful, when it's easy to at least precompile the templates to functions. Brunch is useful to automate this, and has mustache support: http://brunch.io