mr_tyler_durden@lemmy.worldtoSelfhosted@lemmy.world•Recommendations for self-hosting a blogEnglish
3·
1 year agoYeah, I’ve been paying $5 (or is it $10?) a month for my Ghost blog on a digital ocean droplet. It’s not worth it, my plan is to move to a static site generator (probably CloudFront -> S3 deployed via GitHub actions in a private repo) at some point. The features of Ghost don’t really matter to me and I hate maintaining the install/updating. Ghost feels like it’s moved more into “self-hosted substack”-territory which I have zero interest in, my blog posts are all public. Also, you can’t hack static files so security isn’t a worry with SSG which is super nice.
Not sure which SSG I’ll go with, when I was younger I would have written my own but now I’ll just pick something off the shelf that has nice themes lol.
This might be the most sane take in the this thread.
Yes, ideally it would all match up but I’ll reject PRs that want to rename a bunch of files/fields/properties/columns/etc because marketing/business want to call it something else. Also you have to pick your battles, sometimes it’s just not worth fighting it.
We have some things that were named badly on the backend a decade or more ago, in our API we name them correctly (example “qty” on the backed, “quantity” in the API). We will NEVER go back and change the old name, it’s not going to happen. It would take a massive effort for no real gain.
Also parts of our API are (semi-)publicly available and so we take that as an opportunity to rename certain things for “public consumption” because we call something different internally (with justification) but there is no good reason to make external people learn our internal lingo/concepts.
Lastly I’ve learned over the last 15+ years in the industry that just about every “black and white rule” is a bad one. You shouldn’t have a slavish devotion to a rule just because it is a “rule” that someone slapped down at some point. It’s like the REST purists who bitch and moan about “that endpoint isn’t RESTful”. Get out and write some real software with real business requirements then get back to me.
I’m not saying rules are bad and I believe heavily in the “Chesterton’s fence” concept but you also have to know when to break the rules instead of twisting yourself and your code into a pretzel to stay within the “letter of the rule”.