drfloob

I work at a "large company", and I don't agree with most of this. Your write-up is highly subjective, and fairly pessimistic.

Some people hit the ground running, and teams/organizations/companies can thrive if they find ways to embrace that. Sometimes people get hired at the wrong level, and everyone benefits if some sort of work demonstrates that quickly. I have seen promotions happen based on prudent choices around one's individual strengths, simply by choosing to do a bit of the right work and getting eyes on your capabilities. There is no "one size fits all" prescription for what someone should work on.

Having a "shadow lead" can be one of the best situations for your growth, too. Not only do you get the experience leading a thing (for most of what that means, anyway), you may end up with a very strong ally when you knock it out of the park. I had a version of this experience, and I've watched others have it as well.

I'm guessing most of the negatives here are based on your personal experience, and for that I'm sorry. Hopefully you can encourage positive changes in your company's engineering culture.

LinkedIn - Infrastructure Software Development | Senior/Staff Software Engineer - Backend, Python | ONSITE Sunnyvale, CA | Full-time | https://www.linkedin.com/jobs/view/712546597

LinkedIn's Infrastructure Software Development team builds and manages the company's production infrastructure source of truth, data center inventory and configuration management systems, monitoring, and workflow automation systems that underpin all of LinkedIn's production operations. We're looking for strong Senior or Staff level backend engineers to help us build highly reliable systems. We're a small team of strong developers, your contributions would have a large impact on LinkedIn's operations. Experience building data center monitoring, reporting, automation, or capacity management tooling is a big plus, but not a requirement.

Our software craftsmanship standards and culture are amazing, and our benefits and work-life-balance are top notch too, if you're into those sorts of things. I'm an engineer on the team, happy to answer any questions.

Check out the job description and apply here: https://www.linkedin.com/jobs/view/712546597

Flink is listed under `Unified Processing` as it supports both batch and streaming (Kappa Architecture)

Not so say Coursera doesn't have problems, but the start and end dates don't mean much as of earlier this year, when they rolled out their new platform. There's no penalty for late assignments[0], and you can switch to a later session of the course whenever you want[1].

[0]: https://learner.coursera.help/hc/en-us/articles/208279866

[1]: https://learner.coursera.help/hc/en-us/articles/208279776

I did all my college geometry homework with it (and LaTeX) back in 2011/2012, just for kicks. Is that interesting? Probably not too interesting :-)

Right, it sounds like they use tries with 5 bit keys. It's a very neat data structure, for sure, but _tree is just at a lower level. It doesn't impose structure. Tries can be implemented in _tree.

Thanks dangoor. It's a good day when someone shows me two recent projects that are very similar to my own. I started _tree a few months back because I couldn't find a project like it. Turns out I'm in good company.

_tree leans heavily on functional programming techniques, so it's not so different at all. The furthest it gets from functional is the modeling layer implementation, which is prototypal, and still just a thin layer over the core.

I haven't studied any clojurescript, but conceptually, compound operations on immutable structures, such as re-parenting a subtree or sorting a vector/list/set, would be implemented inefficiently without mutable intermediate objects. For example, imagine writing quicksort where exchanges cost O(n) instead of O(1). Performance would totally tank. It'd be silly.

That's why I expect clojurescript has mutable intermediates. I'd love for someone to prove this guess wrong, it would blow my mind. Anyway, that's what _tree's batch mode is, in essence: exposed access to the mutable, pre-finalized versions of _tree primitives.

Ah, right. Benchmark 1 is actually ~350ms on my machine. Thanks for the lesson in profiling asynchronous code. I revisited the React+_tree benchmark claims, too, and I think they are still spot on. If you're interested at all, I'd appreciate you taking the time to check my work there.

Thanks. I knew of Mori, but hadn't looked at it yet. Now that I've glanced, you could definitely implement something like _tree with Mori, but it'd be missing a few key things.

What jumps out most is that I'd really miss batch mode, which lets you escape from immutability and get a big performance boost for complex atomic operations. I think Mori must use something like this internally, but the docs don't indicate it being exposed.

It may be subtle, but I also really prefer _tree's syntax, where objects are fitted with their own methods (Mori does something like `mori.get(m0, 'foo')` instead of the more succinct `m0.get('foo')`). This is also the backbone of _tree's data modeling layer, which lets you work in terms of your domain, rather than a tree.

Performance comparisons are on my list of things to do.

EDIT: not true. see below.

----------------------------

Good call! Benchmark 1 is about 33x faster in my browser (with the setTimeout fallback being used, I think).~

http://drfloob.github.io/todomvc/labs/architecture-examples/...

This is the same React TodoMVC example with a different `react-with-addons.js`, built using React v0.9.0 and https://github.com/petehunt/react-raf-batching.

Part answer to your question, part shameless plug.

