badrihippo/badrihippo.thekambattu.rocks
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Add posts from my earlier blog and remove the dummy one

Browse source 
The posts had to be mildly modified to work here:

- Field names were changed to lowercase in the metadata
- Times were set to 00:00, because Haunt's parser required times
  and I had no clue what the actual times were supposed to be
- The Markdown poem had to be changed from using <del/> tags to
  ~strikethrough with a tilde~, because raw HTML blocks aren't
  supported by the default guile-commonmark parser. Strikethrough
  with tilde's isn't either, but I ended up creating my own fork
  which [does have the option](https://git.disroot.org/badrihippo/guile-strickenmark).
- The "Category" field had to be remove because the parsen was
  complaining about it :(

You can see the source for the original posts, if GitHub is
still around by the time you read this (or you have access to
their Arctic Vault or evil LLM memory or whatever) at the repo:

https://github.com/badrihippo/badrihippo.github.io
This commit is contained in:
Badri Sunderarajan 2024-02-20 18:01:19 +05:30
parent f2f5960dc9
commit bac208e5eb
Signed by: badrihippo
GPG key ID: 9F594532AD60DE03
6 changed files with 427 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
posts/bookmarks.md Normal file
View file

@ -0,0 +1,35 @@
title: Bookmarks
date: 2015-05-17 00:00
tags: code-poetry, books, reading, internet, wordplay
summary: The Bookworm / uses Bookmarks / to mark Pages / in a Book...
---
The Bookworm
uses Bookmarks
to mark Pages
in a Book,
The Firefox
uses Bookmarks
to mark Pages
on the Net.
The Dog-Ear
is a Bookmark
that leaves a Mark
on the book Page,
The Facebook
can share Bookmarks
to the Pages
that you set.
The Silverfish
makes Tooth-Marks
on the Page-Ends
of a Book,
The Myself,
I've not figured out
what a Bookmark
is, yet.

44
posts/gitspeaks.md Normal file
View file

@ -0,0 +1,44 @@
title: git speaks
date: 2015-05-06 00:00
tags: git, python, code-poetry
summary: All your files / are up to date / You've shown no activity / as of late
---
`git status`
All your files
are up to date
You’ve shown no activity
as of late
`git checkout -b`
Getting your act together, I see.
I know you’re in a rush,
but all the same
it would be a good idea
to specify the branch name.
`git checkout -b \`
`all-bugs-eradication`
All? You may be enthusiastic,
but isn’t that too much ambition?
`./test.py`
Testing…done. But why!
Not a single bug found—
that’s too good to be true!
Oh, wait, there’s no code either.
Lots of work ahead for you!
`git checkout master`
Are you planning to work faster?
Or leave it to someone else
in the spirit of collaboration?
`git branch -d \
all-bugs-eradication`
It’s the latter, I see.
`Ctrl+D`

7
posts/hello.md
View file

@ -1,7 +0,0 @@
title: First post!
date: 2018-03-13 18:00
tags: hello
summary: hello!
---
Hello, world!

48
posts/markdown.md Normal file
View file

@ -0,0 +1,48 @@
title: Markdown
date: 2015-05-11 00:00
tags: markdown, markup, code-poetry
summary: I still remember when / I first heard about it. / `.md`—Markdown. / Huh? What is it?
---
I still remember when
I first heard about it.
`.md`—Markdown.
Huh? What is it?
It's a language specially
for formatting text
into a few styles like: *italic*,
**bold**, `code`, and ~cancelled text~.
A whole new language
just for that simple task?
And why can't I just use
HTML, may I ask?
Too complex for newcomers
to learn quickly, is it?
A WYSIWYG editor
could help on their visit!
Developers don't have time to
learn yet another new lang
And normal bloggers? Well—
they just don't know that they can.
Neither simple for newcomers
who don't want to code,
nor feature-full for devs
with a lot on their load
But now I understand.
For simple docs, `.htm`
is too cumbersome to write.
WYSIWYGs don't give results,
if complex, without a fight.
But `.md`—Markdown
—it seems just right!
---
***Fun fact from 2024:** When migrating this file to my new [Haunt](https://haunt.dthompson.us)-powered blog, I realised that strikethrough set was not in fact supported, so to make this poem work I ended up creating [my own fork of the parser](https://git.disroot.org/badrihippo/guile-strickenmark)!*

205
posts/pelican-on-a-branch.md Normal file
View file

@ -0,0 +1,205 @@
title: Pelican on a Branch
date: 2015-05-17 00:00
tags: code, python, pelican, git, github, github-pages, blog
summary: After trying various services like Blogger and Wordpress, I finally settled on GitHub Pages.
---
After trying various services like Blogger and Wordpress, I finally settled
on GitHub Pages. (The [Source Code]({filename}sourcecode.md) post earlier
explains why). I tried installing Jekyll, but there was some problem with my
Ruby installation (partly because I was on
[Puppy Linux](http://puppylinux.org)),so I started searching for alternatives.
I came across [this post](http://www.pydanny.com/choosing-a-new-python-based-blog-engine.html)
about [Pelican](http://getpelican.com), a Python-powered Jekyll-like page
generator.
Here, I'm going to tell you how to set up *this* blog, using Pelican and
GitHub Pages. I'll skip the many bits that I did and undid later, and instead
tell you what I would do *now* if I wanted to get to my current setup.
## GitHub Pages
This blog is a **user** site, http://badrihippo.github.io, as opposed to a
**project** site. In User sites, what is served is the contents of the main
`master` branch of the repo. For project sites, the site is hosted on the
`gh-pages` branch, because `master` will probably be used for the main project.
(I'm assuming you're familiar with using git branches.)
So, after creating the repo, as instructed on the
[Help Page](https://help.github.com/articles/user-organization-and-project-pages/),
I can use `git clone` to clone it into my local folder, then add the new posts
I want and send them back up with `git push origin master`.
But I'm not creating the pages myself - I'm using Pelican to generate the pages!
So I'll have to set up the source files outside, and tell Pelican to store the
generated pages in my git repo folder.
## Meet the Pelican
Pelican is a pages content generator, similar to Jekyll but written in Python.
Since I already had Python and virtualenv installed, all I had to do to get
Pelican was `pip install markdown pelican`. I needed to install `markdown` as
well because I was planning to write my source posts in [markdown](http://daringfireball.net/projects/markdown/).
To install a Pelican website, you `cd` to that folder and do `pelican-quickstart`
(note: single command).
This is an interactive command, which asks you for various info to generate your
initial config file, like this:
$ cd /home/hippo/Desktop
$ mkdir pelitest
$ cd pelitest
$ pelican-quickstart
Welcome to pelican-quickstart v3.5.0.
This script will help you create a new Pelican-based website.
Please answer the following questions so this script can generate the files
needed by Pelican.
> Where do you want to create your new web site? [.]
> What will be the title of this web site? My Pelican Blog
> Who will be the author of this web site? Badri Sunderarajan
> What will be the default language of this web site? [en]
> Do you want to specify a URL prefix? e.g., http://example.com (Y/n) y
> What is your URL prefix? (see above example; no trailing slash) http://badrihippo.github.io
> Do you want to enable article pagination? (Y/n) y
> How many articles per page do you want? [10]
> Do you want to generate a Fabfile/Makefile to automate generation and publishing? (Y/n)
> Do you want an auto-reload & simpleHTTP script to assist with theme and site development? (Y/n)
> Do you want to upload your website using FTP? (y/N) n
> Do you want to upload your website using SSH? (y/N) n
> Do you want to upload your website using Dropbox? (y/N) n
> Do you want to upload your website using S3? (y/N) n
> Do you want to upload your website using Rackspace Cloud Files? (y/N) n
> Do you want to upload your website using GitHub Pages? (y/N) y
> Is this your personal page (username.github.io)? (y/N) y
Done. Your new project is available at /home/hippo/Desktop/pelitest
Of course, normally I wouldn't create the site on my desktop; this is just for
the example.
The above command will create `pelicanconf.py`, `publishconf.py`, and two folders:
`content` and `output`. You write posts in the `.htm`, `.rst` or `.md` formats,
giving the metadata on top. Here's an example `.md` post:
Title: Hello World
Date: 2015-05-17
Category: Test
Tags: hello-word, pelican, test
Hello, **Pelican!**
I see you are rendering my first post :)
Save this as `helloworld.md` in the `./content` folder, and run `pelican content`
to generate the HTML into the `output` folder, which you can then view in your
browser.
![Example Pelican site]({filename}/images/pelisite.png)
One tip I got from the Pelican docs is to `cd` to the `output` folder and run
`python -m SimpleHTTPServer`. This serves the folder contents on `localhost:8000`,
allowing your browser to load stylesheets and other media in addition to the main
`.htm` page. If you select the option during setup, you can also run the
`./develop_server.sh` script to run a development server.
There are two config files, as I mentioned earlier: `pelicanconf.py` is the default
one used by Pelican, and `publishconf.py` is where you can put additional settings
to use in production. To use the publish settings, you do
`pelican content -s publishconf.py`.
In the config files, you can do various things like add links and change themes,
but I won't got into those details—you can see the [Pelican docs](http://docs.getpelican.com)
for all the info.
The setting *I'm* interested in right now is `OUTPUT_PATH`, which tells Pelican
which folder to store the rendered website in. The default is the `output` folder,
but I want it to go into my GitHub Pages repo. Setting
`OUTPUT = '.../badrihippo.github.io` does the trick.
## Set up the Branches
While the final HTML content goes to `master` on the `badrihippo.github.io` repo,
I also wanted to have my other Pelican sources and config files available synced.
So I decided to have *two* branches on `badrihippo.github.io`: a `pelican` branch
for the source files, and a `master` branch for the final output. After a bit of
experimeting, and thanks to [this gist](https://gist.github.com/chrisjacob/833223)
by [chrisjacob](https://github.com/chrisjacob), I finally settled on this directory
structure:
badrihippo.github.io/
├── master/
│ └── (contents of master branch)
└── pelican/
└── (contents of pelican branch)
The `master` branch was already on GitHub, so I created the folder and added the
repo as origin, and pulled changes:
$ cd badrihippo.github.io # Note: this is a new, empty folder
$ mkdir master
$ git init # initialie new git repo
$ git remote add origin https://github.com/badrihippo/badrihippo.github.io.git
$ git pull # pull changes from repo before any modifications
The `pelican` folder already existed, but there was no repo yet. So after moving
the folder to the correct place (and deleting the `output` directory), I did:
$ git init # initialise new git repo
$ git checkout -b pelican # Create new 'pelican' branch
$ git add . # Add & commit files
$ git commit
$ git remote add origin https://github.com/badrihippo/badrihippo.github.io.git
$ git push origin pelican # Push changes to GitHub
The last command creates a new branch called `pelican` on the GitHub repo, with
the contents of the local `pelican` directory/branch inside.
One more change to do: open `publishconf.py` and comment out the
`DELETE_OUTPUT_DIRECTORY = True` line (or change it to `False`). That settings
tells Pelican to delete and re-create the output directory every time pages are
generated, which is not what we want. Because it'll delete our git repo files as
well.
Also set `OUTPUT_PATH = '../master/'` so your changes get saved into the `master`
directory
Now, you have two folders, each containing a different branch of the Github repo.
For safety, you can delete the `master` branch from the `pelcian` folder's repo so
you don't commit to it by mistake:
$ cd pelican
$ git branch -d master
$ git branch # Check branch status
* pelican
Good: the branch is deleted.
## New Post
Now, here's my procedure when writing a new post:
* Write the post in markdown and save it in `pelican/content`
* `git add` and `git commit` the new post (again from within the `pelican` folder)
* Run `pelican content -s publishconf.py`. This generated the website pages in the
`master` directory.
* `git push origin pelican` to upload the source changes
* `cd ../master`, `git commit -a` and `git push origin master` to push the published
website change.
## Afterthought
Having set this up, I'm wondering: do I really *need* to have two branches? There's
nothing wrong with letting website visitors to see the source folder, if they know
how to do it: it's all there on GitHub anyway. Maybe I should just tell Pelican to
save content in the main directory itself (instead of a new `output` directory), and
have everything—config files, `content` folder, templates, and output—all in one branch.
The setup I described in the article, which I'm using right now, may make sense from a
git perspective, because the source is tracked separately from generated content (which
actually needn't be tracked at all). But it would be more convenient to be able to post
with just one commit.
And I doubt my blog will need much version control, anyway.

95
posts/sourcecode.md Normal file
View file

@ -0,0 +1,95 @@
title: Source Code
date: 2015-05-11 00:00
tags: markdown, blogs, markup, html, wysiwyg
summary: I've tried out various blogging sites, but nothing is as good as writing the source code directly!
---
I've tried out various blogging sites. Wordpress, Blogger, Tumblr. They each
have different sets of features. Blogger is a simple blog. Wordpress allows you
to add more customization, pages, and widgets. Tumblr is more like a microblog,
with your posts coming in Twitter-style streams as well as personal, themable
blog websites. There's also Weebly, About.me, Typepad, and so on.
They all have nice features, and nice editors. Some are focused on simplicity;
some on customiability. But the reason I've finally switched to GitHub Pages is
that it allows me to edit the pages from source.
Yes, the WYSIWYG editors do have an "Edit HTML" option. Some services let you
customize the templates and stylesheets. But if there's one small markup change
I want to make, I sometimes have to go all over the place to find out how to do
it in the GUI.
With GitHub Pages, the program that generates the website is right here, on my
computer. I can write posts as simple `.md` files, but if I want to I can also
change the HTML, or go even deeper and tweak how the program itself processes
the input. The interface is simple if I want it to be, but I can also go as
deep as I want.
Lots of people are using frameworks and CMSes now. The age of editing raw code
is coming to and end, it seems. But still, sometimes one *does* feel like going
down and giving the HTML a tweak.
One problem--and feature-- of WYSIWYG editors is that they manipulate the code.
Even after you go to the HTML view and make an edit, they'll usually tweak and
restructure that edit to fit their methodr. This can be useful, having the
editor "clean up" after you. But, as you go through many edits, the WYSIWYG
sometimes ends up making the code unnecessarily messy and convoluted. Suppose,
for example, I had selected some text to be bold. And then, later, I changed my
mind. But now, to unselect it, I'm not sure whether I need to un-bold the
surrounding spaces as well, or not. I find myself constantly switching to the
Source view to make sure that there isn't a redundant `<b>&nbsp;</b>` sitting
in the middle of the text.
Then, there is also the problem of paragraphing. Am I actually writing in a
proper `<p>`, or is it actually just random text with a liberal scattering of
`<br>`s? Some editors even throw a couple of `<div>`s into the mix.
I know, it looks okay in the end. But at the back, there's a lot of unnecessary
markup that I don't like leaving behind. I don't know if it'll come in the way
some time in the future.
For example, I have a collection of emails with text `Ctrl+V`ed from different
websites. Recently, I was trying to concatenate them into a single HTML file,
which I could then convert to ePub to use on my eReader. But when I started, I
found that not only has the text been copied from the website, but so has the
markup: complete with all its extra formatting and styling! From emails, it's
even worse than from web pages, because elements can't even be given classes
from elsewhere. Each element needs to be have its styles embedded into its tag,
giving you something like this:
<div>
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">A&nbsp;</span>
<b style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">villanelle</b>
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">&nbsp;(also known as&nbsp;</span>
<i style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">villanesque</i>
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">)</span>
<sup style="line-height:1em;color:rgb(0,0,0);font-family:sans-serif"><a href="http://en.wikipedia.org/wiki/Villanelle#cite_note-Kaster_1903_p._279-1" style="text-decoration:none;color:rgb(11,0,128);background-image:none;white-space:nowrap" target="_blank">[1]</a></sup>
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">&nbsp;is a nineteen-line&nbsp;</span>
<a href="http://en.wikipedia.org/wiki/Poetry" title="Poetry" style="text-decoration:none;color:rgb(11,0,128);background-image:none;font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px" target="_blank">poetic</a>
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">&nbsp;form consisting of five&nbsp;</span>
<a href="http://en.wikipedia.org/wiki/Tercet" title="Tercet" style="text-decoration:none;color:rgb(11,0,128);background-image:none;font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px" target="_blank">tercets</a>
&nbsp;(three line stanza)&nbsp;
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">&nbsp;followed by a&nbsp;</span>
<a href="http://en.wikipedia.org/wiki/Quatrain" title="Quatrain" style="text-decoration:none;color:rgb(11,0,128);background-image:none;font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px" target="_blank">quatrain</a>
&nbsp;(four line stanza)
<span style="color:rgb(0,0,0);font-family:sans-serif;font-size:12.727272033691406px;line-height:19.200000762939453px">.</span>
<br>
</div>
Ahem. How about just
<p>A villanelle (also known as villanesque) is a nineteen-line poetic form
consisting of five tercets (three line stanza) followed by a quatrain
(four line stanza).</p>
Much simpler, and the extra styling isn't even required in the email! The
line-breaks are mine, by the way.
Anyway, so for now I have my blog posts in markdown, and if I ever need to
convert them to another format, I can just re-generate from `.md`s instead of
having to hand-edit the styling to make it fit. After a lot of searching, I've
finally found a blogging platform that works for me.
For now, at least.
Hopefully.