Facebook couldn't fix it because they just licensed the old Java/ActiveX uploader from a company named Aurigma. Even though Aurigma would give you the source if you paid them enough, you didn't get any ownership over it. When Facebook first started, it was probably the right choice for them, because photo uploading wasn't their focus, but now that they are huge, the improved ability to iterate the design is probably worth it.
It's the IE word for a bookmark, which may or may not happen to mark a favourite link.
Was it a conscious decision to limit the scope in marketing terms to groups of "favorite" items or do people in practise only add a very limited number of items to any group ("kart")?
You might be interested in the book "Punished by Rewards" by Alfie Kohn. It goes into detail about why praise can be detrimental, and what to substitute for it. From the description on his site <http://www.alfiekohn.org/books/pbr.htm>, it "[draws] from hundreds of studies, [and] demonstrates that people actually do inferior work when they are enticed with money, grades, or other incentives." The biggest revelation for me was that 'other incentives' includes both praise and punishment.
If anyone is interested in how to motivate employees without resorting to cash -- which doesn't work well -- I would highly recommend "Peak: How Great Companies Get Their Mojo From Maslow" which, of course, is heavily based on Maslow's work. Tony Hsieh said it helped him think about culture at Zappos; it's a good read.
"It goes into detail about why praise can be detrimental, and what to substitute for it."
What, then? ;)
"Rewards and punishments are just two sides of the same coin -- and the coin doesn't buy very much. What is needed, Kohn explains, is an alternative to both ways of controlling people. The final chapters offer a practical set of strategies for parents, teachers, and managers that move beyond the use of carrots or sticks."
Has anyone read those final chapters and could tell us whether there are any actionable alternatives in there at all?
Accelinova provides chapter 10 for free off of their 'bookshelf': < http://www.accelinnova.com/pdfs/kohn.pdf >. This chapter is focused on motivation in the workplace, and he does have several concrete proposals, organized into sections: 1. Abolish Incentives - While pay is not a motivator, it can be a demotivator. "Pay generously and equitably...Then do everything in your power to put money out of [the employees] minds." 2. Re-evaluate Evaluation - Do away with the regularly scheduled performance review, and instead give employees regular, useful feedback, and in particular, the entire process of giving feedback should be separate from the process that determines compensation. 3. Create the Conditions for Authentic Motiviation - Attend to "the collaboration that defines the context of work, the content of the tasks, and the extent to which people have some choice about what they do and how they do it." He goes on to give more details about these three conditions in the second half of the chapter.
The other 2 chapters in this end section are similar, with one each focusing on raising children and how to structure education.
OK I've read some Amazon reader reviews and it seems like the alternative strategy is to simply give tasks or set goals and leave rewards or punishments out of the picture.
As one reviewer put it: "I believe Kohn realizes rewards are necessary, just not the rewards/reinforcement that have been in use. Learning is its own reward. If this wasn't true, why would these people who reviewed the book have read it? Were they paid to read it? Love is its own reward. Meaningful debate/discussion is its own reward. Generosity is its own reward. Using these as your reinforcers will bring results."
I know this is true, but it doesn't help. Incentives are a side-effect of competition for talent. If a business owner or manager doesn't offer them, people will find the above intrinsic rewards and enjoy them, but will still leave once the competition comes knocking with carrots.
Kohn says that compensation is perfectly fine, as long as it's not used as a cudgel to mold behavior. You should get high quality employees because they want to be successful and good at what they do, not because you pay them to be. One way of solving the problem you propose is to pay your people well, so competitors have a hard time offering significantly more, and then give them the opportunity to enjoy themselves at work. Why would they leave?
I understand that Netflix does something like this. They pay salaried employees top dollar, give them choices about what to work on, and demonstrate their trust with policies such as the no-vacation-policy policy. < http://www.slideshare.net/reed2001/culture-1798664 >.
I had the same question and re-read the end over again looking for the answer. I didn't find it. The whole premise of the book was rewards (including praise) undermines our intrinsic motivation. Compare it to a book on global warming: here's why it's a Bad Thing. So how is everyone going to live without a car? Who knows--that's not the subject of the book; it is trying to raise your awareness of the affect of driving on the planet.
Praise or a reward is the _easy_ solution. There is no motivator that applies to everyone, everywhere for every situation.
Here is a suggestion. Find out what the people you interact with want and tie it into the system. Do they want vacation? Do they want recognition? Money? As you scale up, create a corporate culture that values some set of things and attract people with shared values.
We have 4 developers sitting in a room with a giant white board. When someone discovers a bug, or one is reported to us, we write a few words or a sentence up on the board; enough so that we'll be reminded what its about. When a developer decides to fix one of the bugs, they stick their initials next to it and check it off when completed, which signals to someone else that it needs to be tested and erased.
The goals of our bug tracker are to get bugs fixed and tested quickly, with the main goal of having no known bugs in the system. Specifically, we realized that most tracking systems are optimized for bug archival, whereas we wanted a system which is optimized for getting the bugs fixed, given our environment.
I've found that I have a very strong preference for an empty bug-tracking whiteboard, and the more items on it, the more I feel compelled to fix bugs rather than work on other things. It's great for communication, because you can just go talk about the item on the board. Even the process of marking something off on the board makes everyone else peripherally aware that something changed, so nobody has to check whether there's something for them to fix/test - they know. Often bugs are fixed and tested within the same day they're discovered. If something stays on the board for a while it's obvious to everyone that there's a more serious issue that we need to discuss.
We use a similar system, only we use post-its (and scotch tape) to write on, as the white board is too small to write everything on. Also, our handwriting tends to suck.
if you dont use prototype the function will not belong το the new object you create, therefore you will not be able το call the function from settimeout, which was the problem the author assumed το have.
Try extending the time on your timeout in the example, say to 30000 milliseconds. You might get a surprise when you see your function get called immediatley.
In the article, you are right that he should use prototype, but not for the reason you mention. In the example, he does this.foo = function, so the function does get associated with the object. The problem is that the function gets recreated every time the HotDog constrictor gets called. Better to put getCondiments on the prototype, so that it is only defined once.
I didn't realize how integral the numbers were to how I read HN until now. It's taken me a while to stop feeling lost without them, but with the orange dot present, I at least feel like I'm getting the insightful comments after a quick scan of the page.
This article does a good job of explaining a concept I had trouble with when first using javascript. Now, I usually use the approach recommended in the article of setting a private variable (e.g. self, or my) to the current value of 'this' in a javascript class.
However, I think the article is slightly incorrect on one minor point. It states, "this wants to be window whenever possible, which is not always what you want." I believe the correct description is: the 'this' variable in a function called in response to an event on dom object is set to that dom object. For the example given in the article, this is set to the window object because setTimeout causes an event on window to fire, not because there's any inherent preference for the window object.
|this| is basically a magical variable that by default is set to the global object, but can also be set by the caller of a function one of two ways:
a) by setting a reference to the function on an object, and calling it with object or bracket notation:
var someObj = {};
someObj.f = theFunction;
someObj.f(); // now |this| inside theFunction will
// point to someObj
someObj["f"](); // same thing
b) by using apply:
theFunction.apply(someObj);
You are right that in the case of event handlers, it is common in the DOM for event handlers to get their |this| set to the DOM node that fired the event. Since the default value of |this| is the global object, it isn't possible in the case of setTimeout for us to tell whether the caller (the host) explicitly set it, or if the function is being called without any value set for |this|.
Basically, |this| is an extra parameter to any function. It is controlled by the caller, and as such, should either be documented as part of the signature of the function, or else should not be relied on by the implementation of the function.
The common misunderstanding with people new to JS is that they expect |this| to be controlled by the callee, like it is in lots of other popular languages, and are surprised when calling convention can change its value.
BTW, imo, the behavior of |this| is a really unfortunate design flaw of JS. The amount of time that must have been spent learning and teaching this edge case over and over to every person new to the language is ... well, it's big.
The behavior of 'this' is from DOM bindings and not from the language per se. Javascript can set 'this' of any calling context to any object with 'apply' or 'call'. The convention for on* handlers is that 'this' is set to the DOM element when the handlers are called. I only learned to appreciate this, when I wrote my own little JS DOM framework a la JQuery or Dojo.
I believe actually that 'this' points to the global object.
So if there is no obvious thing for this to point at, it'll point at the global object. Its just implementation detail that in browsers it points to the window object.
Do you know why it was designed this way? Was 'new' added to javascript after the behavior of 'this' was already well defined and the creators did not feel comfortable changing it?
actually, no. As I understand it, the language was supposed to be some sort of weird conglomeration between traditional object oriented languages and dynamic, lisp-ish languages. The problem was that the creators had about 30 seconds to get this done and they could make things look more "normal" by not explicitly supporting every feature they envisioned.
"new", I believe, is actually an ancient relic of the prototypal class system. That's another topic entirely, but it's incredibly cool. Check out Douglas Crockford's articles on inheritance if you want closure on the issue. He has written way more than I have on the topic.
"new", I believe, is actually an ancient relic of the prototypal class system.
I believe it is quite the opposite. It was a failed attempt to make the prototype-based object system look like class-based one. I vaguely remember reading this opinion in Crockford's "Javascript:The Good Parts" book.
Aboodman seems to have a better handle on it than I do. I think what I said about the dom object is correct, but he point out that window is the default value of this for other function calls.
The majority of the users of my company's web application use IE6 on Windows 2000. Additionally, many of these computers have Vista stickers on them, and are quite powerful. Their IT groups already have established practices to support the machines, and they are used almost exclusively to surf the web and run software that was purchased 5 years ago. Our users aren't even unhappy, as their work does not center around a computer; thus, the corporate IT infrastructure has no motivation to upgrade them.
That said, we still pressure them to upgrade, and I'll be extremely happy when they eventually do.
