Does anybody have a Jekyll or other #SSG site with client-side search powered by Lunr.js?
I'd like to borrow your search.json or whatever to experiment with a search thing.
I pushed up the tutorial for writing a "Hello World" app for Dropserver:
It covers the things that make a Dropserver app different (in particular users and migrations). It also prepares you for real world dev by showing you how to debug.
You need ds-dev 0.6 for this:
Docs on ds-dev here:
I would really appreciate it if people could try to go through the tutorial and point out any shortcomings.
Boosts appreciated! 🙏
Whew almost 2 months since the last release but I just tagged Dropserver 0.6:
Lots of work here on improving the developer experience for app devs, so ds-dev has changed a lot, while ds-host is in the same just-functional state.
I don't have the time to push up the tutorial that should accompany this release, but I'll try to do that tomorrow.
Screenshot of new ds-dev UI below:
It's kind of remarkable how much simpler, implementation-wise, serverside software is compared to clientside. And how far that simplicity goes.
For me I've got little more than nginx running atop Apache, and started by systemd. Also an SSH server, but I have that same shell available on my laptop.
Really goes to show the primary challenge in computing is to get them to communicate effectively with us! Though yes, servers do tend to overuse jargon...
After writing the app development tutorial I realized that ds-dev (a sort of dev-tools for a dropserver app) had some problematic rough edges.
Spent the last couple of weeks fixing bugs and redoing the UI.
Much better now! The goal is for ds-dev to help developers understand the Dropserver system by providing a lens into the system. Not there yet but but that's the goal.
Next up: add docs page on ds-dev usage, then push everything up and tag Dropserver v0.6.0.
"The purpose of this list is to track and compare tunneling solutions. This is primarily targeted toward self-hosters and developers who want to do things like exposing a local webserver via a public domain name, with automatic HTTPS, even if behind a NAT or other restricted network."
Found via comment on HN for this post:
I think this is the right approach to bypass the networking challenges for self-hosting. But privacy should be considered.
For ref here is the missing section: (which renders fine in Github)
So now I have no confidence that the rest of the posts are rendered correctly.
Do I need to go through one by one and check every bit of content? And do that after every Hugo update?
Do I need to create unit tests for my freaking blog?
😖 👎 👎 👎 👎 👎
I griped about the Hugo #SSG lately. In particular that it's not stable and has broken my site builds a couple of times.
Lately it's been working well, or so I thought!
I was looking back at an old post and realized there is a whole section missing!
In "What it's Like to View a SpaceX Falcon Heavy Launch" I describe different phases of the launch and landings in numbered lists.
Welp, steps 7-9 are missing in the Hugo-generated HTML, even though it's still in the md.
Huh, Facebook has apparently lost users globally for the first time in its history.
🍾 🎉 🎊
Why I'm leaving iOS development to go fully web after 12 years https://rosano.hmm.garden/01fmeehzvr3n9q0rkrnf7y2d5c
I think SSGs might be complex to use because they try to be too simplistic at original conception: "just run a script over a bunch of markdwon files in a directory structure".
Sounds good at first, right?
But that design fails to offer a clean path to doing non-trivial things.
So new capabilities are added with layers of config and finicky naming conventions, such that the simple thing is now quite confusing.
Result is a complex, opaque, sometimes baffling task to set up an SSG for a site.
For fans of weirdo Soviet aircraft (cc @tsturm ) here’s the Bella-1. It’s sort of a boat/hovercraft/VTOL/ground-effect plane thing that looks like it fell out of the Thunderbirds Supermarionation show.
It appears to not have a Wikipedia page?
The main reason I really like it:
I can leverage my already acquired knowledge of Vue js to generate static sites. So instead of learning a whole new thing (Hugo), I learn a relatively simple thing, and I can still do advanced stuff using Vue as if it were a dynamic frontend.
Result is still a 100% JS free generated site.
It's lacking some features for now, so far I'm happy with it.
Some quick thoughts on SSGs from my experience:
Currently I use Hugo to generate my site. I was hopeful it was the definitive SSG but I don't think that anymore:
- Perpetual unstable state. They never seem to want to get to 1.0, so any update can break my site (and has multiple times).
- Very complex config. Too many options and possible outcomes (combined with different versions that change how these work!) Result is it's like learning an entirely new programming paradigm and API. 😩
It's been fun finally writing a tutorial to teach developers how to create a Dropserver app. After so many iterations and dead-ends I feel like I'm approaching something usable.
There will of course be many more iterations, and the API as it stands is lacking to say the least, but the outline of it all is starting to form.
Not publishing yet because there are bugs that prevent the tutorial from working, and I may do low-hanging-fruit tweaks to the API beforehand.
"Caddy automatically staples OCSP for all relevant certificates. It will refresh the staple about halfway through its validity period. If the next status is Revoked, Caddy will replace the certificate right away."
Tangent: this puts into perspective all that Dropserver will eventually have to handle. Intimidating.
The good news is that Caddy is also written in Go with a permissive license, so I should hopefully be able to leverage their excellent work.