どう足掻こうとNULL

nullに対してのメソッドコール? なんだかしらんがとにかくヨシ!

TypeScript+Reactで小規模SPAの開発環境を構築する②――ユーティリティ編

要約

  • これは技術記事である。
    • ただし参照する際はこちらを確認してリスクを理解した上で扱うこと。
  • ESLint、Jest等を導入
  • スタイルはairbnb
  • Chakra Uiを使うのでstylelintは不要
続きを読む

TypeScript+Reactで小規模SPAの開発環境を構築する①――実行環境編

要約

  • これは技術記事である。
    • ただし参照する際はこちらを確認してリスクを理解した上で扱うこと。
  • TypeScriptとReactで開発基礎環境を整える。
    • lint、test等は次の記事でする。
  • バックエンドも同じリポジトリにある。
続きを読む

git hooksでIssue番号を自動挿入する

要約

  • これは技術記事である。
    • ただし参照する際はこちらを確認してリスクを理解した上で扱うこと。
  • git hooksを利用してコミットメッセージにIssue番号を付与する。
    • bashで組む。
    • ブランチ名の取得にgit symbolic-refを使う。
    • 文字列操作に変数展開を使う。
続きを読む

今までプロジェクトであったこと

要約

  • これは技術記事でない。
  • 現行プロジェクトで起きたことを連ねた。

目次

始めに

今回の記事ではコード片評価サイト作成プロジェクトについて、今まであったことを書き連ねてみる。ボリュームがありすぎて責任問題に発展する可能性があるので、プロジェクトの現状についてはまた後日記事にしておこうと思う。
リポジトリについては以下になる。
https://github.com/NULL-header/fec-frontend
疑問に思った点等あれば、是非ともIssueか当ブログのコメントにて意見を伺いたい。

では以下からがこの記事の本文だ。見出し毎にそれぞれプロジェクトで起きたことについて記述していく。

Issue driven developmentの導入

Issue driven developmentとは、GithubのIssueを使ったチケット駆動開発のことを指す(要検証)。なお、ひとまずこの記事ではこの定義を文脈として利用する。

導入の経緯

事の発端はcontoributorsにもあるg00chyさんが、過去の経験にあったIssue driven developmentを掲示したところ、私とバックエンド担当のkotarouさんが賛同した形になる。それに伴って、githubの機能であるIssueとPull requestsのテンプレートを用意した。またコミットメッセージにチケットであるIssue番号を記載することで、コミットとチケットを紐づけるルールを取り決め、更にブランチ名にもIssue番号を盛り込み、それらの決まりによって開発の手順が確定した。

導入時のメリット

Issueにて仕様を事前に確定させることで、設計を実装の前に行うことが明確化された。これらによって開発手順が画一化され、そのときの開発者の状況によって作業が左右されなくなる。また一つのプルリクエストに対して一つのIssueを紐づけることによって余分な作業がプルリクエストに混じり込むことが無くなり、レビュアーの負担が軽減される。また作業ログとしてIssueがある程度機能するのもメリットだろう。

導入時のデメリット

型安全で便利なプログラミング言語におまじないがあるように、この取り決めがある影響で、軽微な変更でもIssueを書いてブランチ名を長々と切ってプルリクエストを出すという、先ほどのおまじないになぞらえて言うところの儀式が必要になる。これが非常に面倒で、Githubの芝生のカウントにIssue作成が含まれることだけがモチベーションになっている節さえある。

自動デプロイ

今回プロジェクトではCircleCIを用いたサーバへの自動デプロイが採用されている。バックエンドが動作しているサーバで同時にnginxも起動しており、それが読み取るhtmlを自動でビルドするのがフロントエンドでの自動デプロイする仕組みになる。

自動デプロイの経緯

元々の素案ないし要求に、フロントエンドがプルリクエストを出すときにサーバにデプロイされていれば動作確認が容易である、というものがあった。そこでインフラエンジニアであるg00chyさんがフロントエンド用のCircleCI用のymlファイルを書き上げ1、master、develop、featureの各ブランチ毎にルーティングする設定をnginxに沿うように用意してくれた。そのままでも非常に便利で強力なのだが、個人的にはIssueで問題となるページを掲示するときにURLを貼ることのできるのが非常によいと思っている。問題の周知が行いやすく、また文章での説明でなく直接分かりやすい形で問題個所を挙げられるのがとてもよい。

