ブログシステムをHexoにしました

ブログシステムをHexohexo.ioにしました。ブログデザインも新規で作成しました。ブログシステムはそのうちリプレースしたいなと常々思っていたのですが、なかなかこれといったものがなく時間が経ってしまいましたが、ついにリプレースすることができました。

以前のブログシステム

以前のブログシステムはOctopressを使っていました。このOctopress、いくつか問題点がありました。

動作が遅い

Markdownで書いてそれをhtmlに変換する仕組みなのですが、その速度が遅いです。
記事数が少ない場合はそれほど気にならなかったのですが、100記事くらいになってくると明らかに遅くなってきます。
現在では、プレビューモードで変換するのに10秒程度かかってしまい、気持ちよく記事が書けない状態でした。

メンテナンスされていない

2015年で開発が止まっています。新機能や改善もないですし、機能に問題がある場合も修正がされません。開発が止まっているものは使うべきではありません。今から使うのはやめたほうがいいでしょう。

なぜHexoにしたのか

Node.jsで書かれているから

HexoはNode.jsで書かれています。
最近はNode.jsを使うことが多いので、Node.jsで書かれているブログシステムを使いたかったのです。

静的サイトジェネレーターだから

ブログシステムには大きく分けて静的サイトジェネレーターとデータベースを使ったブログシステムがあります。Hexoは静的サイトジェネレーターと言われるシステムです。静的サイトジェネレーターはMarkdown等の形式で書かれたファイルをhtmlに変換するソフトウェアです。

静的サイトジェネレーターのメリットは表示速度が早い、セキュリティリスクがほとんどない、他のシステムに移行しやすいなどのメリットがあります。個人ブログであれば静的サイトジェネレーターがおすすめです。

人気のあるブログシステムだから

Node.jsで書かれていて人気のあるブログシステムはHexoとGatsby、あとは最近VuePressも人気が出てきているようです。
他にどんなソフトウェアがあるかはこちらで確認することができます。

人気のあるソフトウェアは開発が活発で便利な機能も多く、使いやすいことが多いです。

現在も開発が行われているから

Hexoは現在も開発が行われています。2019-10-14にバージョン4.0のリリースが行われました。

Hexo vs Gatsby vs VuePress

Node.js環境の静的サイトジェネレーターはHexo、Gatsby、VuePressの3つが人気です。GatsbyとVuePressは次の理由で採用しませんでした。

Gatsbyを採用しなかった理由

Gatsbyhexo.ioはReactベースの静的サイトジェネレーターです。Reactに慣れている人であればいいかもしれませんが、私がReactに詳しくないのもあり、Gatsbyは学習コストが高いという印象です。あえてその学習コストを払ってGatsbyを使うメリットが見当たらないので採用を見送りました。

VuePressを採用しなかった理由

VuePresshexo.ioがメジャーバージョンになったということもあり、VuePressも試してみました。情報が少なくまだまだ使いづらいというのが正直なところで、VuePressを使うメリットが見当たりませんでした。
ブログではなく、ドキュメントなどのシステムとして使うならありかもしれません。
一応、サンプルコードをGitHubにあげているので興味のある方は参考にしてみてください。

結論

特にこだわりがなくブログを楽に構築したいということであれば、Hexo一択ではないかと思います。最後にHexoを使うメリットについて説明します。

Hexoを使うメリット

ブログの基本機能が簡単に作成できる

Hexoでのブログ構築は5つのコマンドを実行するだけです。

1
2
3
4
5
$ npm install hexo-cli -g
$ hexo init blog
$ cd blog
$ npm install
$ hexo server

hexo server を実行後にhttp://localhost:4000 にアクセスするとブログが表示されます。

テーマの作成がしやすい

Hexoにはテーマ作成をサポートするツールが用意されています。
generator-hexo-themehexo.ioを使えば簡単にブログテーマの雛形を用意することができます。
ブログテーマは自作したのですが、その雛形はgenerator-hexo-themeで作成しました。

CI/CDも簡単

masterにマージしたら自動的にデプロイする設定を入れています。そのあたりも公式のマニュアルが用意してあり、手順にそって設定していくだけでCI/CD環境を作ることができます。私はGitHub Pagesを使っており、サーバー費用0円でブログを運営しています。コストパフォーマンスは最高ですね。

まとめ

Hexoは学習コストが低く、テーマ作成もわりと簡単にできるので楽にブログを作りたい人におすすめです。Node.js環境でブログを作りたいときは検討してみてはいかがでしょうか。

スピードの価値

開発をする上で最も大切にしなければいけないものはなんでしょうか。私はスピードだと思います。

開発はコストです。早く終わるということは、その分コストを削れます。コストを削ることができればその分が利益になります。ビジネスの目的である利益に貢献しているので、これはとても価値のあることです。

バスより飛行機が高いのも早く目的地に着くからですね。食洗機や洗濯機をお金を出して買うのも、家事の時間が短縮されるからです。
ブラウザは何を使っていますか?世界のブラウザのシェアNo1はGoogle Chromeです。Chromeが1番速いからみんな使っているのです。

速いということはそれだけで価値があるのです。

シンプルに実装する大切さ

私はシンプルに実装することをとても大切にしています。最も大切にしていると言っても過言ではありません。

