Blogging

Background (TL;DR)

While setting up the new version of Staticman for my demo GitLab pages, I’ve read developers’ documentations, setup guide and some community blog posts so as to come up with my own guide. It’s originated and inspired from a variety of sources, and refined according to hours of testing. Consequently, despite the original intention to keep things simple, I’ve finally come up with a post with over a thousand words.

To pass my ideas in this post to visitors, it’s better that they have an overview of the contents before actually looking into the details. Therefore, a table of contents is nice-to-have feature for this blog.

Update: I suggest reading a newer tutorial.

To keep focused on the technical setup, please refer to the introduction of this series for the reasons of choosing Staticman and GitLab.

Goal

To set up unauthenticated commenting system on GitLab pages.

This post aims at providing a walkthrough to the GitLab repo setup. If you want to host your own Staticman API instance, you may refer to the next post in this series.

I put some “why” questions here so as to keep focus on the technical setup of the GitLab repo and the optional Staticman API server.

Why static blogs instead of dynamic ones?

• quicker loading time
• better reliability (can handle more request)
• no database needed
• greater control on content, styles and layout

Why static comments?

• allow feedback from visitors
• site owner owns the comment locally (unlike WordPress, Facebook, Disqus, etc)
  • no remote database needed, so no need to worry server errors from third-party commenting services.
  • greater control over the rendering of the comments (allow additional features such as Markdown syntax, and $\KaTeX$ support)
  • more accessible since static comments are incorporated as HTML elements into the post. No JavaScript is required to retrieve the comments, contrary to most third-party commenting services.

Before Staticman’s deployment, another commenting system called Pecosys was already available. However, it’s less convenient to handle visitor’s requests as emails.

Fixed issue #142

Two weeks ago, Google Webmasters complained about the broken urls in this blog’s Tags page. This was reported by Joakim Vivas as issue #142 half a year ago. Pascal had submitted pull request #165 to fix this. However, he self-closed his PR.

Since the last commit by Michael Romero, Beautiful Hugo’s owner, was five months ago, it seems that he has abandonned his project. Therefore, I used Kaushal Modi’s solution to fix this at commit ff536782.

Background

Despite my experience in Vim, the multi-cursor functionality in Sublime Text 3 has seduced my to change my editor.

Unlike Vim, a nonempty new line at the end of Sublime Text 3 file buffer causes the file to end without a newline character. In fact, it’s a POSIX standard to include a newline character at the EOL (end of file). (c.f. No Newline at End of File)

Problem

Unaware of the above POSIX standard and Sublime Text 3 convention, I have edited many lines of code in the repository for this blog and the one for my custom Beautiful Hugo. These edited files were almost everywhere in these repositories, and they polluted their remote counterparts on GitLab .

Motivation

One loves adding colors to his/her life by adding stunning photos to his/her social media profile. However, due to various constraints, such as weather, budget and time, it’s possible that the photos taken look dark and somber.

Despite a suboptimal choice of camera angle, a right tool enables you to take the best out of the photo. Let’s go GIMPing.

Why image optimization?

To save loading .

My old way

ImageMagick provides a great CLI utility to convert and compress images for any purposes. However, to -crop images, I have to specify the numbers in pixels. One certainly works much more efficiently with a GUI tool.

My new way

GIMP can do anything that Adobe Photoshop can do, even saving images for web. In the linked page to this powerful GIMP plugin tutorial, the link for the GNU/Linux binary file is broken.

Goal

To set up a reasonable content structure for my blog.

Before Hugo

In my old Octopress blog, images and posts were placed under source/images/posts and source/_posts folders respectively. They were so far apart that I needed to use copy and paste the URL’s so as to get them right. As the size of the blog grew, I could hardly retrieve an image without first listing the files in the post image folder. This significantly reduced the efficiency of blog writing. In my hometown, people take efficiency seriously.

Introduction

Hello World! This is my new GitLab page powered by Hugo. I’m setting up this blog to practise my math, foreign languages and IT skills.

Why Hugo?

My original goal is to set up a personal blog for posting math.

I used to work with Octopress, but resolving the dependencies and other technical issues had actually took much more time and effort than expected. As a result, I digressed a lot from my studies to look into those problems.