発生した問題

いくつかあったが、g00chyさんから聞いた構築時の問題としては、CircleCIのキャッシュ機能によって変更が反映されない問題が挙げられる。これのためにブランチ名をechoで出力したのをパイプでawkに繋いで、といった文字データの加工が必要になっており、厄介だったそうだ。他にも、フロントエンドのソースファイルのビルド問題もあった。というのも、productionでは当然正規のバックエンドのAPIを使うが、開発段階ではdev版のAPIが必要なのである。そこでビルドするブランチによってAPIの向き先を変える必要があり、今までのURLを纏めていた部分を環境変数から読み取るように改変するなどの処理が必要だった。
また、動作させているうちにDOMルーティングというフロントエンドのソースコードからルーティングさせる処理のためにルーティングのなされていない基本URLの取得が必要になり、それをWebpackから固めるのに手間取ったりと、それなりに問題も発生している。
そんなとき役立った筆者のスキルとして、Bashを書けるというものがあった。それと言うのも、筆者は一時期Pythonに執心していた時期があったのだが、その時テンプレートリポジトリというgithubの機能がなく2、プロジェクトを作成する毎に手でディレクトリを作るのが面倒で、さらに言うなら一々requirements.txt3からライブラリをインストールするのも面倒だった。そこでPythonインタプリタに付属している仮想化機能を使って仮想環境を構築し、自動でrequirements.txtからライブラリをインストールし、更にrequiements.txtの変更を監視して手が加わっていたらライブラリをインストールし直す機能を持ち、またディレクトリを作業用に初期化する機能も持った、複合型パッケージマネージャラッパーとでも言うべきコマンドを書いていたことがあったのだ4。そのときの杵柄でちょいとCircleCIのymlファイルに手を加えてやることで問題を解決したのである。

相互レビュー

今回のプロジェクトではプルリクエストに対して最低一つのapproveが必要であり、それに対して手すきのメンバーがレビューをする形をとっている。

レビューのメリット

まずもって人にコードを見せるという適度な緊張感がとてもよい。見る人を意識するのは美しいコードを書く手助けにもなるし、モチベーションにも繋がる。可読性の意義が向上するというのは本当に素晴らしいことだ。また、フロントエンドではバックエンドの見解が、バックエンドではフロントエンドの見解が得られ、事前にいわゆるオレオレなプログラムを検知できる部分があるのは本当によいことだと思う。

レビューのデメリット

相互レビューが存在するせいでプルリクエストが遅々として消化されないという問題もある。今回プロジェクトメンバーは常駐が二人、臨時が一人と非常に少人数な構成であるので、誰かが体調不良や用事でプロジェクトにいないとその時点で進行が止まる。もちろんgitのrebaseを上手く使って前のプルリクエストのコミットを引き継いだ状態で別のブランチを切るという手法も取ることができるが、その場合プルリクエストがマージされた段階でマージされたブランチでrebaseし直すという手間が発生する。開発のスピード感は間違いなく落ちてしまうだろう。

実際に問題化した点

前述のスピード感が落ちるのに伴って、プルリクエストへのレビューが一部形骸化している問題もある。今回フロントエンド一人、バックエンド一人の構成であるので、どうしても相方のコードを細かくは読めない。設計思想から哲学、果てはやや特殊な文法までもが理解できないために、どうしても命名規則や関数の切り出しなどにレビューが終始してしまう。一度などは相互レビューの取りやめまで検討に入ったほどだった。それでもやって損はないのだから5、続けることに決まったが。

効率的な議論

効率よく建設的な議論をするというのは案外難しい、ということが今回のプロジェクトでの筆者の学びだ。

マナーの欠点

