hharnisch

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.

For all the great things about SQLite there are some concerning things around the project.

First off, even though the source code is public domain, you can't contribute since it is closed source: https://sqlite.org/copyright.html

There are 3 developers who maintain the project https://www.sqlite.org/crew.html and operate under a "code of ethics" that used to be called their "code of conduct" https://sqlite.org/codeofconduct.html

While it succeeded in getting widely adopted I have trouble believing that this is 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.

The company doesn't have to answer every question but it would be a huge red flag if the company could not answer any of them.

We often use GPS as a way to synchronize time accross distances. Even Google's data centers use GPS (and an atomic clock) for synchronization - https://www.google.com/amp/s/www.theverge.com/platform/amp/2...

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.

I am talking solely about stylistic rules. Tabs vs. Spaces. Const vs. Let. Single quotes vs. Double quotes - that sort of thing

let vs const is not stylistic - they mean different things and V8 can optimize for them differently.

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.

These are cool! Have already pushed out a fix for the first one. There's a toggle checkbox now for that. I've added your feedback here: https://docs.google.com/spreadsheets/d/139IKt9Y_ubvLnU3ITLHH.... Thanks so much!

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.

Curious how that would work in chrome, would you drag in individual tab into the chrome extension?

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

A snapshot of the data I'm collecting https://cl.ly/0Y0h0s1N3t0K

Awesome feedback here! Starting to see some patterns on what people expect it to do. Going to fix some of this today and post an update

Updated to the sync api, says it could take up to an hour to publish.

Current implementation uses the local chrome storage api (chrome.storage.local). Could probably swap that out for the sync api (chrome.storage.sync). Haven't tried that yet though https://developer.chrome.com/extensions/storage#type-Storage...

The Chicago tech scene is simply smaller than the Valley and New York scenes. Theres plenty of pockets of talent and ambition.

This is interesting because it starts to peel another layer of the problem. Yes there are still cues that can give away gender, but this seems another step closer to making the interview process a science. The next logical question from here is "why are women more likely to quit after 1-2 bad interviews".

I've captured this exact workflow, and it works really well in practice on mobile and browser (probably anything that can curl with JSON) https://github.com/hharnisc/auth-service

On another note I've been working on a service that generates expirable/refreshable JWTs. Its a good way to start trying them out https://github.com/hharnisc/auth-service

JWT is especially useful for validating requests in a microservice architecture. You can pass around the token an embed roles in them. No need to keep a session store with them!

"Flexbox’s style code is about half as long and far easier to understand than the code of Auto Layout."

Hell yes! Is this a rough estimate or did you compare implementations in each?

Looks like you learned the hard way about hovering over to expose features. If you've got touch screen users those features will be virtually useless as well.

One thing that would have been cool to see your writeup would be how you used direct customer feedback. Maybe it was none at all, but I suspect talking to customers (or even internal employees) helped you reach some of the conclusions you made. It's really difficult to look at a graph and go, yes this is the thing that caused the change.

You missed the point. People aren't posting better algorithms, they're posting domain specific knowledge to improve efficiency. The kind of stuff that takes you away from building new features that add value. Benchmarking and efficiency is an important datapoint when picking a language. It's important to understand how un-optimized code performs too.

I think a lot of people are overlooking something really important here. There are numerous comments about optimizing the code to perform better on this task. I might even go as far to say people are taking offense because their language of choice didn't perform as well they'd hoped. Many of these comments add complexity to the solution and make it harder to maintain. I like the fact that the author kept things simple. It's kind of like using the default settings for each language and then comparing the results. Both the simple version and optimized version are important data points, and they give you a better view of each languages limitations.

Does DNS based service discovery work yet? If not these images don't play nice with kubernetes.

Very! But being a programmer does not necessarily make you happy though. In a similar way that having lots of money doesn't necessary make you happy. If you invest some time in looking for a good team, at a company that encourages learning - you're getting closer. Work on something you're interested in. If you're missing one of those things, change it... Keep changing it until you find something that works for your lifestyle. You'll either find it or figure out programming isn't for you.