bravenewgeek.com

In the start-up stages of an organization, much of what gets done is attributable to resources—people, in particular. The addition or departure of a few key people can profoundly influence its success. Over time, however, the locus of the organization’s capabilities shifts toward its processes and values. As people address recurrent tasks, processes become defined. And as the business model takes shape and it becomes clear which types of business need to be accorded highest priority, values coalesce. In fact, one reason that many soaring young companies flame out after an IPO based on a single hot product is that their initial success is grounded in resources—often the founding engineers—and they fail to develop processes that can create a sequence of hot products.

Summary

There will always be gravity. As such, shit will always roll downhill. It’s important to embrace this structure, to understand the relationships, and to set appropriate expectations. Equally important is fostering an engineering culture—a culture of curiosity, ownership, and mutual understanding. Having the right people is essential, but it’s only half the problem. The other half is instilling the right values and practices. Shit rolls downhill, but if you have the right people, values, and practices in place, that manure might just grow something amazing.

“Winter is Trumping”: The Donald Trump “Game of Thrones” mash-up you’ve been waiting for

"Every one of these candidates says, 'Obama's weak, Putin's kicking sand in his face. When I talk to Putin, he's going to straighten out,'" 

"And then it turns out, they can't handle a bunch of CNBC moderators. If you can't handle those guys, I don't think the Chinese and the Russians are going to be too worried about you."

Some people build furniture. Some people knit. Some people have hobbies that don't involve HTML specs from the 90s. I am not those people. So here's a story about <input>, how it got to be the jerk that it is, and why it needs to die in a fire.

...

Later in 2011, the HTML5 spec added a billion new input types. It's now 2015, and most are not implemented. The TL; DR of the missing features is: type=color only works on Firefox/Chrome, date/time inputs only work on Chrome/Edge/iOS, and everything that works on Chrome works on Opera. Here's a demo of all of the different input types to date, so that you can compare and sob by yourself.

...

You see, I can justify CSS quirks. I worked on Chrome for 2 years, I work next to the Blink team now, I understand we're all writing different renderers and they all have their own CSS bugs. However, the <input> API isn't quirky — it's literally just a jar of spiders, and the moment you open the jar, it's too late. You're covered in spiders. Even your cat is a spider now. Better find some fire.

There's more. I'm sure there's more. The thing is, browsers have had 21 years to sort out inputs, and they haven't even managed to agree on how to communicate "you haven't picked a file".

Ember.js, Another year of churn, instability and festering frustrations.

I’ve been using Ember.js for years. Practically since it’s inception. That doesn’t make me smarter or more qualified, it just gives me a little more perspective [I like to think]. My current role is “lead Ember.js engineer” on a ten person product team. That is to say, it’s my job to keep up with changes to Ember.js, helper ensure good practices, file bugs, etc. I’ve also published and maintained a few add-ons. I’ve written this post in part to vent about growing frustrations and in part to see if other developers share some of the same concerns.

medium.com|Frustrated Ember Dev

For a very long time the phrase, “stability without stagnation”, has been uttered by many on the Ember.js core team. It’s really just a cute way of saying, “things are changing, keep up or get left behind”. The churn of Ember.js has become exhausting. More and more I’m fielding questions from other team members about, “Why did this change?”, “How should I do it now?”, “This is different, but how is it any better?” and my personal favorite, “What’s the status of Ember-Data?”. I’ve become an Ember apologist just to mitigate the frustrations of my colleagues, some of whom who have compared Ember’s churn to that of Tapestry 3, 4 and 5.

So let’s talk about their frustrations, and mine.

We do our very best to “color inside the lines” as Tom Dale once put it. We’ve adopted ember-cli, we’ve adopted new APIs, we’ve discontinued the use of old APIs ASAP, and we frequently refactor to newer patterns (e.g. services, components). All of these have a cost to us. A cost to change the code, a cost to continue to educate team members and most importantly a risk of regressions for our users. After each “major” upgrade/refactor/whatever_you_call_it we review the high level net out. All to often the net out is, “We’re up to date on Ember. Things didn’t get easier, they didn’t get harder, they’ve just changed.”.

Let’s get specific about Ember 1.10.x — Ember 2.x.

Recently, we’ve spent a good bit of time cleaning up all of the deprecation warning and trying to practice Ember 2.x patterns. The first and probably most prominent example that comes to mind is {{bind-attr}}. I spent nearly a week of my life changing: `{{bind-attr class=”isActiveUser:enabled:disabled”}}` to `class=”{{if isActiveUser ‘enabled’ ‘disabled’}}”` and the high level net out of this change is as a previously stated, not better or worse, just different. The same can be said for computed property, `{{each}}` block helpers, `this.attrs`, “router resources”, angle-brackets”, the list goes on. It’s not really better, it’s just different.

With Ember, proper code patterns have always been a bit hard to figure out. And if you try to swim upstream, you’ll get burned. The docs and guides cover the API really well, but they don’t cover holistic patterns. There is no definitive authority on how to structure large parts of your code in a way that is future proof, this recent effort was no exception.

Some examples of improvements are:

• LTS (Long-Term Support) Releases (RFC #56), which can give users who want to upgrade less often than every six week a sanctioned way to do so.
• Mandatory docs. No new features will be added to the Ember 2.0 release channel without accompanying documentation.
• More informative deprecations. All deprecations will include which release their behavior will be removed in, as well as a link to transition instructions.
• Improved deprecation tooling. More informative deprecations allow us to make the Ember inspector's deprecation pane smarter, and more useful for incrementally working through deprecations. In particular, we can avoid nagging you (by default) about removals that will not happen until far in the future. For more information see RFC #65 and the included comments.
• Svelte Builds, which allow you to ask Ember CLI not to include deprecated features you are no longer using. This will reduce pressure on future major releases.