たとえばだが、代案も出さずに問題点を指摘することは少々マナーにもとるところがあるのは否めない。勿論お互いが完全に技術者として成熟してかつ信頼し合っているのなら話は別だろうが、それを除けば、問題点を指摘されるのは気持ちのいいものではない、というのが人情というものだ。ここで、問題点を洗い出せるのだからむしろ気持ちのいいものではないか、と考えた読者は成熟した技術者であるのだろう。だがしかし、文脈とニュアンスを気にするアカデミックからかけ離れた一般人にとって、問題点を指摘されるというのは、お前が気に食わないと言われているに同義なのだ。そういったものに気を付けつつ、相手を立てながら有効な議論をするというのはかなりの難度がある。マナーとは議論のレベルを落とすものだと解釈してもよいぐらいにだ。

論点の記述

プロジェクトのチームの談合においても、よく論点がずれる。お互い技術者であるのにも関わらずだ。その場合の大概のケースにおいては、お互いに自身の文脈に頼って会話していることによる、前提条件のずれが原因である。そういった観点から、提案や意見を述べるときには事前に論点を記述しておくのが効果的でないかと私は思う。ばかばかしいかもしれないが、そういった文脈、論点、前提条件を明確にしておくローコンテクストな会話においてこそ効率的な議論は生まれるのだ。そのために文脈になるべく頼らず、読むことさえできれば子どもにも理解できるような自明さを保つことが肝要であるように筆者は感じた。


といったところで、今回の記事は以上である。

終わりに

やはりというか、プロジェクトであったことを纏めるとそれなりのボリュームになってしまった。まあ致し方ない部分もあって、現在進捗率が一割程度であるのにプロジェクトのフロントエンドのリポジトリの全体のコード量が三千を超えている。純粋なコーディング量(gitが検知している変更量)でなく最終結果でそれなのだから、起こることも多数あってしまうのだろう。
ところで、次はそろそろ技術記事を書きたいと思う。題材としては件のIssue番号のコミットログへの自動挿入についてだ。


  1. バックエンドの自動デプロイはkotarouさんが対応した。

  2. 記憶に頼った結果なので、もしかするとあったが気付いていなかっただけかもしれない。

  3. Pythonでは導入ライブラリ群を記述するファイルをrequirements.txtと言う。NodeJSで言うところのpackage.jsonのdependencies。

  4. 筆者はこれを"Auto Virtual Environment Maker"からAVEMと名付けていた。

  5. 現場ではプルリクエストへのレビュー待ちの時間はそれなりあるらしいので(g00chyさん談)、レビューによって開発が遅れること自体は経験として非常に有用である。

記事のテンプレート

要約

  • これは技術記事でない。
  • テンプレートを用意した。
  • テンプレートの紹介もする。

目次

始めに

はてなブログに投稿する用に、簡単なテンプレートをいくらか拵えた。項目のうち幾ばくかが各記事で統一できるのに気づいたのもあるが、一番の目的は、記事を書くときになるべく考えることを削りたかった、というものだ。ちなみに筆者のやり始めた記事の書き方は、まずざっくりと大見出しだけ並べて構成を考え、その後小見出しでそれぞれを補足していき、最後に中身の文章を書く形だ。こうすると無駄に冗長な文章になったりせずに済むし、見出しになぞらえて論を展開することによって論点がずれるのを防ぐことができる。
ところで以下に掲載するテンプレートにもあるが、表示される際にマークダウンがHTMLに変換されることを利用してHTMLのコメントをマークダウンに書き込む、という荒業が存在する。この手法は現在携わっているプロジェクトを進めているときに知った。IssueとPull Requestのテンプレートを制作しているときに、もう組まれていて使えるようになっているテンプレートが公開されていたので、それを採用していくつか項目を削った形なのだが、その公開されていたテンプレートこそに荒業が使われていたのだ。実際、下手にマニュアルを用意するより、テンプレートに直接コメントを書き込んだほうが遥かに生産的であるように思う。

 テンプレート

さて、テンプレートについて、以下の見出しでまたある程度詳細に記述する。


意図

