Mostly Software

  • Monday

    • https://www.ey.com/en_us/ipo/trends
    • Remember that pyproject.toml is not a poetry config. It’s a general python config, natively meant to define your project. It replaces setup.py, and should be considered at that level. Poetry is just one of the many tools configured in the toml.
    • Planted another round in the humidity caps. Everything is sprouting normally so far (but it’s fresh water, which is the same as the nurseries). I’ll do another humidity-cap-germinate round in the main garden once the water is nutrient-rich. We’ll see if the seeds have the same success rate. They don’t need the nutrients (can’t start absorbing until first set of true leaves), but it may be detrimental to even have nutrients present.
    • I don’t like the way the mona lisa is looking at me, can we give her a quick touchup: https://www.morningbrew.com/daily/stories/2023/02/19/roald-dahl-gets-a-controversial-rewrite
    • Remember poetry show --tree
    • Chamomile and sandalwood in the dehumidifier…amazing.
    • Remember the -C switch to grep for context, to show before and after. Pass a number. For just before or after, use A/B instead of C.
    • Evaluated grpc/protobufs for sbsc: https://gitlab.com/bmahlstedt/supercontest/-/issues/179. Not worth it for those APIs.
    • Looked at some REST extensions of flask. Overall, I just don’t get it. You can build a rest api with native flask. flask-restful certainly doesn’t help with much extra. flask-restplus at least gives you automatic swagger API docs. Both do some of the parsing/marshaling of request/response data as desired. But overall, not worth it imo.
    • Updated some of the rows in the doc Stack.
    • Don’t FK to another col for convenience on the join. It’s canon to just FK to the PK. It’s already unique, blah blah.
    • SBSC. Tests.
    • Finished https://gitlab.com/bmahlstedt/supercontest/-/issues/198.
    • Fixed the old app test. Removed flask-testing, hadn’t been updated since 2017.
    • The test target now produces junit and coverage xml.
    • Both become artifacts in gitlab, which then get shown conveniently on jobs and MRs, historical trends, analytics, badges, etc.
    • Added some unittests.
    • No integration tests for the app yet (including database, webscraping, etc).
    • Gitlab. CICD.
    • Just quick general shoutout: gitlab is an excellent product.
    • Plans.
      • I’m just on free tier right now, which comes with 400 shared runner minutes per month.
      • In order to actually use a plan, you have to associate yourself (as a seat) and your projects (repos) under a group. A free tier group has 5 seats (and unlimited repos, but there are storage limits).
      • It’s $19/user/mo for premium, and $99/user/mo for ultimate. You get more features, more CICD minutes, more storage, better support, etc.
    • I have 5 jobs that run in parallel right now (black, pylint, pyright, bandit, pytest). Each starts with a python image, installs poetry, then installs my project+deps into a testenv. That step is common to all, and takes about 4 minutes on the gitlab shared runners. Rather than spending time optimizing the cache for that right now, I’m going to let it be inefficient; a couple weeks from now I’ll change the pre step to be an image build and pass that to the test steps anyway, which will auto-resolve this.
    • But: These jobs have used a couple hundred minutes in the past few days alone. I’ll need to start a gitlab runner on my desktop, since I don’t have enough shared minutes to last until the month rollover (and even then, until the build change).
    • Did this, and disabled shared runners (and group runners). Instructions below.
    • Download the runner, create gitlab user to run it, run it, and register it with your project’s token.
    • gitlab-runner is managed by init (service <>) rather than systemd (systemctl <>) on my machine (although it supports both: https://docs.gitlab.com/runner/configuration/init.html). It should automatically start on boot.
    • Ended up removing the baremetal (well, WSL2) runner above and went with docker instead.
    • You just start the container with a local volume mount for config: docker run -d --name gitlab-runner --restart always -v /srv/gitlab-runner/config:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest
    • The restart policy means it relaunches when the docker daemon restarts (so on host startup).
    • And then register it: docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register
    • In order to achieve job concurrency: You don’t need to rerun the “register” portion (although you can, details here: https://docs.gitlab.com/runner/fleet_scaling/). Instead, just leave the one runner process, inside the one container, and have it spawn multiple OTHER containers for each job (obviously each job runs in a separate container, you define an image for each job as desired). Go into /srv/gitlab-runner/config on the host and modify config.toml for concurrent = <>
    • Google analytics. SBSC and Blog.
    • Protected the gtag inclusion from dev. Only prod now.
    • Some insights (for both sites): US #1, china #1. Mostly mobile. Chrome most popular browser. ~2m avg engagement time. Blog gets a little more traffic than sbsc (esp in offseason).
    • Enabled google signals.
    • For SBSC, I’ll have to add my custom user IDs soon (not too hard to integrate). Will wait for the cognito ticket.
    • I don’t really take advantage of many other features (conversions, purchases, user bucketing, etc).
    • And remember wordpress is via the monsterinsights plugin. And SBSC has the flask_monitoringdashboard with some redundant info (although FMD has a full profiler).