Appreciate the feedback. #2 is actually a pretty interesting one - while clearly a change in the API’s output, we were careful to make it so that maps without API keys actually still work (though they do get a heavy visual indication that they need to get an API key).
That being said, when we are talking about such large timeframes, is it fair to portray that as “regular” breaking changes?
Hi, I happen to work on Google's Maps JavaScript API, and we actually take great pains to avoid breaking our APIs as much as possible. We take very seriously the implications that breaking changes can have for websites all across the internet, and know that many sites are not under active development.
This page covers the breaking changes from the last few years: https://developers.google.com/maps/deprecations#completed_de...
(Keep in mind that the top portion of the page covers features still in the deprecation period - meaning they still work. And that this page covers deprecations in other APIs like Android and iOS.)
My favorite: the deprecation period for v2 of the Maps JS API lasted 11 years after the introduction of the v3 Maps JS API.
Happy to hear about experiences to the contrary, but I thought a little insight might be appreciated.
For all those saying that ARIA trumps semantic elements, consider that for basic interactions semantic elements come out of the box keyboard accessible.
For example, a <button> will have default tabindex=0 and respond to spacebar key presses, but you'd have to add that yourself if you put role=button on a <div>.
In short, if there is a semantic element that matches your need, use it.
I don’t know, but does it matter? If an employee group understands how much they are worth, and can get more benefits commensurate with that worth, then I applaud them.
I think it was pretty nice of you to use a linear scale. If a company wanted that much more of my time I would have quoted them a premium (just as an hourly employee might make overtime in such a situation).
I see a lot of people who like ember-cli, but after the first few minutes I just found it frustrating. Granted, this was a little over a year ago, but at that time if you simply wanted a npm module in your code you had to do all the extra work to wrap it in an ember plugin. IMO, this severely slowed down the ecosystem.
I’d warn against Gerrit. From the best my team has been able to figure out, Gerrit encourages a development flow that breaks the golden rule of rebase and treats all pushes as force pushes. The result is that in a collaborative environment your changes are occasionally reset by someone else pushing changes.
(To my eye Gerrit seems like it was written by people who wanted git to work like svn.)
I would. A common thing I like to do is start working on top of work that's in a Pull Request. For example, maybe a coworker is adding an API that I want to use. So long as I'm confident the API won't have drastic changes, and there's just smaller polish or testing to be added, I can branch off of their branch and start working without delay. This also gives me a window to live on top of the changes and give feedback from usage even faster (maybe even before it officially lands).
I'm really surprised no one (article included) has brought up the "Golden Rule of Rebase" (https://www.google.com/search?q=golden+rule+of+rebase), which boils down to "never rebase a shared branch".
Git is an extremely powerful tool for collaboration, and it's frustrating when I see that undermined.
I'd love to see a version of this that didn't go through a "random" phase every few seconds. I'd love to see the actual transitions between the times. I think it would be more subtle, but more elegant. (You might be able to add seconds display to the clock if you wanted it to be more active.)