What’s more: that’s an em-dash.

Happy to help. You may want to check out the section on Repository Management.

The key here is to just treat it like any other git repo (like one on GitHub). In fact, you can set it up to pull/push from/to GitHub or another repo also, for off-site backup or collaboration outside your network.

Make sure to clone the report to a local working copy first. From there, it should be pretty simple once you’re familiar with the most common git commands (or use a UI).

They’re an old band now, but Raga Rockers (Norwegian). Also Dum Dum Boys from same era.

Great question! Looking forward to checking back in here for suggestions later.

Ah ok. That explains a lot. I think what you are looking for is the git web server option for Otter wiki.

How that probably works is that there is a git repo inside the container, and probably stored in /app-data. If you have that mount set up you may see what looks like a bare git repo in there.

If you want to poke around inside the container, you can run a shell inside of it like this, assuming /bin/bash exists in the container:

docker exec -it containername /bin/bash

Anyway, you don’t need to mess with that, because Otter wiki exposes a git server itself. All you have to do is clone the URL it gives you in the GUI, add your files, commit and push.

So the most straightforward way is:

1. Clone the repo to a local working copy: git clone https://otterwiki.example.com/repopath (the URL should show in the UI)
2. Enter the directory: cd ./repopath
3. Make your changes, add files, etc.
4. Stage the changes git add .
5. Commit the changes git commit -m "imported buncha files"
6. Push them to the origin remote (Otter wiki): git push

If you’re not comfortable with the git command line, there are a bunch of TUI and GUI git clients you can use. It makes no difference which one. I usually just use the built-in vscode one for my hobby projects.

I understand Docker can be confusing, especially if you’re not a developer. Docker was developed to solve the problem of “it works on my computer” (but not yours), meaning it is meant to behave the same regardless of where it is installed. It does this by carrying all its dependencies with it. How well it succeeds in solving the problem is up for debate and I’m not here to debate the merits of Docker anyway.

I would say two things: don’t get discouraged:; it has a learning curve. And conversely: don’t think Docker solves everything, either. Understanding how it works and what it can do is your best bet at using it successfully or even deciding that your use case is not right for it.

I’m not familiar with Otter wiki (just heard about it today in this thread), but I will go by the online docs and see if I can help you get going. Going by the docker compose instructions, the example shows this compose file:

services:
  otterwiki:
    image: redimp/otterwiki:2
    restart: unless-stopped
    ports:
      - 8080:80
    volumes:
      - ./app-data:/app-data

The two last lines are key: the volumes section. The first and only entry maps a local directory ./app-data outside the container through a bind mount, to the path /app-data (note the leading slash) inside the container. It is mapped by default read-write, so the container can write to the directory. You can also read/write from the host side and put files you want in there.

The files here are only stored in that one place (i.e., not copied), so if you want backups you need to take care of that separately.

For your use-case, it may be enough to use the customization instructions for Otter wiki. Notice how their customized docker compose file has a second volume in it. In their example, you would put additional files into the ./custom directory on the host. It works the same as the app-data volume.

That takes care of just running the application, but what if you wanted to customize it more? That is where you need to use the source and git. I am going to just use a fictional example app for this, because Otter wiki app may have some extra steps that can make it confusing. Basically what you want to do is clone the git repo of whatever you’re building:

git clone https://github/whatever

Now you have the source. You can add files, make code changes, whatever. And once you’re done with that you will use git as usual and commit the changes, push it to your branch, and maybe open a PR to the original repo. That’s not important for Docker.

The next thing you do is build the Docker image. Many people confuse Docker images and containers, but on short: the image is like the file system for the container, and the container is an instance of that file system + processes running on a Docker host. Many containers can run the same image on the same host and in fact that is how you horizontally scale an application.

Once you have the image, you can just run it locally, or you can push it to a registry. Here is how you would do that:

# Build the local image in the context . (current directory) and tag it as my-cool-app with tag latest
# This uses the instructions in the Dockerfile to build the image. It can run commands, copy files, etc.
docker build . -t my-cool-app:latest 
# ...lots of messages...