まずもって言えることは、筆者が潔癖症1であることだ。故に、こういった記事も元々フォーマットを統一したい性質なのである。TypeScriptを初めて触ったときもとりあえずルールをそれなりに縛ったし、eslintにしても無効化しているのはフォーマットにあまり関係ない、煩わしい部分のうち数個程度だったりする。そういう訳で、こういったテンプレートを作成したのに本来深い意味合いはなく、単に気持ち悪くなったからやっただけでしかないのだ。
ところで、テンプレートを作るに当たって、まず基本となるbase、それらを拡張したproject、techとオブジェクト指向的にテンプレートを用意したのだが、マークダウンの記事のテンプレートはクラスのように継承することができず、作成するときにどうしてもコピーアンドペーストが発生する。こういったところも筆者には気になるところである。ケントバック2も重複は悪だと言っていた。偉い人が発する言葉に間違いはないのである。正解もないかもしれないが。

効果

単純にまず挙げられるのは、統一されたフォーマットで書かれることによって、記事の可読性が増す。日本語なのに可読性というとおかしいかもしれないが、たとえば絶対に冒頭に要約を載せると決めてあるので、筆者の記事の全ては要約だけ読めば内容は理解できるようになっている。他にも、(ないとは思うが)筆者の近況報告だけ見たいなら最後の終わりにだけを見ればいい。こういった風にフォーマットを整えることで欲しい情報を即座に参照できるようになり、有用性と理解へ至るまでの容易さが高まるのである。
しかしながら、筆者が最も狙っている効果であり、フォーマットの最たる長所であると考えている機能は実のところそれではない。筆者の考えるフォーマット最大の利点は、脳を殺して記事が書けることである。フォーマットに従ってルーチンワークでぼうっとしながらキーボードを叩いてさえいれば、勝手に記事が出来上がっているのだ。これほどうれしいことがあるだろうか。フォーマットを整えることで、指の肉体労働を極力減らし、かつ頭脳労働の分野にまで省エネを図ってくれる。素晴らしすぎて涙が出てくるぐらいである。ああ、素晴らしきかな、単純労働。極論を言うなら、時給五千円の針金を曲げるだけの仕事に就きたいものである3

動機

ここも筆者なりのこだわりというのが表出してくる部分である。というのも、筆者はこういったテンプレートの統一や、エディタの設定、あるいは単純作業の自動化などは、なるべく最速で行うようにしている。もちろん優先度が低いものは後回しにするが、クリティカルな部分だと判断すれば、即座にその解決に向かう。
突然だが、筆者はクッキクリッカー4のようなゲームがそれなりに好きだ。特段効率の視覚化を好み、自分の書いたプログラムのログが出ている様子を延々眺めて楽しむようなタイプである。つまるところ、効率の最大化が筆者にとってのこの世にある中で最たる快楽の一つなのである。そこで話を戻すと、自動化などが特にそうだが、こういった終わったときからずっと効率があがるような仕様の確定は、長い目で見たときのそれに限れば、気付いた直後に執り行ったときに最大化すると言える。直近だけを見ればもちろん効率は落ちるので、どれほどの期間を見るのか吟味することも重要ではある。

テンプレート群

蛇足だが、以下に今あるテンプレート毎の解説をしていく。もし当ブログの記事の読み方を、先ほどの言葉で述べるところで、確定させておきたいのであらば、こちらが参考になるだろう。


base

以下の形が基本となる。

<!--
全てのテンプレートの元となるテンプレート

構成規則
* この規則はCSSの見直しによって十分に変更されうる
* 箇条書きは全てアスタリスク
* 大見出しはh3
* 小見出しはh5

本文としての見出しの構成は、以下のようになる。

### 本見出し

* 箇条書きで要点説明

<br/>

##### 小見出しで上部に上げた一点を述べる
-->

### 要約

* これは技術記事でない。
* テンプレートを用意した。
* テンプレートの紹介もする。

<!-- 
ここでまず全てを纏める。
先んじて要約を書いておくことで内容を確定させる要約駆動執筆もあり。
箇条書きだが特にハイパーリンクを強制はしない。
 -->

### 目次

