I can't really respect an "article" which starts by stating something and then completely ignores it.
The article starts with an overly simplified definition of the term "Design Pattern". And even though it's been simplified, it then ignores it. I will not discuss how the definition is wrong (or at least half-wrong), but it is sad when you do mention both problems and solutions...
> A design pattern is a general, reusable solution to a commonly occurring problem.
...and then simply fail to explain the problem and the solution. You just present a piece of code with a one line explanation, like:
> The singleton patterns restrict the number of instantiations of a "class" to one.
or
> An object maintains a list of dependents/observers and notifies them automatically on state changes.
Really, this helps nobody. This produces code without knowledge. Mumbles incantations without any explanations. Stupid copy-pasta without understanding.
What is the need, the situation that requires "restricting the instantiations of a "class" to one"? Why would you want an object to maintain and notify a list of observers? (Also, inserting the defined inside the definition? Tsk.)
The example on Factories almost makes me cry. As all explanation, you mention that the pattern "can be really useful when the creation process is complex" and then make a create method around a constructor which assigns *one* property to the new object. I don't want to sound rude, but are you even trying?
I cannot really understand how people upvote this. But then again maybe this is related to the fact that Echojs is so empty of discussion.
The point is how they've decided to implement Array#reduce.
If you go up to exercise 16, you'll see they force the result of reducing to always be returned inside an array.
return [accumulatedValue];
They even remind you in the comment in exercises 17 and 18:
// Remember that reduce always
// returns an array with one item.
I can't say I agree with this decision (it's not the common way to do reduce), but following their own version of reduce, then exercise 19 is correct.
The subject is interesting but I was a bit let down by the talk itself. If you want a (hopefully constructive) critique...
...I think the talk lacks in structure. But first: I don't mind much about you Umm-ing a lot, because I can assume that's due to nervousness or inexperience or whatever and that's ok. So don't worry about that.
The first thing I missed is an "introduction to the problem". You start the talk with the topics slides (Why, How, What) which do layout the content to be presented but what is missing is a "this is the problem, this is what we are trying to solve". I mean, you start to point out the benefits (automation) but you haven't even presented *what process* we need to automate. You need to spend maybe 2, 3 minutes talking about that process, what it entails, before explaining why it needs to be automated.
More generally, I guess the talk lacks structure. You know. Introduction to the problem, overview of possible solutions, conclusion. In particular you need to understand that introduction and conclusion at least as important in a talk as the rest of the content. And you sort of have a conclusion about three quarters of the way and after the conclusion you bring up something that looks like a totally different subject (Browserify). And then... you present a recap, but it doesn't really fit; it's like "now that I've made you forget about our conclusion, let's try to get back to that".
And the problem with structure in a talk is that if you don't have a very clear one, you'll fail to make a point, to transmit a clear message.
I hope I don't sound too negative with this.
The point is how they've decided to implement Array#reduce. If you go up to exercise 16, you'll see they force the result of reducing to always be returned inside an array. return [accumulatedValue]; They even remind you in the comment in exercises 17 and 18: // Remember that reduce always // returns an array with one item. I can't say I agree with this decision (it's not the common way to do reduce), but following their own version of reduce, then exercise 19 is correct.