• 作成:
  • 更新:

ブログを作りました

ブログを作る理由

  • 月並みな話だが, アウトプットをしないと成長が鈍るからである
  • 数カ月前の記憶を消失することがよくあるのでメモを取っておきたい
  • 思考を文章化することによりストレスが減少するかもしれない
  • 自分にとって価値のないと思う情報でも, 他の人にとってはそうではないこともある

なぜQiitaではダメなのか

Qiitaはきわめて便利なサイトであるし, 私も記事を投稿したことはあるし, よくコメントなどはする.

なぜこれをそのまま使わないか

Qiitaを使いたい理由

  • 優れたmarkdownで投稿できる
  • コメントシステム完備
  • pull requsetが送れる
  • アカウントシステムが統合されているのでコミュニケーションが取れる
  • tagシステムにより読んでもらえる可能性が増える
  • わざわざ自分でセットアップする必要がない
  • 枯れている

Qiitaを使いたくない理由

  • Qiitaには技術の記事以外は投稿できないので, それ以外を書くにはやはり自前のサイトが必要
  • 自分のドメインを半分もてあましている
  • デザインなどを細かくカスタマイズできない
  • Qiitaに管理されることになる
  • 自分のサイトの全てを自分で管理したいという独占欲
  • 趣味

なぜ今までブログを作らなかったか

私は数年間ブログを作らずTwitterへの書き込みですべてを済ませていた.

他の人にブログを書くことを勧められたことも数回あったが, 私は自分の書き込みをまとまった形で公開することに恐怖していた.

昔はてなダイアリーに日記があったがそれもずっと放置していて最近削除してしまった.

それらは以下の理由によるもので現在はそれらは解消した.

書くことがなかった

単純に書くことが無かった.

しかし, 大学のレポートを転用したり, ソフトウェアのセットアップで詰まった点をメモしたり, 障害のことについて書いたり, 割と内容があることに気が付いた.

これまでは全てTwitterで適当に済ましていたから気が付かなかったのだ.

また, いつもツイートしているような内容をまとめて書いておけば, 思考が整理されて二度と同じツイートをしなくなるかもしれない.

なので, このブログには~/Documentsに書き溜めた内容や, 脳内記憶を適当に取り出して書いていきたい.

プライドが高すぎた

私は非常にプライドが非常に高く, 自分が低レベルだと感じるような記事の公開はしたくなかった.

本当はこんな記事を公開することも恐れている.

これは, 私の昔からの習性で小学校の時から完成度が低いと感じた学校の課題の作文を提出しなかったりして, よく親や先生に怒られていた.

つまり, 私は自分の文章力が低いことがバレるのが嫌だったのである.

また, 技術的な文章を書いて公開するのは絶対に嫌だった. 何故ならばいつも私は自分の間違いを後になって気がつくからである.

1ヶ月前に書いた文章の根本的な間違いに気が付くこともしょっちゅうである.

これではブログを書いても, 1週間後には根本的な間違いに気が付き, 恥を感じ続ける事は不可避である.

また, 単純にTwitterやブログでの周りの人技術力を恐れており, 自分の技術力の低さを恥じていた.

つまり, 私は自分の技術力が低いことがバレるのが嫌だったのである.

しかし, それでは私の成長速度は遅いものになるだろう. 完璧主義者の成長が低いことはよく言われる.

プライドが高く, 文章力が低く, 技術力が低く, 自虐癖があること, それは仕方がないことして, それを公開していくことで少しは解消させていきたい.

ブログシステムを決められなかった

ブログを書くからには, ブログのインフラやシステムはこちらで管理したかった.

だから, はてなブログやライブドアブログは使いたくなかった.

しかし, 自前で設置できるブログシステムで有名なWordPressは脆弱性の宝庫として恐怖の対象だった.

他のシステム(tdiary)もあまりパッとせず, 決め手となるシステムがなかった.

なので, ブログを書こうと思っても, そのためにまずブログシステムを自作しなければいけないと考えていて, 一年前ほどからPandocYesodを組み合わせたブログシステムを作ろうとか, それとも静的にPandocで変換するシステムを作ろうかとか構想していたが, なかなか時間と技術力がなく実行に移せずにいた.

