Live data from Hacker News

Blog with Markdown and Git, and degrade gracefully through time

brandur.org

91–100 of 182 posts

Re: Blog with Markdown and Git, and degrade gracefully through time

#91
post #34

Earlier quoted context omitted.

I have a similar setup for my blog and I'm using Netlify for both CI and hosting (free). It's been great! GitHub Actions could probably work well for you if you already have decent hosting.

Any particular guide or set of docs you recommend for that? I've heard a lot of good things about Netlify as far as hosting, and I've been wanting to set up a blog; seems like as good a time as ever to start learning.

Netlify is great! Just go to their site, sign in, drag your files to their upload window and boom! You have a site.

When you feel you want more, you can link a git repo and point a domain name at it. When you update the repo, it automagically updates the site.

It's my goto for all new projects.

There is great documentation at every step.

Re: Blog with Markdown and Git, and degrade gracefully through time

#92
post #91
post #34

Earlier quoted context omitted.

Any particular guide or set of docs you recommend for that? I've heard a lot of good things about Netlify as far as hosting, and I've been wanting to set up a blog; seems like as good a time as ever to start learning.

Netlify is great! Just go to their site, sign in, drag your files to their upload window and boom! You have a site. When you feel you want more, you can link a git repo and point a domain name at it. When you update the repo, it automagically updates the site. It's my goto for all new projects. There is great documentation at every step.

The easy git repo is what I was hoping for, that's awesome. Ty for the comment, I'll check it out.

Re: Blog with Markdown and Git, and degrade gracefully through time

#93
This reminds me once more of a piece of the puzzle which we're still missing. Markdown + git is great, but leaving your blog up on Github is just another central point of failure; Github feels like a fact of nature right now, but it's just a website at end of day.

Most broadly, it's called content-centric networking. Bittorrent is a piece of that puzzle, but too static, with no obvious way to connect disparate hashes together into a single entity. IPFS and Secure Scuttlebutt are groping in the right direction.

There was a project called gittorrent which, as you might guess, was trying to be 'bittorrent for git'. It never really went anywhere, the crew at https://radicle.xyz are looking to revive it and I wish them the best of luck.

What I want is a single handle, such that, if there are still copies of the data I'm looking for, out there on the network, I can retrieve them with that handle. And also, any forks, extensions, and so on, of that root data, with some tools to try and reconcile them, even though that may not always be possible.

That would be really powerful. It would made information more durable and resilient, and has the potential to change the way we interact with it. Like I find typos in documents sometimes, it would be nice to be able to generate a patch, sign it so it has a provenance, and release it out into the world.

When I browse old blogs which still exist, I routinely hit links to other blogs, video, and the like, which are just gone. Sometimes Wayback Machine helps, often it doesn't. This problem can't be fixed completely, when data is gone, it's gone, but we could do a lot more to mitigate it than what we're doing now.

Re: Blog with Markdown and Git, and degrade gracefully through time

#94
post #82

Some 15 years ago or so I made a PHP script that took a Word document, saved in XML format, and turned into a static HTML page as part of my blog. It would rely on the paragraph style, turning "Header 1" into etc, as well as extract images and such. Lately I've been seriously thinking of reimplementing that, as I just can't seem to find a decent static site generator. They all seem to require a bunch of plugins and c…

> I just can't seem to find a decent static site generator. Maybe you and I have very different ideas of what is required to write a blog, but it sounds like you should be able to use Hugo + the theme of your choice and just go with it. It's /very/ easy, and posts are all written in Markdown.

Thanks for the input. For me a bare-bones blog needs to support simple-to-use images, that is auto-resizing images with link to full etc without a ton of hoopla, syntax highlighter for code and some tex-ish thing for math.

From what I can see Hugo does seem to have a lot of that these days, so I'll try that.

One immediate issue is the highlighter not supporting my language at work (Delphi/Pascal) but I assume it being Pygments-compatible means I should be able to add that without much fuss.

Re: Blog with Markdown and Git, and degrade gracefully through time

#95
post #15
post #8

I used to have my blog source on GitHub, but then it turned out I didn't want my half-finished works-in-progress public. To use a private repository would rather defeat the point; using a private repo and a public fork is inviting confusion. Now I just use a private repo on my own server, cloned to my dev machine. Does anyone have a usable solution for that problem?

I have a branch and remote called "publish", and a branch and remote called "draft". I suppose if I ever accidentally pushed the draft branch to the publish remote, I'd just delete the branch from the remote.

