I really love using dbeaver[1] as a Postgres IDE. It requires a small bit of configuration for me to use it (why are the defaults to automatically lowercase all of my SQL?!). Other than that it's excellent!
It's a surprising default - for better or worse history made the convention that SQL KEYWORDS be uppercase (when pretty printed). I assume it stems from case being irrelevant and a time of green screens and monochrome printouts - but it's still the most common formatting/presentation of sql?
Ha, initially misread your question as its opposite (~"would reading technical/non-work related books in my spare time be a waste of time") and immediately thought no, of course not! To me, doing non-work related things outside of working is what makes _both_ activities things fun.
Don't be hard on yourself for not spending every waking minute of your life working, preparing for work, or feeling bad because you "should" be doing one of those two. That's a very quick way get burned out.
YMMV, but in my experience, even if you want to optimize your life for doing the best work possible, not working all the time is a winning strategy!
Not OP, but I've recently worked with AWS Parameter Store a lot, and I've been very happy with it so far. We store all configuration (including secrets) using it.
In practice, we have a client written in Python that grabs configuration from Parameter Store and puts it into the process' ENV variables at startup. This allows us to avoid vendor lockin in the rest of our code, since we still just fetch all config from the environment. I like it so far :)
Tailscale looks like it's creating a mesh network - he's not asking for end-users to have VPN connections between each other (what Tailscale is doing).
He's asking for a central server where he can retrieve/update/manage end-user keys, likely: because helpdesk.
You could in theory do this with any number of the existing team password managers, but I think he'd like integration directly to wireguard.
Edit: care to reply rather than just downvote? All of their documentation and examples state exactly what I'm saying. They're turning all the devices into endpoints and creating a mesh - he doesn't want users bypassing his SINGLE VPN endpoint into the company or talking directly to each other based on his description. He wants Cisco Anyconnect - only wireguard.
It doesnt look like a nail/hammer/screw at all. Tailscale isnt configured how he wants out of the box, but using SSO to control access isnt a massively complex hurdle. Anyone with Office 365 will be able to use their Office account to authenticate, which is basically Cloud Active Directory, and way better (if its something you have) than maintaining a separate username/password database for the VPN.
We get this question about ZeroTier from time to time and the answer is the same: set rules (or ACLs in Tailscale) so as to allow only traffic to/from what you want users to communicate with.
Sure - you can block access but the fundamental problem you're appearing to target isn't what he's after. Heck to even get the user-auth he's asking for you have to use tailscale + some third party app whether that's okta or azure or google. I'm not saying he can't sort-of accomplish what he's trying to do but it very much feels like you've got a hammer and think his screw looks like a nail.
The somewhat silly video on that page shows the actual difference in performance our users felt after the change. It was a _huge_ benefit, both in terms of loading time, but also in terms of memory, vastly increasing the number of CS:GO rounds that could be analyzed simultaneously.
I have hereby been whooshed, though in my defense I have a guest-only, throttled and isolated wifi network so the potential for misuse didn't occur to me.
I have exactly the same. I don't want the entire world to use it though, as it still uses my broadband connection, which contains my external IPv4 address. I guess I should tunnel it over a VPN instead.
I think he's referring to the fact that maps are iterated in random order. Now if you print them directly, you may be lead to believe that the order is _not_ random.
If you print them one by one while iterating you would quickly discover the truth. Not sure why this would be worth making the string rendering of large maps much harder to use and compare (eg in log entries). Since any rendering implies an order (which is not guaranteed to remain consistent through the program's lifetime), then any string rendering of a map should be considered misleading by your logic.
Given Python's success with its insertion-order-retaining "compact dict" implementation[1], I've wondered why more languages aren't adopting that design into their maps/hashtables.
"The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon"
Early in Go's development, they intentionally randomized the iteration offset to make sure developers didn't become dependent on a behaviour they didn't want to be tied to.
You see this in Erlang also, where iteration order is deterministic (though not based on insertion order), but documentation makes sure to say iteration is arbitrary.
So, the answer to your question is that most people don't want their dictionaries implementation to be tied down due to this feature.
There's a big difference between "iteration order is deterministic" and "iteration order is <very specific high-level behaviour>" even if the latter is a side-effect of an implementation details. In particular, iteration order being either insertion order or sorted are useful and sought-after properties, while other implementation-dependent deterministic orderings are mostly implicit dependencies and sources of bugs (not unlike e.g. the scheduling sequence of goroutines in Go).
I wonder if this isn't going to be seen as a mistake in the future. What if a faster map is discovered in 3 years that happens to not preserve order? This stuff is really hard to detect, so there's no going back on it.
That was likely weighed and I'm guessing the answer is that they would introduce a new type under collections, but that the new dictionary makes most sense for users while also currently being faster
In Python, they'd probably just make it a separate class, just like `OrderedDict` is/was. People who needed the performance would use it and everyone else would enjoy the convenience of ordering.
One of my friends came up with a tongue-in-cheek name for your "default to many"-advice: https://theharemrule.com
After being given the advice couple years ago, I found it to be applicable to quite a number of scenarios me and my colleagues faced. In my experience its pretty solid!
Yeah, it's one of those tricks that I find a lot of developers in their 20s haven't learned.
There is another trick that I use when I don't control the dev team. For example, say the company has outsourced a pricing app to a third party dev shop, in this case any decision I can make that will make the app more "table-y" I make. So instead of defining control flow to determine price for any given object, what I do is I get them to make a "rules engine" that can operate on the major variables that are typically used to make decisions. That way fine tuning changes can be done on our side, and it doesn't rack up billables. I think this is called "table based design" but Googling for it isn't showing anything.
Agreed, as much as I dislike the acquisition, even I just wait and see. I'm setting up a migration plan right now of course, but I'm not going to activate it unless I have a good reason to.
[1]: https://dbeaver.io/