Threads for arshbot

  1. 1

    I generally appreciate this article as I’ve found myself in peculiar circumstances in the past where going bottom-up wasn’t the best idea.

    However, I’m going to have to push back against the dismissal of unit tests, especially if you’re going greenfield (which it seems like this article is targeted at). I read the article linked and frankly this quote -

    Most of the value of a unit test comes when you change the original (tested) code

    Couldn’t be more wrong, especially in the context of greenfield component building. Unit tests exist to ensure the component holistically functions correctly, and as this article asserts - oftentimes this means relying on other components/apis. If any of those components alter or break in unexpected ways, our original component may fail in unexpected ways as well.

    Basically: Making a change in place A can have an effect in place B.

    In practice, being able to automate the testing of all components is often the only thing keeping legacy code in check. Let’s not brush it off so quickly

    1. 4

      I agree and was annoyed by this line in the article:

      The correct way to architect and write a program is top-down

      I completely agree that the correct way to architect a program is top-down. I completely disagree that the correct way to write a program is top-down. Conflating the design and implementation phases of a program is pretty worrying for someone giving advice on how to design and build programs.

      My general rule is design top-down, implement bottom-up. When you have a top-down design, you know what the components should be. When you write code bottom-up, you don’t have to write much before you can start writing useful tests.

      My corollary is: refactor early and often. Once you actually implement bits of a complex system, you will discover that some of the assumptions that you made in your design are not actually valid. Unit tests help here as well, because any change to the component’s behaviour will affect some tests and you can then check that the behaviour has changed in the way that it should, not some other unexpected way.

    1. 10

      I was expecting a little more than “it doesn’t use semantic html” to qualify it as a “Fractal of Bad Design.” I get that that’s not good, but this article hasn’t really convinced me that i shouldn’t use Flutter Web, just given me a reason to be somewhat more wary of it than I would be otherwise.

      1. 10

        If accessibility isn’t a good enough reason then what is?

        1. 5

          It depends on the circumstances - difference circumstances have different requirement - sometimes I’m making a tool just for myself, so I don’t care that screen readers or userstyles don’t work. Also, the article doesn’t mention it, but Flutter does seems to care at least somewhat about accessibility, and Flutter Web is still in beta, so it seems quite possible that this will improve in the future. I’m not sure what the roadmap looks like (since I’ve never used flutter), but it seems likely that accessibility will improve in the future. Flutter also seems pretty open about the limitations of Flutter Web:

          Not every HTML scenario is ideally suited for Flutter at this time. For example, text-rich flow-based content such as blog articles benefit from the document-centric model that the web is built around, rather than the app-centric services that a UI framework like Flutter can deliver. However, you can use Flutter to embed interactive experiences into these websites.

          1. 1

            What I was expecting was a more in-depth report based on experience, rather than a “I looked at it for a few minutes and here are my first impressions”, which is what this post seems to be.

            It’s almost unimaginable to release something like this in 2020 and not have a11y support, so I did a quick search and it seems like accessibility is possible with flutter. I don’t know how well that works in practice (I never even heard of “Flutter” before I read this post) and it’s entirely possible that it’s really bad, but it’s not even mentioned in this post which leaves me with the impression that the author doesn’t know either.

          2. 10

            I agree. I think this is major flaw, and I think it’s suspicious that google has put out a major tool that essentially breaks automation.

            But ‘fractal of bad design’ implies significant and unique design mistakes that culminate into something much more serious, across a multitude of surfaces.

            And and top of that, the conclusion of

            Flutter is a misguided attempt to achieve the impossible: quality cross platform experiences

            Is I think a little hyperbolic, especially when the article doesn’t tackle any topic related to cross platform considerations at all.

            Classic clickbait, but that shouldn’t take away from the concerns illustrated

          1. 21

            Not directly answering your question, but I think one thing that gets people confused is that the relevant “scale” doesn’t really refer to the number of container instances / processes.

            What’s more relevant is the number of different services that need to be isolated, and the number of people working on them.

            So basically if you have 50 different services by 5 or 10 different teams, then it may make sense to use Kubernetes.

            If the whole company is operating a single service but has 10,000 instances of it, then it may not 00 even though it’s a large “scale”.

            I say this because I saw a 10 person company using Kubernetes, saying it’s because they have a lot of traffic. The amount of traffic is mostly irrelevant – it’s more the amount of configuration.

            So another way to say it is that heterogeneous workloads can benefit from an abstraction like Kubernetes, but a homogeneous workload may not. (And it’s also possible to make your workload more homogeneous to reduce the ops burden.)

            1. 7

              Still, it offers a nice framework anyway. You have loadbalancing, Network policies, replication, volumes, secret management, …

              You have a definition of how your system is supposed to be running. Not just a shell script with diagrams showing that you should manually ask one hosting company to add firewall rules or give you an additionnal 50GB of disk on VM vmbackend02.

              1. 14

                You can have this kind of definition using Ansible/Terraform/etc. — tools that manage resources but don’t introduce a whole-ass distributed cluster mechanism.

                1. 4

                  I’m not sure how much you’ve used those tools, but they definitely have their edge too.

                  In addition, they absolutely don’t offer the same features. Ansible and terraform won’t restart my containers when they crash, they won’t re-schedule them if the VM stops, if you want secret management like in kubernetes you’d have to work with a distributed solution anyway, …

                  I’m very surprised by how much a bad rap Kubernetes is having… I’m not sure many people go beyond “it’s a yaml thingy that does too much”.

                  1. 4

                    Nomad does what you describe, has no YAML and a lot less complexity.

                    1. 2

                      That isn’t true. Nomad doesn’t manage storage/volumes, it doesn’t handle secrets (vault does), I’m not sure it has security policies, and last I check the service mesh was done using consul.

                      So no, Nomad is doing 1 thing (admittedly well), but then you have to plug many other services from different places to get some features from kubernetes.

                      I agree there is a lot that you can dislike in Kubernetes, but there are also many things to dislike in ansible terraform and nomad that you guys mentioned.

                      1. 3

                        However Kubernetes also isn’t just one single piece of software, but multiple, like etcd, etc. and even when setting up Vault (which often gets done in Kubernetes as well), Consul (which often gets done in Kubernetes as well) you will end up with a much easier to reason about and way more flexible system. Also Nomad allows something like what Kubernetes calls volumes in recent versions.

                        I did not mention ansible nor terraform. I however set up both Kubernetes (managed and self hosted) and Nomad with Terraform.

                        Also I am not saying Nomad is perfect and I really don’t think it is, but acting like Kubernetes is the only or best option simply isn’t true. It’s certainly to most hyped though, with all that comes with that. I also think it might be better suited if you are setting up a cloud provider like AWS or GCP, but that’s something that might change when someone starts out offering a managed Nomad (or Hashicorp Stack) cluster.

                        I also think it’s somewhat likely that there will be new generations of these types of software (I say these types, because I wonder how containers evolve as well). I think they first represent a first generation and because of that - like with every other kind of software - this in a way is experimentation and so I wouldn’t be surprised in the next couple of years we see way better options coming up, whether that’s Kubernetes 2 or something completely different.

              2. 1

                The scaling of individual contributors is something most don’t consider when evaluating k8s, and is a huge reason to consider the pros/cons of vendor lock-in with microservices.

                Coinbase recently said this was the main driver for moving away from their monolith to aws based microservices

              1. 15

                Ctrl-Z and fg are shell features and have nothing to do with vim. Also the “-” as a sign to read from stdin is a very common pattern in unix and many tools understand this. The “**” thing looks like fzf and has also nothing to do with vim itself. I know that I am splitting hairs a bit here, but I feel we should attribute things to the right tools and not conflate shell features with vim.

                1. 10

                  Also “nvim” is neovim - not Vim!

                  1. 2

                    I didn’t mean to mislead so much as impress VS-Code users / command-line-shy types with the might of what you can do with vim’s nimble CLI :)

                    1. 1

                      And here I thought I was a fool for installing fzf, but no - it looks like ** simply expands for the current directory

                    1. 3

                      This isn’t a zero day. It’s known by Apple, and presumably already addressed. It doesn’t really say so, except it refers to the exploit in the past tense.

                      Apple also did an investigation of their logs and determined there was no misuse or account compromise due to this vulnerability.

                      1. 7

                        It was a zero-day when he took it to Apple, otherwise they would be suing him for $100,000,000 for publishing this article instead of having rewarded him with $100,000.

                        1. 1

                          No, not really. A “zero day” is an vulnerability that has not yet been patched by the vendor. There’s no vendor here. It’s not like Apple was waiting on Nginx to release a patch; Apple is both the author of the software and the affected party. When they were notified, they patched; as soon as the patch was put in place, all “users” of the software were instantly patched—because there was only one, which was Apple.

                          The premise of a zero day is that you can find a vulnerability in a product and then exploit it in all the places it is used. That’s what makes them interesting.

                          1. 0

                            all the places used

                            All the places that use Sign In With Apple. Just because only one centralized server deployment was vulnerable doesn’t mean it wasn’t exploitable all over the web

                            This is a really stupid thing to argue over, and you’re wrong anyway

                        2. 3

                          There are two definitions of 0-day:

                          • The vulnerability is known outside of the vendor before the patch is released.
                          • The vulnerability is actively exploited before the patch is released.

                          This definitely meets the first definition. The second is less useful: you can sometimes show that something is a zero-day according to this definition but you can rarely show that something isn’t.

                          1. 2

                            I assume that refers to the steps apple took after they verified this bug was valid, however I agree - there is no indication per this article that this is a zero day

                          1. 1

                            Working on a demo implementation of submarine swaps between Bitcoin and the lightning network usijg basic bip199 HTLCs.

                            Pretty much done, just need to do some additional testing, kubify the thing and host somewhere

                            1. 1

                              This is actually a huge reason why I do so much of my development in kubernetes as I go, instead of hosting everything in post. While developing, not only do you get to deal with deployment issues in real time, and savings in time from having to handle a fragile dev environment ( esp if your deployment relies on multiple servers working together ) - you can see realistic performance in real time. Very underrated and you never have to wonder how things will actually perform in prod.