After a journey to Indonesia and a coding project (more on that in some days), I finally had some time to work on the technical side of my website again. There are major changes in the underlying data structure and also in the scope of what I program the underlying system for.
I previously conceptionalized the system my website runs on to be a full fledged CMS, including a newsletter feature, backup features etc. I had disabled most of them though: some were written, because I am running Ppanji.org on the same code basis. There, we have disabled notes, but we have enabled videos as an own category of posts. A newsletter would have a credible use case given ppanji.org's aims, while it certainly has none with my personal website.
On the other hand, additional features make the code slower and potentially more resource-intensive. And since I am not using my own server, I am always weary of wasting processing power and bandwidth. I have thus removed any features I am not currently using or planning to use in the near future.
Moving Away From XML
I originally intended my website to be basically an RSS reader, with RSS feeds used for data storage. This would - had it worked out - taken away any hassle with writing an API. It did not however. Given the length of blog posts and especially additional data like links to syndicated versions of notes on Twitter, the RSS feeds were removed more and more from actual RSS and developed into just another kind of more or less random XML. I thus lost the potential advantages of using RSS.
The downside of using RSS - from the start and pretty much always - is that it's bloated: There's just too much markup for too little content. Say, its was again making the website slower and more resource-hungry than it needed to be. Given my aim of saving things in feeds, I also made the mistake of saving all posts of any kind (blog posts, notes, bookmarks, etc.) in a single file per kind of post. Again, resource hungry and ineffective.
Finally, I was using SimpleXML in PHP for handling the XML files. Given my purposes, this was again overdoing it.
To sum up, using XML was a bad idea, and it was just a matter of time when I'd move away from it. I now finally had a good chance.
Storing Data in Different Formats for Different Things
XML gave me the advantage of using one format for all kinds of post I make. Theoretically, I could have just replicated the same with a more efficient format. I chose not to.
Today, the website is based on different formats depending on what is to be saved: blog posts, notes, and bookmarks are stored in an adjusted form of CSV (I am told LaTeX is using a similar method for separating metadata from contents); calendar entries are stored in an .ics stream; BibTeX is used for publications. Finally, settings are stored using JSON.
ICal for calendars and BibTeX for publications are no-brainers: both are open standards used for storage by the programs I use to manage my calendar and my bibliographical database respectively for storage anyway. Moving over to JSON instead of XML was a harder choice. It's less bloated, but that's it. Since the files are loaded everytime somebody opens the page, this little improvement is worth a change though. Finally, moving to one CSV-like file per entry instead of one large XML file for all of a kind gives me both the chance to read only single entries and the chance to read only specific data (e.g. not needing to read a blog post's content when I only need metadata).
New Design and a New Feature
I finally moved to a yet more reduced design for my website. I had grown to see the old design as rather complex, while my initial aim in doing it was to make a minimalistic one. The one my website uses now is done from scratch: the CSS file is now 197 lines long instead of about roughly 600.
All in all, the redo was a major push to slimming down the code base and reducing what I have to what I need.
But I couldn't hold back to introduce a new feature: extended categories. The Website tag page and others see how my thoughts on a topic developed.