* [始めに](#始めに)
* [終わりに](#終わりに)

<!--
ここで目次をひたすら書く。項目がネストしている場合は目次もネストすること。
-->

### 始めに

では以下からがこの記事の本文だ。

今回の記事は以上である。

### 終わりに

<!--
感想でも近況報告でも。
-->

殆ど語るところはコメントに持っていかれてしまった。一応説明すると、他のテンプレートの元となってこそいるものの、コメントはそれぞれ適切に合うよう調整している。あくまで項目のみが原型なのである。
なお、基本的にはこの通りコメントに従って書いていけばいいのだが、別なルールも用意してあるので、そちらを参照した上での目lintも記事の執筆の上では必要不可欠だ。

project

projectは、今携わっているプロジェクトに関する記事を書くときに利用するテンプレートだ。そのために進捗、という以下の項目を追加してある。

### 進捗

現在の進捗は以下のようになる。

* [ ] メインページの作成
  * [ ] サイドバー
  * [ ] Top
  * [ ] 投稿
  * [ ] 検索
  * [ ] 投稿表示
  * [ ] 通知
  * [ ] アカウントページ
  * [ ] ユーザページ
  * [ ] マイページ
  * [ ] 設定
* [ ] 認証系ページの作成
  * [ ] ログインフォームの作成
  * [ ] 新規登録フォームの作成
  * [ ] リファクタ
  * [ ] 命名規則等の完全な統一

ネストして追加してあるタスクに関しては増減する。
ところでここまで進捗を公開していたらプロジェクトを直接教えているようなものだと、当記事を執筆している最中に気付いた。一応初回の記事でプロジェクトのチームメンバーの名前は伏せていたのだが、それも意味がなさそうである。別段完成したらこのブログでも宣伝するつもりであったし、特にこれといった問題もなさそうなので気にしないことにした。

tech

techはbaseからある程度コメントを調整したり最初に予防線の塊の記事へのリンクを張り付けたりしたテンプレートだ。こちらではなるべく個人の感想、感情、考え方、哲学は避けて、こういう操作をすればこういうものができあがる、ということにのみ記述する予定である。つまるところ、ノウハウの部類はtechのカテゴリのついているものの、実際には技術記事扱いではないということにするのである。


といったところで今回の記事は以上である。

終わりに

やはりテンプレートを作っておくと執筆が捗る。筆者は一時期物書きに憧れていた時期があったのだが、そのときも大筋のプロットから詰めていくタイプであったので、こういった項目の事前だった用意は歓迎するところである。
そして次の記事の話だが、もうそろそろ技術記事を用意したいと思っている。思ってはいるのだが、今思いついているネタは、中途半端にバグるgitのhookと、はてなブログのHTMLにおいてReactをビルドしたHTMLファイルのコピペは可能なのか、ぐらいしかない。後者はそれなりに突飛である自負があるのだが、地味に恐ろしいのが前者だ。詳細は省くが、こいつのせいで百個ほどコミットメッセージが吹っ飛んだ。おかげでこちらは大惨事だ。masterブランチにforced pushしたときは心臓が止まるかと思った。
閑話休題、次の記事はおそらく技術記事に行く前に一度プロジェクトの記事に入ると思う。現状やあったことをひとまずつらつらと書くだけなので何の面白みもないであろうことは宣言しておく。


  1. 掃除は下手なのに、どうでもいい細かいところは気になるのが玉に瑕だ。靴は時々何の意味もなく揃えるのに、ゴミ出しは面倒くさくて中々気が進まない。典型的な血液型占いのA型である。ちなみに筆者の血液型は占い通りA型だ。

  2. テスト駆動開発という本の著者で、テスト駆動開発という考え方の啓蒙者でもある。テスト駆動開発は筆者のバイブルだ。

  3. ここ、自分でもやや思想家色の強さと硬く書き過ぎたことから幼女戦記の原作みたいな文章だなと思った。筆者はヴァイス中尉が好き。ただし九巻までしか持っていないからネタバレは厳禁で頼む。

  4. クッキーを連打することでクッキーを作成するゲーム。パラレルワールドからクッキーを集めてきたり、更なるクッキーが量子的に存在しうる可能性を生産したりもする。