Things should be ‘projects’, not ‘systems’. They should end, so they can be forgotten. They must be in a fit state to be ended and forgotten. Books work with that idea, but websites are trickier. That’s slightly annoying, but there are great tools for making it easier. Not as easy as sticking a book in a cupboard for a century though. Hmm. I think I need another beer….
Midwest Heritage of Western Australia is a terrific database of records of graves and deceased people in the mid-west region of WA.
I’ve been moving all my photos to Flickr lately. It’s been a long process, one complicated by the fact that it seems silly to run my own WordPress installation (and things like ArchivesWiki) if I’m not going to bother hosting everything myself. Of course, that’s not really very logical, and so I’ve decided that it’s perfectly okay to host photos on Flickr, videos on YouTube, and all the text (and miscellaneous) stuff here on my own server.
I’ve been reading about POSSE and PESOS, and getting re-inspired about the value in a plurality of web tools. I sometimes try to focus just on one Software package (MediaWiki, at the moment, because it’s what I code
for at work. But I used to love working on WordPress, and I’ve got a couple of stalled projects for Piwigo lying around. Basically, all these things will be of higher quality if they have to work with each other and with all the data silos (Facebook, Twitter, etc.).
The foundational principles of the IndiWeb are:
- Own your data.
- Use visible data for humans first, machines second. See also DRY.
- Build tools for yourself, not for all of your friends. It’s extremely hard to fight Metcalfe’s law: you won’t be able to convince all your friends to join the independent web. But if you build something that satisfies your own needs, but is backwards compatible for people who haven’t joined in (say, by practicing POSSE), the time and effort you’ve spent building your own tools isn’t wasted just because others haven’t joined in yet.
- Eat your own dogfood. Whatever you build should be for yourself. If you aren’t depending on it, why should anybody else? We call that selfdogfooding. More importantly, build the indieweb around your needs. If you design tools for some hypothetical user, they may not actually exist; if you build tools for yourself, you actually do exist. selfdogfooding is also a form of “proof of work” to help focus on productive interactions.
- Document your stuff. You’ve built a place to speak your mind, use it to document your processes, ideas, designs and code. At least document it for your future self.
- Open source your stuff! You don’t have to, of course, but if you like the existence of the indie web, making your code open source means other people can get on the indie web quicker and easier.
- UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols & formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
- Build platform agnostic platforms. The more your code is modular and composed of pieces you can swap out, the less dependent you are on a particular device, UI, templating language, API, backend language, storage model, database, platform. The more your code is modular, the greater the chance that at least some of it can and will be re-used, improved, which you can then reincorporate.
- Longevity. Build for the long web. If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn’t require us to destroy everything we’ve done every few years in the name of progress.
- Plurality. With IndieWebCamp we’ve specifically chosen to encourage and embrace a diversity of approaches & implementations. This background makes the IndieWeb stronger and more resilient than any one (often monoculture) approach.
- Have fun. Remember that GeoCities page you built back in the mid-90s? The one with the Java applets, garish green background and seventeen animated GIFs? It may have been ugly, badly coded and sucky, but it was fun, damnit. Keep the web weird and interesting.
Every few years I try to move my blog away from WordPress. I tried again earlier this year, but here I am back in WordPress before even a month has gone by! Basically, nothing is as conducive to writing for the web.
I love MediaWiki (which is what I shifted to this time; last time around it was Dokuwiki and for a brief period last year it was a wrapper for Pandoc that I’m calling markdownsite; there have been other systems too) but wikis really are general-purpose co-writing platforms, best for multiple users working on text that needs to be revised forever. Not random mutterings of that no one will ever read, let alone particularly need to edit on an on-going basis.
So WordPress it is, and it’s leading me to consider the various ‘streams’ of words that I use daily: email, photography, journal, calendar, and blog (I’ll not get into the horrendous topic of chat platforms). In the context of those streams, WordPress excels. So I’ll try it again, I think.
There’s a new version of Piwigo out, and so I must upgrade. However, I’ve got things installed so that the web server doesn’t have write-access to the application files (as a security measure), and so I can’t use the built-in automatic upgrader.
I decided to switch to using Git to update the files, to make future upgrades much easier and without having to make anything writable by the server (even for some short amount of time).
First lock the site, via Tools > Maintenance -> Lock gallery, then get the new code:
$ git clone https://github.com/Piwigo/Piwigo.git photos.samwilson.id.au $ cd photos.samwilson.id.au $ git checkout 2.8.3
Copy the following files:
/galleries (these are symlinks on my system)
The following directories must be writable by the web server:
/upload/buffer; I was getting an “error during buffer directory creation” error).
Then browse to
/upgrade.php to run any required database changes.
I’ve installed these plugins using Git as well: Piwigo-BatchDownloader, Flickr2Piwigo, and piwigo-openstreetmap. The OSM plugin also requires
/osmmap.php to be created with the following (the plugin would have created it if it was allowed):
<?php define( 'PHPWG_ROOT_PATH', './' ); include_once( PHPWG_ROOT_PATH . 'plugins/piwigo-openstreetmap/osmmap.php' ); ?>
That’s about. Maybe these notes will help me remember next time.
fremantlecarnevale.com.au has gone off the air.
Mister Stonewaves is online again. That is all.
I don’t really remember what it was, but whatever it was, it no longer is:
(Maybe someone just forgot to pay their hosting bill.)
Three feeds are gone from Planet Freo. Only two of the sites are kaput though; the SFFC still has a site, but they’ve ditched the feed (not on purpose, I’d say, because they’ve still got an icon for it on their homepage).
- South Fremantle Football Club
- Fremantle Carnevale