Skip to content

Home

  • in diary
  • 1 min read

diary record

When I was a student, I have written a little program to model a glissade of a descending plane, as a part of some study task. Not a rocket science, still involved an itty-bitty pinch of differential equations, required some effort (and was not fun). That resulted with a thin white line on a black screen.

Anyone seeing it shrug their shoulders, like "ok, nice".

Also I was interested in graphical effects, and I can tell you that modelling flame is a basic arithmetics. Initialize a bottom of your display matrix with random (or you can play with it) colors, then go over every pixel calculating average of values of surrounding ones, and put that result one pixel higher. Looks awesome. Anyone seeing result was like "wow, you're a hacker man!".

Here probably should be some kind of morale but to be honest, I love that flame effect better myself.

No /var/run/postgresql/.s.PGSQL after reboot (Ubuntu)

Rebooting the server, bumped into the following error, preventing my django server from functioning: psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.xxxx" failed: No such file or directory

Not to easy to search the solution, tons of search spam (and of course stupid advises "purge porstgresql including databases and all the files and reinstall".

Thanks to Abdallah: https://www.abdallahyashir.com/how-to-fix-postgresql-error-connection-to-server-on-socket-failed/

Shellscript

    $ sudo -i -u postgres
    $ /usr/lib/postgresql/14/bin/pg_ctl restart -D /var/lib/postgresql/14/main
  • in diary
  • 1 min read

diary record

Cloud workflows are another level of a mess, not quite a news, is it? A peculiar case of my little struggle with chaos - devops does not have capacity to assign me the access to some db. And I have to deliver little code, involving the other code (not mine), involving that db. Yay, workaround - I do have an access to deployment pipeline, which spins up the container with the access to that db. So my journey is like a hangman game - assume, change code, deploy (10 minutes), check. Trying restart the app within that container relaunches the container. So, this is the way. And I have some time to write this grumpy post.

django app: Resource blocked due to MIME type mismatch

Running your Django app first time in production, you might bump into the issue of your browser blocking static resources (.css, .js) with a message "Resource blocked due to MIME type mismatch". I was googling a bit here and there, most results are providing a bit context demanding answers.

"Hint"

The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should be followed and not be changed.

(The document provided by the link "explaining" the issue in the browser)

Dude, what do I do? Some answers on Stack Overflow recommend to turn of security features in your browser. Well, swiping the issue under the carpet does not make it go.