🌐
Downloads Videos Blog About Series πŸ—ΊοΈ
❓
πŸ”‘
/tcms:
Follow along as we build the tools for building the business!

tCMS current state and plan going forward πŸ”— 1642782163  

🏷️ blog 🏷️ perl

The consistent theme I've been driving at with tCMS development is to transform as much of the program out of code into data. The last thing I've done in this vein was to create parent-child relationships between posts (series), and to allow posts to embed other posts within themselves. The next thing I'm interested in doing is to move the entire page structure into data as well. Recently working with javascript component-based frameworks has given me the core inspiration behind what I ought to do.

Any given page can be seen as little more than a concatenation of components in a particular order. Components themselves can be seen in the same way, simplifying rendering them to be a matter of recursive descent to build an iterator you feed to the renderer. How do I implement this with the current system?

Every post needs to support an array of components. This will necessitate a re-thinking of how the post interface itself works. I should probably have some "preview" mechanism to show an idea how the post should work after you frankenstein it together.

This will enable me to do the most significant performance improvement I can do (static renders) incredibly easily. As a page render will be little more than a SELECT CONCAT statement over a table of pre-rendered component instances for the data. To make updates cheap, we need but check the relevant post timestamps to see if anything in the recursive descent needs a re-render.

As of this writing, a render of the most complicated page of any tCMS install is taking 21ms. This should bring that time down to 2-3ms. It will also enable me to implement the feature which will turn tCMS into a best-of-breed content publishing framework. Which is to automatically syndicate each page we render to multiple CDNs and transparently redirect to them in a load-balancing fashion.

From there I see little more that needs to be done other than improving the posting interface and adding userland features. I still want all of that, but believe technical excellence comes first.


2 Major paths to take advantage of CDNs πŸ”— 1634143208  

🏷️ blog

When considering a switch from traditional web hosting to something like S3 (or ipfs) plus web workers or equivalent stateless compute resources (GKP, Lambda, etc) you need to re-think how you deploy your applications. Many of the complex backends that you are used to are simply not feasible to have on the live web with this model. That said, it's not hard to write CGIs in a stateless fashion, and many only keep their state client side or in a database, which is a model that works just fine here.

That said, most of your backend probably doesn't even need to be public. It could easily be behind a firewall and just push updates to your staging and production buckets and workers. In fact, I'm considering this model for tCMS right now! There's no good reason why I need the login functionality public, at least for post editors -- all of them could run a local instance and push out updates supposing I had an rqlite backend data storage sitting in a bucket as a read only node, with the editors behind firewalls doing the RAFT thing.

From there the question is whether to do static generation or load sqlite with sql.js and do everything client-side (or a combination of both). Static versus dynamic web pages is well trod ground at this point so do what feels best for your application. Personally I will probably go with static generation as I prefer to run as little as possible on the client machine to get the best user experience.

The big drawback to using IAAS is (historically) higher TCO and a lack of good abstractions making it easy to self-host under such models. Things like OpenStack make self-hosting possible, but prohibitively expensive and it feels like swatting flies with an elephant gun for most webmasters.

Even containerization and it's orchestration tools require a lot of extra thought and code versus the traditional LAMP approach. What's really needed to swim in both pools easily are some abstractions to make it easy for you to:

  1. Treat local directories like they are S3 buckets (and/or ipfs tokens) so you have flexibility for storage deployment
  2. Treat local httpds like they're a web worker API you deploy to, rather than vhosts
Implementing such tools would effectively allow any shared host to transition their existing infrastructure into such products, albeit without automatic scaling on their end. That said, if multiple servers are supported in a sort of federated model (again, likely mediated thru rqlite), that would largely ameliorate such concerns.

For S3, s3proxy is exactly what we are looking for. As to an imitation of web workers (or other "stateless" compute resources), that would be far more complex given there is no standardization across vendors.


tCMS September 2021 update πŸ”— 1631660780  

🏷️ video 🏷️ blog
I finally got time to do some work on tCMS! Here's the new goodies all the users of tCMS can expect going forward.

tCMS September 2021 update πŸ”— 1631660718  

🏷️ video 🏷️ blog
I finally got time to do some work on tCMS! Here's the new goodies all the users of tCMS can expect going forward.

Troglodyne year 1 in review πŸ”— 1629315907  

🏷️ blog

About halfway into my year of doing this solo entrepeneur thing, I realized a lot of my work on tCMS was not done out of a desire to outdo wordpress, ghost or any of the other CMSes which are a part of this cambrian explosion of software most of us have lived through.

