Skip to content

Instantly share code, notes, and snippets.

@vkz
Last active May 29, 2023 22:55
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save vkz/ea7cf2dac5ac6e2ef775cdd5dce869d5 to your computer and use it in GitHub Desktop.
Save vkz/ea7cf2dac5ac6e2ef775cdd5dce869d5 to your computer and use it in GitHub Desktop.
GitHoot: blogging distilled to a GitHub gist

GitHoot in a nutshell

Why blog with GitHoot

Or rather why blog with a gist. git.ht is a very simple and minimal service. One I created for myself, mostly with my needs and requirements in mind. When all said and done, git.ht is closest to a "blogging" platform1. Kind of. Idea is to minimize transactional costs of having an idea you want to put in writing or a bunch of technical notes, research or findings that you deem close enough to be shared and actually reaching your audience. Of which, of course, you may not even have any, yet. Bit of a chicken and egg problem. Until you start publishing, you won't have an audience; until you get your first readers your audience won't grow and you won't have that gratifying feedback loop that nudges you to write more. Finally, writing more means practice; practice makes you better; more people will read what you have to say; you'll capture and captivate the masses and level up to the influencer status or so I'm told. Is this accurate? Feels like I'm channeling @patio11 here, so it is only apt to quote him:

one of the reasons to have a blog is that it allows you to establish a reputation as an expert in your field. Having that reputation leads to all sorts of doors opening up for you

Patrick McKenzie 2, Blogging As Personal Marketing

Boy, oh boy, does that resonate now that I'm trying to market git.ht. I sure wish I started all those years ago. Writing software seems easy and fun in comparison.

treadmill

While we are on the topic it only seems fair to note that there is a difference between casually publishing something every now and again and maintaining ones presence, reputation, dare I say brand through writing. Despite perceived gung-ho attitude towards blogging, producing a coherent and thoughtful essay requires time and genuine effort. I assert it is a fulltime engagement that very much becomes a deliverable if you want to do it regularly and well. This is where git.ht shines - it simplifies the entire publishing pipeline so that you may focus on the content.

How to blog a gist

Anyway. git.ht is mostly about disseminating what you have i.e. publishing and sharing side of things. There's only so much cognitive energy you have. Treat it with care, spend frugally and wisely - pour into your content. That's where GitHub comes in. Writing and publishing something should require no more energy, ideally, than starting a new Github gist (or editing an old one). Here: https://gist.github.com/ when clicked, assuming you're logged into Github, you'll immediately start a new gist. Can't make it simpler than that.

feed

Now, if you name the gist's file hoot.md or hoot.org and make that gist public, git.ht will publish it. What does that mean? A few things.

  • your gist becomes a hoot i.e. a version of it will now be hosted under your git.ht subdomain e.g. https://vlad.git.ht/602a0e1fe234285e9ef7bda6bfbc9ba6;
  • this hosted version aka a hoot will:
    • render nicely with your readers' convenience in mind,
    • will incorporate meta tags necessary to get decent preview in social media,
    • image, title, description from your gist will make it into the above mentioned meta tags,
    • bottom of the page will also render your latest hoots to help your readers discover more of your writing,
    • top of the page links to the original gist, which has a comments section your readers can use - sweet;
  • all of your hoots become part of your Atom RSS feed;
  • reluctantly we also added a minimal timeline aka feed, mostly to help you grab older hoots for sharing and make them more accessible to people who may not even know what RSS is;
  • oh and hey, you can easily search and filter hoots courtesy of advanced Github search.

That's basically all there is to git.ht. Publishing something should be as hustle free as possible. If there is a whole process to follow to get your ideas or thoughts in front of your readers, only the most stubborn will persevere and keep at it. They may even arrive at a nice enough workflow to make the process nimble and mostly out of their way. I guess, that's part of the reason we have so many half-baked static site generators. Or, maybe it's a rite of passage for techincal bloggers. I dunno. I have a couple of "abandonware" quality generators I wrote that will never see the light of day.

