Friday, May 23, 2014

Web programming is mostly server administration

I sort of lost track of what to do next with my web site project, so that means time for a blog post.

I have two big goals: restore's old content into a modern website, and build a new task tracking system to experiment with various ideas.  I'm sort of stuck, and my pretty list of working tasks has turned into a tangle:

The hierarchy broke down within Task 16 (Set up production Django) but I'm pretty sure that if I mapped it all out I'd have some loops.  (Setting aside the biggest loop, that I need to build a production-calibre, Enterprise-grade task management system to keep track of the tasks necessary to learn how to build a production-calibre, Enterprise-grade web site.)

I got part way into recovering my old web writing, enough to reassure myself that it was totally practical and also that most of my old writing follows Sturgeon's Law ("ninety percent of everything is crap").  Then I got hung up on the detail that, while I could recover the original publication date, Django-CMS was not eager to help me do anything with it.  I could see the data in the database, and I could see how to put a variable into the html template that gets displayed, but I was blanking on what lay between these two end points.

So I decided to take a break on the coding and go shore up some foundations.  I was running the quick and dirty Django development site, on SQLite.  I'm much more comfortable with PostGreSQL, and working on code without version control is like going commando in a baseball game: you'll get away with it for a while but when a ball finally bounces into your crotch, it will turn out not to have been worth it at all.  And maybe it's more agile to get a production-ready system launched and then roll out improvements than to build the whole thing on a temporary dev server before launching anything.  So it seemed like a good time to work toward four intertwined goals:
  1. production system that runs on a sturdy database, starts automatically on reboot,
  2. full version of the system running in a local VM
  3. everything into source control
  4. automated deployment of the site across different hosts
Going local is easy enough with VirtualBox, although I don't care to see the word Oracle appear on my screen.  Everything into source control is kind of stalled because I decided that I made a mistake going with git over Mercurial, with the tipping point being 10 things I hate about git, which did not have Julia Stiles or Heath Ledger but did have diagrams of the kind of version control I'm comfortable with (Julia):

And what git offers (Larry Miller?):

Git is basically aimed at one user, and so it's pretty quirky.
The most spectacular example of this is the command “git am”, which as far as I can tell, is something Linus hacked up and forced into the main codebase to solve a problem he was having one night. It combines email reading with patch applying, and thus uses a different patch syntax ...

Since I'm not going to integrate thousands of patches from hundreds of contributors over an enormous code base, or learn Finnish, this learning curve is a lot of cost for no benefit.  I do still want to master distributed version control, so time to get going with Mercurial.  However, Github is really useful both for the central and stable code hosting and for the sharing.  However however, Github appears to have some toxic culture issues.  Still not sure what to use instead.

Back to goal 1, production hosting, I've been reading various installation instructions for Django-cms, such as How To Install and Configure Django with Postgres, Nginx, and Gunicorn. But after four or five rounds of this, getting various errors and tracking them down, many of them going back to minor discrepancies in the instructions, or conflicts from trying to apply two different, overlapping but individually incomplete (for my purposes) instructions, I'm getting fed up. This kind of mediocre documentation is what led me to rewrite the OpenACS installation instructions and get involved in that community. And my goals here are not weird; I want a production environment for my website, and a development environment, and a straightforward way to move code and data between the two, and an easy way to spin up more environments as needed. This should be utterly standard and common; there is no reason to have a billion different ways to do this and all of them obscure. OpenACS was providing mostly adequate solutions to these problems (how do I promote code from dev to test to production? How do I move code around when it includes database changes?) in 2001. Why is there nothing better yet? And can I please get a damned diagram of Postgres, Nginx, and Gunicorn, and an explanation not only of why I end up with this in my directory structure:
but of why anybody thinks that's even okay?

And then I found this:

which comes right after this:
But struggling to configure nginx is just a waste of time. I’ve found many partial guides to Django deployment but haven’t found any single, recently updated resource that lays out the simple, Pythonic way of deploying a Django site in production. This post will walk you through creating such a set up.
Okay, I am renewed.  New task list:

1) set up a production-ready server on my desktop VM according to these instructions
2) throw it away
3) Learn Mercurial and find some minimum offsite backup procedure
4) Set up production on a plain django-cms site
5) Manually fix the home page and put up a newer picture of Kona
6) Publish one good old article (if there is one! Nothing about that bastard Rumsfeld, no matter how damning it is)
7) Figure out all of the CMS stuff (menus, graphics, minimalizing the look, etc) on dev and push it out
8) Go back to recovering blog content and the Songs not in 4/4
9) Build the ultimate task tracking system

The only problem is that I now need to get this list of nine things into my task tracking system, which is annoying, and makes me want to build the ultimate task tracking system.

No comments :

Post a Comment