665 karma · joined December 15, 2011
E.g., 1.1.7.0 or 1.7.0 are equivalent.
[Cross posted from the other thread: https://news.ycombinator.com/item?id=8244920]
E.g., 1.1.7.0 or 1.7.0 are equivalent.
It's pretty good, though I personally find his view of business management to be dated and out of touch like his view of title inflation vs Facebook's title normalization. Still a good and insightful read.
Even at famous Silicon Valley companies with a tech track, becoming a Staff Engineer is a generally inferior career path compared to the title inflation seen on the business side. Ben Horrowitz endorses this in The Hard Thing About Hard Things when advocating that title inflation is "free" in respect to competing companies.[1] Fortunately, it's juxtaposed with Zuckerberg's / Facebook's title normalization, which ensure engineering titles remain comparable with non-engineering titles.
Software engineering needs stronger leadership and career tracks that encourage craftsmanship and mastery. Why continue in an inferior career track, when you can start your own company and leap frog all of middle management altogether? The value proposition simply isn't there. We need a new management structure, one that resolves the multiple and independent types of leadership and encourages engineers to become better engineers, and not to become managers who don't code.
[Edit] What's really interesting is the way in which this power dynamic plays out in most tech companies. Engineers clearly possess the upper hand, but aren't interested in power and so are heavily placated with a pile of perks to the resentment of others because of their lack of corresponding responsibilities. In SV, engineers are the "talent" and everyone else implicitly fills support roles, even PMs. This also of course creates cultural disparities where you can make $250k/yr (including bonuses and RSUs) and work < 40hr/wk.
[1] http://blog.skillbridge.co/teams/unless-its-king-james-be-wa...
https://news.ycombinator.com/item?id=5672023
I used to never be able to fall asleep before 5am.
"After Kryptos, he went onto a segment of his work where he was fascinated by the way light was projected onto things," says Dunin. "He went out into the southwest of the US at the middle of the night and he'd beam a pattern of light onto a mountain and use time-lapse photography to record it. There's dozens and dozens of pictures. They look like they're made in computer graphics, but they're Sanborn beaming light on mountains."
Given K2 also seems to be referential back to other Sanborn works, my guess is that the clues/keys lie in his other works... Interesting stuff.
[1] http://images.eurogamer.net/2013/articles/1/6/8/1/6/7/0/the-...
As a developer, it was wildly successful (can't overstate that enough). As an entrepreneur, it was a big failure. If, as an entrepreneur, you're jealous of his success, you need to reevaluate your priorities and consider a change of profession.
Too much Silicon Valley navel-gazing here.
Optimism is fundamentally a belief that we are not currently at a local/global maxima. Determinism is a belief that the path to local/global maxima is knowable through human intelligence.
This is why A/B testing, as pointed out in the article, is fundamentally incapable of leading to anything other than a local maxima. It is optimistic, but without determinism, it will never sacrifice traversal through local minima to achieve a greater maxima.
This is personally why I have such a reaction of disgust to "ideas are worthless" and "nobody knows anything until you build it," because I am adamantly optimistic deterministic at heart and do believe in design, increasing ectropy, and vision. A side effect of this is that in our pessimistic indeterminate societal POV you are characterized with delusions of grandeur until you prove out your vision. Even then though, you may be discounted as lucky.
[1] Ask a programmer to review 10 lines of code, he'll find 10 issues. Ask him to do 500 lines and he'll say it looks good. -- https://twitter.com/girayozil/status/306836785739210752
The Tower Defense model is an approach to software reliability that focuses on catching bugs at the lowest level, to avoid the inevitable combinatorial explosion in test coverage surface area. In other words, deal with problems like these at the language level, so there is NO NEED to deal with them at a higher process-level.
No one is disputing that processes, QA or Devops couldn't/shouldn't hypothetically catch these bugs before entering production. The problem of course is that they usually don't, because the lower level defenses are allowing too many bugs through, that they really shouldn't and the higher level processes become overwhelmed, fail, and allow bugs to cross the critical production threshold.
This means always giving higher priority to lower-level methods of reliability. For example,
* Language rules are more important than
* Unit tests are more important than
* Integration tests are more important than
* Code reviews are more important than
* QA is more important than
* Monitoring is more important than
* Bug reports
trycatch is nestable as well.
> they can store arbitrary values, timers
Nice. I am currently decoupling trycatch's hooking layer to allow for this arbitrarily[1]. The continuation-local-storage library[2] allows for this functionality as well.
> intercept microtasks
Care to elaborate?
> wrap closures to be associated with the Zone
Yup, similar to domains, though I do wonder when this is necessary? One use case that came up with trycatch was finally support, or the need to exit the current domain/trycatch context.[3]
Lastly, there's one consistent failure I see in all these domain-like, async listener-like, long-stack-trace, event-source modules and that's long-lived resources or how they incorrectly handle EventEmitter handler's context[4], with the core issue being the boundary at which the hook is applied (From Trevor Norris' comment):
After thinking this over, it occurred to me that trycatch is a top down approach. Whereas AsyncListener is bottom up.
Long story short, things like keep-alive sockets will retain a domain/context/zone(?) and their handlers will be called with the incorrect context.Do you fix this in your zone.js implementation?
[1] https://github.com/CrabDude/trycatch/issues/38
[2] https://github.com/othiym23/node-continuation-local-storage
I agree with this whole-heartedly, but it does put the limitation on the human, and not on the computer, which is actually the opposite direction we want to go. I don't think we're there yet, so in the meantime, node.js is fantastic for when you need/want to hyper-optimize your critical code path for response time.
One thing I would add is that node.js makes job-queueing, background-task handling, side-effect inducing trivial since it makes networked IO / SOA trivial. In other words, having a separate process deal with anything not necessary for returning a response is almost effortless, allowing your responses to always take the minimum time necessary, freeing your client to continue.
[1] http://en.wikipedia.org/wiki/Computer_multitasking#Cooperati...
function trycatchit(fn, that, args) {
try {
return fn.apply(that, args)
} catch(e) {
return e
}
}
var value = trycatchit(fn, null, 'someValue')
if (value instanceof Error) {
...
}
Really though, you should just let co or whatever generator library you're using catch the error and rethrow it (or pass it to a callback) or be mindful to minimize your error handling.[1] https://github.com/CrabDude/trycatch/blob/master/lib/trycatc...
[Edit: see my comment below[0]. This is more a coincidence of wording than a StrongLoop marketing line]
When StrongLoop talked at my south bay node.js meetup group, BayNode[1], at Hacker Dojo last month, they demoed Zone.js. Before demoing though, they asked if anyone in the group had "solved this" to which I made it very clear that, "Yes, I did about 2 years ago with trycatch[2]." Their response could be summed up as, "Oh?"
Long story short, not only does my async try/catch library solve this, I can say with near certainty that it solves it in a better, more consistent, more tested, more battle proven, more performant manner. We use trycatch at LinkedIn and have not had to worry about async error handling since.
Additionally, adding it to any control-flow of your choice is trivial, as I have done with my stepup library[3]. Further, their main bullet-points are about enforcing the callback contract, something EVERY control-flow library should be doing, (I previously went into more detail here[4]) and the primary reason for the popularity of promises since they formalized this contract.
In fact, I teach these core contract rules in my monthly week-long node.js bootcamp I give here at LinkedIn[5], and the only thing they have to do with control-flow is that your control-flow library of choice should enforce them, as stepup and promises do. I do add a few rules:
* Function that takes 2 arguments: 1. first argument is an error, 2. second argument is the result, 3. Never pass both, 4. error should be instanceof Error
* Must never excecute on the same tick of the event loop
* Must be passed as last argument to function
* Return value is ignored
* Must not throw / must pass resulting errors
* Must never be called more than once
Long story short, domains are broken, try/catch is insufficient, use trycatch because I solved this problem over 2 years ago and have been perfecting it since.
[0] https://news.ycombinator.com/item?id=7598983
[1] http://www.meetup.com/BayNode/
[2] https://github.com/CrabDude/trycatch
[3] https://github.com/CrabDude/stepup
Empty comments can be ok if they're positive.
From http://ycombinator.com/newswelcome.htmlVisions aren't always correct, but they're enhanced by immersing yourself in the relevant context and data to provide your subconscious mind ample time and information to make those connections to generate those "Aha" moments called inspiration.
Richard Feynman described in one of his books the best way to appear like a genius is to always be actively learning at least 3 new unrelated topics, and you will glean patterns and details from everywhere to constantly increase you understanding of these topics, leading to inspiration.
And so, in companies like Facebook and Google, it doesn't matter what you know, it only matters what you can prove. Meanwhile your competitors in the market are unburdened by the need for proof and shout down at you from the mountain in the distance when they arrive.
co(function *(){
let promiseA = makeHttpRequestA()
let promiseB = makeHttpRequestBFromA(yield promiseA)
var res = new Foobar(yield promiseA, yield promiseB);
})();A couple examples: Bill Cosby[1], Jamaicans[2], black raised by whites[3]. (There are numerous others, but these are the easy three.)
Jamaicans for example, see African Americans as lazy and deserving of their place in American society and often hate being referred to as African American because it is both inaccurate, and because they do not culturally identify with them, seeing no conflict between their blackness and their ability to achieve the American Dream.
When you hear cries of racism, consider whether you actually see people being mistreated or considered inferior because of the color of their skin, or if their own (cultural) behaviors are ensuring their struggle. It's extremely unfortunate and my heart breaks for anyone suffering from cultural peer pressure or family pressures to not forsake their "heritage" by "acting white," especially since you don't have to act white in order to act successful.
My opinion is that you see this exemplified most in the Bay Area because you are viewing the top 0.1% of achievers in the tech industry. Adding a self-sabotaging cultural identity certainly cannot help, and I imagine going to non-top 20 public university probably also doesn't help, which is why so many in the Bay Area grads are from MIT, Stanford, Harvard, Carnegie Mellon, etc... graduates.
FWIW, I acknowledge that there ARE in fact some cultural pressure to conform to arbitrary FLOABW "white" behaviors, which have similar ramifications to racism, but that's not what I'm talking about here.
Lastly, self-sabotaging culture is not uniquely black, white, hispanic, etc... which is why it's has nothing to do with race or racism.
[1] http://www.snopes.com/politics/soapbox/cosby.asp [2] http://www.jamaicans.com/articles/primecomments/1002_amerija... [3] Barack Obama, Halle Berry, numerous friends...
npm link lib
link -s lib node_modules/lib
Then: require('lib/models/user')
No matter where you are.