...more recent posts
I still have never said anything explanatory about the new software. And it's not that I haven't tried. Explaining software is difficult. So I'm still hoping for a longer, more thorough post, but here's something shorter about what I am working on presently.
The software is basically done. This is what I wrote several months ago during the initial phase of my long absence from blogging. It is a descendant of the software that runs this site, but much more generalized in an effort to target small business websites (especially inventory-centric websites,) instead of just blogging. Where this site has posts and then a bunch of meta-data associated with each post (author's name, date, summary, comments, etc...) the new software allows you to define anything as the main post - these are called 'Items' in the new system - and then associate any number and kind of metadata 'Atoms' with each item. All items, and their associated atoms, can be specified through the same sort of browser based interface that I use everywhere.
So, in other words, this site works great for blogging, but not for much else. The new software could be set up to blog, but it can also handle the situation where, say, instead of blogging you want to have a website for your wine business. Now instead of blog posts you have bottles of wine as your main items. Each wine then has a bunch of metadata associated with it (grape types, producer, year, etc....) To do this before would require me to write a lot of code. Now I can do it all through a web interface.
I wish I could explain it better because it's pretty cool.
You specify what your item and it's atoms are going to be like. Text, binary data, numbers? Then the software asks you a few questions about your items and it's atoms (like, what sort of form elements will be necessary for adding and editing,) and it builds all the necessary user interface pieces for you. I'm not sure how clear that is, but that's the slick part. The posting and editing scripts are very generalized and they can deal with any data, no matter how it is structured.
The whole project was a matter of abstracting the software that runs this site. Boiling it down, but at the same time radically expanding it's scope. Freeing it from the conceptual mold of blogging, while maintaining the blog like ease of creating and editing right in the web browser.
And, like I said, it's largely done. It's already deployed behind a few sites that I will point to eventually. But how the sites look isn't really the main thing. It's how they run. It's how (hopefully) easy they are to build and maintain. That's the key.
So now I am working on polishing the whole package. This is something I've never done before. I have put the older software behind a number of different blogging type sites (and even tried to adapt it for several business sites,) but it is a monsterous pain in the ass to deploy. It takes me the better part of a day to set it up, and that's assuming everything goes right. There aren't any instructions (which even I need and I wrote the thing,) it's very unintuitive, and the whole thing is just a sprawling mass of weird hacks and dependencies. It runs well once you get it working, but it gives off a sort of "don't even breathe on it" vibe.
So I'm trying to fix that this time around. Yesterday, for instance, I wrote a program that automatically sets up the database for a new installation (of the new software.) If you can believe it, I've never had an automated way to do this. I would just fire up mysql in an ssh session and create all the tables by hand. That's fine if your just deploying one site, but my goal now is to be able to deploy lots of sites. Quickly and painlessly. So that means building the automated tools to do it.
I thought I could do it in a few hours yesterday morning. How hard could it be? Ended up taking 10 hours. And 6,000 lines of code (not that number of lines means anything - a better programmer could have done it in less.) But I now have an automated way to set up the rather complex database schema. And not just that, but I can also run it against an existing database and it will analyze every table and fix anything that is not right. This includes modifying create statements on table columns that are not formed correctly, adding missing table columns, as well as adding completely missing tables.
This brings us the the key point of my recent efforts. Maintainability. This is what I learned when I tried to put the old software behind more than one site. The basic problem is that I would make a fix to one installation, but then that fix would not get propagated to the other sites. So they quickly fell out of sync with each other, and then each one had to be maintained as it's own independent entity. As they say in the biz: this doesn't scale.
So the new mantra is centralization. And the database creation/updater program I wrote yesterday is the first part of that. If I need to make a change to the database now - say, I realize that the user table needs another column to store a contact phone number of users - I create that new column in the program I wrote yesterday, and then I run that program across *all* installations of the software. This will keep everything in sync. Building tools to do what you previously did by hand allows you to scale.
Next up is constructing a similar tool to keep the code in sync across installations. The goal is to make changes in one place (say, on the test server on my development machine,) and then when things are running correctly I want to be able to run one script, and have all the changes to both the database structure and the code itself be replicated across all installations of the software. In other words, as a one person business, I'm trying to make myself scale.