71–80 of 111 posts
Is there a web-based editor that can be used together with these static site generators? This editor should be small, self-contained and secure and could be located in a separate access-restricted area of the site.
There is no lack of technical choices when it comes to starting a blog. I can start five blogs in the next 30 minutes, each one on a different platform/infrastructure. What I do lack is something interesting to write about, in a consistent manner. I have been writing code for a long time. I did build some interesting stuff. I'm currently working on a startup that does use some blog-worthy tech: any attempt ends up wi…
Is there a web-based editor that can be used together with these static site generators? This editor should be small, self-contained and secure and could be located in a separate access-restricted area of the site.
Is there a web-based editor that can be used together with these static site generators? This editor should be small, self-contained and secure and could be located in a separate access-restricted area of the site.
I believe that GitLab pages offers something similar that also supports Hugo, but I opted to use GitHub+Jekyll as I personally find it significantly easier to custom-build a website than with Hugo (I really struggled with on some basic stuff, e.g. I had a lot of blank pages at dir roots (e.g. /something/goes/here would have blank pages at something/ and something/goes/ etc)). Hugo feels over-complicated to me.
There is no lack of technical choices when it comes to starting a blog. I can start five blogs in the next 30 minutes, each one on a different platform/infrastructure. What I do lack is something interesting to write about, in a consistent manner. I have been writing code for a long time. I did build some interesting stuff. I'm currently working on a startup that does use some blog-worthy tech: any attempt ends up wi…
Or maybe there's a decision I'm making: I'll write up how I'm thinking about it, where I am so far, and publish that. Often I get good feedback on these posts that makes me think about the problem differently.
I try to notice when I get ideas that would make good posts and write them down. Then, in the evening, I'll sit down, look over the ideas, and see if there's anything I feel like writing about.
There is no lack of technical choices when it comes to starting a blog. I can start five blogs in the next 30 minutes, each one on a different platform/infrastructure. What I do lack is something interesting to write about, in a consistent manner. I have been writing code for a long time. I did build some interesting stuff. I'm currently working on a startup that does use some blog-worthy tech: any attempt ends up wi…
[in my opinion] Don't write to be read. Write for you, write because you enjoy the process and the exposition helps you process and crystallise a concept. Write because you are interested and engaged.
Earlier quoted context omitted.
[in my opinion] Don't write to be read. Write for you, write because you enjoy the process and the exposition helps you process and crystallise a concept. Write because you are interested and engaged.
But then why blog? Why not just journal in a notebook or on your "notes" app and be done?
There is no lack of technical choices when it comes to starting a blog. I can start five blogs in the next 30 minutes, each one on a different platform/infrastructure. What I do lack is something interesting to write about, in a consistent manner. I have been writing code for a long time. I did build some interesting stuff. I'm currently working on a startup that does use some blog-worthy tech: any attempt ends up wi…
Earlier quoted context omitted.
I feel like x.example.com is preferred over example.com/x because it is simpler to move the files around (when you want the same app/bundle of static files to be y.example.com). Browsers by default will make into x.example.com/foo/bar.html when served from x.example.com, but it won't make it into example.com/x/foo/bar.html when served from example.com/x/; something else has to make sure the URLs are correct. The opti…
Reverse proxies do pass the host header which is all you need.
Are Hugo really substantially better than say pelican or Nikola or all the other 'established' SSG?
From experience, I say that installing Python or Ruby static site generators (Hyde and Jekyll specifically I have in mind) starts out markedly harder, and tends to get steadily harder over time, particularly if you don’t ride the upgrade treadmill¹, whereas the likes of Hugo (Go) and Zola (Rust) are a single binary that you just download and run, and it’ll continue to work forever, and when you switch computers you can just copy or download the binary again and it’ll still work.
This difference concretely saved substantial quantities of time for redoing Fastmail’s website last year in Zola: once it genuinely was just “download Zola 0.8 from such-and-such a location and run `zola serve`”, a few people that would have given up on setting up a Jekyll or Pelican or similar environment, and instead gone with a longer “try modifying it, deploy it and see what happens” or “ask someone else to do it” approach, instead did just download the single binary and use it, because it genuinely did Just Work™.
If it’s hard (here probably meaning “takes longer than five minutes of effort”) to get an editing environment going for your blog or website or whatever, you will abandon your website sooner or later, for a cause that you wouldn’t if you were using one where it was easy.
So I say: prefer a single-binary for your occasionally-updated website, so that it’s your fault when you abandon it, rather than the SSG’s!
___
¹ For example: I used Hyde for the previous iteration of my personal website, and last time I tried to spin up a fresh build environment for it, I genuinely failed—I knew what I was doing, but a couple of packages in there would no longer build. Admittedly Hyde is abandoned and you’re not likely to have quite such trouble on an actively-maintained project, but still: treadmills, and processes that you can’t be confident in.