HN user

sciyoshi

176 karma

[ my public key: https://keybase.io/sciyoshi; my proof: https://keybase.io/sciyoshi/sigs/GpbbM2psK6642uQi_woEd6V8gEiLVFQmn5F_Ssya5CY ]

Posts15
Comments40
View on HN

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.

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:

https://dev.to/alexandras_dev/decaffeinating-2020-migrating-...

More power to you if you keep on using it, but maybe this can help explain the reasoning behind why we made the decision to switch.

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.

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.

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.

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?

They're literally making up money as they see fit.

I'm playing devil's advocate here (I agree that the whole Tether situation is concerning), but also genuinely curious - is this any different than what banks have been doing for forever with fractional reserve? Even if Bitfinex is overcommitted and there's more USDT in circulation than they have in USD reserves, is there a problem unless a lot of people try to convert at once?

Not quite. A sha256 preimage attack would possibly let one mine blocks more quickly, but would be significantly more difficult than a collision attack, which won't help you in this case. On the other hand, finding private keys for a given account would require solving elliptic curve discrete logarithms, and only then for bitcoin addresses which have been used as inputs to transactions. (This is one reason why change addresses are a good idea).

For something as important as contract code, there should still have been more failsafes. Even just having a kill() on the main contract that doesn't delegate out to the library would have protected against this.

This vulnerability had to do with the multisig wallet library code, not with Parity itself. Using geth won't protect you from badly-written contracts.