I find it very surprising that they went for unchecked exceptions. For JsonValueException the following rationale is given "This exception is unchecked, so that scripts and small programs are easier to read and write." But for JsonParseException there is no rationale. This is surprising especially given the pushback from openjdk members against jackson3 moving to unchecked exception.
I wonder how the legal battle will develop : the trademark https://data.inpi.fr/marques/FR5133202 is France only I think ? So a Paris resident infringed upon by a NYC resident, with content on github and also a website registered with godaddy (according to whois) and using cloudflare dns servers. Good luck sorting everything out. Although maybe the relative fame of the project will act as a lubricant/privilege in this case ? (IANAL but if this case is as obvious as it looks, speed would be good. And ideally it would be fast for any such case, not just the famous ones)
Since they had the reconciliation system because they decided the main use case was declarative, it makes sense that they used it to implement kubectl run. But they could have done it differently.
Imagine if pods couldn't reach other and you had to specify all networks and networking rules.
Or imagine that once you created a container you had to manually schedule it on a node. And when the node or pod crashes you have to manually schedule it somewhere else.
To me the core of k8s is pod scheduling on nodes, networking ingress (e.g. nodeport service), networking between pods (everything addressable directly), and colocated containers inside pods.
Declarative reconciliation is (very) nice but not irreplaceable (and actually not mandatory, e.g. kubectl run xyz)
I'm surprised the author doesn't mention environment secrets, which I think currently are the only way to avoid that anyone with push access to any repo also gets full access to all secrets (by pushing a new workflow file and triggering it). This makes org and repo secrets practically useless for any team where only admins or maintainers should have access to secrets.
Neither Branch Protection nor the newer Rulesets allow to protect secrets from someone with push acces to the repo. From what I understand, only environment secrets provide this feature (and have the drawback that you can't share them among multiple repos in the same org without copying them everywhere, although you can script the copying with the github api)
I would have had more sympathy for the author if they explained why they care so much about github stars. It's just internet points after all. At the very end, they say "What started as a side project has recently become a company" so if it's all about business, maybe they could have made that more prominent.
EDIT: sorry, not meant to be harsh. Hopefully you get what you want and thank you for writing open source software
Where are all these batteries and solar panels made ? How much GHG was emitted to build them, and how much GHG is expected to be saved by choosing this kind of electrical grid instead of alternatives ?
This website is overloaded with adds. It almost feels like a scam. Based on the fact that almost all other comments are not talking about it, I guess at least one of the following hypotheses is true (if not all of them):
- most people here use an efficient addblocker
- The website changed since its first appearance on the first page (maximize revenue?)
- some comments are sponsored
- on mobile it feels overwhelming but on desktops it's more bearable
We use socat to buffer logs sent from containers (docker-compose) during the short window at startup where logstash and elasticsearch are not ready yet. Works great!
Using java8 in 2019 is pretty normal. It's "only" 6 years old (released at the beginning of 2014), nothing like the cobol horror stories. The 6 years old java is not very different from what software you get from debian stable. The next lts java11 was released at the end of 2018 and does break some things so you need time to update. It was supported by oracle until Jan 2019, while other vendors have pledged support until 2023 and more.
And most importantly java8 is still a decent experience.
Too bad that google codejam limited the available languages starting from 2018..
Factor is a very impressive engineering accomplishment, the standard library has so many useful algorithms and data structures implemented, and almost all of it with very clean APIs and documentation.
It's a nice visualization, but cpu usage shoots through the roof ! Deleting the animated arrows between the countries helps a bit, but then it still uses around 50% cpu (and that's on a fast desktop computer. Can't imagine my laptop trying to display this page). Using Ubuntu + firefox (it's a little better with chromium).
Is it a problem with this page ? With my setup ? Or is it just impossible to do something of this quality on the web without monster cpus ?