There’s an old joke in programming, that the two hardest things to do are naming things, cache invalidation, and off-by-one errors. But this doesn’t pay sufficient respect to one of the other hardest things, namely handling date and time.
Today I got two major bits of functionality in: Publ will now asynchronously scan the content index (which speeds up startup and fixes some annoying race conditions with entry creation), and it also asynchronously generates image renditions (which makes pages not take forever to load on first render, and will also use multiple CPU cores if available). Seems to work well so far.
I was running into scaling problems with beesbuzz.biz (what with there being a couple thousand entries and some pages with hundreds of images on it) and this keeps it feeling pretty good.
So, this brings us up to version 0.1.14.
Two major updates for v0.1.13:
- Rewrote the pagination logic to actually work across category-recursive views, and to support pagination where the sort order isn’t necessarily the same between renders
- Refactored images so that the template
image()function has access to the tag writer
These changes were made as part of migrating beesbuzz.biz over to Publ, which I’ve made a lot of progress on now. It’s pretty nice getting my overall design proven out, and to shake out all the little bugs and misfeatures.
Hopefully soon I’ll have Publ in a state where I feel comfortable releasing it as beta.
I just released v0.1.12 which adds a couple of quick, minor-ish fixes to Unicode handling; in particular:
- UTF-8-containing headers no longer get MIME-mangled on first import
- I finally made the automatic slug text way better by switching to awesome-slugify
So, now it’s no longer US-English-centric, at least. Right now it just uses the defaults; at some point I’ll want to make it so that you can configure a site’s or entry’s language locale so that things work better on that end too.
I have now implemented the basic OpenGraph API to Publ, so now a template can generate an OpenGraph card with
So in theory when this entry gets autoposted to Twitter, this first paragraph should appear, as should the below image:
Anyway that’s what’s new in v0.1.11 (as well as a bunch of internal refactoring to support this addition).
If you are reading this, it means that Publ v0.1.10 is out. This release is mostly about a few cleanups, such as:
- No longer nests a
<div>for an image gallery inside of a containing
<p>(which both fixes an HTML validation error and makes styling more controllable)
- Cleans up error handling somewhat
- Also cleans up a bunch of code for property caching
But there’s also a new feature, namely
view.range, which you can read about over in the API docs.
I am also making significant progress in porting my main website over to Publ and hopefully I’ll have something to show for it soon. (And I promise it looks way nicer than this site!)
I’ve had people ask me why I’m not building Publ using PHP. While much has been written on this subject from a standpoint of what’s wrong with the language (and with which I agree quite a lot!), that isn’t, to me, the core of the problem with PHP on the web.
So, I want to talk a bit about some of the more fundamental issues with PHP, which actually goes back well before PHP even existed and is intractibly linked with the way PHP applications themselves are installed and run.
(I will be glossing over a lot of details here.)
So, note to self: library version pinning is a good idea. I should also learn how to properly manage my library version dependencies.
Not a lot to say, just that
all my intended image rendition functions work now (historical note: this entry was back when the Publ site included the test suite, which is no longer the case).
I really need to stop dragging my feet on migrating beesbuzz.biz over, because there is absolutely no excuse now.
Anyway, this ups the Publ version to 0.1.5. Have fun.
I’ve released version 0.1.4 of Publ, which makes the following major changes:
limithas been changed to
countin the API (for more consistency and clarity)
- Similarly, on image sets,
- More template functions now support positional (rather than keyword) parameters; this has yet to be documented however
And on this site I’ve split out the manual to put the various template object APIs into their own category, although the organization of the documentation is still h*ckin' messy.
Converting Publ into a pip-installable library ended up making the Heroku deployment really easy. While the main site is running on Dreamhost, there is an instance on Heroku as well, which seems to be running reliably (although if it gets hammered with activity I assume Heroku will shut it down until I start actually paying them money).
There’s a few pluses and minuses to Heroku compared to traditional hosting on a persistent server (such as Dreamhost).
I finally separated out Publ-the-library from the main Publ website files, and released v0.1.0 on PyPI, making this the first time I’ve released anything there. Woo!
Check out this image:
Check out this tinier version of the image:
If you have a high-DPI screen, notice how the tinier version is sharper!
I threw PyLint at the code. Then I cleaned everything up.
This blog entry is really just to test the fixes to make sure everything works. Seems fine.
Instead of working on image renditions I decided to try adding in some caching
functionality, and experimented with both
Flask-Cache. Neither is a particularly
great solution to caching but they get the job done.
I was just on a few days' business trip for my augmented reality startup (we just released a new app, by the way! check it out, it’s free and fun) and so I haven’t had time to work on Publ for a bit. But I’ve been getting a bunch of questions about Publ, so I figured I should answer some of them!
EDIT: Moved this into its own page on the main site.
So I was trying to figure out why new entries weren’t appearing in indexes until
things restarted. I thought it might be a caching thing, but editing entries caused
them to update instantly. So then I thought it might be an index thing, like maybe
something silly with how SQLite handles timezone-aware DateTimes, so I overhauled
the date handling so that it separated out
that didn’t help either. Then I looked closely at the database before and after
restarting the process, and that didn’t help. And then I made sure my queries
were using the right timezone, and that didn’t help.
Then I had one of those moments where I realized what I’d done wrong with such sudden clarity that I couldn’t help but yell at myself a little.
So, previously I was just letting the database generate entry IDs on its own. In SQLite this means it would always generate the next entry ID as the highest one plus one. This is fine in a circumstance where entries always get assigned their IDs in the same place, but in Publ’s model that might not be the case.
One particularly fun circumstance: A site’s maximum ID is 406. You’ve written an entry on your own machine, and someone else has written an entry on their own machine (or you wrote two entries, each on a separate branch), and when testing the rendering they both end up getting entry ID 407. Which one’s right?
There was a silly bug with how I was generating paginated views which I noticed as soon as I did my commit/merge last night but I figured I’d wait until today to fix it (because the fix was obvious and I was already up way too late). And I fixed it.
There is only one feature left before I can start making a real site with this thing: Image renditions.
This is the single most important feature (at least for the initial phase of Publ), and in fact about 95% of the reason why I decided to write a new CMS to handle my site content; this is the one thing that every CMS I’ve seen does a poor job of handling, and which is very difficult to hack around. (I hacked around it in Movable Type, as I mentioned previously, and it is one of the most irritating things about running my site as it is.)