# Run the app - press control-C to stop it
docker run --rm -it my-cool-app:latest 

If you want to push it to Docker hub or another registry:

# Tag the image with the repo name in front
docker tag my-cool-app:latest registry.example.com/myuser/my-cool-app:latest 
# Push the image to the registry
docker push registry.example.com/myuser/my-cool-app:latest  

One thing to keep in mind here is do not include any secrets with the image. If you do, anyone who can download the image can read them, because they get baked in with it.

Let me know if you have any other questions and I’ll be happy to answer.

I don’t know the specifics of your app, but Docker containers aren’t designed to be used for persistent data. They are designed to be immutable after they’re built.

Instead you would create a volume to keep files in and mount them where your application needs them. Typically like /data or /var/something. (Edit: otter wiki wants /app-data)

You can use a bind mount to mount a local directory or a named volume which is kept in a set location by Docker. Generally bind mounts are easier to start with since you can browse the files directly on the host.

your Blinkenlights fluid. Not to be confused with blinker fluid

For best performance, remember to always change your internet filter when you change your blinkenlights fluid

I’ve been around long enough,I know. It is indeed good advice to make things extensible, within reason. I have written some over engineered things that ended up being a pain to maintain.

My best advice is to learn the domain as much as possible, then you’ll be more aware of both the concepts involved and the potential pitfalls. In the OP comic, knowing that the machines are capable of making other shapes would have helped predict the problem even when management says “we’re a triangle shop”.

I’m the guy that goes “fuck, another exception to add to my logic” after the PM swore that “we’re only ever doing triangles”

95 in Europe is like 87 in the US. Different ratings.

Yep. Use free tools like gitguardian, gitleaks, etc. and run them in pre-commit hooks. Makes it a lot easier to catch.

And if you leak one by accident, change it immediately. There are bots trolling sites and repos for this information.

I use Merlinwrt on my Asus router. They have a bit longer support and I think it’s open source. May be worth looking into.

It only happens with ISO weeks. An example is 2006. Each of the weeks belong to different years (so 2005W52 and 2006W52 are different), but each can contain days from another year. So for example Sunday 2006-01-01 is part of week 52 of 2005. Week 1 starts on January 2. Then at the end of 2006 you have another week 52, but that week is actually part of 2006.

It’s a bit of a cheeky thing to point out, because at no point is a day in two different weeks, and the week itself only belongs to one year. It’s just that you can’t assume that any given day belongs to the same year as the week it is in. That is: 2006-01-01 is in 2005W52 not 2006W01.

Yep, but the year of week will be different for each.

Use a date library. Life is too short to make your own. The new Temporal library in JavaScript is quite good.

Even better: two weeks with the same week number can exist in the same year.

Looks like you’re in Norway, so I suggest you reach out in norge.chat (matrix) and see if anybody can suggest something, perhaps a local provider or community of people with similar interests.

Each month would be named after one of Elon Musk’s children, but the names would be randomized every year (any future children are added to the rotation). Eventually this becomes impossible to keep up with and we just end up using numbers anyway, which is fine with me.

That depends where you are. In America it is more often associated with lynchings than suicide.

Edit: to add a little context from Wikipedia: Noose: Use in intimidation and hate-based racial politics - this is why I said “depends where you are”. I had no idea of these connotations before I moved to the US, either.

Fair point, and taken. Interviews are a two-way street: the candidate should ask about everything that matters to them, and the company should ask about everything important they want.

To avoid situations like this, it’s best not to assume anything unless you ask first. Windows is the de facto standard in business, yes, but not everywhere and not in every industry.

If your work OS matters to you enough that you will pass on the job if you can’t pick, then you should ask. I would not want to hire someone who will be miserable in the job. And as a middle manager I probably don’t have enough pull to make an exception just for this guy anyway.

Rock stars play by their own rules and they will get whatever they ask for. For the rest of us, we just have to take what we’re issued.