There are 3 people on the planet who can make changes to it and one person who can work on their custom made source control system. Single points of failure are not sustainable.
Having worked in Cedar Rapids there's really only 1 employer that makes up the "good job" pool - used to be called Rockwell Collins.
I'd guess there's a similar situation in most of towns on this list, which would mean living there is a huge risk unless you plan on working at the one or two companies in town for life.
I was expecting another company copying the core business logic based off the title, but it looks like things related to redirect and auth are very (very) similar.
Nearly every API is going to need solutions for these, and they all look very similar. I'd be surprised if the redirect and auth parts weren't at least in some way inspired by other APIs.
GPS is such a weak signal that almost anyone transmitting ground based signals on the right frequency could easily drown out GPS - and do spoofing with a little extra research. So theoretically you could spoof near a data center and mess up a lot of data powering 1000s of applications.
On top of this civilian GPS is made to be jammed and innacurate - there's a better one the military has moved onto because of this (see the m-code section: https://en.m.wikipedia.org/wiki/GPS_Block_IIIA)
So yes, relying on an easily jammed atomic clock hurtling through space seems like a bad idea... But it's kind of the best we've got right now. At least until the cost of putting your own satellite into orbit goes down.
I switched from the native Facebook app to the web app in 2014 -- which is the last location Facebook has on me. I guess this explains why deleting the app gave me double the battery life.
I've gone to the last few KubeCons and given talks at two of them and I'd also consider myself to be more of an app developer than ops. The tone has been very much that Kubernetes is deeper in the stack than most developers want or need to be thinking about. Mantras like "kubectl is the new ssh" have become super popular. So Kubernetes ends up being the platform you build your tools developers deploy their applications with -- if you work on ops. The problem seems to be that there's not a lot of agreement on what those tools actually look like. What Kubernetes does end up doing is providing a consistent API to deploy workloads across (many, but not all) cloud providers. Over time we'll see better and better developer facing solutions built on top of Kubernetes, rather than part of Kubernetes.
Depends on the person, team, and company. I've yet to see a company do local offices and remote work successfully at the same time. While there are plenty of examples of remote first companies having success. Seems like a communication issue.
Thank you for highlighting this is a such a common mistake. I hope developers of all skill levels look at this and realize it how easy it is to make this mistake and learn from it.
Hey! Just wanted to say I did try Tabli and found it to be a solid extension. However it didn't quite fit into my workflow and there's enough features that it felt overkill for what I was trying to accomplish. The goal is to save a group of tabs with a minimal steps restore them later, just keeping it simple.
Nice shout out for Toby, it's a really great product!
Toby has a bunch of features that I didn't use in my workflow and I found them getting in the way at times. Nothing wrong there at all, just intended for a different set of use cases.
The short answer is GA because it's free and allows for collecting events. I wasn't sure how people would use the app so I wanted to measure a few events. One specific question I had at the beginning was "would people want to save and close tabs". The answer so far is yes they do, but only 15% of the time. Not sure if that means to keep or remove the feature yet though :D