I think you asked the wrong question:

http://www.ask.com/web?q=what+javasc...epageSearchBox

laugh at the nerds falling behind:

http://www.ask.com/web?q=what+javasc...rpSearchTopBox

make sure you get ahead of the game:

http://www.ask.com/web?q=what+javasc...rpSearchTopBox

No one recruits louder than we do! (R)

That rejection was super exciting to read! They were so glad to have met me! Unfortunately, my background didn't fit their needs! They will keep me in mind for later!

Thanks for applying!

Q4 2016 called - it said you should have waited for Apple/AirBnB/some other company with infinite resources' framework. Now you're stuck with react/ember. Facebook silently mocks you.

My actual job is working with a proprietary framework that from what I can tell was made around 2008.

=/

We have one of those - based on prototype. We call it Jake-Query or Jake JS - named after the guy who created it and the only one who ever really understood it. We're slowly replacing it with angular.

Correct, iOS has no built-in mechanism to delete all text messages and text messages only.
Fastest way without 3rd party apps is to go to the overview of all conversations, hit edit, mark all of them (yes, manually), then hit delete.

I believe the 30 day thing only kicks in when nothing happens on that particular conversation for 30 days (ie. I think older messages do not get deleted as long as new ones come in.)

I'd use a 3rd arty app for both 1 and 2.

You can only export single messages (or a group thereof) from one conversation at a time with iOS functions.

ugh 20 day streak on github = this is now a thing.

not sure if what we do is standard, but we pass stuff around mostly in services. if nesting we just use directives for widgets.

so if we have a 'likes' widget on the 'projects' details page

it'd be something like

The like-widget directive will just have an isolated scope but have access to the project object (and can modify it)

Inside Amazon: wrestling Big Ideas in a Bruising Workplace

Quote:

The company is conducting an experiment in how far it can push white-collar workers to get them to achieve its ever-expanding ambitions.

I have heard from more than one person that Amazon was "churn and burn" and I guess this article confirms that. An interesting read in my view, what it is like to work for "bleeding edge" companies perhaps.

thanks for the answer!

Yeah I did some reading today and that's what I came up with. Some articles advocating using services to encapsulate a model which includes methods for manipulating the data as well as the data itself. Keeping controllers bare-bones, which is something I'm accustomed to doing in ASP.NET MVC and I think is a good way of doing things.

Amazing what just sleeping on stuff can do, I read some of the same stuff a couple days ago and was like, wat? Then I came back to it today and it all made perfect sense.

btw having done some more reading/thinking about the direction of JS frameworks and such, I'm a fan of flux-type architecture with a unidirectional data flow, but remain sceptical of the React approach of bundling views into "render methods". I still haven't actually used React and am open to changing my mind. I also still feel like React has a bit of the Lisp problem of "you can do things any way you want!", which sounds great to skilled coders but doesn't provide enough structure to rank and file hackers, aka 95% of developers.

I'm very much liking the direction of what I've seen of Angular 2, now that I understand better some of the problems of Angular 1.x. Two-way databinding had to go, scope was pretty much a bad idea, and it seems like the team is working hard to make Angular compatible with the future of web development.

Has anyone used Meteor? I had a bit of a look at it and it seemed... suspiciously magical. The close coupling with MongoDB is an issue for me aside from anything else.

Interesting rebuttal: https://www.linkedin.com/pulse/amazo...ick-ciubotariu

I'm sure the truth is somewhere in the middle, but I generally treat the big in depth articles like the NYT article with a lot of skepticism. They write these articles to tell a simple story in an 'interesting' way. So they pick one narrative and go with it. While I don't have a lot of insider knowledge of Amazon, I can confidently say that everytime I've read an indepth article of a topic I do know a lot about it - it's almost completely wrong and at best a single oversimplified facet of a complex story.

I'll add that the NYT article really lost me at:

The wording of the bolded is a perfect example of how you take a completely standard thing that all companies do and word it in a way to reinforce the simplified narrative that you're trying to sell.

