![\"Dark](\"https://lukewiwa.com/img/dark_wiwa.png\")
With a growing family the idea of buying a second car mostly for school drop off and local errands felt like bringing a gun to a knife fight. Financially and in terms of the overall space and hassle a second car would occupy in our lives. In essence we didn't really need two cars, we sort of needed a car and a half. I'd been hearing good things about cargo bikes and their potential as a family vehicle. So we took a punt on buying one. It's been in our possession for over a year now and has done over 3000km in that time. In short it's been a fantastic investment for us on several axes: financial, fitness, health and overall wellbeing.
\n\nThe cargo bike in question is a Tern Quick Haul P9. We came to the decision about buying this bike after utilising the Canberra E-Bike Library. This service allows you to borrow e-bikes over several weeks for a small fee. This allowed us to see how it would actually fit into our daily lives and really show the shortcomings of each style of cargo bike. Needless to say there are many styles, long-john or Bakfiets, Long Tail, Mid Tail, Trike and some other more exotic styles. In the end we tried a bunch and came to the conclusion that a mid tail would suit us best as we didn't need to haul two kids and it rode very much like a normal bike. There was pretty much no question that Tern is the front runner brand when it comes to long and mid tail cargo bikes. Along with using the excellent Bosch motor system they used largely standard parts and had a wide array of accessories that remains unmatched by any other vendor.
\nFor the most part the cargo bike has been a resounding success. It has delayed our need for a second car and has provided me and my family an alternative for getting around town. Additionally it's fun! I can't describe how nice it is to chuck the kids on the back and just whizz around town. The motor makes light work of any hills or headwinds and we always get parking right out front of wherever we are going. Within certain bounds it's more convenient than getting in the car. The kids love it too, they are much more likely to enjoy hanging out on the bike than being shoved into the car. We can ride out for a picnic with all the blankets and snacks without breaking a sweat. I've hauled my kids bikes on it!
\nSurprisingly even the cold winters here in Canberra have not been a huge deterrence. As long as I have the right clothing, good coverage over my hands, ears and toes, then I'm fairly fine riding in the cold. The kids are perfectly fine too as long as I throw a heatpack in the back with them.
\nEven without kid duties I'm often using it to pickup groceries or takeaway. I commute from time to time with it, I carry tools and accessories from the local hardware store. There is something quite nice about riding and not worrying about how much I can carry, the answer is always "a lot!". Just the carrying capacity changes the way you think about riding.
\nThe range on this machine is fantastic. I commute 20km each way to work with the motor set to "turbo" and I get home with battery to spare. I neither need nor want a spare battery, this is plenty. If I need to go further than this I'm probably going to use the car or jump on public transport anyway. Anywhere that takes more than an hour commute is probably too annoying for me to do unless we're desperate.
\nThe running costs are near zero. I do pay for insurance on the bike, and I get it professionally serviced from time to time since I don't have the tools to work on the electrical side of things. But those costs are comparatively quite reasonable and not something I want to skimp on.
\nThe bottom line is that I and my family ride more. I'm fitter and my family are more likely to ride, not just the cargo bike but our regular bikes too.
\nThe groupset that came with the bike, a shimano alivio set, was frankly garbage. It would not shift reliably at all. I tweaked it so much to try and get it working but I suspect the cable run was just too long and windy. I eventually replaced it with a groupset from a Chinese manufacturer called L-Twoo. It was cheap but effective. With that installed it was night and day. The shifting since has been flawless.
\nI replaced the seat post with a cheap dropper post with a trigger built in to the seat. This has made switching between me and my wife riding a breeze. I highly recommend this upgrade if you are sharing a bike with someone even slightly different in height to you.
\nEvery spring the magpies come out to swoop and it's annoying and discouraging for the kids. Luckily I'm usually the target so i've had to attach a tall flag and add a brim to my helmet to distract the maggies. In the same vein when the weather really turns wet it can be a miserable experience riding in the rain. I will say it's usually not that bad, I'll often times not regret getting out. But when it really comes down you're just going to get wet.
\nAdditionally for any reasonable use case you will need to invest in some accessories. It's pretty much non negotiable that a front basket and extra rear storage need to be added at purchase time or very soon after. Carrying kids will up the cost again. The trick here is to frame the costs not as an extra expense, but as a trade off to not buying another car. None of these accessories cost that much when you compare to even the running costs of a car.
\nI can't gush enough about how good it has been, to the point where I've convinced at least one friend to join the club. I'm on the fence as to whether we will remain a one car family but the bike seems to have already paid for itself compared to the opportunity cost of purchasing a car. It's fun, my family are riding more and the maintenance costs are minimal.
\n", "date_published": "2025-12-03T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/end_multi_arch_manylinux2014_builds/", "url": "https://lukewiwa.com/blog/end_multi_arch_manylinux2014_builds/", "title": "End of lukewiwa/manylinux2014 Container Image Builds", "content_html": "I previously created a github repo to amalgamate the different architectural builds of manylinux2014 into a multi architectural manifest. With manylinux2014 gaining multiarchitectural image support I'm going to stop the schedule for these builds.
If you are hosting a web app on AWS you should be putting a Cloudfront instance in front of it. There are a few advantages but at the end of the day it's cheaper, allows for global caching at the edge and provides a fairly straight forward way to obtain SSL certificates. In my own hosting of apps I will more often than not use API gateway in front of Django too as this gives you some nice tools such as rate limiting and whatnot. But it seems really annoying and difficult to get it all working with a Django app given Django's security model around the allowed hosts.
\n\nI had a few goes at this and thought it might be fairly straight forward but it turns out AWS needs it's own host headers for integration purposes if you are using cloudfront and API Gateway. As such we need to do a little bit of faff to get the host header over to Django.
\nFirstly on the application side we need to tell Django to use the x-forwarded-host header for host checks in the ALLOWED_HOSTS setting. This is necessary if we are integrating into API Gateway or Lambda URLs since the host header is expected to be the domain of the cloudfront distribution.
ALLOWED_HOSTS = [\"yourdomain.com\"]\nUSE_X_FORWARDED_HOST = TrueSecondly we need to actually forward the host through using the x-forwarded-host header. Cloudfront has no native setting to do this for us so we need to use a cloudfront function. It's not particularly complicated but does introduce another resource to manage.
function handler(event) {\n const request = event.request;\n request.headers[\"x-forwarded-host\"] = { value: request.headers.host.value };\n return request;\n}Thirdly we need to connect to our integration. Below is a CDK representation of what that would look like. It's important to note that there are a number of native cloudfront CDK integrations in to various AWS services. In my particular case I'm using API Gateway HTTP Endpoints which are somewhat simpler than the old REST Endpoints but you do have to do a little bit of work yourself.
\nconst forwardHostHeader = new cloudfront.Function(\n this,\n \"ForwardHeaderCfFunction\",\n {\n code: cloudfront.FunctionCode.fromFile({\n // Filename of the above cloudfront function code\n filePath: \"./lib/forwardHostFunction.js\",\n }),\n runtime: cloudfront.FunctionRuntime.JS_2_0,\n }\n);\n\nconst cachePolicy = new cloudfront.CachePolicy(this, \"CachePolicy\", {\n cookieBehavior: cloudfront.CacheCookieBehavior.all(),\n queryStringBehavior: cloudfront.CacheQueryStringBehavior.all(),\n});\n\nconst distribution = new cloudfront.Distribution(\n this,\n \"CloudfrontDistribution\",\n {\n domainNames: [\"your-domain-name.com\"],\n defaultBehavior: {\n // This could be a load balancer or an API gateway\n // or any number of AWS services.\n origin: new origins.HttpOrigin(\n `internalAWSdomain.com`\n ),\n functionAssociations: [\n {\n function: forwardHostHeader,\n eventType: cloudfront.FunctionEventType.VIEWER_REQUEST,\n }\n ]\n cachePolicy,\n originRequestPolicy:\n cloudfront.OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,\n allowedMethods: cloudfront.AllowedMethods.ALLOW_ALL,\n viewerProtocolPolicy:\n cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,\n },\n }\n);In terms of the cloudfront distribution itself there are some extra configurations that we need to add on the defaults to make our Django application work as expected.
\nALL_VIEWER_EXCEPT_HOST_HEADER managed policy.With all this in place the host header should flow from cloudfront all the way through to our application using the x-forwarded-host header and we should be able to set the ALLOWED_HOSTS Django setting to our original URL.
Annoyingly I feel like none of this is particularly clear in the AWS docs, the only reference I could find to it was in the managed origin request policies page which calls out specifically API Gateway and Lambda function URLs as requiring this header.
\n", "date_published": "2025-02-19T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/django_on_aws_for_chump_change/", "url": "https://lukewiwa.com/blog/django_on_aws_for_chump_change/", "title": "Django on AWS for Chump Change", "content_html": "Below are the resources to my PyConAU 2024 talk "Django on AWS for Chump Change"
\n\nI've tried a lot of productivity software over the years. I seem to churn through apps and systems fairly regularly. I suspect part of this is because I just need a change from time to time. My brain requires a reset and adopting a new system provides that demarcation line and some fresh energy. Lately though I've moved to a very analogue system for personal note taking.
\n\nSince the beginning of this year I've started carrying a pocket notebook and a pen. Part of this motivation was some youtube video that popped up in my feed with a good story to tell about the concept. Another part was that I decided I needed to find a way to be less Phone Dad around my kids. Finally with my wallet becoming lighter as more cards become digital I had a little more space to carry something on my person everyday.
\nThere is a plethora of personal notebook systems out there and you can tie yourself in knots trying to adhere to them. For me I began this with the clear goal that my notebook is strictly formatless and freeform. I must not be precious about it because that would cause me to write less if it wasn't "perfect" or within the system. The notebook is throwaway, a mental scratchpad and very much ephemeral. It can be torn to shreds and I'll just buy a new one and continue on. It had to be small enough to throw in any pocket, it must also be as reachable as my phone. Hopefully the goal was to reach for it first before my phone.
\nWith all that in mind I bought the cheapest A5 notebook I could find and started writing in it. Obviously the first couple of weeks were high energy and I was writing multiple pages a day. As I settled in to it more a rough "system" emerged from my daily scribbles. I would write the date, a rough agenda of the day as I knew it and a rough "upcoming" list of events I should keep in mind for the coming days. After that it was a mix of personal journal entries, todo lists, scribbles and doodles, rough notes and a portable art book for my daughter.
\nAs of today I've gone through roughly 10 of these notebooks and I suspect this might continue for some time. I wouldn't say on the whole it's been absolutely life changing but it has made a difference at the margins. I have something else to occupy my time with in those small moments where I would reflexively reach for my phone. I now am a slightly better example to my children with me reaching for my phone less, when my daughter is bored I hand her my notebook and she happily doodles some lovely art. It's a much more engaging experience to take a quick note during a conversation when it's written down on paper rather than in a phone. People notice. There are numerous studies saying that writing something down makes memories stick better than typing it in a device. I have found this to be true.
\nOne thing that I found very interesting as time went on is that an online todo list lasts forever and you will always add items at a greater rate than you will complete them. The ephemerality of the notebook means that some items never get done. They live on a previous page and at some point you forget to move it to today's agenda. A natural attrition occurs where these tasks end up less important or don't need to be done at all. I am really enjoying this phenomenon. It feels much more natural in my busy life than doing a "weekly review" or having to consciously clean up tasks.
\nThere are some downsides. I still lean on technology for reminders and calendar events. This is fine, the notebook isn't a system in and of itself but is part of a larger system that helps me manage my life. One of the most annoying things though is that I have run into unreliable pens. This has really annoyed me more than I thought it would! I'm happy with cheap notebooks but I definitely have found out that I need better quality pens. Sometimes carrying a notebook and pen is annoying in a way that a wallet isn't. Sometimes I forget my notebook!
\nAnother thing worth noting is that I am effectively paying roughly $5 per month to keep this habit going. I have no issues with this personally but it is funny on reflection that I probably would think twice about paying that much for a personal software subscription that does largely the same thing. In any case it's a cost I'm willing to bear at this point because it does give me upsides. I also enjoy looking out for my next notebook. I've tried a variety and I mostly land on moleskins with a dotted grid since they're easy to acquire but I've found some nice ones from various book stores.
\nI've had this blog post down as a task for some time now transferring it from notebook to notebook and I guess now I can tick that item off, physically. It will feel good.
\n", "date_published": "2024-09-28T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/debug_django_management_commands_in_vscode/", "url": "https://lukewiwa.com/blog/debug_django_management_commands_in_vscode/", "title": "Debug Django Management Commands In VSCode", "content_html": "Adding break points to a django management command in Visual Studio Code is one of those tasks that I’ve been wanting to achieve for a while but never really got around to investigating. I generally fell back on print statements which has been Good Enough.
\n\nVSCode does give you some helpful templates for debugging commands when setting them up. It already has a pretty workable Django server solution but nothing specifically in the way of management commands. However the entry for “Python File With Arguments” looked interesting and that seemed like a good stepping stone into what I wanted.
\n{\n \"version\": \"0.2.0\",\n \"configurations\": [\n {\n \"name\": \"Python Debugger: Current File with Arguments\",\n \"type\": \"debugpy\",\n \"request\": \"launch\",\n \"program\": \"${file}\",\n \"console\": \"integratedTerminal\",\n \"args\": \"${command:pickArgs}\"\n }\n ]\n}This is pretty close. What we want to do is tweak the program entry so that it follows the standard ./manage.py <filename> [args] format that Django requires. For the arguments we can keep the args entry in the configuration as is. The tricky part is getting the currently open file without the extension. VSCode already has this as a predefined variable for this ${fileBasenameNoExtension}. So with this we can put together a debug configuration that should allow us to add breakpoints to a management command and run that file with all the niceties of VSCode debugging. Here’s the full configuration.
{\n \"version\": \"0.2.0\",\n \"configurations\": [\n {\n \"name\": \"Python Debugger: Django Management Command\",\n \"type\": \"debugpy\",\n \"request\": \"launch\",\n // Make sure the path to `manage.py` is correct for your project\n \"program\": \"${workspaceFolder}/backend/manage.py ${fileBasenameNoExtension}\",\n \"console\": \"integratedTerminal\",\n \"args\": \"${command:pickArgs}\"\n }\n ]\n}This way we can set break points inside a management command file and run the currently open file from the debugging options. You’ll also have options to add arbitrary arguments too.
\n", "date_published": "2024-04-29T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/finish_work_on_aws_lambda_python_sqlite/", "url": "https://lukewiwa.com/blog/finish_work_on_aws_lambda_python_sqlite/", "title": "Finishing Work On Docker Image aws-lambda-python-sqlite", "content_html": "AWS now has preview support for python 3.12 in their lambda docker images. They are built on the new Amazon Linux 2023 base images and as such stop the need for my hacky image aws-lambda-python-sqlite.
The reason I built the image aws-lambda-python-sqlite was because the base image didn't support a version of sqlite high enough for Django. Happily the new base images have a more up to date version and this means support for python 3.12 in aws-lambda-python-sqlite will not come. It's been a fun little project and I'll keep the build pipeline going for a while yet but there will be no new python version support.
I went ahead and updated the build scripts for my custom AWS lambda container. Now there is Python 3.11 available with all its goodies.
\n\nFrom memory this python version is much more performant with a few more really nice things that I can't remember off the top of my head.
\n", "date_published": "2023-07-25T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/multi_arch_manylinux2014/", "url": "https://lukewiwa.com/blog/multi_arch_manylinux2014/", "title": "manylinux2014 Multi Architecture Build", "content_html": "manylinux is a linux distro created to provide the widest support possible for python packages. The folks at the Python Packaging Authority (PyPA) provide convenient docker images of this distro but due to the scale and issues of providing builds across multiple architectures the images are distributed under different tags for different architectures. I created a repo github action to aggregate these images into a multi architecture build using the docker manifest command.
This allows me to mindlessly pull lukewiwa/manylinux2014 and let docker sort out the architectural details. This was fairly straight forward to do and I hope the PyPA team implement something like this (although I understand the issues they face). I've got this setup to update every month which feels like a relatively good update schedule without wasting CPU cycles.
I created a python package that runs django migrations on every request. It seems silly but has been useful for creating almost stateless AWS Lambda functions using django.
\n\nI've found using django in AWS Lambdas pretty useful for creating little websites that need a little server work and can't be fully static. Sometimes I want a little state and the power of django's database integration between a request and a response has proven really useful. Using an ephemeral sqlite database in the /tmp directory is really handy for stuff like this. As such this package allows each request to have a database available.
An example of this pattern is implemented in my set fire to emoji website. You can see in the source where my package being used.
\n", "date_published": "2022-12-28T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/no_growth/", "url": "https://lukewiwa.com/blog/no_growth/", "title": "No Growth", "content_html": "This end of year break my goal is to have no growth. No goals, no targets, no feeling guilty about not finishing that book or that side project.
\n\nThis year more than any other I feel like everyone around me has a heightened sense of exhaustion. It's palpable, people need the rest and I am no exception. It's been a big year for me personally and next year is likely to be just as full.
\nAs such I've set a personal goal this holiday period to allow myself to meander, to be slow, to not achieve any personal or professional goals. If I read a book it's because I felt like doing it in the moment. If I create a little side project it's for fun and if it withers on the vine it was meant to be. I'm giving myself permission to suck and be lazy. Perhaps I'm lucky and privileged to have this opportunity but I am taking it with open arms.
\nHere's to a break in work and life. A delineation in the forward momentum of the universe. A rest.
\n", "date_published": "2022-12-23T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/never_use_a_virtual_env_in_a_container/", "url": "https://lukewiwa.com/blog/never_use_a_virtual_env_in_a_container/", "title": "Wiwa's Axiom for Python Virtual Environments In Containers", "content_html": "Don't.
\n\nNever use python virtual environments in a container. At least not directly. There is one argument that holds some water and that's using it as a base to copy from in a multi-stage build but on all honesty that's done quite neatly with a pattern like this:
\nARG PYTHON_VERSION=\"3.9\"\nFROM python:${PYTHON_VERSION} AS builder\nARG PYTHON_VERSION\n\n# use whatever method you like here.\n# I usually use poetry but let's use the common\n# primitive for demonstration purposes.\nCOPY requirements.txt requirements.txt\nRUN python -m pip install -r requirements.txt\n\nFROM python:${PYTHON_VERSION}\nARG PYTHON_VERSION\n\n# Copy files from build container\nCOPY --from=builder /usr/local/lib/python${PYTHON_VERSION}/site-packages/ /usr/local/lib/python${PYTHON_VERSION}/site-packages/\nCOPY --from=builder /usr/local/bin/ /usr/local/bin/If we need to install "standalone python executables" then the best way is through pipx. A good example might be to install cookiecutter.
FROM python\n\nRUN python -m pip install pipx\nENV PATH=\"/root/.local/bin:$PATH\"\nRUN pipx install cookiecutterpipx technically does create a virtual environment for each executable but that's not something we need to worry about managing.
Never use python virtual environments in a container.
\n", "date_published": "2022-11-27T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/dev_container_features/", "url": "https://lukewiwa.com/blog/dev_container_features/", "title": "Dev Container Features", "content_html": "Dev containers have been a thing for a while now in different forms and it looks like Microsoft is really trying to push them forward as a standard rather than something siloed off in Visual Studio Code. One of their latest additions to the spec is a feature creatively named features. I took the time to investigate them and write some of my own.
\n\nI've standardised my own development using dev containers for almost everything. It provides me with a consistent developer experience regardless of the machine and has been a huge boon for onboarding people onto big projects that require a lot of moving parts.
\nOne annoying point that I had with them though is that any development tool you would like in your environment you would have to install into your container and that led to awkward Dockerfiles with patterns like this:
\nWORKDIR /tmp/dev-setup\nARG HADOLINT_VERSION=\"v2.10.0\"\nARG HADOLINT_ARCH=\"arm64\"\nRUN if [ \"$DEV_ENV\" = \"vscode\" ]; then \\\n yum install --debuglevel=1 -y zsh vim git amazon-linux-extras \\\n #\n # Install docker\n && amazon-linux-extras install docker -y \\\n #\n # install zsh\n && sh -c \"$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)\" \"\" --unattended \\\n #\n # install hadolint\n && curl -sSL \"https://github.com/hadolint/hadolint/releases/download/${HADOLINT_VERSION}/hadolint-Linux-arm64\" \\\n --output /usr/bin/hadolint \\\n && chmod +x /usr/bin/hadolint \\\n #\n # Clean up\n && rm -rf /tmp/dev-setup && yum clean all; \\\n fiUgly as hell and mixes IDE logic with deployment logic. Dev container features allows us to abstract all this away and install an extra layer on top of what your "production" Dockerfile will be. It also allows us to have one bit of abstracted code and use it in enumerable projects. All the above can be replaced with this addition to the devcontainer.json file:
\"features\": {\n \"ghcr.io/devcontainers/features/docker-from-docker:1\": {},\n \"ghcr.io/devcontainers/features/git:1\": {},\n \"ghcr.io/guiyomh/features/vim:0\": {},\n \"ghcr.io/devcontainers/features/common-utils:1\": {},\n \"ghcr.io/dhoeric/features/hadolint:1\": {},\n}I wrote a couple for myself and it's surprisingly straight forward to get started. There are nice starter templates which helped immensely in getting a basic idea into a repo. At it's very bare bones all you need is a devcontainer-feature.json file and an install.sh file. But the sky is the limit, there are a lot of powerful options such as setting an entrypoint or messing with the mounting points. See the docker-from-docker feature for something that extensively used the available features.
The first feature I wrote was a simple installation of the shellcheck tool. Additionally you can add an extension so naturally I added the excellent vscode shellcheck extension. Now for any project I want shellcheck for all I need to do is add a line to my features key in the devcontainer.json file and I'm off to the races.
\"features\": {\n \"ghcr.io/lukewiwa/features/shellcheck:0\": {}\n}The second feature was adding the wait-for-it tool. This one required adding an entrypoint and a few options for what host and port to wait for.
\"features\": {\n \"ghcr.io/lukewiwa/features/wait-for-it:0\": {\n \"host\": \"postgres\",\n \"port\": \"5432\",\n \"timeout\": \"60\"\n }\n}The only downside is that because these features are build as layers on top of your existing dockerfile if you regularly make changes to your dockerfile you can expect some slow build times if you have a few features to load. All in all though I'm ok with this trade off if it abstracts away all this code from the main production logic of the project.
\n", "date_published": "2022-11-24T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/setup_mangum_in_aws_lambda_for_django/", "url": "https://lukewiwa.com/blog/setup_mangum_in_aws_lambda_for_django/", "title": "Setup Mangum in AWS Lambda for Django", "content_html": "Here's a quick setup guide to get mangum working as the request handler in a django project in AWS Lambda.
\n\nThe first step is to setup the handler function itself. The tutorial in the official docs outlines this process but I like to add a little extra processing to the handler for running select management commands. This could be abstracted out further than here but I find the migrate command enough for my needs. Add the following to asgi.py.
from django.core.asgi import get_asgi_application\nfrom django.core.management import call_command\nfrom mangum import Mangum\nfrom mangum.types import LambdaContext, LambdaEvent\n\napplication = get_asgi_application()\n\n\ndef handler(event: LambdaEvent, context: LambdaContext):\n if event.get(\"migrate\", None):\n call_command(\"migrate\", interactive=False)\n else:\n return Mangum(application, lifespan=\"off\")(event, context)The next step is to setup logging. It seems under default configs this goes missing when deployed so the below config tweaks the default django config just slightly so that mangum largely mirrors the output you would get running this on a standard asgi or wsgi framework. Add the following to your settings file (usually settings.py).
LOGGING = {\n \"version\": 1,\n \"disable_existing_loggers\": False,\n \"formatters\": {\n \"django.server\": {\n \"()\": \"django.utils.log.ServerFormatter\",\n \"format\": \"[{server_time}] {message}\",\n \"style\": \"{\",\n }\n },\n \"handlers\": {\n \"django.server\": {\n \"level\": \"INFO\",\n \"class\": \"logging.StreamHandler\",\n \"formatter\": \"django.server\",\n },\n },\n \"loggers\": {\n \"mangum\": {\n \"handlers\": [\"django.server\"],\n \"level\": \"INFO\",\n \"propagate\": False,\n },\n },\n}There is something so wrong and rigid about how we teach pommel horse in Australia.
\nIn contrast we seem to be so savvy and inventive when it comes to high bar or even floor. Our "middle class" routines are adequate and serviceable.
\n\nSure we had Prashanth and now Jesse but where are our all around stalwarts getting solid mid 13s?
\nI'm telling on myself here. Quite obvious that pommel was my worst. Part of me reckons with a coach that thought a little more outside the box we could've gotten a lot more out of me on that apparatus.
\nLast aimless thought. Whatever has worked for us on high bar needs to be bottled up somehow and applied to pommel.
\nSome nations have achieved this. GB and Brazil are good recent examples.
\n", "date_published": "2022-11-03T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/wiwas_axiom_for_python_packaging/", "url": "https://lukewiwa.com/blog/wiwas_axiom_for_python_packaging/", "title": "Wiwa's Axion For Python Packaging", "content_html": "Python packaging will be "solved" when a packaging and dependency manager that is written in a compiled language becomes mainstream.
\n\nThere are many efforts to fix packaging and dependency resolution on Python. PDM, Poetry, Pipenv and many other efforts have been made in this space. The fundamental flaw in my opinion as that they are all written in Python. Javascript is having a boon in tooling due in part to many of these tools being written in Go, Rust or some other language that can compile down to a static binary and releases itself from the hard dependency of the language it's built for.
\nI look forward to the day that we see that same explosion for tools in Python.
\n", "date_published": "2022-10-26T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/aws_lambda_and_django_with_sqlite/", "url": "https://lukewiwa.com/blog/aws_lambda_and_django_with_sqlite/", "title": "AWS Lambda and Django With Sqlite", "content_html": "Running Django on AWS Lambda has become fairly mainstream and there are many tools to assist with this goal. There is however a pain point which is admittedly not a conventional use case but a possible use case none the less. Django supports a version of sqlite that is above the current version supported on the underlying operating systems of the AWS python lambda implementation. If you're interested lambda functions run on Amazon Linux 1 and 2 which are based on CentOS 6 and 7 respectively.
\n\nThere are a few ways to get around this, all of them involving either building the source yourself or standing on the shoulders of other people who already have. Some people have created lambda layers to add the required libraries.
\nWith lambda now supporting container images I thought an easy thing to do would be to precompile sqlite inside the image using the build process in the pysqlite3 repository. This repo formalises a build process for creating more up to date sqlite3 python modules. Using the magic of multi-stage builds we can build everything and only copy over the relevant output files. The final image won't even have the build tools which cuts down on image size. Here's an example:
ARG PYTHON_VERSION=3.9\nFROM public.ecr.aws/lambda/python:${PYTHON_VERSION} as build\n\nRUN yum groupinstall -y \"Development Tools\" && \\\n yum install -y tcl\n\nWORKDIR /\nRUN git clone --depth 1 --branch master https://github.com/coleifer/pysqlite3.git\n\nRUN curl -sSL https://www.sqlite.org/src/tarball/sqlite.tar.gz?r=release \\\n --output sqlite.tar.gz\nRUN tar xzf sqlite.tar.gz\nWORKDIR /sqlite\nRUN ./configure && make sqlite3.c\n\nRUN cp /sqlite/sqlite3.[ch] /pysqlite3/\nWORKDIR /pysqlite3\nRUN python setup.py build_static build\n\n\nFROM public.ecr.aws/lambda/python:${PYTHON_VERSION}\nARG PYTHON_VERSION\n\nCOPY --from=build /pysqlite3/build/lib.linux-*/pysqlite3/_sqlite3.*.so /var/lang/lib/python${PYTHON_VERSION}/lib-dynload/You can see the source at github and pull the final product from dockerhub. I've set up monthly builds so hopefully things keep up to date for a while.
\n", "date_published": "2022-10-20T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/another_refresh/", "url": "https://lukewiwa.com/blog/another_refresh/", "title": "Another Fresh Lick Of Paint", "content_html": "I finally found the time and space to do my semi regular migration to a new static site generator. I thought it was time to step away from Vue and try something new, partly out of curiosity and partly because I really like JSX as a templating language. And frankly I'm just not really up for the migration from Vue 2 to Vue 3.
\n\nThis site is now generated using lume. Lume is a static site generator built on top of the Deno programming language. I've been somewhat enamoured with Deno when it came out. It's pretty fantastic to download a single binary and it's got everything I need for compilation, formatting and typechecking.
\nI've used Deno for a few small scripts (which I think it excels at) and I wanted to get into a deeper project with it. Additionally I love JSX as a templating language and was wondering whether there was anything out there that would build static web sites using it. I mean particularly calling the renderToStaticMarkup method in react at build time and leaving just HTML files to serve. I wanted to steer clear of tools like Gatsby and Next.js, just pure HTML in the end.
Well turns out lume really scratched that itch. It's a neat little framework and suits my needs ok. I do enjoy using TailwindCSS but found no clear way to install it using Deno so I ended up using TachyonsCSS which covers similar ground.
\nI've also added new.css for base styles because I'm lazy. It turns out it has a dark mode which I'm not in love with but I'll take it and hopefully finally learn the particulars of detecting dark mode preferences.
\nSo enjoy the different colour scheme, point out the inconsistency in styles and subscribe to my rss which I'm sure I borked somehow.
\n", "date_published": "2022-02-19T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/notification_service_aws/", "url": "https://lukewiwa.com/blog/notification_service_aws/", "title": "Personal Notifications Using AWS", "content_html": "I've found quite a few uses for recurring and scheduled scripts in my personal life. In days gone by I would have run these in a cron job on a server somewhere but as I've gotten into the weeds of AWS infrastructure I've leant on some AWS services more for these little personal conveniences. My preference nowadays is to use AWS Lambda as my first point of call and integrate other services as I need them. I'm very confident that AWS won't be deprecating their Lambda platform and they connect well to Cloudwatch, meaning I don't have to worry about creating a logging solution. Additionally now that I'm pretty confident with the AWS CDK for spinning up infrastructure it's a breeze to connect other services to assist with any other needs. Today I'll go through one example which provided a flexible and cheap solution to my problem.
\n\nIt can be quite difficult to find a good sports massage service and I've recently been very lucky to find a fantastic one. Of course they are booked out months in advance, which doesn't bother me too much but sometimes after a big training session I'll need something worked on sooner rather than later. Appointments do pop up from time to time due to cancellations but I didn't really want to keep checking their website throughout the day. So it made sense to automate the process somewhat.
\nFirstly the code for the lambda. Fairly easy to test locally (minus the SNS dispatch), I've abridged a few things here but you get the idea. Basically it performs a GET request to the API endpoint for appointments available, if the response array has anything in it send an SMS message to all subscribers.
\nimport axios from \"axios\";\nimport { DateTime } from \"luxon\";\nimport { PublishCommand, SNSClient } from \"@aws-sdk/client-sns\";\nimport { URL, URLSearchParams } from \"url\";\nimport { EventBridgeHandler } from \"aws-lambda\";\n\ninterface MonthYearProps {\n month: number;\n year: number;\n days?: number[];\n}\n\ninterface ResponseAppointment {\n day: number;\n day_parts: 1 | 2 | 3;\n}\n\nconst region = process.env.AWS_REGION;\nconst TopicArn = process.env.TOPIC_ARN;\nconst apiEndpointUrl = process.env.API_ENDPOINT_URL\n\nconst nextMonths = Array(2)\n .fill(DateTime.now().setZone(\"Australia/Canberra\"))\n .map((date: DateTime, index) => date.plus({ months: index }));\n\nconst apiEndpoint = ({ month, year }: MonthYearProps) => {\n const endpoint = new URL(apiEndpointUrl);\n const searchParams = new URLSearchParams({\n month: month.toString(),\n year: year.toString(),\n });\n endpoint.search = searchParams.toString();\n\n return endpoint.href;\n};\n\nconst sendNotification = async ({ month, year, days }: MonthYearProps) => {\n const client = new SNSClient({ region });\n const dates = days.map((day) => `${day}/${month}/${year}`).join(\", \");\n const message = `Appointments available: ${dates}`;\n const command = new PublishCommand({\n Subject: \"Appointments available\",\n Message: message,\n TopicArn,\n });\n await client.send(command);\n};\n\nexport const handler: EventBridgeHandler<string, unknown, void> = () => {\n nextMonths.forEach(async ({ month, year }) => {\n try {\n const { data }: { data: ResponseAppointment[] } = await axios.get(\n apiEndpoint({ month, year })\n );\n if (data.length !== 0) {\n const days = data.map(({ day }) => day);\n await sendNotification({ month, year, days });\n } else {\n console.log(`No appointments found on ${month}/${year}`);\n }\n } catch (error) {\n console.error(error);\n }\n });\n};Now let's build the infrastructure around it. I've pretty much standardised on AWS CDK for deployment since it does a great job of holding your hand and creating a lot of the interlinking IAM permissions for you. There's only a few things going on here.
\ngrantPublish.import {\n Stack,\n StackProps,\n aws_sns as sns,\n aws_lambda as lambda,\n aws_logs as logs,\n aws_sns_subscriptions as subscriptions,\n aws_events as events,\n aws_events_targets as targets,\n} from \"aws-cdk-lib\";\nimport { NodejsFunction } from \"aws-cdk-lib/aws-lambda-nodejs\";\nimport { Construct } from \"constructs\";\nimport * as path from \"path\";\n\nexport class InfraStack extends Stack {\n constructor(scope: Construct, id: string, props?: StackProps) {\n super(scope, id, props);\n\n const emails = process.env.EMAILS?.split(\",\") ?? [];\n\n const topic = new sns.Topic(this, \"WiwaNotificationsTopic\", {\n displayName: \"Available Appointments\",\n });\n\n const fn = new NodejsFunction(this, \"WiwaNotificationsLambda\", {\n entry: path.join(__dirname, \"..\", \"..\", \"src\", \"index.ts\"),\n description: \"Check booking site for open appointments\",\n environment: {\n TOPIC_ARN: topic.topicArn,\n },\n runtime: lambda.Runtime.NODEJS_14_X,\n logRetention: logs.RetentionDays.ONE_WEEK,\n });\n\n fn.node.addDependency(topic);\n topic.grantPublish(fn);\n\n emails.forEach((email) => {\n topic.addSubscription(new subscriptions.EmailSubscription(email));\n });\n\n const rule = new events.Rule(\n this,\n \"WiwaNotificationsScheduleRule\",\n {\n schedule: events.Schedule.cron({ minute: \"24\", hour: \"0-8,20-23\" }),\n description: \"Check every hour during the day\",\n }\n );\n rule.addTarget(new targets.LambdaFunction(fn));\n }\n}And that's it! This now sends me open bookings which probably pop up once or twice a week. It's a nice little piece of functionality which lives well within the free tier limits of AWS.
\n", "date_published": "2022-02-11T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/guitar_tabs_fortune_teller/", "url": "https://lukewiwa.com/blog/guitar_tabs_fortune_teller/", "title": "Fortune Teller by Xavier Rudd - Guitar Tabs", "content_html": "There are no good tabs for this track online so I finally figured it out and created them.
\n\n\nFor the authentic key you can uptune 2 half steps or put a capo on the second fret.
\nE|--------------------|--------------------|\nB|--------------------|--------------------|\nG|--------------------|--------------------|\nD|--------2h3p2p0-----|---------0h3-3--0h3-|\nA|-----0h3-------0h3/5|----0h3p2-----------|\nD|-0------------------|---------0h3-3--0h3-|E|--------------------|--------------------|\nB|--------------------|--------------------|\nG|--------------------|--------------------|\nD|--------2h3---------|--------2h3---------|\nA|-----0h3------0h3---|-----0h3------0h3---|\nD|-0----------------3-|-0----------------3-|\n\nE|--------------------|--------------------|\nB|--------------------|--------------------|\nG|--------------------|--------------------|\nD|--------2h3---------|---5--3--2-3-2------|\nA|-----0h3------0h3---|--------------------|\nD|-0----------------3-|---5--3--2-3-2------|Not sure whether this has been done before but I created a docker container with four (4) Python installs. To get there I heavily abused Docker multistage builds from external images. You can check out the repo for the gory details. Now I'm not insane there is a specific reason why I did this.
\n\nI'm pretty all in on Visual Studio Code dev containers and I also like having sensible CI pipelines to catch things. I recently wrote a little library that I diligently tested against multiple python versions using tox. I like to be able to test and debug this locally and not rely on the pipeline specific syntax. So the challenge was to create an environment locally and in the pipeline where a single tox command would kick start all my tests. This seems to be the solution that satisfies this criteria.
Here's an example using Github Actions:
\nname: tests\non: push\n\njobs:\n test:\n runs-on: ubuntu-latest\n container:\n image: lukewiwa/pythons:latest\n steps:\n - name: tox\n run: toxAnd one for bitbucket pipelines:
\nimage: lukewiwa/pythons\n\npipelines:\n default:\n - step:\n script:\n - toxUsing the magic of multi-stage builds using external images and Amazon's official aws cli docker image it's actually pretty easy to add the AWS CLI to a huge amount of containers.
\n\nI haven't tested this on every single docker image out there but for my needs this is a quick and easy way to add the AWS CLI. Configuration can be done using environment variables so no need for mucking around with config files.
\nARG IMAGE\nFROM ${IMAGE}\n\n# Install AWS CLI\nCOPY --from=amazon/aws-cli:latest /usr/local/aws-cli/ /usr/local/aws-cli/\nRUN ln -s /usr/local/aws-cli/v2/current/bin/aws \\\n /usr/local/bin/aws && \\\n ln -s /usr/local/aws-cli/v2/current/bin/aws_completer \\\n /usr/local/bin/aws_completerI've been generally impressed with the preview of Windows Subsystem for Linux 2 (WSL2) and it's integration between the windows desktop and the underlying linux kernel.
\n\nI did notice on a talk by one of the main devs that you could manually import and export linux and container images. This seemed like a nice idea if you wanted to separate dev environments or perhaps have separate work or personal accounts. The demonstration showed exporting and importing docker containers and linux tarballs using the Cool New wsl command in powershell. My dilemma was that I had already setup one Ubuntu environment and wanted a clean one from scratch. So I did a little digging and managed to get one working with a few hiccups along the way.
The Ubuntu wiki has a very neat guide on how to import an image. Be sure to download the nightly image with the -wsl.rootfs.tar.gz suffix.
As in the Ubuntu wiki run the command below. I decided to keep the image location in my home directory, in a distro folder.
wsl --import <DistributionName> <InstallLocation> <FileName>Drop into the wsl2 instance by running the name of the distribution as a command in powershell, or by using the excellent new Windows Terminal app. By default the only user in the image is the root user. While the stock standard Ubuntu image you install from the Microsoft Store prompts you to create a user at startup we'll have to do the prompting ourselves here. The adduser command should get you what you need. Be sure to add your new user to the sudo group.
adduser <username> --ingroup sudoNow that we have created the user we would like it to be the default user whenever you start a new shell. This is a little tricky and there's a github issue outlining this pain point and some possible work arounds. I went with the powershell option but pick your poison.
\nAnd that's it, enjoy separating those concerns.
\n", "date_published": "2020-05-26T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/dark_wiwa_published/", "url": "https://lukewiwa.com/blog/dark_wiwa_published/", "title": "Dark Wiwa Published", "content_html": "I've been using my self made theme for Visual Studio Code for some time now. With every new installation of vscode I've had to manually copy and paste the project directory into the proper extensions directory. Couple this with the fact that I am now using the excellent Settings Sync extension to synchronise my setup between machines this manual copypasta becomes tiresome.
\n\n
Well no more because I have now published that theme for all to enjoy and/or criticise. Check out the Marketplace page or if you like or install it from the command line:
\ncode --install-extension lukewiwa.dark-wiwaMy wife and I are about to have a baby, as such my wife is applying for paid parental leave which is painfully done through the Centrelink system. We also got married in the intervening years between us being on Centrelink regularly and now, and she subsequently decided to take my last name after our marriage. This has caused a headache linking accounts in her MyGov account since the information doesn't match and the system refuses to move forward. We eventually found a solution after tearing our hair out. I thought I would leave it here for any other lost souls who need this guidance.
\n\nUnlink all your accounts! This will allow you to link your Centrelink account. Yes you will have to relink your other accounts if you wish but this is probably a small price to pay versus being on hold with Centrelink for an interminably long amount of time.
\n", "date_published": "2019-02-10T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/ease_of_deployment/", "url": "https://lukewiwa.com/blog/ease_of_deployment/", "title": "JavaScript Remains The Best Deployment Target", "summary": "It is abundantly clear that targeting the web, even as a Single Page App with heavy JavaScript, hits that sweet spot of development time, availability and cost.", "content_html": "I have finally got to the point where I can throw together a single purpose web app over the course of a weekend. I recently was in need of a quick utility that could translate the session times of the recent Gymnastics World Championships, being held in Doha, into my own timezone. I also thought this was a problem that more people probably had so I started thinking about the quickest, easiest and cheapest way to share that utility with others.
\nJust by shear chance that I work mostly on Python and Javascript projects, and deciding I needed to brush up on my React skills I chose a Single Page App as my distribution method of choice. So I rolled up my sleeves and built a web app that did just that.
\nMuch as I've wanted to expand into learning a bit of Android development, on this occasion my lack of knowledge and time constraints pushed me towards the languages and platforms that I already know. What is abundantly clear though is that targeting the web, even as a Single Page App with heavy JavaScript, clearly hits that sweet spot of development time, availability and cost.
\nJavascript is ugly as hell but with modern JavaScript libraries like React and Vue, among others, and their requisite cli commands for bootstrapping a boilerplate app, developing for the current web is pretty nice in the scheme of things. It's easy to iterate, there are plenty of resources out there to help with most issues and there is a metric tonne of helper libraries and components just a quick NPM install away. It truly is a matter of gluing a few pieces together.
\nNothing has more reach than the Web at this point in time. No app store or packaged app is anywhere near as easy as to share as a URL with anybody and everybody. Additionally there is no wait times for app auditing or to register as a developer. There are dozens of services that will host your static files.
\nNot only are there dozens of static hosting services but the vast majority of them are free. No registration fees, plenty don't even ask for a credit card number. I was amazed at how simple it is to push a bunch of static files up to a service and grab a URL.
\nCharging for Web Apps, especially small, single purpose utility ones is notoriously hard to do. This is the strength of an App Store where the user is more conditioned to pay for an app (although I'm not so sure about that anymore). I didn't need to monetise my app but if you do care about pulling in a bit of spare change perhaps the current web isn't your best bet.
\nIf you ever get to the point where you need to start building more features on top of your app or you start needing a database to back it then you are looking at a bit of rebuilding and rethinking your strategy.
\nAll in all I was pretty happy that I could build a utility that did exactly what I needed in pretty quick time, and that I could share with the world easily and freely.
\n", "date_published": "2018-11-10T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/pinocchio/", "url": "https://lukewiwa.com/blog/pinocchio/", "title": "Pinocchio", "content_html": "My siblings and I, when growing up, had a VHS tape of Pinocchio which we would watch on occasion. The interesting thing about it was that this was a very particular adaptation, not the one made famous by Disney but a decidedly creepier and more disturbing version. It left such a mark on us that it became a frequent topic of conversation when meeting for family events as adults. We described it with such disdain that our friends and significant others seemed sceptical as to how bad it could be. It appeared no amount of googling could find this mythical portrayal, until now.
\n\nThe truth is that this Pinocchio adaptation was a BBC series originally airing in 1978. Produced by Barry Letts who famously produced many Doctor Who episodes and various other BBC productions. This version is a darker reading of original text. I found an obscure upload of the entire series of the show on DailyMotion and having rewatched (parts) of it I can definitely say my family's fears are fully founded.
\n![\"Look](\"https://lukewiwa.com/img/pinocchio.jpg\")
You could not make a more unsettling version if you tried, the marionette of the title character is terrifying with jet black eyes, a shrill voice and body movements deep within the uncanny valley. The supporting characters are not much better with humans with elaborate face make up playing the fox and the cat, and a whole host of characters who are cruel and unforgiving. Interspersed musical numbers grate the ears and crude green screen techniques round out the package.
\n![\"More](\"https://lukewiwa.com/img/pinocchio_cat_fox.jpg\")
If you're curious enough I've linked to the offending videos here and part two here and you, dear reader, can confirm the absolute skin crawling nature of this imagining of Pinocchio.
\n", "date_published": "2018-04-18T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/a_good_year/", "url": "https://lukewiwa.com/blog/a_good_year/", "title": "A Good Year", "content_html": "It's that time to take stock of another year in my life and I think it's worthy of a blog post. Professionally and personally a lot has happened and I'm hoping the next year can be very much like it.
\n\nStarting with the personal, I cemented my partnership with my bestie Megan by finally tying the knot. I can definitively say we (she mostly) organised a damn good wedding and we had a ton of fun celebrating with the special people in our lives. I have no desire to have another one any time soon. On that note my peers and friends have had their own special moments including marriage and kids and I'm privileged to have been a small part of these.
\nI've always been a late starter to professional work but this year was the one in which I took small steps into a larger world. A rocky start to the year saw my work experience in controls engineering not flourish into a career. For various reasons my internship was not seen valuable enough to move me into the team proper however I learnt a lot from the experience.
\nMy few months of work experience did see me fulfil the criteria for graduation and after ten long years chipping away I can finally call myself a graduate! Thanks to my gymnastics career this was a very slow burn which sometimes left me wondering whether I'd even finish but this year I finally have closure on this chapter of my life.
\nFinally I was extremely lucky to get a graduate engineering role in civil engineering. I am excited for the future and I seem to be working with a pretty good group of people.
\nAll in all I'm hoping for more years like this one.
\n", "date_published": "2017-12-29T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/new_text_editor_theme/", "url": "https://lukewiwa.com/blog/new_text_editor_theme/", "title": "New Text Editor and Syntax Colour Scheme", "content_html": "After trying a few different text editors out, from the standard of gedit, to sublime text and even attempts at nano, I've standardised on Visual Studio Code which seems to be a standout for a few reasons. I'm not exactly an advanced programmer but when I am punching in a few crummy lines of python or writing some markdown notes I've reached for VSCode time and again. It seems to be both extremely flexible, as well as fairly intuitive. The VSCode's extension ecosystem and the git interface is straight forward and easy to use.
\n\nThere was however one bug bear of mine which irritated me somewhat when using it. I love the Vibrant Ink theme and there is an extension available, however the available theme does not have markdown support and I spend a lot of my time punching in notes using the markdown syntax. As such I attempted to do some tweaking of the Vibrant Ink theme but I wasn't happy with the results. I decided to eventually start from scratch.
\n
I made use of Microsoft's Yeoman to generate a scaffold theme and then used a great generator to populate that scaffold with a basic colour scheme and added my own tweaks. My choice of colours ended up looking very festive. I've put the theme up on Github.
\n", "date_published": "2017-12-06T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/automation_and_driving_performance/", "url": "https://lukewiwa.com/blog/automation_and_driving_performance/", "title": "Does Driving Performance Degrade Or Improve With Increased Automation", "content_html": "During my studies I took a human factors and ergonomics course and found it quite interesting to see the implementation of human factors and how it relates to engineering in general. I was fascinated to study the psychology of how people in general accept certain designs. For better or worse here's an essay which I wrote answering the question "Does Driving Performance Degrade Or Improve With Increased Automation".
\n\nHow is driving performance affected by the introduction of automated systems? It appears the answer is more complex than a simple more or less. There has been increased research into the automation of the tasks involved with driving (Cottrell & Barton, 2013; Merat & Lee, 2012). Coupled with this there is increased study into how these automation’s affect the driver of the vehicle and the safety and reliability of the car in general. Adoption of these automation systems is very much dependant on the willingness of the general driving population to use them (Cottrell & Barton, 2013; Merat & Lee, 2012) and how they interact with the system (Carsten, Lai, Barnard, Jamson, & Merat, 2012; Larsson, 2012; Young & Stanton, 2002; Muhrer, Reinprecht, & Vollrath, 2012). In that sense human factors in driving automation is an important area of study. It can be argued that driving performance increases up to the point of the confines that the automated system works under, however as the system fails and control of the vehicle is handed over to the driver driving performance degrades to a point greater than manual operation.
\nWhat is automation and how is it implemented? Driving and operating a vehicle is a complex task which involves many physical and cognitive tasks, often times concurrently (Carsten et al., 2012). Automation systems aim to control a selection of these tasks, or even sometimes all of these tasks, thereby relieving the driver of some cognitive load and increasing the driving performance of the vehicle. The primary tasks of driving can be broken down into longitudinal and latitudinal patterns (Carsten et al., 2012), which basically mean the throttling and steering respectively. As such there has been an effort to cut away some of these tasks and subtasks by using automated systems. These automated systems often look to take care of mundane or repetitive tasks which would allow the driver to concentrate on the higher level tasks associated with operating a vehicle (Larsson, 2012).
\nA lower level automation system is the automation of a single task which can be coupled with warning systems. Such an example is the forward collision warning (FCW) and forward collision warning plus braking system (FCW+) (Muhrer et al., 2012). This system indicates to a driver that he/she should take action to avoid a forward collision, the plus braking component initiates the braking for the driver in the event of an imminent collision. This system also gives both visual and audio cues in an increasingly attention grabbing sequence to indicate the threat of collision. Additionally it can also be turned off by the driver allowing full manual control.
\nSome higher level examples include the, already commercially available Active Cruise Control (ACC) and Active Braking (AB), automated lane keeping and automated highway driving (Larsson, 2012; Muhrer et al., 2012). These automation systems operate in different ways and have different visual and auditory cues depending on the task. In the case of ACC it is engaged by the driver of the vehicle and has a visual cue on the dashboard to indicate that the system is running. The system works in tandem with the driver rather than taking over an entire task. To deactivate there are several ways, the driver can simply hit the brakes, or turn it off at the control point or the system will disengage itself when outside its boundaries of use (Larsson, 2012).
\nIn some circumstances however there has been a focused push on automating the entire vehicle and taking the control away from the driver to the point of simply being an observer rather than an active participant in the operation of the vehicle, the so called ”driverless car” (Merat & Lee, 2012). In this circumstance the driver does not have any role and the system makes all the decisions.
\nWhy does automation matter and what are the advantages? Automation from a high level is seen as an improvement to the current limitations of manual operation of a vehicle. The advantages include increased sensitivity to road and traffic conditions (Muhrer et al., 2012), more efficiency and better assistance and comfort to drivers, especially with low driving skills (Merat & Lee, 2012). Automation is also proposed as a solution to reducing congestion by increasing road capacity (Merat & Lee, 2012). In addition to these advantages automation systems allow the abstraction away of mundane or low level tasks allowing access to vehicle driving to a wider population. Ultimately the entire automation of the vehicle could possibly allow huge advantages to many people. These can include the accessibility to driving a large population that previously couldn’t. This includes the disabled, such as blind or physically incapable of driving, will have a level of mobility not previously accessible to them. For all these reasons automation is a sought after technology by car manufacturers and as such can require intense human factors study.
\nSome more specific advantages can be seem in human factors studies. Within the limitations of the automation systems they are extremely effective and reduce risk on the road (Muhrer et al., 2012). Automated systems have distinct advantages to human drivers. Some include the inability of automated systems to get distracted, automated systems use sensors which is outside the scope of human senses and automated systems sense multidirectionally. Automated systems also are able to carry out several tasks at once which humans struggle at. In addition to this the reaction time of automated systems are well above that of the average driver (Muhrer et al., 2012). Additionally automated systems do not suffer from fatigue, meaning they stay much more resilient than regular drivers.
\nWhat are the potential drawbacks of these automated systems? As automation increases there come some drawbacks which can affect the adoption and safety of these systems. One drawback is the edge cases and limitations of the system for which it was not designed for. A good example of this is for automatic throttling (ACC) the systems forward radar loses contact with the forward car due to a sharp bend in the road (Larsson, 2012). As the system starts to reach its operating limits the system has to make a decision as to when to fail and also how to fail and hand back control to the driver (Merat & Lee, 2012). At the system limitations the system has to be intelligent enough to know when and how to do this otherwise it remains a bad system. Additionally automated systems suffer from another seemingly widespread drawback, that is that with increased automation the awareness of the driver drops and increases the reaction time, and therefore risk, in situations where the system fails and the driver has to take over operation of the vehicle (Cottrell & Barton, 2013; Merat & Lee, 2012; Young & Stanton, 2002). Although countering the last point, if the driver is given more time and education with the system to learn its limitations and quirks, the reaction times and acceptance increases reducing the risk in the changeover of control (Larsson, 2012). This can be demonstrated by (Larsson, 2012) that as time and experience with the ACC increases the driver is more aware of the limitations and the situations in which ACC fails, such as bends and roundabouts, and therefore the awareness in these situations increases.
\nThere is also another argument that many of these automated systems can be disparate and piecemeal which can hinder education and acceptance of these automated systems (Merat & Lee, 2012).
\nAnother interesting drawback is if the system is only a warning system than the drivers reaction time may decrease even with the warnings in place (Muhrer et al., 2012). This is particularly interesting as it indicates a seemingly unique issue of under automation. The system does not take over enough from the driver and hence puts the driver at a larger risk.
\nOn top of these drawbacks there is also the a specific human factor drawback of acceptance of the automation systems. As automation systems are introduced to a vehicle it necessitates an adoption by the driver. Acceptance and trust must be given by the driver to the system. This can prove difficult. Often the driver must learn new and different behaviours which creates a barrier to entry. Often times drivers can be slow to learn these new behaviours, sometimes to the point where drivers may give up and not use them (Larsson, 2012). Conversely when the driver learns the behaviours and limitations of an automation system then the acceptance and trust raises (Larsson, 2012). In this particular study as experience with the system increased so did the acceptance of the system.
\nHow can we interpret the results of human factors studies and determine how driving performance is affected? So we have automated systems that create a safer and better driving experience within the limitations of the system. But when the limitations are breached there remains a larger risk and loss of driver awareness and reaction time due to the inattention these systems allow (Cottrell & Barton, 2013; Merat & Lee, 2012). We also have a gap of education due to unfamiliarity with the system of the driver and the drivers knowledge of its limitations. However as this education gap is overcome the risk and awareness gap shrink as well (Larsson, 2012). It appears a gap of education is a barrier to entry for the adoption of these vehicle systems and we therefore have a vicious cycle of adoption and awareness of the system limitations. To keep driving performance at a desirable level there seem to be a few strategies in relation to these automated systems. The simplest strategy is to simply not automate the driving of a vehicle at all and keep all the tasks the responsibility of the driver (Muhrer et al., 2012). There are some advantages to this, in that the driver is always in control and always comfortable with the control he/she has of the vehicle. This allows for quicker awareness in emergency situations. Countering this though the more mundane tasks of regular driving can reduce the awareness of the driver to the tasks and subtasks needed for regular operation (Young & Stanton, 2002). This results in higher stress overall but within the confines of an acceptable and sometimes optimal level of stress for the operation of a vehicle (Cottrell & Barton, 2013).
\nTo the ultimate conclusion of full automation it seems we eliminate this gap of risk and inattention. If the fully automated car is capable and indeed possibly better than a driver at all the tasks needed for operating a vehicle than the elimination of the driver and thus the gap of inattention and risk driving performance should be completely improved. The only drawback to the driverless car is that acceptance is very low as drivers prefer to have the illusion of control (Merat & Lee, 2012). But to counter this drivers enjoy a more integrated approach to rather than piecemeal implementations of various disparate automation systems (Merat & Lee, 2012), therefore if the driverless car has an appealing automated experience than adoption may well remain high despite the removal of driver control.
\nThere are however some points to make about the research and testing currently available. Many of the studies are done within the confines of a simulated environment (Young & Stanton, 2002; Muhrer et al., 2012; Carsten et al., 2012) which is a limitation of the studies. One which possibly must be put up with due to health and safety concerns of undertaking these tests on the open road. It is possible that participants in these tests behave differently in a simulator as opposed to how they act on the open road. One study was able to research drivers in the real world (Larsson, 2012) via a survey. However the sample size remains small with all the respondents electing to pay extra to have the automated system installed, thereby possibly introducing some confirmation bias into the study results. The final two papers (Cottrell & Barton, 2013; Merat & Lee, 2012) being meta analyses of various papers the conclusions drawn can be trustworthy provided the papers these analyses have drawn from are reliable. So it is clear that more than just these papers must be taken into account for a more rigorous understanding of drivers reaction to automation and how this affects performance on the road.
\nThe overall takeaway from these studies can be as follows. Under the management of an automated system driving performance improves. Sometimes it even improves significantly. However when the system fails or returns control to the driver there is a period of time where driving performance degrades to a point lower than with manual operation. After this period performance is restored. There seems to an antidote to this problem, with increased education and familiarity this gulf of performance can be overcome. The challenge is to implement more standardised systems which cultivate familiarity and keep the driver educated about these systems and their quirks and limitations.
\nIn conclusion using automation systems to take over driving tasks has many advantages and car manufacturers seem to be moving in the direction of offering these systems to drivers more and more. However as driving becomes more and more automated there tends to be a moving gap of acceptance and safety as drivers have to learn to operate and understand these systems and limitations. As such driving does improve with automation within the confines of the systems limitations. Outside of these limitations driving performance can degrade for a critical amount of time, but with education and awareness of system limitations this gap may be minimised. As such we tend to trend towards fully automated systems where the system is inherently more capable than the driver and hence driving performance improves with automation, but with a moving gap of driver-system interface.
\nCarsten, O., Lai, F. C., Barnard, Y., Jamson, A. H., & Merat, N. (2012). Control task substitution in semiautomated driving does it matter what aspects are automated? Human Factors: The Journal of the Human Factors and Ergonomics Society, 54(5), 747–761.
\nCottrell, N. D. & Barton, B. K. (2013). The role of automation in reducing stress and negative affect while driving. Theoretical Issues in Ergonomics Science, 14 (1), 53– 68.
\nLarsson, A. F. (2012). Driver usage and understanding of adaptive cruise control. Applied ergonomics, 43(3), 501–506.
\nMerat, N. & Lee, J. D. (2012). Preface to the special section on human factors and automation in vehicles designing highly automated vehicles with the driver in mind. Human Factors: The Journal of the Human Factors and Ergonomics Society, 54(5), 681–686.
\nMuhrer, E., Reinprecht, K., & Vollrath, M. (2012). Driving with a partially autonomous forward collision warning system how do drivers react? Human Factors: The Journal of the Human Factors and Ergonomics Society, 54 (5), 698–708.
\nYoung, M. S. & Stanton, N. A. (2002). Malleable attentional resources theory: a new explanation for the effects of mental underload on performance. Human Factors: The Journal of the Human Factors and Ergonomics Society, 44 (3), 365–375.
\n", "date_published": "2017-08-18T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/toyplot/", "url": "https://lukewiwa.com/blog/toyplot/", "title": "Toyplot - A Simple Python Plotting Library", "content_html": "My previous attempts at using python for plotting saw me use the massive and widely used library of Matplotlib. I managed to produce some workable plots which I exported to jpeg and used on one of my medium articles. Although extremely customisable and functional I began the search for a plotting library with a nicer API that would export to more web friendly formats such as html and SVG.
\n\nAfter some searching I stumbled upon toyplot which I've been quite happy with. I went ahead and updated the plots from my medium article using the library and uploaded the results to where I've mirrored that medium article here. The format options are various but I decided to export to an html/css/js format and simply copied and pasted into my static site generator.
\nThe API is quite straight forward, it boils down to a single Canvas object which you can then add different attributes to. It's a nice way to block together the things you want. It doesn't seem to have hard opinions about what plot you are building to begin with which for me is nice as it generalises my code across different graph types. You tend to always begin the same way. Here's a quick snippet of the heat map plots I produced with it.
import pandas as pd\nimport toyplot\nimport toyplot.html\n\n# initialise a pandas dataframe of the code of points\nwith open(csv, 'r') as f:\n data = pd.read_csv(f)\n\n# Produce heat map matrix. I chose Rings\napp_name = 'Rings'\nmatrix = pd.crosstab(\n data[data.app==app_name].value,\n data.eg,\n)\n\n# Some variables to make the plot pretty\ndomain_min = matrix.values.min()\ndomain_max = matrix.values.max()\ntlocator=toyplot.locator.Explicit(labels=list(matrix))\nllocator=toyplot.locator.Explicit(labels=list(matrix.index))\nwidth = 500\nheight = 600\nlabel = app_name\ntlabel = \"Element Group\"\nllabel = \"Value\"\ncolormap = toyplot.color.brewer.map(\n \"Greens\",\n reverse=True,\n domain_min=domain_min,\n domain_max=domain_max,\n)\n\n# initialise the Canvas object with variables above\napp_canvas, app_table = toyplot.matrix(\n (matrix, colormap),\n tlocator=tlocator,\n llocator=llocator,\n width=width,\n height=height,\n label=label,\n tlabel=tlabel,\n llabel=llabel,\n)\n\n# Clean up the Canvas, give it a name and render in html\napp_table.body.grid.hlines[[0,-1],...] = \"single\"\napp_table.body.grid.vlines[...,[0,-1]] = \"single\"\nplot_name = \"{}.html\".format(app_name)\ntoyplot.html.render(\n app_canvas,\n plot_name,\n)The output is a rather nice looking plot based on html, css and javascript. The result is below.
\n![\"cool](\"https://lukewiwa.com/graphs/sr.svg\")
The full code is available on Github for anybody interested.
\n", "date_published": "2017-07-12T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/the_2020_code_predictions/", "url": "https://lukewiwa.com/blog/the_2020_code_predictions/", "title": "The 2020 Code of Points: What we might expect", "content_html": "The Code of Points for the 2020 Olympic cycle is official. The time has come to make some wild speculations about the consequences of these code changes.
\n\nI decided to map the distribution of skills across value and element groups using a heatmap type graph. Not extremely complex but enough to get an idea of where skills are concentrated in certain values and element groups. The darker the colour, the more occurrences of that skill. To see more varied and, in my opinion, interesting routines I’m willing to speculate we need two things from these graphs:
\n![\"Floor](\"https://lukewiwa.com/graphs/fx.svg\")
![\"Pommel](\"https://lukewiwa.com/graphs/ph.svg\")
![\"Vault\"](\"https://lukewiwa.com/graphs/vt.svg\")
![\"Parallel](\"https://lukewiwa.com/graphs/pb.svg\")
![\"High](\"https://lukewiwa.com/graphs/hb.svg\")
My predictions looking at these charts are:
\nI've been making a little web app for my partner and I. I decided to use the Bottle framework as opposed to Flask since I've always liked the lightness of Bottle and my little app has no need for scaling.
\nFlask and Bottle seem have much the same features but there's one pattern in particular that is done easily in Flask but wasn't obvious in Bottle. In many flask tutorials a simple redirect to a url, usually after an authentication seems easily done.
\nIn Flask it's basically implemented like this:
\nfrom flask import route, redirect, url_for\n\n@route('/')\ndef root():\n return 'home'\n\n@route('/redirected')\ndef redirected():\n return redirect(url_for('root'))In Bottle this can be done with the little documented url method, however it works a little bit differently. The route needs to be named using a keyword argument, but then the rest is much the same.
from bottle import route, redirect, url\n\n@route('/', name='home')\ndef root():\n return 'home'\n\n@route('/redirected')\ndef redirected():\n return redirect(url('home'))For my own purposes I wanted to do some analysis of the Code of Points and I had little option but to scrape the important information from the current MAG Code of Points PDF file. I appreciate that the Code is now freely available online however if one wants to do any sort of analysis of the Code the PDF format is one of the more annoying formats to work with. As such I've made my scraping efforts available on github to anyone who would like to download it or make changes.
\n\nOn that note I truly think that the FIG needs to consider making the Code of Points available in a machine readable format. Nowadays more and more of the community is starting to make efforts moving gymnastics and the Code of Points into the digital age. Having the FIG provide that data in a digital friendly format is a great first step into allowing the community to engage more and create interesting things with the data. To be clear when I say machine readable format that can be done in any number of ways. Whether it's simply a csv file published in tandem with the pdf or a fully fledged public API I don't honestly care, as long as it can be consumed and manipulated quickly.
\nIn addition to this the way that most people will read the Code nowadays is on a digital device of some kind. I'd personally prefer a format which is responsive to the device you are reading it on. PDF does not lend itself well to this use case.
\nA few fun things I've done with the data can be found at my projects page.
\n", "date_published": "2017-04-08T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/dumping_ground/", "url": "https://lukewiwa.com/blog/dumping_ground/", "title": "A Dumping Ground", "content_html": "I have tried a few different iterations of personal websites and of online publishing in the past. Although I will still publish random thoughts on my favourite social media sites and longer thoughts tend to find their way to medium this platform might be a nice dumping ground for a few things. Mainly I intend for this to become a landing page for some personal projects and also a better place to leave more personal or technical ramblings.
\n", "date_published": "2017-03-03T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/gymnastics_teams_suck/", "url": "https://lukewiwa.com/blog/gymnastics_teams_suck/", "title": "The Case Against Gymnastics Teams", "content_html": "There has been plenty of debate about the new team format for the current cycle and, as usual, nobody is happy. There is of course one solution to this problem which has not been talked about, although it appears to perhaps to be the most logical. Abolish all gymnastics teams. Get rid of them. Really reform the system. This is a radical solution I’ll admit but let me outline some reasons as to why this option may actually be very appealing.
\n\nGymnastics team events are essentially shoehorning an individual event into a team format. Gymnastics is not basketball, volleyball or football, it’s not a sport which requires two teams face each other. The sport can’t even pretend to be a team sport like relay events in swimming or athletics where individual athletes do their individual performance directly after each other. Stop pretending gymnastics is something that it’s not.
\nWe should keep in mind team event rules change all the time, even within the same competition (hello team final vs qualification). How are we to take the team competition seriously when the teams that make the team final do so under different rules compared to the ones they follow competing in the final. Team numbers have been diminishing from 7 members to 6 to 5 and now 4 in the next cycle. Some events, such as the European Games, have experimented with 3 member teams. The logical conclusion is not hard to see in the distance. 1 member teams!
\nWe don’t see the best gymnasts make it to the Olympics currently. The current team qualification system is a large reason why this is not the case. We get gymnasts that fit the small teams of countries under the arbitrary rules that competition decides on. Sometimes even the best gymnasts in the country can miss out on selection for their own team due to strange team structures. Which brings me to my next point.
\nGiven this massive reform this would open up many spots at the Olympics and other events for those who are competitive and deserve to contest at these major competitions. Now I have no huge ideas on the specifics of how to pick the competitors but the numbers would open up room to explore radical new options rather than the tinkering around the edges we see now.
\nIn essence the gymnastics community has been asking itself the wrong questions and we really need to take a hard look at ourselves and decide what we really want from gymnastics in the long term. Granted it takes two medals away from the Olympic Games events but if we really want to be honest with ourselves as a community we should stop beating around the bush and tackle this issue head on.
\n", "date_published": "2017-03-03T00:00:00.000Z" }, { "id": "https://lukewiwa.com/blog/broken_code_review/", "url": "https://lukewiwa.com/blog/broken_code_review/", "title": "The “We Say You Do” Model Of Code Review Is Broken", "content_html": "With the upcoming review and rehash of the Code of Points for the 2017–2020 cycle one thing is becoming increasingly clear, the FIG and requisite technical committees should do as students are told to do and show their working. The Code has been a living and morphing document since it’s inception. This needn’t change, however the way in which we go about modifications has to become a more data driven process.
\n\nI have been attending athletes meetings at every World Championships since 2011 and I can say they it has been important and useful method to communicate ideas and feedback between the athletes and the FIG about many issues. The consultations last year concerning the new code changes, however, were underwhelming and it has taken me a long time to really unpack why that was. To be clear these are criticisms about the process of the Code review rather than criticisms of the final draft.
\nThe biggest change proposed for the upcoming MAG code was the move from 10 to 8 counting skills. There were of course other changes put forward but for the purposes of this discussion I will focus on this issue. This was extensively discussed and the general consensus was that it would make gymnastics more forgiving on the body, it would possibly improve the overall quality of competitions (especially if gymnasts can discard that one problem skill) and raise the base level of gymnasts. There was one thing that really bugged me though and so I asked a question:
\n\n\nIs there any evidence for these claims?
\n
The reaction was mostly shrugged shoulders. The FIG and the Men’s Technical Committee (MTC) have a responsibility to provide the best arguments for and against any Code modifications and on this occasion it didn’t feel like this was the case.
\nA change from 10 to 8 counting skills is not without precedent, The WAG code has been operating with 8 counting skills this Olympic cycle. This should provide a great opportunity to do some real data analysis on some of these claims. Here are just some examples that I thought about off the top of my head that could help with justifying the arguments for Code changes either way.
\nI don’t know what data is collected by the FIG but I have heard they have made an effort recently in collating data for injuries during competition. A demonstration of injury frequency before and after the change for the WAG code could be an invaluable statistic. Now many factors need to line up to correctly obtain this data. The National medical teams need to be willing to participate, reporting of injuries needs to be consistent across the board and the FIG need to collate and analyse this data in a meaningful way. However if this is going to be an argument for modifications based on injury rates these kind of statistics are surely an integral part of that argument.
\nTo justify whether less counting skills translates to an increase in skill quality we could take execution scores across various competitions and find the average execution deduction per skill before and after the WAG code changes. This eliminates the bias towards 8 counting skills having a higher execution score as would happen if the analysis were to be done per routine.
\nA more basic measure would be to calculate the rate of falls per routine or per skill to see whether, on average, 8 counting skills correlates with less falls. These kind of statistics would, at the least, provide some evidence to support arguments concerning the quality of routines after the changes.
\nHas the average or median participant age increased for major competitions around the World? If longevity is an argument then this may be borne out in the statistics themselves. There are problems, however with this as the minimum age restriction got bumped up to 18 for WAG recently Update: I have been reminded this was only on the MAG side. Not an insurmountable problem however for statisticians.
\nI’ve heard through the grapevine that a justification for keeping with 10 counting skills was put forward because of the unique situation at Glasgow World Championships where Uneven Bars had a four way tie for first place. The argument follows that this would not happen in a 10 counting skill system. Now this argument could easily be backed up with a little data analysis. Have we had a sudden increase in tie situations in WAG competitions since the introduction of 8 counting skills? This would be fairly easy to justify either way by simply checking back on major competitions and comparing the rate of tied scores before and after the change. One data point does not an argument make.
\nWithout any analysis no real conclusions can be drawn. I’m sure there are many ways to manipulate the data. There are also many smarter people out there who could get more out of the data than I ever could and the FIG and MTC should be embracing these possibilities. I for one would be happy to stay with 10 counting skills or move to 8 if there was something, anything, concrete the FIG and MTC could hang their hat on but so far I am left underwhelmed. Who knows, perhaps some analysis has been done and I am ignorant of it, if so feel free to point me towards it. I really hope that I am wrong.
\n", "date_published": "2016-02-24T00:00:00.000Z" } ] }