Since we don't have many time to creating our own blog, we'll use GitHub Issues for sharing our thoughts & experiments (like this ones).
Why use GitHub Issues?
First of all, it fits with my workflow (and support markdown!). The idea behind this was when I create this issue. It makes me think like: Hey, why don't we just write our thought/blog post here?. It has great UI, (ehm) free hosting (images), and I use GitHub everyday.
Built-in SEO Support
Implementing some SEO stuffs is so wasting time, although has a good ROI. This is how I search "undefined is not a function" on Google:
The link was placed on page 1.
Built-in social-meta support
People loves sharing great content, because sharing is caring. This is how I share my
Cache response headers issue to Twitter:
The format was:
Title • Issues #n • orgs/repo
So for this context, it should be looks like this:
Hello World • Issues #1 • evilfactorylabs/blog
Hey, the Issues term seems like a "magazine" style.
Built-in discussion functionality
And... Emoji!
Also we can close the issues whenever we want (to prevent the comment).
Built-in categories
We want our post managed well so people can discover it easily. Luckily, GitHub give us a "Label" for that! Also, maybe we can use "Projects" to link the post to the "mentioned" project.
Cool!
Built-in related posts
We can "mention" related post as easy as use a hashtag-ish continued with issue number. Don't worry if you don't remember the number, GitHub gives us the autocomplete feature:
And yes, we can mention someone too.
API support!
Need to list our posts? Use the API! This is an example for my cuddly-doodle projects. Here is the output:
[
{
"url": "https://api.github.com/repos/108kb/cuddly-doodle/issues/3",
"repository_url": "https://api.github.com/repos/108kb/cuddly-doodle",
"labels_url": "https://api.github.com/repos/108kb/cuddly-doodle/issues/3/labels{/name}",
"comments_url": "https://api.github.com/repos/108kb/cuddly-doodle/issues/3/comments",
"events_url": "https://api.github.com/repos/108kb/cuddly-doodle/issues/3/events",
"html_url": "https://github.com/108kb/cuddly-doodle/issues/3",
"id": 435536113,
"node_id": "MDU6SXNzdWU0MzU1MzYxMTM=",
"number": 3,
"title": "Cache response headers",
"user": {
...truncated
"login": "108kb",
"site_admin": false
...truncated
},
"labels": [
{
"id": 1328652793,
"node_id": "MDU6TGFiZWwxMzI4NjUyNzkz",
"url": "https://api.github.com/repos/108kb/cuddly-doodle/labels/good%20first%20issue",
...truncated
}
],
"state": "open",
"locked": false,
"assignee": null,
"assignees": [
],
"milestone": null,
"comments": 0,
"created_at": "2019-04-21T18:42:37Z",
"updated_at": "2019-04-21T19:24:25Z",
"closed_at": null,
"author_association": "OWNER",
"body": "Caching is great in order to deliver fast response. From application-level, we are only do caching to prevent puppeteers doing something same again and again. In short, if user request `?108kb`, it should give a response from the cache if the requested artifacts are stored in cache store.\r\n\r\nIn DNS-level, we can tell the browser to \"cache our response\" so the browser _\"doesn't request the same thing again and again\"_ by giving a response headers with `Cache-Control` ..truncated"
},
{
"url": "https://api.github.com/repos/108kb/cuddly-doodle/issues/2",
"repository_url": "https://api.github.com/repos/108kb/cuddly-doodle",
...truncated
}
]
issues.map(issue => issue.title) anyone?
Disadvantages
Maybe GitHub issues is not a suitable place for blogging. This is why
No Iframe support
Yes. But we can just link it, right?
No "Export" support
We cannot export our content here. But since GitHub provides us an API, basically we can just "manually" export it from the API.
No powerful analytics support
Although GitHub has an insight section (including traffics!), but we don't know from where/when our readers comes. Who cares.
No full control
Since this is not a self-hosted services, we don't have a (full) power to control it.
This is looks funny and risky. But we love tinkering. This was our first post of our tinkering with GitHub platform––how to use GitHub in our daily basis by using it as a blog platform via Issues––and I'm excited for this.
Some notable "features" I don't mention early:
Guest post
Revision history
Subscribe (via RSS & Atom). Or via Watching
Draft Mode (By using additional Labels, but your revision history are publicly available)
Since we don't have many time to creating our own blog, we'll use GitHub Issues for sharing our thoughts & experiments (like this ones).
Why use GitHub Issues?
First of all, it fits with my workflow (and support markdown!). The idea behind this was when I create this issue. It makes me think like: Hey, why don't we just write our thought/blog post here?. It has great UI, (ehm) free hosting (images), and I use GitHub everyday.
Built-in SEO Support
Implementing some SEO stuffs is so wasting time, although has a good ROI. This is how I search "undefined is not a function" on Google:
The link was placed on page 1.
Built-in social-meta support
People loves sharing great content, because sharing is caring. This is how I share my Cache response headers issue to Twitter:
The format was:
So for this context, it should be looks like this:
Hey, the Issues term seems like a "magazine" style.
Built-in discussion functionality
And... Emoji!
Also we can close the issues whenever we want (to prevent the comment).
Built-in categories
We want our post managed well so people can discover it easily. Luckily, GitHub give us a "Label" for that! Also, maybe we can use "Projects" to link the post to the "mentioned" project.
Cool!
Built-in related posts
We can "mention" related post as easy as use a hashtag-ish continued with issue number. Don't worry if you don't remember the number, GitHub gives us the autocomplete feature:
And yes, we can mention someone too.
API support!
Need to list our posts? Use the API! This is an example for my cuddly-doodle projects. Here is the output:
issues.map(issue => issue.title)
anyone?Disadvantages
Maybe GitHub issues is not a suitable place for blogging. This is why
No Iframe support
Yes. But we can just link it, right?
No "Export" support
We cannot export our content here. But since GitHub provides us an API, basically we can just "manually" export it from the API.
No powerful analytics support
Although GitHub has an insight section (including traffics!), but we don't know from where/when our readers comes. Who cares.
No full control
Since this is not a self-hosted services, we don't have a (full) power to control it.
This is looks funny and risky. But we love tinkering. This was our first post of our tinkering with GitHub platform––how to use GitHub in our daily basis by using it as a blog platform via Issues––and I'm excited for this.
Some notable "features" I don't mention early:
Thanks for stopping by.