~ephes

Recorded and produced a new Podcast Episode about Ansible. Had to learn that streaming 48Khz 24bit FLAC audio to AirPods is too much for the Bluetooth bandwidth. At first, I thought the recording was broken, but then realized it was just a Bluetooth glitch, phew.

Did some preparation for a Python training course next week (setting up a JupyterHub instance, preparing a HedgeDoc installation).  Also, normal work as usual until we got evacuated because of a bomb disposal (a 500kg bomb from the second world war was found a few hundred meters down the street).

Progress on having a landing page where people can create podcasts/blogs:

• Did some infrastructure work to be able to use a Python installation via pyenv on production
• ...

Courses

• Databases - Stanford School of Engineering

Out of Context Images

Back to work. Picked up my jogging habit after having to stop during covid / vacation and it worked out fine. Made plans to get more into music again (atm just got more hardware).

Progress on having a landing page where people can create podcasts/blogs:

• #32 fixed by only having one place to turn on the test client
• #33 moved registry app urls into urls.py of registry app
• #34 tests for account and social account adapters only open for registration with appropriate setting present
• #35 test coverage is now at 100%
• #36 fixed some mypy issues
• #37 replace poetry with pip-tools
• #38 fixed showing multiple running deployments at the same time for tests
• #39 tried to speed up ansbile (mostly without success)
• #40 handling of exceptions raised during starting a deployment

Out of Context Images

For the last two weeks, I was on vacation, so no work. Seems my job is to listen to podcasts because there were significantly fewer episodes I listened to. Need to check with my boss 😄.

Had to learn the hard way that shared albums in apple photos are completely broken and will cripple your images (max width or height set to 2048px + conversion from heic to low quality jpeg). And even if you stop following a shared album, those broken images still sit in your library and you have to remove them manually one by one. Great fun if you just imported a few hundred photos from a shared album. I don't understand tech companies'  obsession with destroying their user's photos. Signal is bad, Whatsapp is worse, and now even you Apple? A working method for Apple devices is to generate an iCloud share link (which takes lots of time) from which others then can import the original photos.

Progress on having a landing page where people can create podcasts/blogs:

• Finished Add Email Backend for Registration Mails. This feature uses mailgun which is a pretty crappy service, if you've found a better one, please let me know.
• Add WordPress Ansible Service #28 moved the ansible folder over from podlove_test
• Cleaned up the register link and removed some unused code #30
• Use always _base.html in favor of base.html #31
• Added styled allauth templates #27

Out of Context Images

Found a workaround for the fastdeploy / SQLAlchemy / asyncpg / Linux deadlock bug. I now instantiate a new SQLAlchemy engine on every request. That's probably not very efficient, since it would be better to use the engine's built-in ability to hold a connection pool, but having working code is a good start.

Progress on having a landing page where people can create podcasts/blogs:

• Finished Add remove domain / deployed fqdn #14
• Finished Switch between cast / wordpress #2 for deployments 🍾 - it was a complete surprise for me that this is even possible. But since I have now a working deployment system where all responsibilities are nicely separated, it's possible no not only to deploy Django, but anything including weird stuff like Wordpress without having to worry the rest of my system might suffer.
• Finished Fix pytest warnings + some cleanup stuff and coverage

Out of Context Images

Fought with strange bugs last week, also some work and much outdoor stuff.

For example when using Jupyter Notebooks in a Django environment, the PYTHONPATH was always set to some old project and therefore imports from my current project didn't work. And it was simply not possible to get the PYTHONPATH right. I could not find the old projects name in any config or virtualenv. Weird. But then I had a closer look at the kernels using jupyter kernelspec list:
 

$ jupyter kernelspec list Available kernels: django_extensions /Users/jochen/Library/Jupyter/kernels/django_extensions python3 /Users/jochen/.virtualenvs/foo/share/jupyter/kernels/python3

Ok ~/Library/Jupyter/kernels is weird. And there the name of the different project appeared in the kernel.json. Whoa. Somehow this old django_extensions kernel has overwritten my django_extensions kernel from the virtualenv. After deleting the old one, my kernelspec looked like this:

$ jupyter kernelspec list Available kernels: django_extensions /Users/jochen/.virtualenvs/foo/share/jupyter/kernels/django_extensions python3 /Users/jochen/.virtualenvs/foo/share/jupyter/kernels/python3

This was pretty hard to debug.

And then there was this strange fastdeploy bug forcing me to have a closer look at SQLAlchemy. I still don't know what the root cause of the problem is. I switched to using SQLAlchemy in combination with asyncpg a frew months ago and there were this "The garbage collector is trying to clean up connection <asyncpg connection>" in the logs right from the beginning. I didn't pay attention, because it all seemed to work fine. But during my deployment tests with cast_registry I finally saw some real errors. The tests caused a lot (well, not really) of read queries to the database while the deployment process is posting steps to fastdeploy causing writes. And now I saw 401 responses to some requests from cast_registry, because the access token could not be verified or 404 because some object was not found. Looking at the logs I found some messages from asyncpg like "asyncpg.exceptions._base.InterfaceError: cannot perform operation: another operation is in progress". Hmm, seems like two coroutines are trying to use the same database connection which should not happen. After some debugging I found out the reason for this was me using "uow=SqlAlchemyUnitOfWork()" holding the database connection as a default argument in a bootstrap function, which causes uow to be instanciated at import time and never be replaced by a new uow, ouch. But after fixing that, fastdeploy is now ending up in a deadlock after some time. But only on Linux.

And while I'm sure it's all my fault and I'm just holding SQLAlchemy wrong and being and early adopter using it in combination with asyncpg doesn't help - I just cannot wrap my head around the SQLAlchemy interface. Why are there engines, connections and sessions? When do I have to instanciate/open/close them?  Why do I have to close a connection, but dispose an engine? I often close a session, then a connection and then dispose the engine. If you should always use this combination, why isn't there a highlevel function doing just that? If you don't, why is there no documentation showing why and how? 😤

Progress on having a landing page where people can create podcasts/blogs:

And then I started an experiment trying to help someone getting started with Django and writing a series of blogposts about it.

• Merged the old work in progress on the "Deployed Services Configuration"-issue to be able to work on this database bug without conflicts getting out of hand 🫣

Out of Context Images