1. 1

    Nice post. Thank you sharing. I’,m not sure if I understood your object equality dilemma. Can you not compare objects using a double equal instead of a triple?

    > {x: 1, y: 4} == {x: 1, y: 4}
    true?
    
    1. 3

      Double equals stands for “loose equality” rather than “structural equality” in JS; all it does is cast the values to a common primitive type before comparing.

      1. 2

        Double equals and triple equals both evaluate to false for that comparison. Object comparisons are by reference, not by the contents of the object. And each side is a separate instance of Object.

        1. 1

          Just ran it in console :) I find this behaviour odd.

      1. 5

        Based on this writing, it seems that we are yet again separating dev from prod. Use ubuntu/debian base for dev, but build special for production.

        I thought one of the main points of Docker was being able to run the same container in production. Seems that’s still not going to happen with Docker either. Dev just has to run long enough to make the next commit, and needs gobs of debug built-in. Prod has to run forever and be secure.

        Seems the only upside you really get with the Docker workflow is similar tooling between dev and production.

        1. 2

          From my experience, the difference from dev/prod is not the biggest issue, as long as you have the same images for testing/staging and production.

          Some teams do not even use Docker images for development and that’s not a big issue as long as you have good CI (at least that’s been a very long time we didn’t have the “that’s work on testing and not in production”.

          1. 1

            Use ubuntu/debian base for dev, but build special for production.

            You can use the same images for development/testing, though? You might install a few extra packages into your dev environment (gdb, …) with the same base Dockerfile.

            1. 1

              If testing becomes production, I think the goal would be having production and testing IDENTICAL, or as identical as you can make them. Otherwise what’s the point?

            2. 1

              You’re right, you should strive to keep containers immutable. Having two Docker images for the same code defeats the benefit of having a CI pipeline with promotion across environments. The article doesn’t shed much light on what’s best practice when it comes to packaging applications for dev/prod. But the author seems to suggest that there’re better ways to debug containers than attaching to it. I suspect he’s referring to health checks for readiness & liveness and a proper logging library to record logs. Also, it’s generally slower and more tedious developing an application within a Docker container. Usually, it’s much easier to work locally on the code and then let CI package the immutable container. The Docker image is akin to a jar or a deb file. You don’t build those differently for dev or prod.

              1. 1

                I would think monitoring, metrics and logging would be the way to debug production in most cases. In general you just want the starting inputs and the output errors, so you can replicate the issue in dev to fix. If you can’t replicate it, then you have to break out dtrace and friends and get serious, which is super annoying.

                Well you might build your jar or deb file differently, you might strip out debugging symbols in production, it’s pretty common actually.

                I agree developing INSIDE a docker container is way annoying. I think the dev answer for Docker is to run all the extra crap your code depends on in development. I.e. my code needs Redis, a PG instance, etc to to work right, so I’d run Redis and PG in Docker for dev, but still do main code locally, if possible. Harder to do if you are writing *nix apps on Windows for instance, but :)

            1. 1

              NIce article Alex! wish you had a share button on your blog…I would have shared it!

              1. 2

                Thanks Keith! I’ll take a look at what my options are. My main concern is that those buttons are often used for tracking. On the other hand, people who care about that are probably already using things like ad blockers anyway.

                1. 1

                  I like that you care about tracking :) I don’t think users will mind though, most websitez do track users. I use “sharethis” it’s free but, yeah, They track users as much as Google does.

                2. 1

                  What’s wrong with just copying the URL from the address bar?

                  1. 1

                    :)) Well, the process for both:

                    1. Share button = click.

                    2. No share button = Ctrl+d, Ctrl+c, Ctrl+t, [start typing twitter until it is auto-suggested by browser address bar], scroll to the suggested, ENTER, Wait for loading, Click the tweet button, Ctrl+v, click tweet again.

                    The 1st option kind of encourages you to share and the user stays in same window or web page.

                    1. 1

                      I’m not saying that they’re equally easy. But even #2 only takes a couple of extra seconds. I bet it took you longer to type that response ;-p

                1. 1

                  This is a very current issue. Even I.T. jobs will start to decline soon due to ML and here we are still trying to convince students and parents to focus on I.T. when this was important 30 years ago.

                  1. 6

                    I’ve been reading this sentiment quite often now, and it puzzles me. Even human level AI is going to create human level bugs. The problem with software has rarely been the implementation, but vague and shifting requirments.

                  1. 1

                    Thanks for sharing this post. I agree that reviewers have to keep the author in mind too. As much as other devs and the product owner.

                    1. 2

                      Wow. How did you get hold of this?