• some guy (unregistered)

    If you have a python, everything looks like a mouse at frist.

  • ichbinkeinroboter (unregistered)

    I did the Windows and cmd script equivalent to this sort of thing quite a lot back in day (25-30 years ago). I can't rememeber if it was genius or madness (or just neccesity). I would have to send the robot to fetch and load that backup tape into my memory ... and I don't know if its been kept in nice enough conditions to survive :-). Plus the robit has a tendency to just slam the tape not QUITE in the slot... LOL.

  • (nodebb)

    "Yeah, but I always forget to."

    I'm going to rule out "one of the best", just from that sentence alone.

  • (nodebb)

    "If I just do it in bash, if the first command fails, the second command doesn't run."

    You have to use the -e option with bash for this behavior. The default is for bash to continue.

    As far as the best or the worst programmer... He wrote code that does what he wants it to do. That makes him a good coder.

  • (nodebb)

    Maybe I'm misunderstanding something but this doesn't seem like a WTF. The way it reads it sounds like these are personal scripts for the dev and not something the dev writes for others to use. The dev is correct about a lot of the points.

    • Calling "docker-stop" is better than having to write out the commands, it's much easier to remember, and it's less likely to fail because you got a command wrong.
    • They don't use bash directly because they're not familiar with it and if they took the commands they wrote and ran them directly it wouldn't necessarily work as pointed out in the next point.
    • When he said it handled errors I don't think he meant in the programming sense of the word. He just meant it still works even if there's errors. Why should he care if there are no containers to kill? He just wants to be in State A. He doesn't care about how he gets there.
    • If they're a Python dev that works in Python all day he could use the Docker library but in that case you have to learn something new. It's not free to learn library after library especially when it's just something for personal use. Maybe it's just me but I feel like I have to learn a new library constantly with my non-personal projects.

    Of course, all of this goes out the window if other devs have to use these scripts.

  • noOne (unregistered)

    but since shell=True is set on run(), these are more or less shell/bash scripts, he even uses shell features ($()).

    So, don't tell him, but he knows and uses shell/bash.

  • (nodebb) in reply to miniragnarok

    I totally agree.

    For personal dev scripts, there is only one rule: If it works, then it works.

  • (nodebb) in reply to noOne

    The way I read it, that's kind of the point. It's a bash script running from Python, but he "doesn't know bash".

  • Officer Johnny Holzkopf (unregistered) in reply to Baflingo

    I don't see any bashisms so far, so it's just sh (if $SHELL is not really bash, but ye olde paine sh, or maybe dash, or something else sh-like), making the thing more portable if needed - in his case, just python is a dependency on the target system. So "Ernest was either the worst developer he was working with, or one of the best." maybe can be answered with YES.

  • Jonathan (unregistered)

    I once inherited a C program that did stuff like

    char cmd[256];
strcat( cmd, "mv ");
strcat(cmd, src);
strcat(cmd, " ");
strcat(cmd, dest);
exec( cmd);

    Somehow it just felt worse seeing it in C than in Python.

  • (nodebb) in reply to Jonathan

    Actually exec ? I ask this because "exec" isn't a POSIXy function. It's a family of wrappers around "execve", normally, so its presence here indicates that the original author of the code wrote it, and I wouldn't be surprised to learn that this "exec" is just a wrapper around a call to "system". (None of the exec family functions takes a command line. They all take an array of argv[]s, and possibly an array of environment variable strings.)

    It's also a bit of a shame if src or dst is a string containing ; malicious_command ;...

  • (nodebb) in reply to dpm

    What? He noticed a flaw that he personally had an used the computer to address it. That's exactly what programming is for! I bet you don't like static typing either :p

  • H (unregistered) in reply to miniragnarok

    Agree.

    "Aankhen" really needs to learn to keep his nose out of people's personal tooling.

  • Kotarak (unregistered)

    I use make to handle such things. A make push does all the necessary file creation and image building required and pushes the image for example.

        base: .base-image-timestamp
    
    .base-image-timestamp: docker/base.Dockerfile renv.lock
            docker-build-base-image-stuff
            touch .base-image-timestamp
    
    app: .app-image-timestamp
    
    .app-image-timestamp: $(SRCS) docker/app.Dockerfile .base-image-timestamp
            docker-build-app-image-stuff
            touch .app-image-timestamp
    
    push: .app-image-timestamp
            docker-push-image-stuff

    Works quite nicely. Especially if you have to generate for example some intermediary files from sources, where the intermediary file goes to the docker image.

    Yeah, yeah. I know. I'm old-fashioned.

  • 516052 (unregistered)

    So wait, this guy wrote a short and quick script that gets him to a desired state and instead of being praised for it some fool suggest he learn a new language, new library and rebuild that script as an entire program?

    Now that's a wtf.

  • My name goes here (unregistered)

    Aankhen didn't understand that, when Ernest said that his code handled errors, he meant that it handled errors exactly the way he wanted, which was NOT AT ALL. His code was simple, it did exactly what he needed AND it was not meant to be used or maintained by anyone else. Why would anyone have to take issue with it?

    I have to admit that, if there is a WTF among them both, it is with Aankhen.

  • (nodebb) in reply to 516052

    It's not a short and quick script compared to the shell. The shell script for this is literally the two strings passed to subprocess.run concatenated with a line separator between them.

    For example

    #!/bin/sh
docker kill $(docker ps -q)
docker rm $(docker ps -a -q)
  • Ryan (unregistered) in reply to jeremypnet

    You can even leave out the #! and it will still work perfectly well if you only care about running the script in the shell you're currently using.

  • 516052 (unregistered) in reply to jeremypnet

    And yet it is short and quick in absolute terms. It does the job. And most importantly it's done in a way that's familiar to its creator.

    A good engineer does not chase perfection. Nor do we settle for good enough. Good enough IS the end goal.

  • Anonymous (unregistered) in reply to Rick

    Rick, he's basically written a bash script with extra steps. I have to regard him as a mediocre to poor coder (I lean mediocre, because the code does do its job and account for side-effects well enough), because this kind of comfort-zone logic suggests that he is not very good at learning new things and using the right tools for the job. I'm all for hackish solutions to problems and getting clever with code in ways that your tools weren't intended to be used if it does the job well, but evidence of not being a good learning animal and resorting to unnecessarily inefficient problem-solving is a bad sign in coders when coding ought to be a creative, problem-solving profession where you figure new things out and try to make it run quickly and smoothly.

  • 516052 (unregistered) in reply to Anonymous

    And that's all fine and well if you have the time and budget to bother with that sort of thing. Some times you just want to hack together a tool quickly and make it work so that you can get on with the job people are actually paying you for.

    You can't put "making my private helper tool more efficient and better" on your time sheet. Well, you can. Once.

Leave a comment on “All Docked Up”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article