Entries tagged 'IndieWeb'

I keep running into things about the Zig community that intrigue me. The latest was this post by Loris Cro about “Critical Social Infrastructure for Zig Communities,” where these paragraphs really grabbed me:

We definitely also need bolder moves, but for now let's try to take it one step at a time, starting from structuring our communities around the idea that other interesting Zig communities exist out there, and that we should try harder to at least stay informed of what we all are collectively working on.

Conversely, we should also strive to make it easier for others to keep track of what we are doing. The time for bolder moves will come, but this a strong prerequisite before can we get to those.

Maybe it is because it is a new and small community compared to PHP’s, but the Zig community seems pretty great. Mitchell Hashimoto’s investment in the community is a good sign.

A lot of what Loris wrote about also brought to mind the IndieWeb principles and my own interest in promoting the ideal of doing open source development in the open using open tools. I chafe every time a community is centered on Discord or Slack, or finding that the real discussions and decision-making is happening in inaccessible places. One person’s tight-knit community can be another’s exclusive club.

I did a first cut of moving my bookmarks on to this site instead of using Pinboard.

I still need to wire up a way to create new bookmarks, but that should be pretty straightforward.

Each bookmark can carry with it an excerpt and a comment. That way I can clip a little text for the bookmark while I’m creating it. None of the existing bookmarks use that yet because Pinboard did no such thing.

Things to be done aside from adding a way to add bookmarks include adding an Atom feed, really wiring them up to search, figure out how to be marking these up in a more IndieWeb-friendly way, and thinking about whether I want to take snapshots of the bookmarks. (Those would probably only be accessible to me to avoid copyright headaches.)

I was checking out the “zero-emission web hosting” providers listed at Get Green Hosting and noticed that IONOS (formerly known as 1&1) has a $2/month virtual private server (VPS) plan that should be totally adequate to run this website. So I spent a couple of hours setting one up, and now this is it.

The only hassle in getting the server set up is I had to reboot to make sure the IPv6 address I added was correctly being used by the VPS and my container setup, and I had to set up a swap file so it wouldn’t go into a tailspin when I tried to do too much.

It looks like the server is located at their datacenter in New Jersey, but I’m not actually sure.

I have been with Linode for just over 17 years, but I haven’t felt the same loyalty since they were acquired by Akamai, which has always seemed like a pretty soulless corporation.

This probably isn’t really a move that pays off in any meaningful way (getting that hosting bill down to $24/year instead of $60/year), but it was an interesting exercise. Looks like Akamai isn’t on 100% renewable energy yet, except for their Seattle datacenter, so this is an improvement on that front.

Inspired by Claudine Chionh’s mention of using Open Library identifiers, I realized that I could link my isbn: pseudo-URLs to the Open Library listings instead the ones on Bookshop.org, which sometimes went nowhere because they have a limited catalog. No affiliate revenue for me, but nobody is really reading this or buying books on my recommendations, so I don’t think I’ll miss it.

The Internet Archive would be a fascinating place to work. They are currently hiring a Website Software Engineer, which is way more front-end focused than I’m looking for, and a Director of Platform Engineering which calls for experience I don’t have. Too bad!

In Chris Ferdinandi’s article about different static site generators (SSGs), he says that they “store content in flat markdown files instead of a database” and that immediately brought to mind “Bake, Don’t Fry,” a blog post from 2002 by Aaron Swartz where he started exploring the concept of baked sites as compared to fried sites.

At the time, you had blogging systems like Blogger and Movable Type that stored their data in a database but generated static pages for viewing, and systems like b2/cafelog (this was pre-WordPress) and OpenACS that stored their data in a database but generated pages on the fly. The first blogging system that I remember that just used the file system to store all of its files was blosxom.

I started this blog on Blogger but quickly switched over to a homegrown PHP/MySQL system in October 2000. I have rewritten it from scratch once or twice since then.

I have been thinking about moving to a setup that baked and published a static version of my site. A reason I haven’t done it is because doing it all fried hasn’t been a performance problem so far.

I’m not convinced that I want all of the content in flat files and not a database. I guess I just don’t see the advantages of working with flat files for how I like to write, and I can’t imagine expecting less technical users deal with things like text files with front-matter and tools to manage those files.

It is strange that all of the popular static-site generators I’ve looked at have filesystem storage baked into their design. It should be rather straightforward to abstract that out a bit, and then you’d be able to pull your content from a database but generate static output. Like Blogger did twenty-five years ago.

I’d call it maybe an alpha release, but a very basic version of my photo library is now up and running. There is one last picture I need to migrate over from my old Flickr presence, but otherwise they should all have made it over. I should look at pulling in the photos from my Instagram account. The real test of things would be to load my iCloud photo library, but that is about 25,000 pictures and I’d certainly have to go through to see what could be public. It would probably be better to figure out how I want to get photos into the library going forward, and then I can back-fill photos from before this year.

Just implementing this has made me think a lot about how my system here is structured, how the data is structured, and how I want to structure it. I am trying to move towards adopting more of the IndieWeb principles and standards.