Amazon has access to metrics that dwarf every company.

They can even tell when some of their Web pages load too slow!!!

I like React. The componentized approach works very well for the typical web application, way better than the template approach of angular. I never got as far as custom directives in that so maybe thats just as good. I like 1 way binding that is manually updated through setState way better than the magical 2 way stuff as well, and I wound up "enjoying" JSX more than I thought I would.

The weakest part of React for me is Flux itself. Not only is there no standard product meaning you have to rely on weakly documented 3rd party approaches but it doesn't have a very good structure and a lot of times you have to bounce around between "ok, does this component retrieve its state from a React parent itself, or from Flux?" and yeah. But its fine.

This is coming from a guy who just used a React method called "dangerouslySetInnerHTML".

i agree with jj's general point, but in fairness i think what is being said is that they are using metrics on user behavior to infer problems with load times. While ofc anyone can profile load times with chrome dev tools, what amazon is doing is far more general: it can also be used to detect problems with changes to UI / UX, or with anything that can possibly influence human behavior.

My specific point there was that you monitor pages that don't load quickly enough because slow loading (however you want to define this) pages are bad and you need to fix them. Sometimes its a code bug, sometimes its hardware problem, sometimes its a UI problem, sometimes its just a scaling issue, etc..

But they word it as if its a way to monitor engineer performance/skills. Which its not - except in a very tangential way.

As far as Meteor I haven't seen a use case that requires isomorphic javascript in the way they heavily promote. Maybe validation but how hard is that to adapt? Frankly I immediately lost interest when during a presentation on it I noticed a method on the Meteor global unfortunately named "call".

Custom directives for me is the heart of what angular is. If you're writing stuff without embedding things in directives you're doing it wrong for the most part I think. If you don't have declarative semantic clarity in Angular there isn't that much point to it.

Yeah, I agree that 1-way binding is better - something that is addressed in Angular 2 - but the fact that React is not very opinionated I think is an issue. The problem is, that freedom appeals to highly skilled coders but is likely to confuse and annoy the majority of coders who want to be shown how to do something. There's some complaint over the Angular learning curve, yet takeup is astronomical. All the articles on React praise it for how easy it is to get started, yet takeup remains anaemic.

I have no doubt gaming_mouse is a better programmer than I am, but there is zero chance Mithril becomes a widely-used framework. The chances are higher for React, but I think it is likely to remain a niche thing. Like Lisp and many others before it, I feel it may fall victim to the Worse is Better trap.

I was making fun of the insinuation that they are using load times to performance review their engineers' work, as if that is some brand new oppressive set of metrics.

I would argue that almost every company that is in the eCommerce space and is doing >10mm yearly probably has similarly "oppressive" metric driven performance analysis for their website engineers or vendors.

Again my experience with Angular is writing a few simple apps that display data so not sure how great custom directives are vs React's built in component style so I can't judge them there. On the surface they look significantly more difficult to implement.

I think the takeup on Angular is partially because of google backing and because people needed a solution that wasn't out there beyond Ember. I wouldn't be surprised to see significant React uptake mostly due to HN spam, facebook backing, and React native as a solution for mobile. Most of the startups I see lately are built on React vs Angular.

And yet that's still a lot better than the grunts in the logistics centers. Amazon just seems to suck all around as an employer.
[pretty sure the article is overstated but the general idea seem accurate. Amazon doesn't really seem to have "employees make us great" in their corporate DNA]

Aren't Relay and graphQL meant to replace Flux for the most part? Relay has recently been introduced so no idea yet.
http://facebook.github.io/react/blog...d-graphql.html

Overall I agree the component based approach makes sense to me. At least it feels like the right way to abstract stuff for now.

Haven't heard much about those beyond that intro post. It says they're working on a public release so will maybe look then. Oddly, their last code commit on github is from 3 years ago. Regardless it seems like its more about data retrieval than state management so flux may be around for a while.