There is no legitimate purpose to the referrer within applications that isn't replaceable via internal claims based tokens, or external sites' parameterised (thus, opt in) source tracking.
224 karma · joined January 26, 2011
There is no legitimate purpose to the referrer within applications that isn't replaceable via internal claims based tokens, or external sites' parameterised (thus, opt in) source tracking.
(my version - https://gist.github.com/vai/4647768 )
Being as that the article consistently refers to these being fixed values, and that they're optimising for 3rd party use of their library, that doesn't seem to be the case.
This seems to be the classic case of a solution looking for a problem.
3 disks.
Ah, nostalgia.
I could have sworn it said 'news' up there.
Second: you didn't understand the market, not just your customers. The market is _everyone_ you have to deal with, not just those that buy the bread.
Third: I'd place PG's #5 (Obstinacy) covers both your 'knowing how to code' problem, and the fixated / obliviousness.
Knowing how to do something is just knowledge. Knowing why, when, and when not to is wisdom. In the end, it sounds like you're glad that you could afford the lessons.
In short, these articles exist because people are trying to rationalise their way past the cognitive dissonance of wanting to want things, without being willing to actually change themselves.
Decision making is fundamentally a process of "I want, there is no greater want, I can, so I will". If you're not getting to do what you want, it's simply that you have a greater want. Sometimes that's just a want to not actually exert effort.
tl;dr - you will not change what you do without changing what you are.
There are things like https://github.com/panesofglass/frack already. That's not the only one. This entire approach running on the stack and frameworks it can is a massive deal, and running silent at present.
On the practical, implementation detail side of this, users should have been allowed to remove the item. I'm sure the reason that didn't happen is simply because of the way it was implemented, and implementing the item as something that was actually per-user would simply have pushed into the 'not happening' zone.
As regards, morals, sensibilities and where the hell 'right' is on the larger picture the answer is 'who knows?' - Personally, I think the fact that a slight prompting would have resulted in millions of tiny acts of goodness, and a few larger ones of users being upset, but there's no particular metric one can apply there. My intuition says the balance falls largely on the side of it being a net postitive for their users at large, and their families too.
As far as those offended go, I'm sort of reminded of the parallels with doctors and malpractice suits - hundreds of lives saved, helped, made more comfortable, and it' can take one slip-up to undo all of it. No, it's not a 'gtfover it', but it's not so much the message appearing as the inability to control it that led to a small slight being taken as an offense. Anger is almost always fear, and fear almost always a simple desire to not be hurt, and the inability to stop it continuing to prompt them - that likely just resonated with the aspects of whatever hurt in the first place, whether it was mortality, abuse or anything else.
No one meant any offense, and there was a person, and then people who thought they'd do something they thought would be good, and might make a few people happier (and possibly serve their employer's larger aims too).
They didn't do a bad thing. They did a good thing, badly.
I prefer 'Director'.
edit: as per https://secure.wikimedia.org/wikipedia/en/wiki/Executive_Dir...
You're not just referring to the percentage of the surface area of a sphere (which earth isn't), atmospheric distribution isn't uniform even if we go by volume (or should we be going by density?), then there's the curvature of light in the atmosphere to take into consideration, and the arbitrary descisions as to what height above sea level our observer is standing at, the variable nature of the tropopause ...
an interesting problem, but likely more interesting as a mental exercise than in actual execution.
That still doesn't mean that it's not a chrome bug - the exploit may use flash to retrieve the payload, make use of flash-js communication, flash-chrome communication quirks etc.
I've enjoyed webstorm, and that add-in is really the icing on the cake.
edit: ... and then I read the next comment :)
Too often developers do what we see as 'right' technically, which is not necessarily 'right' for the client / project. It's not something to be 'guilty' of, just something to be aware of. Although there is a balance - I've often fought for things and had them save the client's ass later.
And as for explaining why something is important - because the client should have an appreciation for why they hired _you_, not someone else.
Technology doesn't pay the bills. Clean code, good architecture, solid frameworks - they count far, far less than you wish they did. As developers, we're systems oriented, looking for the ideal approach, the 'right' way. 90% of clients are more worried about the right shade of cornflower blue. Don't lose your idealism about making use of the right tech stack, and where pragmatic, don't miss an opportunity to explain why it's important.
But don't make the mistake of thinking that's what counts for clients. There will be exceptions, but generally the guy with the purse strings isn't technical, and is in no position to appraise your use of tech.
You need to practice business as much as you plan to demonstrate technical competence. Negotiation, selling, conflict resolution (it'll happen), knowing when to walk away (that too) and probably the hardest thing - embracing risk. Many chant the 'fail fast' mantra, but I'd rather point out that our caveman brains are badly suited to accepting that risk is vital. Cold calling is terrifying, as is naming a price, telling a client they're wrong, and so many parts of simply staying alive.
Otherwise, go make some luck.
We ate together every day. Every day of the week, it was someone's duty to make lunch. I mean that, make it. You started an hour before lunch, went to the kitchen and made a meal. Generally a full hot meal. We got every variety you could think of - people enjoyed the time out creating someting different, something else for their co-workers to enjoy, and it Worked.
We got to sit outside, in the garden, next to the pool, and eat lunch (and yes, there was beer). And if it was Friday, well. Then we started a fire, and had some more beer. And there may have been instruments. And our respective children running about.
Not bad for a bespoke dev company. Not bad at all.
To address some of the other points raised in the comments -
No-one was forced to be there, if they wanted to go out for lunch they could. Few did, and rarely. More important than an individual's 'desire to associate' is whether they fit in. If they don't, they likely don't belong on that team. Ditto for if they can't communicate honestly (positively or negatively) about/with peers/managers.
thank you for =>