プログラミングの経験が浅い人は、難解なコードを書いたり、短い行数でコードを書けることがかっこいいと考えているかもしれませんが、完全に間違っています。シンプルに実装することは実は難しいのです。プログラムというものは、すぐに複雑になってしまうからです。複雑でかっこいいコードを書こうという考えがそもそもの間違いです。

この記事を読んでいるみなさんは、今後は簡単でシンプルな必要最小限のコードを書くという意識でコードを書いてください。

私はNode.jsのコミッターがトラディショナルなfor文を使ったコードを書いていることを見たことがあります。そのコードは、これ以上ないくらいシンプルなコードでした。

現在のプログラムの多くは、今後も多くの変更が入ります。そうであれば、完璧に動くことよりもメンテナンスがしやすいことが大切です。後々、悪い影響を及ぼすコードは複雑で難解なコードです。シンプルで意図が明快なコードが問題を起こすことはありません。

一般的な技術を有したエンジニアであれば誰でも理解できるコードを書いてください。

テストカバレッジ100%を目指さない理由

結論

テストカバレッジ100%は目指さない

理由

以前、このようなツイートをしました。

テストカバレッジ100%に違和感を感じない人はもう少し勉強した方がいいですね。

テストカバレッジ100%を目指すとこのようになってしまいます。

さらにテストの問題も発生します。

テストカバレッジの問題については次の記事に詳しく書いてあります。

全てのコードにコメントを書くのは馬鹿げていると感じる人は多いでしょう。全てのコードにテストを書くということも同じように考えるとどうでしょう。何事も過ぎたるは及ばざるが如しです。

データベース固有の関数の使用を避けるべき理由

こんにちは、しょーやんです。

私はエンジニアとして12年目で、現在はエンジニアチームのリーダーとしてWebアプリケーションのシステムを開発しています。キャリアとしては、SIerで1年、ベンチャー企業で3年、300人程度の企業で5年、現在は6000人規模の会社でエンジニアとして働いています。

前提として、ここで話すことはアプリケーション設計に関する話しです。データベースの関数自体の使用を否定しているわけではありません。データベース固有の関数を使う前に少し考えてみましょうという話しです。まずは、データベース固有の関数を使うリスクについて説明します。

データベース固有の関数を使うリスク

データベースには固有の関数が用意されています。MySQLだとDATE_FORMATやNOW、SUMといったような関数です。これらを利用するのは便利ですが、安易な利用はおすすめしません。相応の理由がない限りは避けるべきです。理由は、データベース固有の関数を利用すると移植性が失われてしまうからです。

多くの人はデータベースを変更することはほとんどないだろうと考えます。本当にそうでしょうか。

例えば、開発環境ではSQLite、プロダクション環境ではMySQLを使うということは特段珍しいことではありません。
トランザクション境界を分離できないようなインテグレーションテストを実行するときはどうでしょうか。

ユーザーの情報を取得するAPIのインテグレーションテストがあるとします。このテストをクリアするためには、事前にユーザーのデータをデータベースに登録しておくことが必要です。そうでなければユーザーのデータを検証することができません。
テスト用のデータベースを共有で利用していた場合、一時的に作成されたテストデータが他のテストに影響するようになるでしょう。この問題は複数のテストが同時に実行されるようなCI環境になると顕著に現れます。解決策の1つとしてプロダクション環境と同じデータベースが含まれたイメージを作成するという手がありますが、複雑なイメージファイルを作成することは、なるべくなら避けたいところです。

データベースはドアノブである

ロバート・C・マーティンは著書「Clean Architecture」で、データベースはあくまで道具の1つであり、アーキテクチャの中心になるものではないと言っています。データベースは家のドアノブのようなものであり、アーキテクチャ的にはどうでもよいのです。ドアノブに家の設計を合わせることはしないでしょう。データベースがドアノブのようなものであれば、データベースに依存しないようにアプリケーションを実装するのは当然のことのように思えます。

RailsやSpringのような現在のフレームワークは、データベースを抽象化して扱えるような仕組みを提供しています。多くの場合、それはORMとして提供されており、利用するドライバーの設定を変更するだけでデータベースを変更することが可能です。

アプリケーション設計の側面から考えると、データベース固有の関数は避けるべきです。データベース固有の関数を利用する必要が場合は、基本的なCRUDで同じことができないかを検討しましょう。さもなければ、たった1つのデータベース固有の関数のせいでアプリケーションの移植性は失われてしまいます。

原則としてアプリケーション側で対応する

多くのアプリケーションは基本的なCRUDで構築することが可能です。少しの手間を省くためにデータベース固有の関数(例えばMySQLのREPLACE)を利用することはデメリットの方が大きくなる可能性があります。よく見られるアンチパターンはNOWの多様です。時刻はアプリケーション側で取得できます。アプリケーション側で対応できるものはアプリケーションの機能で対応しましょう。

データベース固有の機能に頼った方がいい場合

データベース固有の機能に頼った方がいい場合も存在します。例えば、位置情報を扱うような場合です。位置情報を扱う場合、PostgreSQLの拡張であるPostGISを利用した方が少ない労力で実装することができるでしょう。このように明確なアドバンテージがある場合はデータベース固有の機能を利用しない理由はありません。

12331