Compare to this hoot right here. I literally just opened a new gist and started typing. Type type type, check Github preview. Drop an image, type some more, check preview. Change width= attribute of an image, add align="right", check preview. Iterate. Going for longform or want to avoid churning diffs or hide your thought process? Clone and Emacs away (insert smug lisp weenie face), git push when done. You can peek into raw source to confirm how simple it is - your run-of-the-mill markdown - nothing fancy.

There is tension between desire to control the process and just wanting to sit down and write something, have it reach other people. I guess that's why platforms like Medium and such exist. What I don't like about them is that they all reinvent everything and you're typically expected to use their authoring tools; they haven't figured out their monetization strategy so inevitably you become the product. git.ht dispenses with many of the problems by essentially being a minimal overlay over Github for authoring tools and storage and RSS for distribution with a few tiny features to accommodate present day expectations. With foundation this flexible even with a minimal featureset like ours, you still get more than anywhere else I'm aware of. You get version control, ability to edit locally and just do your tried and tested git push routine, etc etc.

git.ht will never be as flexible as hosting your own website, but it is near damn close. Topic for another time is ... git.ht was conceived and built with self-hosting in mind, but let's not dwell on that now. Also, every programming language under the sun has a library to parse XML: fetch the RSS feed we generate from your gists and do with your hoots what you will.

feed-rss

What will it hurt to try?

Give git.ht a try. Just claim a subdomain by authenticating with Github and you'll have a week or so to give it an honest try. Click through here to see how. If you never pay for it by subscribing, it'll eventually be "garbage collected" i.e. the subdomain will return to the pool of available. But if you pay subscription, even if later you cancel it, the subdomain remains yours forever linked to the Github id you used. That is, old links will never break, not as long as git.ht remains online. Let me repeat this, cause it matters. Even if you cancel and stop your subscription the subdomain and the state of your feed, both RSS and timeline, will remain unchanged. It'll remain yours, it'll remain online. We'll just stop fetching updates and new hoots. That's it.

Give us feedback

If you have an issue to report or a feature you think is missing, please raise an issue: https://github.com/fullmeta-dev/githoot-public

You can also tweet at us https://twitter.com/githoot aka @githoot

Why pay?

Do we save you time and hustle? I'm in my 40s with 3 kids and two businesses but I too want to write code, learn new things and share what I've learnt. I'd pay for git.ht: no ads, no silly features, no playing fast and loose with my data and timeline. Building git.ht I've accumulated enough material to write a book - most of it Github gists. It is now a matter of cleaning up and publishing them. Maybe I should turn them into a book ;)

Nough said - show me

Not a streamer, but maybe I ought to record myself hooting away. I just installed OBS so I might. Did you know you could embed videos on Github? Works in gists, too. Will embed here if I ever get to it or add an Youtube link or whatever. Stay tuned?

Coda

Did you know I'm running a (mostly) Clojure SWAT team in London at fullmeta.co.uk? We are always on the lookout for interesting contracts. We have two exceptional engineers available as I type these words. Now that git.ht is up, which you should go ahead and check out rigth now, I'll be going back to CTOing and contracting, which makes me available for hire, too. Get in touch directly or find us on LinkedIn. We aren't cheap, but we're very good. We can also perform competently in modern Java, ES6/TS, Go, C#, etc.

Any comments?

As always this hoot is nothing more than a GitHub gist. Please, use its respective comments section if you have something to say. Till next time.

Find me Twitter

Footnotes

  1. I feel like "blogging" is a bit of a misnomer with respect to the kind of content git.ht is best suited for, or perhaps the term has been corrupted somewhat if not hijacked from the golden age of blogging of the 1990-00s. "Essay" or a lab-journal entry maybe more apt designations here. Former implies longer-form with more thought and effort going into it, the latter consists of scribbles and notes as you research a domain or attack a problem both to have them on hand later, but also to structure your thoughts better. What do I know. In the end git.ht will be what you make of it.

  2. If you haven't followed and read Patrick McKenzie you probably should. I could fill this entire hoot with his quotes. Let me start you off. Head over to Twitter and search: @patio11 blogging

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment