I'm not even old (mid-20s), but I scale the site to 150%. HN is honestly one of the worst sites I have used with regards to default scaling across resolutions.
OTOH the simplicity of the site allows for very easy browser-based scaling, which means I only really think about how bad the text size is once per machine.
This seems to only really work in languages that allow null variables/timestamps. I wouldn't really want to have to do comparators to the default value of a timestamp.
I think that the biggest differentiator between Discord and the others (mumble, TS, Vent, etc) was that Discord has very mature text chatting as a first class citizen, rather than an afterthought. This is what I have anecdotally seen as the primary thing that has made even people who casually voice chat join public discord servers. The model is much more friendly to casual users than either TS or Mumble are.
I have been a big fan of the Mozilla Public License 2.0 [1]. I find it is the best combination of "if you use this and improve or modify, those changes need to go to the original code" while not restricting overall usage.
IMO there really isn't anything you can do to prevent people from making a product out of your work if it is open source, but what you can do is make sure that if someone makes improvements to your work, those improvements need to be publicly available under the MPL2.0 license as well.
This has the effect that if someone wants to make a product by just 'adding one line' that line needs to be published and you could add it upstream, making it publicly available again(thus making it harder to make a product solely from your code).
There was a really interesting paper [1] being circulated a bit last week in the circles I frequent on a few sites that dug a bit deeper into this. The villains are often very superficial and the consequences of the ensuing fight is very rarely shown in the movie itself, and if it is mentioned only in passing. There is this 'cleansliness' to the fight scenes that give you all of the enjoyment while removing any of the dirty human tragedies from the context.
Really interesting read, and something that I have thought about quite a few times while seeing how popular these movies are nowadays
To be fair, from a security standpoint if you want *the highest security* allowing third party installers is one of the first things I would disable as well.
I have a very hard time getting behind these complex configuration languages. To me what makes a configuration format good is the simplicity of reading the configuration of a program, and almost all of these languages are optimizing for feature complexity over readability. I think that all of the popular config formats (yaml, json, toml, etc) have issues, but none of the major issues with them have to do with being unable to represent a fibonacci sequence in their language.
To draw a direct comparison, when I look at the examples in the github repository, all I can think is "I would never want to have this be a source of truth in my codebase". While I get frustrated w/ whitespace in yaml and the difficulty of reading complex json configuration, if I need a way to programmatically load complex data I would almost always rather use those two as a base and write a 'config-loader' in the language that I am already using for my project (instead of introducing another syntax into the mix)
Yabai (https://github.com/koekeishiya/yabai) and skhd (https://github.com/koekeishiya/skhd) together makes a very powerful combination that works extremely well. It's as close to i3 as you can get on MacOS, and outside of a few odd things with 3 monitors I haven't run into any issues.
Yabai is actually the second iteration of tiling windows that koekeishiya has made and it's super well developed.
In my experience, I have seen much less of the OOP-only group, especially in recent years. The general feel I have seen when communicating with other developers about this is that OOP is a tool and it's probably not the best one, but they are comfortable with it and it's problems.
In general it feels like the overall feeling to FP is either
"I don't have time to learn a new paradigm when my current one is working good enough to make the company money"
or
"I love using FP ideas in my code when it makes sense"
I really feel like this is the ideal state for Software Development, as either side "winning" will only hurt the robustness of the environment.
I have to say I really appreciate this! I was going down very similar lines just last week (I had installed Hammerspoon and was experimenting with some applescript hacks, but to no avail).
Just intercepting the actual scroll and inverting it is a really elegant solution (that doesn't require a relog) which is great.
This solves one of the two biggest gripes I had about MacOs - with the other being my inablility to "pin" my dock to one of my monitors, overriding the swap functionality. Thanks!
I have been looking for a solution to this problem for a very long time and my reasoning is that on a trackpad, natural makes a lot of sense intuitively, since you are "pushing" the document (page/app/whatever) the direction you want it to move.
Whereas when I am using a mouse I feel like I the document is below the mouse more or less and when I move the scrollwheel it is physically moving the document as if it was tied to the scrollwheel.
Not sure if that makes any sense, as this is just some internal feelings on it, but I have beeen manually toggling the natural scroll when i plug and unplug my mouse ever since I started using MacOs
I think that is a very optimistic view of how things are currently - I think 80-90% of all business still operates in a similar organizational fashion as it did 20 years ago, and it is changing linearly at best, not exponential.
TBF with a completely greenfield project and managed K8s (GKE or EKS) you can absolutely get a pretty well set up infra very quickly if you are willing to learn how to do so.
I often get the feeling a lot of the negativity comes (rightfully so) from trying to replicate a current existing project into kubernetes. This is true of almost any paradigm - try replicating a Java EE monolith into Erlang and you are going to have a lot of problems. The big thing to note is that starting a project on Erlang very well might solve the problems that a Java EE project ran into, but that is because they were able to solve them at the ground floor, and just popping a Java EE project with all of it's architecture into an Erlang project will probably end up in a worse spot.
I think that this is what often happens with k8s as well - if you or your company have a currently working implementation that isn't on k8s, of course you won't be able to just easily plop it into a k8s cluster and everything be all well and good, but I think the problem is that people are equating that issue with k8s itself, which is a completely different paradigm.
Large projects like Hugo and Kubernetes have used Cobra to build their CLI tools, and it's fairly light as well even if you need simpler usage. We use it at my workplace simply for wrapping our microservices and the few commands (serve, migrate, etc)
As a counterpoint, buses/railways are imo 100% an essential service for cities and yet they were running empty during the COVID-19 lockdown where I live. I would hate to see them recategorized as non-essential because of a situation that is clearly completely abnormal.
First off, thank you for looking at the project and giving feedback - I really appreciate it!
- Do all the consumers of gila config use the singleton class instance and just call gila.get() everywhere?
You can either use the singleton pattern (which is the recommended way of utilizing the library) or you can assign the Gila object to a local variable and ship it around your code (this would allow you to have two separate configurations at the same time). You could see that here: https://gitlab.com/dashwav/gila/-/blob/develop/examples/mult...
I also think striving for readability is the way to go when building code in general, and that is actually one of the reasons I opted to keep the `.get()` syntax! This may come down to personal opinions but I think that when the behavior of a library is fundamentally different than that of a base type like dict it should be explicit that a library is being used.
While dictionaries also have a `.get()` syntax I think that seeing `config['value']` would lead a developer to make the assumption that config is simply a dictionary, and this might lead to erroneous code whereas `gila.get("value")` (or even `config.get('value')`) will make it more obvious that this is not a dictionary but actually a library that is doing more than a dictionary under the hood.
As a final point this syntax keeps it closer to the Viper go library that I was inspired by and therefore eases the transition between the two should anyone have familiarity with either library.
Yeah I had used django in the past and had run-ins with `django-configurations` and while it is an extremely powerful configuration library, I set out to make Gila a much more portable and simpler API for more generalized use - with the goal that this library can be nearly drop in with 0 configuration in most projects.
I would love to hear any feedback should you decide to use Gila in one of your projects!
I recently ran into a few roadblocks as well when trying to get my python applications set up in a true 12factor way, and I was surprised by how much I had begun to take for granted the ease of configuration that the Go library Viper provided. I went ahead and wrote a library [Gila](https://gitlab.com/dashwav/gila) that implements a similar set of features that I think does a very good job of allowing for 12factor app building in python.
Specific to the article, my way of handling the issue of "turn everything into an environment variable" is to rely on the cascading feature of Gila/Viper and store sane defaults in code that only are overridden when need be. This allows for default values to be set, overridden by config files provided, and further overridden either by code or by ENV variables.
This would allow us to instead of having config written in python (something I usually try to stay away from) we could have it written in something like YAML or TOML instead and loaded in on the fly in each environment, while still allowing for overrides in either the code or by ENV variables.
I recently (last few months) have switched all of my python projects over to using Gila and I have been super impressed by how well the language itself lends to building dockerized 12factor apps when using tools made for that purpose - which is a sentiment I would not have had last year at this time.
MIPS still has a very large presence in the education sector as well - MIPS asm is very easy to learn because of how consistent it's syntax is and the plethora of open source debuggers as well.
Learning MIPS was what originally got me interested in ASM programming since we had a class that was focused on MIPS code and another class that had us build a digital MIPS processor from scratch. The combination of these two classes really sold me on the magic of super low-level programming.
Thank you for this - my team and I have been looking for a replacement to PgAdmin for quite some time now and this fits the bill exactly. Two features I thought we were going to have to give up when moving from MySQL to PG where ERD management in-app and the ease of use of MySQL workbench.
OTOH the simplicity of the site allows for very easy browser-based scaling, which means I only really think about how bad the text size is once per machine.