This site has served content over HTTPS for a couple of years now. Not long ago I also enforced HTTPS everywhere instead of allowing HTTP in parallel (all old URLs get redirected to its new, encrypted counterpart). There were some small, but obvious omissions though.
The search form at the bottom of every page was set up to send data to an unencrypted version of the most popular search engine. The form is also encrypted now and all major browser should display a lock now. In addition to that I also changed the search engine to DuckDuckGo.
If you have your own website and still haven’t enforced HTTPS everywhere I would strongly suggest so. Domain-validated certificates are basically free now and in the worst case you’ll just get the benefit of increased privacy for you and your visitors.
I survived a few high traffic moments from Hacker News and was thrilled to see the site stay up even when I managed to break MySQL on the server.
Another benefit of static sites compared to dynamically generated pages is speed and reduced server load. Tyler Hall has a similar setup to this site, but he uses incron instead of a normal cronjob. This should reduce the server load even further if your hosting provider gives you enough access or you have complete control over your server. Once you install and configure everything posting new articles is even easier than with bookmarklets, e.g. for Tumblr or WordPress.
The PHP generator script runs on the server. The entire blog is kept in Dropbox, and through a dummy account linked to my server synchs automatically with the server whenever I make a change. Most iPhone and iPad text editors work with Dropbox, so I can write and publish wherever I am.
I always used WordPress for all of my sites. I also recommended the publishing platform to a lot of clients and friends who wanted to run a website that wasn’t necessary a blog. During the last couple of months I begun switching more and more sites to static sites that are automatically generated on the command line. This has not only the benefit of a much better performance, it is also more secure. There are no scripts that could potentially give an attacker the chance to take over the server or at least your user account.
I started with this site and migrated it to Jekyll. My publishing workflow was rather tedious. I had to manually create a text file, and then commit it to the server. An update hook on the server automatically updated the published site. Inspired by David’s article I got rid of the Git part and replaced it with Dropbox. The server instance runs as a separate user. It has only access to the raw website and not my whole personal Dropbox folder. I’ve written a small server-side script that checks every two minutes if there are any changes inside Jekyll’s post folder. When I modify an article or create a new one, the site is regenerated. I wanted to use incron, but this server doesn’t have inotify and there’s no chance to install it. Additionally I created a Keyboard Maestro script that takes the current selection from Safari, creates a new text file in the drafts folder and optionally opens BBEdit with a new article and the quote.
The best thing about this setup is that I can write articles and publish them from almost everywhere. I wanted to share all scripts, but they’re tightly coupled to installation and deployment paths. It needs a lot more work to clean everything up and make it usable for everyone.