しかし, この間名前は聞いていたHakyllが, 私の考えていたシステム要件をすべて満たしていると Hakyll, stack, Travis CI, Github でブログを管理するを読んで知り, 衝撃を受けさっそくこれでブログを書いてみることにした. 静的サイトなら脆弱性が存在する可能性も少ない.

私の構想がすべて無意味になってしまったのは残念だが, これでブログを書き始めることが出来て幸いである.

というわけで衝動的にブログを作成することにした.

Hakyllによるブログの作成

私は主にHakyllでブログを作る(実践編) - Wake up! Good night*を参考にした.

Hakyllでのブログ作成情報なんてネット上にはありふれているので, 体系的な情報を書く必要はないだろう. なので, このサイトで行ったことをあまり整理せず書いていく.

セットアップ

stack new blog-ncaq-net hakyll-templateで雛形を作り, デフォルトの設定を削除してカスタマイズしていく.

今はstackにtemplatesが用意されているので, stack newした時点でサンプルが用意されている.

未だにstackがresolver: lts-5.18になっていたため, 普通にstackageで検索してもパッケージが出てこないことに注意する. ltsを指定しよう.

urlを短くする

各記事のurlは単純に2016-10-11のように日付だけを書くことにした. 不精な私が1日に2つも記事を書くことはないだろうし, 書いたとしてもその時だけurlを崩せば十分だろう. ファイル名からurlは自動生成されるのだから, urlには柔軟性がある.

特異なところはHakyllのurlでは普通postsなどのprefixがついて記事のurlがつくところが, このブログではいきなり記事のurlが来るようになっている.

実際のこのブログでも各記事のmarkdownファイルはentryディレクトリ以下に置いてあるのだが, それはurlからは取り除かれている.

また拡張子.htmlもなくなっている. urlをとにかく短くしたいという思想の表れである.

実現方法はディレクトリ作ってその中にindex.htmlを作成してwebサーバに参照してもらうだけであり, 具体的な方法は公式ドキュメントの Clean URLs with Hakyll | The Perpetual Amateur に書いてある.

追記: 最大の失敗でした

これは後から考えると最大の失敗でした.

不精な私が1日に2つも記事を書くことはないだろうし,

まずこれが全くの間違いで日記のようにこのサイトが使われるとは限りませんでした. よって今では時間も含めたURLにしています.

URLには連番の数値だけを使うべきで日付のデータはyamlメタデータに入れるべきでした.

個別記事はentryディレクトリ以下に見えるようにURLを設計すべきでした. 後から記事一覧ページをトップページ以外に置きたい時に階層構造が崩れてしまいます.

サイトのURL設計を変更しました - ncaq

ハイフンをスラッシュに変換

実際のファイルのディレクトリを深くして2016/10/17.mdのようにするのは面倒臭いが, urlでスラッシュ以外の区切りを使うのは気持ち悪い. なのでファイルはentry/2016-10-21.mdのように置き, urlは2016/10/21/のようになるように変更した.

みたいにハイフンをスラッシュに変更していたら, 普通にハイフンとして読み込まれるべきファイルのURLまでスラッシュにしてしまった.

あくまでハイフンを変換するのはentryのものだけであることに注意する.

dateの自動補完

メタデータにdateをいちいち書くのは面倒臭いし, ファイル名にある情報をもう一度書くのは情報が重複して美しくない.

dateFieldのソースコードを読むと, 本来何もせずともparseTimeMによってファイル名からdateは自動補完されるように見えるが, [ERROR] Missing field $date$ in context for item entry/2016-10-11.mdというエラーが出て非常に悩んだ.

数時間悩んでもよくわからなかったので, 日時のフォーマットなどを無視してファイル名から日だけを取り出すという荒業で解決させた. 私だけに影響する関数なので私がファイル名をちゃんと守れば実用上の問題はない. とはいえ少し気持ちが悪い.

Pandocの設定編集

sectionが好きなのでhtml5で出力されるように設定した.

残念ながら読む場所が違うのかpandoc_title_blockは使えないようなのでおとなしくyamlでタイトルを書くことにします.

Pandocの目次追加

Pandocによる目次がデフォルト状態だと追加されなかったので, writerStandalone = TruewriterTemplate = unlines ["$toc$", "$body$"]を設定することで埋め込むように設定.

