I have promised, repeatedly, that it's no problem that we're using a flat text file as our database. Now I'll make good on that promise by swapping out that text file for SQLite.
Why now?
That last is slightly more serious than it might appear. First, programming effectively depends heavily on your reserves of energy and gumption. Things that sap those are ipso facto bad. Second, as you get better at programming, the correspondence tightens between what bothers you and what is actually bad.
Why SQLite?
Moving fast matters a lot. There are big changes here, but they took a total of perhaps an hour to implement (and really I should have done it faster).
SQL has been explained by other people better than I'd explain it from scratch. You should know:
Some notable features of this migration are:
.gitignore
file so that the database (and anything with a .db
file extension) are not committed to version control. This respects the basic distinction between code and data; prepares us for a future where several clients read from a given authoritative database; and prevents anyone with access to the code from also seeing all of our tasks. (Properly securing this application is a large project, but not keeping all of our users' tasks in plain text in a public GitHub repository is a good first step.)README
.And this work makes certain exhortations relevant:
README
section with reminders about deleted functionality. (But this is mostly to make it psychologically easier to throw away--although I do sometimes go back to look at these vestiges, I'm not sure the README
notes have ever made this process more efficient.)set_tasks()
method on TaskRepository
was a mistake. It is worth the effort now to delete it. (See the last installment for notes on why extra methods on your interfaces are dangerous.)These are both more important than they might seem. It's easy to recite slogans about how programming is, centrally, a matter of managing complexity. Actively fighting against quadratic complexity is a lot harder: it requires a combination of clear thinking and professional discipline.
The Web interface runs just as it did before--perhaps a bit snappier. The tests pass. Take a look around: we now have a functioning app backed by a production-quality database.
Here's the current commit in the veery/
repository.
Next post: Python task manager from scratch, part 28: Taking stock