Indeed. I was mainly responding to the comment about waiting for "independent seasoned mathematicians to verify", whereas in this case it is easy enough to convince oneself of the counterexample's correctness.
Because I was curious about this: the use of "categorically" in the phrase "categorically false" doesn't directly relate to the concept of "categories" as groups or classes of things. Turns out it's actually related to the philosophical use of the term which originated with Aristotle and was further developed by Kant (see "categorical imperative" on Wikipedia).
"categorically" in this situation is used to emphasize the absolute, unambiguous, and unconditional nature of the falseness.
Congrats to the black team on this release, and thank you scrollaway for your fork. We are in a similar position where we are (for various reasons) stuck on using tabs for an existing project. Luckily it seems like there might be some movement on this front where the maintainer team is at least more receptive to reopening this conversation:
There's definitely a segment of people for which GSuite access and cloud storage of notes is a non-starter, but in many cases those can be mitigated even when it comes to early adopters in larger enterprise companies (eg SOC-2 compliance). On top of that, you get a lot of the usual benefits when using a collaborative tool: others can help take notes for your meetings so that effort is shared, agendas can be prepared beforehand, contributed to by all the meeting attendees, and easily accessed via your meeting invite.
You're right that one of the biggest reasons to switch is that everyone else has switched (which is a bit sad to me since I think Coffeescript had some good features to offer), and community support + developer tooling are always important factors to consider. We were on Coffeescript 2 which had niceties like JSX syntax support, but even then our team had issues with the lack of IDE support for it. We were using it with GraphQL/Relay which also meant we needed to maintain our own compilation toolchain.
In the end, the benefits of having types and first-class editor integration convinced us to switch fully which we did over the course of a few months towards the end of 2019. One of our team members even wrote a blog post about how we did it:
I really respect companies that have well-written engineering blogs that go in-depth into their technical problems - Figma comes to mind here, for example.
For a small team/company, what are some good tips or resources on how to start an engineering blog? We've worked on many interesting challenges and I know the team would have a lot of insights to share, but it can be difficult to find and justify the time that writing a good article takes, and it's not something that everyone is necessarily interested in doing either.
I'm curious about the mention of Cloudflare's culture of "internal blogging". That seems to me like it could be a first step in that direction.
There's always more than one way to do things, and it's good to be aware of the trade-offs that different solutions provide. I've worked with systems like you describe in the past, and in my experience you always end up needing more complexity than you might think. First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one? How do you track changes to server configurations and manage server access? How do you do a rolling deploy of a new version - custom SSH scripts, or Fabric/Capistrano, or...? What about rolling back, or doing canary deployments, or...? How do you ensure that dev and CI environments are similar to production so that you don't run into errors from missing/incompatible C dependencies when you deploy? And so on.
K8s for us provides a nice, well-documented abstraction over these problems. For sure, there was definitely a learning curve and non-trivial setup time. Could we have done everything without it? Perhaps. But it has had its benefits - for example, being able to spin up new isolated testing environments within a few minutes with just a few lines of code.
We've been running our own cluster on EC2 nodes built with kops and it's worked well so far. As for logging, which part of ELK is heavy? You can use the cloud operator to run it from within your cluster (https://www.elastic.co/elastic-cloud-kubernetes). We've also switched to https://vector.dev as a more lightweight alternative to filebeat/logstash.
I would highly recommend getting to know https://github.com/ovalhub/pyicu, which in addition to counting grapheme clusters with BreakIterator can also do things like normalisation, transliteration, and anything else you might need to do relating to Unicode.
Seems really interesting after a quick read-through. Specs that allow range-based validation look useful, and the structural declarations also feel like they'll help reduce a lot of boilerplate and repetition. I wonder how this compares with Dhall and Jsonnet, both of which I've been looking into as a safer alternative to templated YAML. With Google putting its weight behind this I'm curious if it'll start finding its way into K8s.
I've had a good experience with pip-tools (https://github.com/jazzband/pip-tools/) which takes a requirements.in with loosely-pinned dependencies and writes your requirements.txt with the exact versions including transitive dependencies.
Funny, because I think the Wolfram language (also as a long-time user) is actually really well-designed and consistent, and has stood the test of time. Even ignoring the standard library, it has a really expressive syntax for pattern matching and functional programming, and I find that you can often do very complex things with very little code. For doing any kind of symbolic manipulation or lazy evaluation, it's pretty hard to beat.
On the other hand, I feel that his theory of cellular automata as some fundamental underpinning to mathematics is misguided.
Agreed on avoiding yaml templating at all costs, but I've also found that you don't normally need a full programming language for these types of config files - if you do find yourself reaching for those tools you might be better served by something like Dhall https://github.com/dhall-lang/dhall-lang (which has its own K8s bindings as well)
I would agree with that. If you take a look at the exhibition match replay, there's some cases where it makes objectively suboptimal decisions. We couldn't see this during the live stream, but the double immortal warp prism caused AlphaStar to bring back its entire army from across the map, when a few units at home would have been enough to defend. It even kept trying to blink its stalkers to a place where the warp prism couldn't be reached. Perhaps this version with the limited viewpoint hadn't been trained with enough games?
Nice to see that we'll be getting a more flexible design system to work with - one that will hopefully reduce a bit of the homogeneity of the current generation of Material-based apps while still keeping some consistency.
Has anyone used the MDC Web toolkit? Does it play nicely with React and Vue?