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

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

以前のブログシステム

以前のブログシステムは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を採用しなかった理由

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

VuePressを採用しなかった理由

VuePressがメジャーバージョンになったということもあり、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-themeを使えば簡単にブログテーマの雛形を用意することができます。
ブログテーマは自作したのですが、その雛形はgenerator-hexo-themeで作成しました。

CI/CDも簡単

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

まとめ

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

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

私はシンプルに実装することを最も大切にしています。これは単なる好みではなく、長期的なプロジェクトの成功に直結する重要な原則です。

シンプルさは難しい

プログラミングの経験が浅い人の中には、難解なコードや短い行数で書けることが「かっこいい」と考える人もいるかもしれません。
実は、シンプルに実装することは非常に難しいのです。プログラムは自然と複雑になっていく性質を持っているため、意図的にシンプルさを保つには、継続的な努力と判断力が必要です。

実例：Node.jsコミッターのコード

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

最新の機能や複雑な構文を使うことが必ずしも良いわけではありません。むしろ、一般的な技術を有したエンジニアであれば誰でも理解できるコードを書くことが、チーム全体の生産性を高めます。

メンテナンス性の重要性

現在のプログラムの多くは、今後も多くの変更が入ります。そうであれば、完璧に動くことよりも、メンテナンスがしやすいことが大切です。

後々、悪い影響を及ぼすコードは複雑で難解なコードです。シンプルで意図が明快なコードが問題を起こすことはありません。6ヶ月後の自分や、チームの他のメンバーがコードを読むとき、そのシンプルさが大きな助けになります。

実践への心がけ

この記事を読んでいるみなさんには、今後は簡単でシンプルな必要最小限のコードを書くという意識でコードを書いてほしいと思います。複雑さを避け、読みやすさを優先する。それが、長期的に見て最も価値のあるコードです。

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

テストカバレッジ100%を目指すことは、一見すると理想的な目標のように見えます。しかし、実際の開発現場では、100%のカバレッジを目指すことが必ずしも最適な選択とは限りません。

テストカバレッジ100%の落とし穴

テストカバレッジ100%を目指すと、以下のような問題が発生する可能性があります。

コストと時間の浪費

100%のカバレッジを達成するためには、テストが困難なコードや、実際にはほとんど実行されないエッジケースまでテストする必要があります。これらのテストを書くために費やす時間とコストは、得られる価値と比較して不釣り合いなことが多いです。

メンテナンスコストの増加

カバレッジを100%に保つためには、コードを変更するたびに、その変更に関連するすべてのテストも更新する必要があります。特に、実装の細部に依存したテストは、リファクタリングのたびに壊れやすく、メンテナンスコストが高くなります。

テストの質の低下

カバレッジの数値だけを追いかけると、意味のあるテストを書くよりも、カバレッジを上げるためのテストを書くことに意識が向いてしまいます。その結果、バグを発見できないテストや、将来の変更に対して脆弱なテストが増えてしまいます。

カバレッジの数値よりも大切なこと

テストカバレッジは、テストの質を測る指標の一つに過ぎません。カバレッジの数値よりも、以下のことを重視すべきです。

重要な機能のテスト

ユーザーに直接影響を与える重要な機能や、ビジネスロジックの核心部分は、しっかりとテストする必要があります。一方で、単純なgetter/setterや、フレームワークが提供する機能については、テストを書かなくても問題ない場合があります。

バグを発見できるテスト

テストの目的は、カバレッジを上げることではなく、バグを発見することです。実際にバグが発生しそうな箇所や、過去にバグが発生した箇所を重点的にテストすることが大切です。

リファクタリングを支えるテスト

テストは、コードを安全に変更するための支えとなります。リファクタリングを支えるテストを書くことで、コードの品質を保ちながら、柔軟に変更できるようになります。

現実的なカバレッジ目標

100%を目指すのではなく、プロジェクトの性質やチームの状況に応じて、現実的なカバレッジ目標を設定することが大切です。

一般的には、70〜80%のカバレッジがあれば十分とされています。ただし、これはあくまで目安であり、プロジェクトによって最適な数値は異なります。重要なのは、カバレッジの数値そのものではなく、テストが実際に価値を提供しているかです。

まとめ

テストカバレッジ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を利用した方が少ない労力で実装することができるでしょう。このように明確なアドバンテージがある場合はデータベース固有の機能を利用しない理由はありません。

手軽にスプラトゥーンをYouTubeで配信する

私はYouTubeやOPENREC.tvでよくスプラトゥーンの配信を視聴しているのですが、みているだけでなく自分もやってみたいと思ったのでYouTubeで配信をはじめてみました。この記事では、YouTubeでゲーム動画を配信する方法を紹介します。

配信の手順

配信の手順としては次の通りです。

  1. キャプチャボードを使ってゲームの動画と音声を外付けの記録媒体に保存
  2. 記録媒体に保存した動画をPCの編集ソフトを使って編集する（アフレコをしたり、不要な部分をカットしたり、音量の調整をする）
  3. 編集した動画をYouTubeにアップロードする

配信に必要な機材

  • キャプチャボード
    • ゲームの動画と音声をキャプチャするのに必要です
  • 記録媒体
    • USBメモリや外付けHDDなど。PCに保存する場合は不要です
  • PC
    • 動画の編集に必要です。私はMacBook Air(メモリは4GB)を使っています
  • マイク
    • 実況を録音するためのマイクです

キャプチャボードを用意する

ゲームの動画と音声を録画するにはキャプチャボードが必要です。キャプチャボードには様々な種類があり、どれを使ったらいいのかよくわからなくなると思います（私がそうでした）。私のおすすめのキャプチャボードはI-O DATA HDMI キャプチャーボード GV-HDRECです。

このキャプチャボードは1万円程度と手頃な値段で操作方法も簡単です。最初の1台としておすすめできます。ただし、PCとの接続はできないので、リアルタイム配信には使えません。

記録媒体を用意する

私は32GBのUSBメモリを使っています。スマートフォンに接続できるタイプがおすすめです。録画した動画をスマートフォンで観たり、不要な動画を削除したりできます。

32GBで2時間程度の録画ができます（記録形式によって時間は変わります）。32GBだとこまめにデータを消す必要があるので、もう少し大きな容量がよいかもしれません。

動画の編集

画像の編集はiMovieを使っています。簡単な編集であればiMovieで十分です。YouTubeへのアップロード機能もついており、この機能を使ってYouTubeにアップロードしています。iMovieの操作方法についてはドキュメントをご覧ください。

アフレコに使うマイクはアップルの純正イヤホンのマイクを使ってます。

おわりに

このような感じで、特に難しいことをせずに動画配信ができてしまいます。今後もスプラトゥーンの動画を配信していくので、ぜひチャンネル登録お願いします！