You could set up an integration to automatically reject a branch called 'draft', if you really cared to.

Edit: this is easy, in fact: you make a copy of your 'publish' branch on the publishing site, call it 'draft', and then protect it.

Re: Blog with Markdown and Git, and degrade gracefully through time

#96
post #90

"or fun, I tried “de-archiving” an old colleague’s blog from The Wayback Machine. Getting the first few pages was easy, but getting the whole thing, and with quality/precision, was very hard." Any good tool to extract a website from archive.org?

https://github.com/hartator/wayback-machine-downloader

(I discuss it on my https://www.gwern.net/Search tutorial and use it every once in while eg to make my mirror of 'Climb Mount Improbable' https://www.gwern.net/docs/genetics/selection/www.mountimpro... or 'Hard Truths From Soft Cats' https://www.gwern.net/images/hardtruthsfromsoftcats.tumblr.c... )

Re: Blog with Markdown and Git, and degrade gracefully through time

#97
post #35
post #31

This is how the Oil blog is made: it's markdown in git, and it renders fine in Github. I use a bunch of old Unix tools that will be around forever to make it look nice: http://www.oilshell.org/site.html The toolchain has changed significantly in 4+ years. It started as literally a shell script invoking Gruber's original markdown.pl. Then I switched to CommonMark, etc. But the core data hasn't "rotted" at all, which i…

> The toolchain has changed significantly in 4+ years. It started as literally a shell script invoking Gruber's original markdown.pl. Then I switched to CommonMark, etc. Wouldn't switching formats like that break peoples pages? That's one concern I have with using markdown for a site like this. For anything non-trivial, you either end up using HTML (in which case, what's the point) or some dielect-specific feature.

CommonMark solves that problem! It's a precise standard for Markdown that multiple implementations are converging on (Pandoc, etc.)

CommonMark is a Useful, High-Quality Project http://www.oilshell.org/blog/2018/02/14.html

At the bottom of this article I note one incompatibility I encountered with the reference CommonMark vs. markdown.pl. But I just fixed those and have been using it for 3 years, and it's been great.

----

The key point is to have a diversity of implementations, so you don't get locked into one, which may go away in 10-20 years. In 10-20 years, I'm very confident that there will be CommonMark renderers available.

(Even apart from the fact that the reference cmark implementation I use is extremely compact C with no dependencies. C will outlive Perl -- the Lindy effect at work! http://www.oilshell.org/blog/2021/01/philosophy-design.html#... )

Re: Blog with Markdown and Git, and degrade gracefully through time

#98
post #46
post #12

I started my blog about python/django ( https://simpleisbetterthancomplex.com ) using Jekyll and hosting on Github Pages and it was pretty good to get started because back then I wasn't sure if I would keep it up or not. After a year or so I migrated to a 5 USD droplet on Digital Ocean (back then GH Pages didn't offer https for custom domains) and integrated with Github webhooks to automate the deployment when pushin…

There was a company on here the other day talking about their product, built on top of Docker. I wish I'd bookmarked it. Their secret sauce is, effectively, partial evaluation in Docker images. They run the code to detect if any of the changes in a layer have side effects that require that layer to be rebuilt (which invariably causes every layer after to be rebuilt) I mention this because if I'm editing a single page…

Are you referring to LayerCI, possibly?

Re: Blog with Markdown and Git, and degrade gracefully through time

#99
post #56
post #22

Earlier quoted context omitted.

Is it slow to regenerate a single post even with Jekyll’s ‘—incremental’ mode?

yes because of a bad design decision I made to create a custom "related posts", which is a code that searches all my markdowns to pick the best pages and add to the current page. so even with `--incremental` it take quite some time to regenerate

I wouldn't call that a bad design decision if all it needs is a `if Jekyll.env == "production"` :)

Re: Blog with Markdown and Git, and degrade gracefully through time

#100
post #8

I used to have my blog source on GitHub, but then it turned out I didn't want my half-finished works-in-progress public. To use a private repository would rather defeat the point; using a private repo and a public fork is inviting confusion. Now I just use a private repo on my own server, cloned to my dev machine. Does anyone have a usable solution for that problem?

Using git submodules might work, but it's not very convinient in my experience. I'm now thinking about having a GitHub Action in my private repo that pushes all public posts into a separate public repository automatically
Post reply on HN