feed配信

atomを使うかrss2.0を使うか少し悩んだが, atomの方が少しシンプルだったので, そちらを使うことにした.

特にidが必須というのがわかりやすい.

feedのidにindex.htmlがついてしまう問題を修正

withUrlsはhref属性などurlっぽい文字列のみしか対策しないため, entryContexturlフィールドごと index.htmlを抹消する.

field "url" (fmap (maybe empty (cleanIndex . toUrl)) . getRoute . itemIdentifier)

もともとあったサイトをブログに取り込む

私はもともと単純な自己紹介を書いたwebページを公開していたのだが, それもまた単なる静的webサイトであるし, わざわざ分けている必要もない.

もともと, そのサイトはwww.ncaq.netとして公開し, ブログはblog.ncaq.netとして公開するつもりだった.

しかし, サブドメインを分ける主なメリットは, オリジンを分けてcookieの名前空間を衝突しないようにすることである. 静的サイトがそのメリットを受けることは少ない.

これを機にHakyllに統一してしまい, もともとのwebサイトはaboutページとして保存することにした.

gitリポジトリを別々に管理していたため, リポジトリを統合する方法を検索して実行した. merge--allow-unrelated-historiesオプションをつければ, 整合性の無さを無視してmerge出来るようだ.

2016-10-17T09:07:44 ncaq@nonohara/pts/0(0) ~/Desktop/www.ncaq.net
% git remote add blog https://github.com/ncaq/blog.ncaq.net.git
2016-10-17T09:10:02 ncaq@nonohara/pts/0(1) ~/Desktop/www.ncaq.net
% git fetch blog
From https://github.com/ncaq/blog.ncaq.net
 * [new branch]      master     -> blog/master
2016-10-17T09:10:05 ncaq@nonohara/pts/0(0) ~/Desktop/www.ncaq.net
% git merge blog/master --allow-unrelated-histories
Auto-merging index.html
CONFLICT (add/add): Merge conflict in index.html
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Automatic merge failed; fix conflicts and then commit the result.

indent

動的webフレームワークではインデントは諦めて, むしろパフォーマンスのために圧縮するhtmlですが, 静的サイトなので出力されたhtmlを目で確認することもそこそこあるので, html tidyによってインデントを美しく整えておくことにした.

もちろんPandocはデフォルトでhtmlをインデントしてくれるのですが, テンプレート埋め込みが絡むと整合性が取れません.

またfeedはatomで配信しているのですが, こちらはブラウザのinspectorでデバッグするのも難しく, 目で構造を確認するしかないので, このxmlをインデントしておくことは特に重要である.

unixFilterを使うとちょっとした警告でも失敗扱いになるので, 自前でreadProcessWithExitCodeすることで対処.

HTML

Haskellでブログを作った | eliza.link

を参考にしてshakespeareを使おうかと思いましたが, shakespeare templateの強みは型安全変数による安全な変数の埋め込みなので, 変数が静的に解決されるHakyllではあまり意味がないので, やめておきました.

CSS

Clay, CSS Preprocessorをせっかくなので使ってみることにしました. SCSSから移行する意味は全くもって無いのですが, せっかくなので新しい言語を使ってみたい.

CSSを型付けする意味はあまりないと予想して, 実際あまりありませんでしたが, タイプミスやわけのわからん記法を使うのを防止する意味はあった.

デザインは趣味なのでCSS frameworkとか使わずに適当に組んだ.

JS

TypeScriptでJavaScriptファイルを1ファイル作ってそれで済ますことにした.

Google Analyticsとhighlight.jsを設定した.

デプロイ

GitHub Pagesで公開している方が多いみたいですが, GitHub Pagesの仕様とすりあわせるのが面倒なので, 自宅サーバにデプロイすることにしました.

せっかくdeployコマンドもあることですし, どうせ記事公開前には1回ぐらいはローカルで確認するので, Travis ciの自動デプロイはあまり魅力的ではありません.

これから何を書いていくか

  • 魅力的なソフトウェアの紹介
  • ソフトウェアの設定
  • プログラム断片
  • これまで書いたことの焼き直し
  • 愚痴
  • ポエム

などを予定しています.