Posts

• Migrating to a Parent Model with Multi-table Inheritance in Django

  I just added a “Notes” section to this website, and in so doing, did a fair amount of refactoring. Notes are different from Posts in that a Note doesn't have a title and is only short content. But otherwise they are very similar. Additionally, I wanted to show a single feed on the home page of both types.

  At first I tried adding the Notes model and an abstract model for both Notes and Posts to inherit their common pieces from, but getting a combined feed for the home page was a bear. I did get it working, but the code was a mess.

  My next shot was using multi-table inheritance. Have a proper model, “FeedItem”, with the shared properties and then I could use the built in View classes to do a feed of FeedItems, testing for and passing the child model for templating. The only problem here was Django’s makemigrations command really choked on adding a multi-table inheritance parent model. To make it work took a stepped migration process.

  First I made a manual OneToOne relationship between FeedItem and Note/Post, a key point being that in multi-table inheritance, the parent model is called model_ptr and the database column is model_ptr_id. In this first iteration, the relationship was nullable and was not the primary key. And FeedItem was an empty class, so I didn't have to worry about field name collisions. I ran makemigrations and migrate and made sure everything was working.

  Next I made an empty migration and used the migrations.RunPython to write functions that created FeedItem records for each Post and Note in the database, attaching them through the OneToOne relationship. I ran makemigrations and migrate and made sure everything was working.

  Once every Note and Post had a FeedItem, I changed the relationship to be the primary key. This sets up the relationship to move from OneToOne to multi-table inheritance, because, behind the scenes, this is the multi-table inheritance relationship. I ran makemigrations and migrate and made sure everything was working.

  At this point, removing the relationship and adding the FeedItem as a class being inherited shouldn't trigger any migrations. I ran makemigrations to make sure Django didn't see any database changes.

  Next I prefixed all the fields that needed to go to the parent model with old_, ran makemigrations, migrate, and made sure everything was working.

  I added the fields to the parent model and ran makemigrations. In the migration I added a step to follow the field creation to copy the old_ values to the new fields. I ran makemigrations and migrate and made sure everything was working.

  Finally I removed the old fields from the child models and did a final makemigrations and migrate run.

  In reality, it took several failed attempts to finally to do it in small enough steps for everything to work. It was a big ol‘ pain, but it did work.

  I'm finding that a lot of my work on this new site is requiring tricky refactors in Django. Hopefully it's just my unfamiliarity with the platform and doing a poor job architecting from the beginning, but it does feel a little difficult to make application changes. I'm often starting new apps, deleting them, having to make database changes, undoing database changes, and so on just to figure out how to implement new features.

• The Hills of Clairmont Heights and Medlock Park

  While we’re sheltering in place, I joined the Cabin Fever Achiever challenge. It’s an 8-week event where each week you get a different running challenge to be completed solo.

  The first week’s challenge is to find the biggest hill in your neighborhood, run up it as fast as you can, and repeat as many times as you can (or can stomach). Of course, that meant I first had to find the biggest hill in my neighborhood. I identified 51 hills in our neighborhood and used Strava Route Builder to get their distance and grade, and then calculated each hill’s Strava Climb Categorization points, which basically uses both distance and grade to get an objective difficulty rating for a hill. While I was at it, I added Strava segments for any of the big hills that were missing one.

  These are the 10 biggest hills in Clairmont Heights/Medlock Park ranked by Strava Climb Categorization points:

  Segment	Cat. Points	Distance	Avg Grade
  First Hump	2743	0.25mi	6.8%
  Desmond Dig	2682	0.39mi	4.3%
  N Hills Hill	2499	0.21mi	7.4%
  Take it ALL the way	2346	0.38mi	3.8%
  Can’t Go ’Round It	2103	0.16mi	8.2%
  Could Be Worse	2011	0.17mi	7.4%
  Willivee Wall	1981	0.27mi	4.6%
  Just up	1920	0.10mi	11.9%
  Woodridge WB	1798	0.24mi	4.7%
  Second Hump	1767	0.14mi	7.8%

  I think Wednesday is when I'll tackle First Hump for the Cabin Fever Achiever.

• Tweeting From The New Website

  Over the past week I’ve been working on adding the ability to send tweets from my new website. Specifically, I want the option to tweet all or some of my content when I publish.

  I still have some wrinkles to work out and questions to answer, like: how should I handle hashtags? what about tagging other Twitter users? But it’s working!

  In my Admin, I have a checkbox Syndicate to twitter. If that’s checked and the post is published and I haven’t already tweeted the article, the site updates my Twitter status with content from the post and a link. Also, if I uncheck the box, the site deletes the tweet.

  In Django, I set up a new App, Syndications, to handle the logic with interacting with Twitter (and any other site I end up posting to from my website).

  In my Posts App, I added a TwitterSyndication model to handle the Twitter data associated with a Post, and added a few properties and methods to the Post model for handling the update status/delete tweet logic when saving.

  I’m still unclear when I should and should not create new Apps in Django. I feel like a new concern is a new App, but I'm ending up with a lot of Apps. I’m sure much of this will become clearer as I continue to work with the framework.

• First Pass at Styling

  I made my first pass at styling the new website. I mostly focused on the basic styling for mobile and older browsers, so no new fun stuff like flexbox, grid, etc. I'm certainly still tweaking it and will try to enhance as I go, but it doesn't look as raw as it did with just plain browser styling.

  From a design perspective, I had a hard time picking some fonts. It's been a long time since I've built something and been able to make all the design decisions from scratch. I thought I'd go in the direction of more modern and geometric, but I didn't like how bland it looked, so I tried out Libre Baskerville, which I really like, but wanted to have the option for a bold italic. I settled on EB Garamond and really like the print-inspired humanism of it. Pairing it with another font proved to be difficult, but I'm trying out Open Sans and, so far, don't feel like it's fighting with the Garamond, but swap for something different later.

  I wanted to keep the orange color I had used in my previous Orange Gnome site, but it didn't pass accessibility muster without a dark background, and I wanted to keep the default color scheme light. So I ended up darkening it a bit to get it to WCAG AA for normal text. I hope to implement “dark mode” styles at some point and will revive the original orange for that.

  I also always liked the gnome head I created for my original site, so put that in the footer as a fun element.

  From a technical perspective, I did a bit of hem and hawing on how best to implement styles for a Django site. At first I thought maybe each App would have its own styles, but I didn't want to have so many stylesheets on the same page, nor did I want to have a build dependency to concatenate them into a single file. And even then, where should that file go?

  I ended up adding another App, Base, to the Project and refactored the base templates there. Then housed all the styles there too. This made sense to me: Base has a dependency on the other Apps as a kind of “presentation App”, but the other Apps don't care about Base

  I added the django-sass project to handle SASS compilation and after that things were pretty smooth sailing. I was unsure how deployment would work with the new static files, but everything worked fine.

• Old WordPress Blog Migrated to New Django Site!

  I finally managed to get my WordPress posts migrated to the new Django site. Django has a cool feature where you can add command line scripts to an app, so that's what I did. It isn't generic enough to use for any WordPress-Django migration, and it's not safe to run more than once (I wrote a second script to clear the populated tables if something happened during migration), but it did the job.

  I still need to go back and figure out how to handle the WordPress shortcodes, and I need to figure out how to improve the writing experience in Django.

  But! It's not like I write a lot of posts, and I'm happy to have this piece behind me. I think next task will either be getting the post authoring/display experience cleaned up or getting my Strava content integrated.