Instead, it was actually done for the same reason carpenters build their own house. By god, I'm gonna do it the way I want it for once! What you get is indeed quite satisfying. Though when you zoom out and think of the long term perspective, does it actually mean as much as I feel it does? After all, generations of my ancestors built their own homes and barns. Those now living in them (if they weren't razed) now have no idea what went into it or why it was built that way.

It will be the same with software and the brands and businesses built around them. Like with houses, the only ones that will remain standing will largely be a function of what particular families, towns, firms and industries managed to stick around. As such the "0 code" grifters, for all their embarrassing obviousness are essentially right when they focus almost exclusively on building their customer pipelines.

Now that I'm out in the world of general contracting, I actually see this everywhere. The biggest and most successful businesses tend to run lean and hard on their creaking and ancient facilities be they real or virtual. Even obsolete software, hardware and real estate work just fine, and usually with great margins now that they've long outlived their depreciation curve.

What I'm trying to say here is yet another reason to not get too wrapped up in your tech. So what if it's a mountain of garbage? Plenty of money to be made mining that heap! Using a dead language? Necromancy tends to have pretty high margins! Lots of people make their livings with run-down trucks and dilapidated real estate.

Which is ultimately why I'm sticking with my little CMS. Sure it's using Perl, and probably an evolutionary dead end as far as CMSes go. But it's mine, and at the end of the day you have to live like nobody else to live like nobody else. As long as it delivers where I need it to, I'm not gonna sweat about the future. Having seen several people build successful business with worse tech up close and personal, I'm confident that I can actually build a business atop this little house for my data.

I'm quite blessed to have had good advice, prudent planning, discipline and a patient business partner which has allowed me the ability to putter around until I figured out how all this works. I'm grateful for the clients I've had up to this point and their ongoing custom. I think this next year I'll be able to finally add in a software offering of my own.

I'm also quite happy with how well I've done keeping up with my open source projects. Now that it looks like I've actually got a credible hourly rate I'm beginning to wonder if setting up a charitable OSS foundation (or getting sponsorship from something existing) so I can use this pro-bono time as a writeoff will make sense in the future. I'll have to look into this, and hopefully can get a good article and video on the subject in the future.


Link Unfurling with HTML::SocialMeta πŸ”— 1609954054  

🏷️ video 🏷️ programming 🏷️ blog
I did a deep dive into how pasted links turn into previews in chat and social media applications and was pleasantly surprised to find CPAN had the solution for me. I found a couple of gotchas you might want to know about if you don't want to figure this out the hard way.

tCMS on CentOS 7 with Apache πŸ”— 1609367187  

🏷️ video
I learned a few things deploying tCMS via proxy to a CentOS 7 box with Apache. Here's a breakdown.

tCMS Retrospective: Houston.pm.org πŸ”— 1609273339  

🏷️ video 🏷️ blog
It took a bit of creative thinking to cram a site that wasn't my brainchild into muh box. Though thankfully it didn't require too much custom fitting and fixes to get the job done.

That said, it could have gone a lot smoother. Discussing that and more!

tCMS Retrospective: Phase 1 Completion πŸ”— 1608164452  

🏷️ video 🏷️ blog
tCMS is more or less doing what we wanted it to. What's more, it fit into the time we allocated for getting it done! Today we looked back at what we did and where we want to go next with Troglodyne.

tCMS update: ACLs, Sitemaps, RSS and more πŸ”— 1607802643  

🏷️ video
Wherein we get closer to finishing the prototype

tCMS Early Progress Report 2 πŸ”— 1607756053  

🏷️ video
Theming, Logins, Dynamic Routes and more!

tCMS Migration Retrospective: Teodesian.net πŸ”— 1607727832  

🏷️ video
You'll probably need the *heavy flamer* to deal with the heresy on the site we just migrated. Regardless, this shows off some of the power that we've built into tCMS and some of what's to come!

tCMS: Early Progress Report πŸ”— 1607727401  

🏷️ video
An early video on tCMS as we developed it.

Amazing how things come together when you have matured as a programmer and have the time to execute on a good plan. There's a lesson in that, I think.

tCMS Migration Retrospective: Troglodyne.net πŸ”— 1607717978  

🏷️ video 🏷️ blog
Now that the prototype has gone to production twice, we mull on what lessons we've learned and where to go next with it.

tCMS Updates πŸ”— 1607717775  


Follow along as we build the tools for building the business!

25 most recent posts older than 1607717775
Prev Size:
Jump to:
POTZREBIE
© 2020-2021 Troglodyne LLC