Node cloning can be done fairly quickly if the bulk of the node data is shared. The `_tree` immutable tree library (https://github.com/drfloob/_tree#quality-metrics) has a 1,024 child-node benchmark. On my slow laptop, it can build 1024 node trees at ~10/second, and the performance appears logarithmic on node count (http://jsfiddle.net/9x7aJ/2734/). I found it fast enough for my client-side use cases, but Clojurescript's optimized branching scheme could probably be implemented to boost performance. And anyway, if 10ops/second isn't fast enough, `_tree.Tree.batch()` lets you temporarily bypass immutability if needed, making modifications much quicker.

> it seems like it is invoking React's event loop more than I would expect ... Perhaps this difference is because of requestAnimationFrame?

I think so, yes. The performance difference is already negligible with Om, so I didn't see a real need to optimize it any further. Pete Hunt's react-raf-batching (mentioned already) could probably be dropped in to get that last bit of optimization, but I haven't tried.

As for what I mean by "application data policy", I think that if you work with your application's data in such a way that it batches modifications, renders entirely from the top down, and uses fast `shouldComponentUpdate` implementations, you'd achieve most of the improvement you see in the Om vs React+Backbone TodoMVC comparison. Lots of things could achieve that. Immutability isn't a hard requirement to get those features done. And if my React+_tree example is any indication, requestAnimationFrame isn't buying you that much performance either.

I haven't really analyzed what Om's Benchmark 2 was doing under the hood, so thank you for that. I assumed it was doing something, but with the ~4ms benchmark, I just assumed that particular something was wizardry.

Well, we can check a few of those guesses pretty easily. Here is the stock React TodoMVC demo augmented with Swannodette's benchmarks:

http://drfloob.github.io/todomvc/architecture-examples/react...

Benchmark to your heart's content! On my system, Om is about 4x faster on benchmark 1, and 1000x faster on benchmark 2. I don't think requestAnimationFrame has a lot to do with it, and immutability only slightly more; I think the real performance gain is in having an application data policy tailored to make the most of React's behavior.

To plug my own work a bit, I built a TodoMVC example with React and my own immutable data structure library in pure JS. It performs a lot like Om on both benchmarks, and actually seems a bit snappier in places, like toggling and clearing all completed todos:

http://drfloob.github.io/todomvc/labs/dependency-examples/re...

All respect issues aside, generic names like this are a pain in the ass. "go" (google) and "react" (facebook) are similar. For example, Twitter-folk have taken to using #ReactJS to mean Facebook's React UI framework, but react.js[1] has been around a while already, and it does some similar stuff (if you squint a bit).

You can't mention or search for them without barfing out the company name, and sometimes a specific property alongside to be unambiguous about your meaning. It makes finding discussions and blog posts harder because people don't have a common language for these poorly-named things.

It just seems like these companies are shooting themselves in the foot. Is natural word-of-mouth growth no longer a concern?

[1]: http://reactjs.com/

I get your gripe, but there's a good use case for this stuff in building dynamic web applications. Just because a technology is misused doesn't mean the technology is to blame.

Thank you, Xmonad, for not supporting chrome fullscreen in your default configuration.

... and if P = NP, the market doesn't matter because everyone will have cracked all your bank passwords.

Link: http://goo.gl/ZlTnM

Spaced Repetiton learning techniques: https://en.wikipedia.org/wiki/Spaced_repetition

Literally the worst developers I've ever known are the sort that would eat this kind of thing up.

The worst developers in my opinion are those that appear highly proficient and effective until they're asked to actually produce something, then never produce anything of value whatsoever. They're infinitely worse than those who are clearly ineffective from the beginning. They're talented but immature; unwilling to do anything they don't see as a game; unable to see everyday tasks as games.

That depends on what you want to do with your life. If you want to build and sell startups, start building and selling them. You don't have to be a great developer to do that.

If you want to become the best developer you can be, then here's my advice:

Learn about the process of building software. Diligently practice various development systems (agile, scrum, kanban, etc.). Build a reliable, disciplined behaviour into your personal development process, so no matter what the task, you know exactly how to best take an idea through to completion efficiently and with as few headaches as possible.

After that: learn about architecture, algorithms, and hardware.

Being consistently loud and annoying are indications that this person doesn't adapt well to his surroundings, especially if everyone around him seems displeased. It may be a sign of poor overall judgement.

It may also be that this person was nervous when you interviewed him, and didn't have the forethought to say "I get loud and annoying when I'm really nervous, it will pass."

My advice: test him out. If he is truly great, and you really need a truly great developer, and the annoying bits don't go away: isolate him from your team, manage him closely, and keep him happy.

Say you're signed in to BrowserID already ... is there anything that would stop an attacker from being able to log you into some other BrowserID website without your knowledge or consent? With login reduced to two mouse clicks, it seems like a well-crafted webpage could log you in wherever it wanted. If that were the case, a CSRF-vulnerable BrowserID webpage could easily be exploited at a large scale.

Nice project. I'll be putting this script on my sites for sure.

At first glance though, I didn't like that it translated the content of <pre> and <code> tags, so here's my quick fix for that.

  TranslateThis({onLoad: function(){
    // avoids <pre> and <code> tags
    var nt= function(el){el.className+=" notranslate";};
    var pres= document.getElementsByTagName('pre');
    var codes= document.getElementsByTagName('code');
    for(var i=0; i<pres.length; i++) { nt(pres[i]); }
    for(var i=0; i<codes.length; i++) { nt(codes[i]); }
  }});

The "explore" interface is really slick, but I can't link to or bookmark a search filter to share with anyone. It'd be easier to spread the word if I could pre-filter strains based on someone's particular needs/personality, and link them directly to that.

Also, since this is a startup, how do you plan to make a business out of this site?

sun block, coconuts, and a bit of gasoline