evilfactorylabsarchive / blog

blog by evilfactory team
https://blog.evilfactory.id
Creative Commons Attribution Share Alike 4.0 International
5 stars 0 forks source link

Hello World #1

Open faultables opened 5 years ago

faultables commented 5 years ago

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:

Screen Shot 2019-04-22 at 02 16 37

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:

Screen Shot 2019-04-22 at 02 20 01

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!

Screen Shot 2019-04-22 at 02 24 16

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.

Screen Shot 2019-04-22 at 02 27 41

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:

Screen Shot 2019-04-22 at 02 29 09

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:

Thanks for stopping by.