昨日は @kuenishi の「RustのプロジェクトでDockerfileを書かなくてもよくする話 - kuenishi's blog」だ。

今年もアドベントカレンダーの時期がやってきた。

最近は、仕事と趣味が高度に一体化してしまったせいで、大きな熱量を割いてやってる活動についてこっちに書くことがない。

という訳で、それほど熱量がある訳ではないけど、まぁまぁやっていってる事をダラダラ書いていく。

今日のお題は中年男性による体重管理の話だ。

体重管理を突き詰めれば摂取してる栄養と、生活で消費される栄養を合算して余りがあれば増えていくという話になる。

とはいえ、旨いものや気持ちいいものを自由に食いたいし、辛いトレーニングの果てに基礎代謝を向上するなんてのは、やりたくない。

このエントリでは、そういう生活の合間に捻りだしたちょっとしたノウハウを皆さんに共有する。

食欲は本当に食欲か問題​

新型コロナ以来在宅ワークが一般化したが、皆さんは日々仕事をしながら、どんなものを口に入れているだろうか。

お茶や水、栄養ドリンクのような飲料。タバコやガムといった嗜好品。ちょっとしたお菓子のようなもの。

まぁ、色んなものを飲み食いしているでしょう。私も例に漏れず仕事をしながら色んなものを口に入れている。

昼夜を問わずに働きまくっていると生活サイクルがグダグダになってしまう。

生活サイクルとは、いつ起きて、いつ寝るのか？いつ食事をして、いつ排せつするのか？いつ風呂に入るのか？みたいな事だ。

色んな事の境界が曖昧になっていく過程で私が遭遇したのは、何か食っているけども、これは一体どういう活動なのか分からない、という状態だ。

要は腹が減ってるからメシを食っているのか、休憩としておやつを食べているのか、喉が渇いているからお茶を飲んでいるのか、よく分からない状態になっていた。

結果として体重が数年で激増し、174cm・78kgの運動不足中年が爆誕し健康診断で警告されることになる。

健康に長生きしたいとは思っているので、あまりきつくない方法で状況を改善しようという話になるわけだ。

という訳で、まずは仕事の合間を縫って自分と向き合う事から始めた。

まず、私は日常生活に困っていないとはいえ軽度の多動症があり、集中力が散漫になり易い。それを自律的にコントロールするために、意図的に意識を分散させるという事をやっている。

要は、一つの事、例えば仕事だけに意識の全てを向けることは出来ないので、足をバタバタしたりだとか、音楽を鳴らしたりだとか、何か食べたりだとかして、意識の一部を遊ばせているのだ。

特に何か口にものを入れておくというのは、本来向き合うべきことから大きく意識をそらさずに、一定量意識を逸らす習慣として極めて効率がいい。

20代の頃は、これが喫煙習慣だったが既に喫煙習慣は完全に失われている。もう一度煙草を吸い始めるというのも、出来れば避けたいという気持ちがある。

仕事中に何かずっと飲み食いし続けているのは、栄養が欲しい訳では無くて、この多動症への対処を行っているのではないか？

という仮説を元に、この1，2年は口に入れるものを徐々に栄養の無いものに置き換えて、仕事のパフォーマンスが低減するかどうかを観察してきた。

ソフトウェアエンジニアという仕事は、基本的に頭脳労働ではあるので、糖質を制限し過ぎると成果の出る量が低減する。なので、何でもかんでもやめればいい、という話ではない。

少なくとも、今の私は仕事のパフォーマンスを著しく劣後してでも、体重減少すべきであるという状況にはない。

単に継続的な体重の上昇が止まればよくて、毎月数百グラム程度ずつ減少傾向にあるなら、それは望ましい状態である。それよりも劇的な変化は求めていないのだ。

欲望を代替するものたち​

突然だが、私は醤油味を基調とした揚げ物であり、ある程度の歯ごたえがある歌舞伎揚げとコカ・コーラが滅茶苦茶好きだ。

この二つの組合せの味や食感に加えて、若いころの過酷な労働において、これらが傍らにあったという成功体験が組み合わさり自分にとって特別な組み合わせになっている。

二つを取り揃えて並べると、自然と集中力が高まりいわゆるゾーンに入り易くなるのだ。BGMとしては、Symphony Xをかけると更にいい。

ただ、今の職場にそんな過酷さがあるかと言われれば、そんなことは全くない。単に自分の過去の成功体験のうち苦しかった部分が曖昧になったり忘れたりして、良かったことだけを美化しているに過ぎない。

という訳で、これらを自分の中で特別なものとして意識することから始めた。コーラについては、既に別な理由で普段の生活からは遠ざけていたので、歌舞伎揚げを漫然と買うのをやめた。

一方で、自分が歌舞伎揚げに求めていたものが何かを探るために、要素分解して口に入れるようにしてみた。

例えば、「揚げ物」であることは重要なのかを確認するために、都昆布のようにある程度塩味と旨味は強いが脂の無いものを食べてみる、などだ。

毎日、根を詰めて考えていたわけではないけども、スーパーでおやつを買う際の指標として、少しずつ要素の欠けているものを選んでいく、という事をやっていった。

こういう時に、よく採用されるのがキシリトール入りのガムではあるけども、これは本当にうまくいかなかった。

キシリトール入りのガムは一日に数粒噛むくらいなら全く問題の無いものではあるけども、私の場合はボトル一つを一日で消費するようなペースでずっと噛み続けることになってしまった。

その結果、腹を下し易くなったので、ガムをかむのはやめた。

噛んでいるうちにかたくなっていく歯磨きガムを試していた時期もあったけども、一日の終わりに噛み過ぎて顎が痛くなるという事が頻発したのでこれもやめた。

何かを口に入れっぱなしにするという観点で考えると、乳幼児向けのおしゃぶりも良さそうに思えた。

しかし、これは毎日熱湯消毒する前提で使われている以上、衛生的に使い続ける事が難しいので候補から外れていった。

徐々に詰めていく中で、要は脂質と塩分は特に重要ではないという結論に至り、そうこうしているうちにアイスキャンディーがかなり良いのではないか、ということに気が付いた。

アイスキャンディーを要素分解すると、氷と砂糖と香料と棒だ。まず、一日中食べ続けるものとして氷はキシリトール入りのガムと同じ理由で望ましくない。

残ったうちの砂糖と香料が良いのかを試すために、一回分ずつ個包装されたかき氷シロップを水に溶かして飲んでみたりもした。これは悪くないがよくも無かった。

必然的に、最後に残るのは棒だ。

たどり着いた答え​

製菓材料として販売されているアイスの棒は、当然ながら口の中に入れて問題ないものとして生産されている。

一方で、木製のアイスの棒は割りばしと同じで基本的には使い捨てされる想定のものだ。よって衛生面も問題ない。

気が付いたのは、夏だったのでコンビニやスーパーで買うアイスを買った時には、その棒まで丁寧に味わうようにしていった。

結論として、コンビニで買えるパルムの棒が自分にとってはベストなアイスの棒であることが分かった。スーパーで買える箱に入った個包装のパルムは、少し小さすぎる。

そう考えて探してみると、アイスの棒はAmazonやヨドバシなど、様々な場所で製菓材料として購入できるのだ。

面白いので、ネットで買えるアイスの棒を次々と購入しては試食してみた。

まず、アイスの棒には食べて良いものとそうでないものがある。食べてはいけないアイスの棒というのは、工作用の部材として売っているものだ。

「クラフトスティック」「DIY材料」などと名前の一部に工作を想起する名前付けられているものは、アイスの棒状であるというだけで、食べる事を想定していないものた。

これは、口に入れると大変に不快で刺激の強い味がするので、恐らく本当に食べてはいけない。

次に、アイスの棒といっても、品質は様々であるということだ。材料として使われている木材も様々であるし、面取り加工の精度も大きく違う。

竹や松などの材料で作られている事が多いようだが、恐らく白樺が最高級品である。

この話を会社の若い子にしたところ、彼から衝撃の質問が飛び出してきた「舌圧子って知ってます？」。その時は勿論、知らなかった。

舌圧子とは、例えば耳鼻咽喉科などで医者が喉の検査をする際に、患者の舌を抑えるために使われる棒状の器具だ。確かに、使われたことはある。名前は知らなかった。

舌圧子も、アスクルやモノタロウなどで簡単に購入できる。そして、大抵の舌圧子は医療用なので加工品質が極めて高い。加えて個包装されているケースが大半だし、材料は白樺が多い。

空前の舌圧子ブームがやってきて、手軽に買えるものをいくつか買って試してみた所、多くの舌圧子が少し長すぎるのと幅が広すぎることが分かった。

当然と言えば、当然なのだけども、舌圧子は医者が検査に使う道具なので、一人が口に入れっぱなしにするために使う訳では無いのだ。子ども用の舌圧子は、大人用よりも相対的に短いのだけども、それでも長すぎる。

具体的には、私が普段使っているアイスの棒は、幅9mmで長さ93mm、厚さが1.9mm弱だが、舌圧子は子供用でも幅が14mmで長さが140mm、厚さが1.6mm程度はある。

要は、舌圧子は長すぎる上に幅広で取り回しづらく、薄いので食べ応えがないということだ。なお、パルムの棒は厚さが2mm以上あるので直感的に厚みを感じられる。

まとめ

長くなってきたので、話を強制的に終わりにするが、今私が継続的に食べて？いるアイスの棒は松尾物産の木製 アイススティック棒 (50本束) 93mm 0836-0901だ。

色々試してみたが、簡単に買えるアイスの棒としては、これが今の所ベストである。もし、より良いものをご存じの方がいたら教えて欲しい。

ちなみに、いくつか試した中で唯一リピートした舌圧子は、OO Osaki(オオサキ) SF滅菌オオサキ舌圧子こども用1本入(100袋) 一般医療機器 74307である。

これは、白樺材で作られているため、ごくわずかに甘みがあり旨い。炭酸水にある特有の苦みを日常的に経験していると、白樺材の甘みを感じられるようになるだろう。

棒自体の加工も大変に素晴らしい。数百本は味わったと思うが、一度もささくれのようなエラー品が無い上に、少々のことではささくれないので安心してくわえていられる。

医療機器なので当然ながら個包装されており、衛生面でも問題ない。梱包に使っている箱の上部3割くらいがパカっと開いて、そのまま机の上に置きやすいのも使い易くて好感だ。

では、みなさま、よいお年を。

という話を、ここから延々と説明する。何の話をするのかわかる人や結論だけ欲しい人向けの情報は、これ以降何も存在しないので、どうぞよしなに。

はじめに​

久しぶりにフロントエンド仕事をしようと思って、手元のテンプレートリポジトリを見たら、何もかもが時代遅れになっており大変につらい気持ちになったのがつい先月のことだ。

やれやれだが全部を選びなおすってのも、まぁ悪くないよなって考えた自分がいかに甘かったか、このエントリでは出来る限り説明していく。

なんのためかって？未来の自分のためだ。将来の自分から見て現在の自分がどのくらいの能力だったのかというのを、きちんと記録しておくことには重要な意味がある。

そして、この記録を有識者の皆さんに御覧頂くことで、何か有益な指摘をもらえるかもしれない、という微かな希望もある。

議論の範囲と要件​

まずフロントエンドアーキテクチャ全体を少ない時間で議論するのはもう無理だ。知識範囲が広くなりすぎてて全く追い切れる気がしない。アプリケーションが動作するためには、サーバサイドだってクラウドインフラだってあるのに、ユーザに接するフロントエンドにかけられる時間は、それほど多くはない。というわけで、今回はUIコンポーネントライブラリについてのみ議論することとする。それだって広すぎる。

また、基盤となるライブラリはReactのみとする。AngularやVue3、Svelteあたりは良いものだと思うが、いかんせん僕が知らなすぎる。そして、そのレイヤーからやり直すのはつらい。よってReactに特化したAPI構造をしていることは必須だ。色んなフレームワークに対応するための抽象化レイヤーなんてものは百害あって一利なし。

次に、CSSは自由にあてたいし、DOMの構造はいじりたい。要はスタイルをちょっと変な弄り方したいだとか、コンポーネントの一部にちょっとした機能追加したいだとか、そういうことのためにコンポーネントを丸っとコピペして作り直すみたいな事はやりたくないってこと。

そして、モバイル対応はしなくてもいいけども、ウェブアクセシビリティは確保したい。言い換えるとWAI-ARIAへの対応をできる限り少ない工数で実現したい。世の中に出回ってるスクリーンリーダーで読み上げして貰い易いようなDOMを作ってくれると良いんだけども、そんなことは可能なんだろうかね。

何でこんなことを言い出してるかって？そろそろ老眼がきつくなってきて、目が自在に見えるって事が当たり前じゃなくなってきてるんでね。僕が抱える体調不良の大きな原因の一つは眼精疲労によるものだ。音声だけでアプリケーションを操作できたら目を休ませられるかもしれない。それで、頭痛や肩こりを少しでも低減したい。その延長で色の違いが少々分からんかったり、視野が欠けても使えるようなアプリケーションが増えたらいいよね。

キーボードやマウスだけでなくタッチパネルみたいなデバイスに対応する際にもガイドになるような機能が用意されていると加点だね。今はまだキーボードやマウスを使えているけども、段々怪しくなってきてるんだよね。

評価対象となる要素技術の洗い出し​

Reactを前提に、CSSを自由にあてたいって時点でヘッドレスコンポーネントライブラリを選択することになる。その上でWAI-ARIAに対応するってなると選択肢は大きく絞り込まれる。

具体的には、この3つしか見つけられなかった。

• Radix Primitives
  • Radix UIというスタイリング済コンポーネント集が存在している。それを実現するためのスタイリングされていないコンポーネントライブラリが独立して使えるようになっているもの。
  • スタイリング済のコンポーネントが使いたい場合は、Radix Themesを使う。
• React Aria + React Stately
  • Adobeが定義したSpectrumというデザインシステムをReactで実装したものがReact Spectrum だ。これには４つのライブラリが含まれている。
    • React Spectrum
    • React Aria
    • React Stately
    • Internationalized
  • React Aria と React Stately はデザインシステムとは独立して利用できるHooksのライブラリだ。
  • React Ariaの中にはそのまま使えるコンポーネントライブラリとして React Aria Componentsが含まれている。
• ariakit
  • コンパクトなライブラリでコンポーネントの状態管理用HookはAPIとして分離されている。
  • OSS版はコンポーネント数が少ないように見えるが上位の有償版が存在する。

この手のライブラリを選ぶときには、外側にあるエコシステムを無視することはできない。

例えば、最近人気のツールとして shadcn/ui がある。こいつは、RadixとTailwindで作ったサンプルコードを自分のプロジェクト内にコピペしてくれるのだ。

Radixのドキュメントは、よく出来ていてTailwindでスタイリングしたコンポーネントのサンプルコードをパッとコピペできるようになっている。それを効率化しつつ、新しいコンポーネントを追加したり、AIでUIコンポーネントを作れる v0 と連携できるようにしたものが shadcn/ui だ。

大変に興味深い事に shadcn/ui が提供するツールでReact AriaとTailwindを基盤にしたコンポーネントをコピペすることもできる。それが、JollyUI だ。

React AriaとTailwindを基盤にしたコンポーネントライブラリとしては、Hero UI もある。React AriaのCopomnent APIよりも更にパッケージングされているので、自由度は下がるがさっさと作れる。OSS版はコンポーネント数が少ないけども上位の有償版が存在する。網羅性を確保するために紹介したが、柔軟性が相対的に低い事が明らかなので、今回は検討しない。

何の細工もなしにCSSを書くってのは大変につらい。というわけでCSSのユーティリティとして、Tailwind CSS を検討する必要があるだろう。他にもCSS フレームワークが沢山ある事は何となく知っているが追いきれていない。

ここまでに出てきた要素技術を図示するとこうだ。

様々な課題設定があり、それぞれに対応している範囲が違う。選定基準を明確にしなければ、どれを選んでも後悔することになるだろう。

要素技術の詳細な検討​

ここからは、列挙した要素技術について詳細に検討していこう。

デザインシステムについて​

まず明確にしておかないといけないのは、僕はデザイナではないし、その素養もない。よってデザインシステムそのものの是非についての意見はない。

今回の選定対象の中に含まれているデザインシステムの実装は Radix ThemesとReact SpectrumとTailwind CSSだ。Tailwind CSSだけがちょっと特殊でデザインシステムを作るためのフレームワークにデフォルトのデザインシステムが最低限付いてる、みたいな理解をしている。

作られているドキュメントの内容や質という意味では、React Spectrumが優れているようには感じる。しかし、Radix Themesで提供されているドキュメントがあればアプリケーションを作るうえでは十分だ。

この数か月対話している生成AIの皆さんが上手く扱えるのはどうやらTailwindっぽいという、あまり根拠のない肌感覚みたいなものはある。生のままのCSSは、どうも思い通りに作ってくれないのよね。僕が持つ語彙が足りない可能性は大いにあるだろう。

というわけで、デザインシステムの選定を棚上げしたい自分としてはTailwindを使っておこうという判断になる。

後は一緒に仕事をすることになるデザイナーさんがTailwind慣れしていてくれることを祈るばかりだ。

ヘッドレスコンポーネントライブラリの比較​

３つのライブラリを比較検討するにあたって利用できるコンポーネントの数は、まず比較対象になるだろう。使わないものが沢山あってもしょうがないが、使いたいものが無いなら作るしかない以上、基本的には多い方がいい。

• Radix Primitives は28個
• React Aria は45個
• ariakit は17個

Radix Primitivesの特徴は何と言ってもasChild だろう。このプロパティを有効にすることで、子要素として指定したコンポーネントが代わりにレンダリングされる。これによって、可読性を維持したままコンポーネントの振る舞いを大きく切り替えられる。型のサポートもばっちりだ。詳細は公式のドキュメントを確認して欲しい。cf. Composition

各コンポーネントの状態管理は、コンポーネントの内部にカプセル化されており、調整の余地はあまりない。これがRadixの分かり易さであり、融通の利かない部分でもある。

既存コンポーネントのDOM構造を弄りたくなっても、それはできないのでasChild を使って置き換えるという事になる。

asChild は、大変にクレバー仕組みだが、僕には動作が難しすぎると感じる。

React Ariaの特徴はガチムチなHookベースAPIだろう。何に難しさを感じるかは人によるだろうが、Reactを正しく理解しているなら、React Ariaは正しく理解できるはずだ。React Hooksがそもそも難しすぎるだろうという指摘については同意する。

UIコンポーネントとしての振る舞いを定義したHooksをパッケージングしてあるのがReact Ariaである。UIコンポーネントの状態を管理するHooksをパッケージングしてあるのがReact Statelyだ。

問題なのは、Hookだけそうやって提供されたからって画面には何も表示されないってことだ。それらをJSXに適用するのはライブラリの利用者側の責任ってわけだ。それはつまり、ボイラープレートコードが爆増することが予想される。そんな分かりやすい問題がほったらかされてる訳もなく、React Aria Componentsというライブラリが提供されている。これで最低限DOMとHookが統合されたUIコンポーネントが使える。

ariakitは有償のコンポーネントがあるのであまりフェアな比較ではないけども、買ったからといって、それほど大きな差が発生するようには思えない。利用する状況が限定されている複雑なコンポーネントが多くでも使いようがないわけだし。金を払う前にどんなコンポーネントがあるのか確認できなかったので評価し辛い。

それほど大きな話ではないけども、ariakitはServer Side Renderingに対応しているかどうかについて言及が無かったのも残念。この時点でariakitを選択することは無くなった。

というわけで、基本的にはReact Aria Componentsででき合いのコンポーネントを使いつつ、必要な場所ではHook APIを組み合わせて、より状況に強く依存したコンポーネントを作っていくのが良いだろうと結論した。

React の Hooksについては、随分前に時間をかけて学習したので新しく覚えることは少ない。RadixのasChild が、どういう動作なのかは、少し調べてみたが正確には分からなかった。能力不足だと言われれば、残念だが否定しようがない。

コピペツールの是非について​

shadcn/ui は大変に良いツールだ。UIコンポーネントライブラリが持つ根本的な課題を解決している。それは何かというとカスタマイズ性だ。こに対処するための根本的解決手段として、UIコンポーネントを提供するのではなく、コピペを効率よく実施するための手段を提供する。これは、かなりクレバーなアプローチと言える。

どうせカスタマイズのために、元のコードベースをコピペして必要な場所を変えて動かすことになるんだから、最初っからそうすればいいってこと。

これによって、画面の構成部品を作るという事に対する生産性は明確に向上する。コマンド一発で各コンポーネントがローカルディレクトリにバンバンコピペされるんだから、時間当たりの生産されるコード行数は目に見えて増える。なんてこったい、これはマジで最高だな。

だが、ちょっと待ってほしい。5個10個とコンポーネントをローカルにコピペしてるうちに気が付くことがある。これらは、どうやってメンテナンスするんだろか？見た目良い感じに動いてはいる。後の事は、後の人が何とかするっしょ。基盤部分はRadixなんだから最低限の品質は担保されてるさ。起きてもいない問題を解決しようとするべきでない。そういう考え方ができるならOK。v0でコンポーネントを作りまくろう。

残念ながら、僕はそういう風には考えない。基本的な振る舞いを確認するためのユニットテストすら付いてこないものを、正しく動作しているって自信を持って言えるほどの蛮勇はどっかに置いてきてしまった。これが老いってやつだ。細かいことが気になってしょうがない。

基盤はRadixだっていうけど、なんか気が付いたらTanStack Tableが依存性に入ってる、いつ入ったんだ？おいおい、話が違うじゃねぇか。いや、TanStack Tableは良いライブラリだよ。そこに疑問は無い。でもよ、知らんうちに入り込んでるのは違うんじゃねぇかな。これからも知らんものが知らうちに入ってくるのか？ローカルにコードがあるんだから、それは利用者側の自己責任ですってわけだ。勘弁してくれ。

コンポネントに何か脆弱性があっても、それに一々対処するには、ライブラリのアップデートじゃ済まなくて、自己責任でコピペしたものを逐一全部確認して回る必要があるってことね。きつすぎる。

コピペされてくるコンポーネントがpath aliasを前提にimportしてんのも大分気にいらない。こいつがいるだけで、開発環境のセットアップがとてつもなく複雑になる。import文の煩雑さをちょっと低減するというリターンに対して、path aliasがもたらすリスクは許容限界を超えてると個人的には感じる。

JavaScript界隈のモジュール名を解決するロジックは歴史的経緯によってアホほど複雑だ。tscみたいなコンパイラとESLintみたいなLinterとwebpackみたいなモジュールバンドラが、整合性をもってモジュール名を解決できるようプロジェクトを構成するには、とんでもない慎重さが求められる。

なんかよく分からんプラグインをあっちこっちに入れたり、設定を書いたり、処理順を正しくしたりする。一度動いてしまえば、何度でも動くようになるけども、すぐに誰も触れない禁断の領域になる。そして、使ってるツールをアップデートするとよく分からんプラグインが不要になったり、設定のデフォルト値が変わったりする。プロジェクトが成長してきたのでディレクトリ構成を整理しなおしたいとか思っても、その魔界は許してくれないだろう。

というわけで、コピペツールの導入は見送り。

まとめ​

最近のUIコンポーネントライブラリってのは、すげぇもんだね。どれもこれも立派に動く。色んな事を詳細に考えてきちんと作りこまれている。

僕が認識していないUIに関する課題ってのは、まだまだ沢山あるだろうし、それを解決するために作られたライブラリはもっと沢山あるだろう。

このエントリ内に何か見当違いな事を書いている可能性については特に否定しないので、気が付いた人はXか何かにシュッと書いてくれると非常にありがたい。テキトーにエントリのURL何かを付けといてくれれば、こっちからエゴサしとくんでよろしくお願いしますね。

この長文に付き合ってくれるような忍耐力のあるあなたに感謝をささげて、エントリの〆とします。

はじめに​

この15年くらいは、おおむね平均すると毎年2，3人程度の技術者をOn the Job Training（OJT）で教育する機会に恵まれており、その中で蓄積した知見や私の考えを散発的に説明していきます。

私自身は受託開発を主たるビジネスとするシステムインテグレータ（SIer）と呼ばれる企業で働いており、足掛け25年程度のキャリアがありますがソフトウェアについて専門的な教育を受けたことはありません。また、教育についても同様です。

このエントリに記載された内容について何らかのエネルギーを注いでくれる方がいるなら、XあたりのSNSでURL付きで指摘して頂ければ非常にありがたいです。

教育によって形成される技術者像​

まずは、どのような技術者なら育てられるのでしょうか。私の考えを述べます。

一番最初に明確にしておくことは、ここでの議論はソフトウェア技術者を中心としたものです。強電や弱電といった分類が妥当な技術者の話はしません。また、ソフトウェアが動作するために必要な種々のインフラは全て揃っている前提で考えます。利用者としてオペレーティングシステム（OS）を扱います。しかし、OS自体を作ったり修正することは考えません。

OSIモデルで言うとネットワーク層（L3）あたりが最もプリミティブなレイヤーだと考え、日常的にはほぼ意識しないものとします。基本的にはプレゼンテーション層（L6）を利用します。セッション層（L5）については、業務で利用するコマンドラインアプリケーションやライブラリが露出してくる範囲については理解するくらいの温度感です。

正直言って、楕円曲線暗号がそれ以前の暗号に比べて何故強固なのかを数学的な根拠を持って説明することは私自身もできません。最新のスゴイやつだから使っておく方がいいくらいの気持ちでいます。

ここまでを前提にソフトウェア技術者としての期待値を定性的な基準で説明してみましょう。私は技術者の能力を以下に列挙する5+1段階で捉えています。

ほぼ素人​

基本的に最初はみなほぼ素人です。稀に大学でプログラミングをそれなりにやってきた新卒採用の若手がいますが、業務としてのソフトウェア技術者を経験している新卒は恐らく私が所属する企業には来ないのでしょう。遭遇したことがありません。

未経験で他業種から転職してくる方も、基本的にほぼ素人です。

半人前​

プロジェクト内で利用するツール類に習熟し、参画しているプロジェクトが採用している開発プロセスに則って報告・連絡・相談を必要に応じてできる状態になっている人です。

業務で求められるドキュメントを記述したり、プログラミングについては他人の成果物をコピー＆ペーストしつつ手直しすることで作業を完了できることを期待します。

私の経験上は、受託開発の業界ではこのレベルの人が最も多いです。経験年数は余り関係ありません。１０年やってても半人前の人は沢山います。

それでも今までは生きてこれたのですから、いい仕事なのかもしれないですね。今後どうなっていくのかは分かりませんが、すぐに状況が大きく変わるとは思えません。

一人前​

プロジェクト内で利用するツール類に習熟した上で、開発プロセスに則って作業見積りと業務遂行が出来る人です。

必要に応じた詳細さのドキュメントをドキュメントテンプレートから書き起こすことや、多少のサンプルコードがあれば、ゼロからアプリケーションコードを書くことを期待できる人です。

私が教育を行うなら最初に目指すのが、この状態です。ほぼ素人が対象なら半年から１年程度。半人前からなら最短で３か月程度の期間で一人前のソフトウェア技術者に育てられます。

ただ、所属する企業の新卒採用プロセスは突破するのが非常に難しいため、基礎的な能力の高い方が多く採用されていることは付記しておきます。

チームリード​

一人前に働いた上で、他人の面倒をみられる状態になった人です。他のメンバーから相談を受けたり、チーム内にある細かな解決すべき課題に気が付くことも期待します。

ドキュメントテンプレートを作ったり、通常の業務とは別に開発環境や業務環境の改善を必要な相手に提言し、実際に手を動かせるとより望ましいですね。

業務やソフトウェア技術について自発的に学習し、それをプロジェクト内に持ち込めるようになると十分な働きを期待できるでしょう。

学習する習慣を身につけられた人は、ここから更に伸びていきます。ただ、そういう人はごく少数です。

会社組織として考えた場合には、このチームリードを沢山輩出できることが望ましいのですが、私はそれが出来ると明確には言い切れない状況です。

私が教育を手掛けた人の中には、私の元を離れた後に本人の努力によってチームリードに成長する人は何名もいます。ただ、それは私の活動による成果だとは言い難いですよね。

技術責任者​

数億円規模以上のプロジェクトにおいて要素技術選定や非機能要件定義を主体的に実施できる人です。

体感ではソフトウェア技術者の1％程度しかいません。そういう人に遭遇したら逃がさないようにしましょう。

こういう人を教育によって再現性高く輩出することは原理的にできないと考えています。中途採用することも非常に難しいでしょう。

会社として出来ることは、そういう稀有な人が学習と訓練によって実績を重ね、それがきちんと評価される環境を作ることです。

例外的な存在​

いわゆるツヨツヨ人材については例外的な存在だと考えています。彼らは生活の中に組み込まれた強固な学習習慣を持っており、食事や入浴をするように学習するので、本人は負担感が少ないことが多いです。

昼だろうが夜だろうが、関係なく学習して前に進んでいくので、こういう人達と自分や教育対象を比較するのはやめましょう。比較してしまう時点で負担感なく夜昼構わず技術を触っていないので、そういうやり方には向いていません。

組織的な取組みとして考えた時には、ツヨツヨ人材を理想的な存在であると定義してしまうと、各種の法令を遵守することが難しくなるでしょう。

ツヨツヨ人材の多くは社内外で形成される技術者コミュニティに多く参加するため、会社に所属しているというよりは業界に所属している共有リソースの一種だと考える方が良いかもしれません。自分達のためだけに占有するよりは、業界全体にとって良い方向になるような業務に携わって貰う方がいいんじゃないでしょうか。

こういった人々を適切に処遇するというのは、極めて困難な課題で定式化できるようなものではありません。もし幸運にもそういった人材が社内にいるなら大切に扱いましょう。

教育環境について​

継続的な学習や訓練の習慣を確立するには、本人が日常的に接する環境の影響が強いと私は考えています。

独学で必要な知識や技能を過不足なく得ることが出来る人もいますが、多くの人にとっては一緒に学習や訓練に取り組む同じくらいの能力を持つ同僚の存在は不可欠です。

そして、目先の業務をこなすだけでなく、学習や訓練を業務の中に組み込んでいくことが許される環境は組織が強靭であり続けるために必要な事です。

ここでは、教育環境について少し考えてみましょう。

オンラインとオフラインの使い分け​

新型コロナの蔓延をきっかけに私が所属する会社でもテレワークできる環境が急速に整えられました。例えば、私が所属する部門では出社率は25%程度です。大多数の従業員は出社せずにサテライトオフィスや自宅で仕事をしています。

そういった状況を前提に考えて下さい。リモートワークを継続したままで効果的な教育を行うことはできるでしょうか？

今現在の私の認識としては、リモートワークのみでの効果的な教育は極めて難しいと考えています。

特にほぼ素人の状態から一人前に育てるには、対面でのコミュニケーションが必須だと考えています。なぜなら、知識や経験が著しく不足していると自らの状況を適切に言語化できないからです。こちらから見れば、明確に知識不足や理解不足によって手が止まっているにも関わらず、それを認識できていないことが多く発生します。具体的な弊害としては、本人にとって助けが必要な時に自分で助けを呼べないのです。

これに対処するには、教育を行う側が能動的に教育を受ける側の状態を観察し必要な措置をとることが望ましいと私は考えています。そのために使うツールとして現代のリモートコミュニケーションツールは基礎的な性能が不足しています。カメラやマイクを通すと余りに多くの非言語的情報を削ぎ落してしまうのです。一時期は、オンライン会議を開いて接続したままずっと作業するというのを試してみたりもしましたが、あまり上手くいきませんでした。

私の所属企業が主に使っているツールはMS Teamsですが非言語的なコミュニケーションを取るための道具としては全く使い物になりません。そのために作られている訳ではないので当たり前と言えば当たり前ですが…。

話は少しずれますが、個々人が独立してタスクを遂行できるチームではリモートワークは有効に機能すると考えています。業務に集中できるよう作りこんだ自宅環境において言語化されたコミュニケーションのみで成果に向かって作業することは効率的で合理的なあり方です。そういった状況では、非言語的なコミュニケーションは業務をすすめる上で弊害になり易いので避ける方が望ましいでしょう。

チーム内で知識や考え方、価値観が統一され一定のルールが徹底された結果、言語化されたコミュニケーションを取らずとも、同じ課題設定に対して同じ結論に到達できることが理想です。しかし、非言語コミュニケーションによって、お互いの考えや状況を類推しあう事によって働くのは精神的なコストが非常に高く、また事故が起きやすいので望ましい状況ではありません。

ややこしいのは、前者と後者を外形的に区別する方法がほとんどないことです。チームの中心的な人物にとっては前者のような環境だと認識していても、単に周りが上手く合せていただけという状況は相応に存在します。

コミュニティの作りこみ​

私の所属企業は、それなりに規模が大きいので基本的にはピラミッド型の組織構造をしています。

事業セグメント→事業部→部署→グループといった構造ですね。これによって、基本的な人間関係は縦の構造によって規定されます。

同じ部署内にいたことのある人の事は良く知っているけども、隣の事業部の事は概要レベルでも何をやっているのか分からないというのは、特に珍しい事ではありません。

一方で新卒採用者であれば同期入社と事業部を越えた繋がりを形成できる人達もいます。こういった関係性を横の繋がりと考えた時、会社の中にはより多くの横の繋がりが存在することが望ましいでしょう。私が所属する企業内では、横の繋がりを形成するための様々な取組みが存在します。

技術者教育にも、横の繋がりがあると能力が伸びやすい傾向があると考えています。教育担当者の能力に依存し過ぎるのは望ましくありません。

では、私が取り組んでいる横の繋がりを作る活動をいくつか説明しましょう。

輪読会​

少し難しめだったり、分厚くて挫折し易い書籍を複数人で集まって読む会です。例えば「プログラマのためのSQL」や「コードコンプリート」といった書籍を題材にしたことがあります。これらは名著ですが軽い気持ちで読むには辛いですよね。

輪読会では事業部門横断で参加する人を公募して、多くても７，８人で1チームにします。

そして、キックオフの際におおむね10～20ページ程度ずつを、その一人ずつに担当範囲として割り付けます。章や節を基準にすると分かり易いことが多いです。

担当者は、その範囲における議論の中心になる役割を持ちます。具体的には、その範囲内において理解が難しかったことや、納得できなかった部分について輪読会当日までにメモ書きをまとめておきます。

輪読会は１枠１時間で実施し一人分の担当範囲について議論を行います。つまり、一回の輪読会で議論の対象になるのは、多くても20ページ分程度ということですね。

最近やってみてうまくいったのは最初の１５分～２０分を全員が黙読する時間にすることです。これによって、担当者以外の参加者は当該範囲を事前に読んでこなくてもよくなるので、輪読会参加のハードルを下げ心理的負担を低減する効果がありました。黙読が終わったら、担当者が自分の疑問点や納得性の低かった部分について説明し、担当者以外の参加者と議論していきます。

輪読会の主催者である私は基本的にファシリテーションを行うのですが、疑問の内容が複雑すぎたり、ごく単純であった場合には直接回答してしまうこともあります。しかし、重要なのは参加者同士が議論する事で理解を深めることです。

ハイパフォーマーとの面談​

これは、社内でハイパフォーマーとして評価されている高度な技術者と、まだそこに至ってはいない中堅くらいの技術者が、直近の業務を題材に面談する場です。

私が所属する企業はSIerですが、技術的能力を評価されて高い職位にいる人（雑に言えば高い給料を貰っている人）は相応に存在します。しかし、あまり目立たない事が多いので組織内における縦の人間関係だけで暮らしていると、社内に高度な技術者はいないし、いても評価されていないと誤解し易い状況にあります。

この取組みでは、中堅技術者が他の事業部門で働いているハイパフォーマーと接点を持つことで、キャリア観を形成できるようにすることを第一の目的にしています。技術者として働き続けたいのに、先が無いと思ったら会社を辞めてしまいますよね。評価のあり方を誤解したまま退職してしまうのは会社にとっても本人にとっても不幸です。そういう不幸を少しでも減らしたいと活動しています。

面談の中ではプロジェクトに対する取り組み方や、採用した要素技術について議論していくことで、仕事への取り組み方を中堅技術者が学習していけるようにしています。ハイパフォーマー側も、自らが所属していない部門で採用されている技術の事例を学習する場として活用しています。

この取り組みを継続していくと、社内に学習意欲の高い技術者同士の繋がりが増えていくでしょう。

雑談用ワークスペース​

所属部門の枠組みを超えて緩やかに雑談するために、ある種の社内X（twitter）みたいなものをイメージしたチャットスペースを運営しています。

そこでは、私が作ったチーム内にそれぞれのユーザが自分用のチャンネルを作るような形になっています。

全員が強制参加の「一般」チャンネルにはチームへの新規参加者がいると顔写真付きで自動投稿されます。また、給料日やボーナス時期に何か買物に困っていると「実質無料」などとコメントして購買を煽るボット（人力）がいたりと独自の文化を形成しています。

あまり有用な場所であることを目指してはいないのですが、社内の手続きについて困っていることを書くと詳細を相互に教え合うような空気感もあります。

私が気に入っている文化としては、チャンネル名の一部にアイコンを使う流行が数年前にあって以来、色彩豊かなチャンネルが作られるようになったことです。

類似するようなチームが社内にはいくつかあるという話は聞いたことがあるのですが、私自身はそれらに参加していないので、どうなっているのかは知りません。

こういうものがいくつもあって、それぞれが独自の文化圏を形成するのも一つの多様性だと考えています。

私のやり方における限界​

私が考える技術者教育のやり方には明らかな限界があります。それは、教育対象にする人数を増やせないことです。

非言語コミュニケーションを前提に時間をかけて対応するので、多くても７～８人までしか一度に対応できません。

教育対象となる人が持つ現在の能力に応じて、教える内容を柔軟に組み立てているので明文化したカリキュラムのようなものを作り出せていません。

持つべき知識や技能がどういったものであるのかを整理できていないために、再現性の無い活動になっているのです。

例え私に教育を受けた人でも、同じことを同じようにはやれません。

私のやり方では、自分が持つ知識や経験の１割程度、かなり都合よく考えても２，３割程度しか伝達できていないために再生産できていないのです。

現状はあくまでも技術者を教育しているのであって、教育者を教育している訳ではないという状況であるとも言えます。

おわりに​

本当は技術者教育における訓練の内容について書きたかったのですが、前提を整理するだけで随分と長くなってしまいました。一旦ここまでにしたいと思います。

年末年始は宴会も多いので、そこでの議論によって、続きを書く気力が生まれる可能性は高いでしょう。

私と直接対面する機会のある皆さまにおかれましては、ご協力のほどをよろしくお願いします。

明日以降の自分に期待して、このエントリの締めとさせてください。

知識と学習​

一つ目は、学習するに足るだけの知識体系がそこにあるかどうか。

知らない事を知る、出来なかったことが出来るようになる快感ってのは、何度経験しても最高なんであって、一人でも多くの人にこの体験をして欲しい。素晴らしいことに、ソフトウェア技術だけに範囲を絞ってもまだ理解できてない事は大量にあるし、増え続けてる。

生成AIがアシスタントしてくれるけど、ちょいちょい嘘をついてくるってのが、また熱いよね。AIが言ってる事だけを真に受けちゃダメで自分でちゃんと試さないといけない。そして、インターネット上に無い情報について、やつらは手も足もでない。

最近は新しい技術が出てこないなんて言ってる連中もいるようだが、現実の社会課題を解決し、それを付加価値として提供できて初めて新しい技術だろ。ゴミみたいなチュートリアル一通り触って、それでおしまいじゃ専門知識とは言えねぇよな、俺達はプロだぞ。

まともに使えるエディタがあり、Lintやコンパイラで細かい作業ミスやアンチパターンをきちんと潰せる。まともなバイナリを吐けるコンパイラがあり、それらを一貫したプロセスでビルドできるCI環境があり、各種デプロイ環境やツールがそのバイナリを受け入れる体制がそろってる。そして、細粒度の監視だの、実行プロセスの異常検知だの、エラー時の対応だのが現実的な工数で対処できる。そういうランタイムなんて、そう多くはねぇ。そして、その状態まで技術が進展するのには10年単位の時間がかかる。

んで、今挙げたような事を、全部一通りまともに扱えるような技術者なんて、ほとんどいない。つまんなくなったとか言ってねぇで学習と訓練をしろ。サボってるやつに限ってつまんなくなったとか言い出すんだよな。

俺たちのJavaは幸いこういう事が高度に実現されているから安心して使ってられるわけだな。最近だと、Goはあっという間にこのレベルまで育ったわけで大変に素晴らしい。Rustはまだまだ不足かな。個人的にはPythonなんかも安心して任せられる言語だと思ってる。

TypeScriptはJavaよりもJavaだなって思いながら使ってる、色んな意味で俺はTypeScript大好きだよ。UI作るのにも、サーバ作るのにもいい。NodeのGCはJavaに比べるとアホだけど、あんま重要な事を任せなければ可愛いもんよ。どうせ今時のアプリケーションは１プロセスで信頼性を担保することなんてできねーし、アプリケーションプロセスの手前にはちゃんとロードバランサがいるんだ。気にせずプロセスは落としていけ。

UI作るフレームワークはもう何年もReact中心だよな。もう飽きたなんて思ってるやつは少数派だよ。そうでなけりゃ、useEffectの使い方解説するだけで、みんなが大喜びするわけねぇだろ。どいつもこいつも雑に使いやがって、おかしな使い方するから画面がチラついてしょうがねぇんだよ。

そういうのは、実装の詳細であってバッドノウハウだから本質ではない、とか言っちゃう？おおー、上から物言えば後はどこからか集められた皆さんが勝手に作ってくれるアーキテクト様は偉いねぇ。俺は少なくとも、そういう所にはいねーんだわ。要件定義から運用まで見れる範囲のものは全部責任を持って最高の状態に仕上げる。こちとら、そういうスタイルで仕事してんだわ。だから、文字コードがおかしくてうまく動かねー古いJavaScriptと格闘したりもする。とは言え、こういうのはマジで最悪だからみんなはやんない方がいい。

サーバについても同じよ。Javaだと大体JAX-RS使っとけみたいな所で落ち着いてるけど、社会課題をまともに解決するレベルに使いこなすってのは大変な事よ。確かにチュートリアル動かして雑なアプリケーションデプロイする所までは1日でいける。色んな事が整備されまくってすげー簡単になったなって思うよ。生成AI様に、使い方教えてくださいって言えば、細かい嘘混じりだけど何でもポンポン教えてくれる。それをコピペして動く範囲のものなら簡単に作れる。

でもよ、そんなんじゃ仕事は始まってもねぇんだわ。いや、確かにその程度の事が出来れば良い役割ってのはある。あ？なに？僕ちんはすごい「ぎぢつりよく」あるのに、こんな簡単な仕事しか任せて貰えなくてつまんないでちゅーって事？残念なこったな。

問題解決​

二つ目、その得た知識を実社会における問題解決に適用できるかどうか。

ソフトウェアが世界を侵食するようになったってのは、電車の中でみんなの手元を見ればすぐわかる。どいつもこいつも、スマホに嚙り付いていて完全に魂を奪われた状態だ。

勿論、俺自身もそう。ゲームで暇つぶしをするもよし、SNSで承認欲求を満たすもよし、買い物だってできる。勿論、学習のために本を読めるし、本を読んでるフリしながら漫画も読める。この片手に収まる小さいやつがいなかった頃の生活なんて、思い出したくもないってのが正直なところよな。

そして、ソフトウェア技術者ってのは、消費者でありながら、その提供者でもあるわけだな。自分は基本的にB2Bなソフトウェアしか作らないから、必ずしもみんなの手元にあるようなものを作ってる訳じゃないけどさ。

現代のソフトウェアシステムは、大前提としてインターネットがありウェブがある。一部のマニアしか使ってなかったおもちゃであった時代はとうの昔に終わって、今や上下水道と同じくらいにインターネットは生活と切り離せないものになってる。つまり、現代は人間側がインターネットに寄せてきてくれたので、ウェブで動作するアプリケーションを提供するだけで解決可能な社会課題が、それこそいくらでもあるんだよね。

ITつまんねーとか言ってる連中は仕事無くて暇なのかねって思うわ。

解決すべき社会課題がいくらでもあるって事は、それに対応するためにより高度な技術的知見や技能が必要になるって事。ビジネスが分かる必要があるだの、無いだのって話もあるようだが、現実社会の課題を解決できるだけの技能ってのは、よっぽど高度なものだよ。片手間にできるようなもんだと考えてんなら甘く見過ぎだろ。専門的な訓練が必要なものだし、一度訓練が終わったら一生使えるってわけでもない。継続的な課題解決への技術適用がありつつ、それに向けた準備も必要だ。これはソフトウェア技術者だけが特別だってんじゃねぇぞ、高度な付加価値を提供する専門職ってのはそういうもんだ。

最先端技術が生成AIでそれの応用の話ばっかり技術イベントで聞かされてウンザリしたなんてのも見たが、何言ってんだって話よ。生成AIが作れるシステムで解決できる範囲の社会課題なんて、ほんのちょっとだけじゃねぇか。便利で賢いエディタが増えたくらいの話よ。付加価値として提供できる課題解決に集中しろや。そのパートナーとして生成AIは信頼に値する存在か？

技術以外の事も分かる人間の方が金勘定だけやってる人間にとって使い易いってのは理解するとしても、技術者としてやってきたって人間が、それだけになってしまったなんて悲しんで見せるのは、了見が狭すぎる。流され過ぎだろ。

報酬​

三つ目、解決した問題に応じた報酬があるかどうか。

ITで金を稼ぐのは広告一択とか言ってんのはどんだけ見えてる範囲が狭いんだって話よ。確かにB2Cビジネスでは広告を使って収益性を確保することが広く行われている。でもよ、有償のコンテンツ配信サービスに全く金を払わずに暮らしてる人の方がすくねぇだろ。アニメでも、漫画でもゲームでも良いんだけどさ。非接触IC使った決済なんかも地獄便利よな。俺は小銭ジャラジャラするのも好きだけどよ。NISAやるにもiDeCoやるにも書面だけじゃ出来なくてITの力は必須だよ。こういうビジネスはどれもこれも著しく収益性が低いとでも？そんなわけねぇ。みんなクッソ稼いでる。

自分の仕事はB2BでITによって課題解決する事で対価を貰う仕事をしてるけど、そこに広告の要素は一切ない。システム作るのに使ってAWSやGoogle Cloudには毎年億単位の金を会社は払ってるし、それの何倍もの売り上げを作って利益を出している。それを原資に十分な給料やボーナスを貰ってるよ。

スタンプ売ってるSNS屋さんは無理に広告出さなきゃシステム規模に応じた売上が立たなくてきついのか？そりゃご愁傷様。でも、それは社会全体の話じゃなくて御社の話よな。

ただ、猫スタンプを友達に送れなくなったら生活に支障がでるから頑張って欲しい。そのためなら、頑張って広告見るよ。お願いだから猫が出てくるやつを多めにしてくれ。

まとめ​

正直言って、良い年こいた大人が公衆の面前で「～～はつまらなくなった」とか言い出すのは老化だよ、老化。俯瞰的に物事を見れて、歴史も知ってる斜に構えた俺カッケーってか？そういうシラけた態度がかっこよかった時代はもう終わってんだよ。

社会の持続的な発展を担うものの一人として、後進の皆さまがこの仕事に夢や希望をもって取り組めるように、継続的な改善を行う責任についてもう少しまともに検討してはどうかね。

最先端のモードは物事に真っすぐ向かって真面目に取り組む。これ一択よ。

反省したら、明日からはオートミール食ってプロテイン飲んで筋トレしとけ。今日は風呂に入る前にスクワット10回、寝る前にストレッチ30分な。忘れんなよ。

はじめに​

このエントリはFactorioのSpace Explorationというmodを導入して遊んでいる人向けのエントリである。

Factorioというゲームがどんなゲームであるかについては、多くの情報がネットにあふれているので、ここでは説明を繰り返すことはしない。

Space Exploration mod は、Factorioの何もmodを導入していない状態でロケットを打ち上げる所までは遊んだ人向けのmodだ。つまり、クリア後の世界を拡張するものである。

Factorioでロケットを打ち上げた後、この世界はどうなるんだろう？と思った事はないだろうか？開拓した星を飛び出して宇宙空間や更なる惑星を求めて冒険に出たいと思ったことは無いだろうか？

それをかなえてくれるのがSpace Explorationだ。このmodを導入することでどんな景色が見れるのか少し紹介させてほしい。

• 衛星軌道にむかってそびえたつ軌道エレベーター

• 衛星軌道上に作られた宇宙ステーションと地上の間を巡回する銀河鉄道

• 水のない惑星に立つ謎のピラミッド

膨大なコンテンツが含まれている大型modだが、信じられない事になんと無料だ。そして、日本語で遊べる。注意点としては、modはPC版のみ対応だ。もしPC版Factorioを一通り遊んだことのあるなら是非遊んでみて欲しい。

このエントリは、Space Exploration modにおける中盤以降で建築することになる宇宙船に関する攻略情報つまり、ネタバレを含むものである。もし、完全に自力で攻略したいと思っているなら、読むのを避けて欲しい。

それでは本題に入っていこう。

最小の宇宙船​

まずは、テックレベルをSpaceship consoleが作れるところまでゲームを進めて欲しい。そうしたら、床と壁を作ってその中にSpaceship consoleを配置することで宇宙船を建築できる。

今回の説明で使う宇宙船は、そこからさらにテックレベルを進めてIon Engineを作成できるようになっている。

具体的にはこういうものだ。説明に使った宇宙船は最後のまとめでBlueprint Bookのインポート用文字列を用意してあるので、説明できなかった部分を詳細に知りたいという事であれば使って欲しい。

棺桶である。かっこよさは微塵もない事は認める。何せ筆者は絵心というものを気がついたら、どこか遠くに置いてきてしまったのだ。取りに戻ろうとしたが、もう分からなくなってしまった。

冗談はさておき、この棺桶は宇宙を飛び回れるし、惑星に着陸したうえで、大気圏を突破して宇宙に戻ることもできる。

⚠️ Space Explorationを遊んだことのある人は違和感を覚えるかもしれない。 本来なら、液体ロケット燃料を使うロケットエンジンが無ければ、地表面から宇宙に出られない筈なのだが、現在の仕様ではなんと液体ロケット燃料のタンクだけ据え付けておけば大気圏脱出できる。このバグが修正されたらロケットエンジンを自分で追加して欲しい。

レーザータレットは宇宙空間で飛んでくる隕石を打ち落とすために必須なので設置している。上を歩けるフラットな太陽光パネルと広域電柱を配置して電気系統は実装してある。

ここまでは特に難しいことは無いはずだ。

手動スイッチによる発着​

Spaceship consoleに回路を接続して操作するための基本的な部分から理解していこう。

まずは、定数回路を使った離陸と着陸について説明する。

最小の宇宙船に定数回路を2個と宇宙船を係留するクランプを取り付けてある。クランプは宇宙船側に一つと港側に一つ付けると宇宙船の着陸を自動化できる。

今回の回路で使うシグナルは、その他のタブに配置されているものを使う。

二つの定数回路とSpaceship consoleは単一の回路ネットワークで接続してある。

左側の定数回路には、宇宙船の離陸を表すシグナルを設定した。かっこいい宇宙船に上向きの黄色い三角がついているシグナルだ。値としては1以上の数値を設定すればなんでもいいので1を設定してある。この定数回路の電源をOnにしてシグナルをSpaceship consoleに送信すると宇宙船は離陸する。

右側の定数回路には、着陸するためのシグナルを設定してある。

シグナルパレットには、クランプを表すシグナルが４つあるが、三角の向きが同じ黄色と青のシグナルが対応関係にある。

黄色い三角がついているシグナルが宇宙船に設置してあるクランプを表す。青い三角がついているシグナルが港に設置してあるクランプを表す。

クランプの値は、クランプを一意に特定するためのIDを表す。黄色い三角形側のクランプは各宇宙船の中で一意になっていればよい。大抵の宇宙船はクランプが一つだけなので実質的にどんな値でも問題ない。青い三角形側のクランプに設定された値は、それぞれのマップごとに設置した複数のクランプの中で一意になっている必要がある。例えば、軌道衛星上と母星の地表はマップが違うので値が重複してもよい。

最初のうちは複数の宇宙船を単一のクランプに複数の宇宙船を係留しようとすることは事故につながるためやらない方が良いだろう。分かり易さのため宇宙船のクランプに付与するIDと港のクランプに付与するIDは同じにするのがおすすめだ。

なお、単一のクランプに対して、複数の宇宙船を係留しようとすると二つ目以降の宇宙船は該当するクランプが空くまで着艦しない。また、同一のIDを持つクランプが複数ある場合には空いているところに着艦する。

筆者にはFactorioで管制塔の制御システムを実装するだけの根性はないが、誰かが挑戦するのであれば見てみたいという気持ちはある。

この定数回路では、宇宙船に設置した500番のクランプを使って、港に設置した500番のクランプに係留するように指示している。

それでは、宇宙船に配置したクランプを見てみよう。クランプ本体をクリックして、シグナルのアイコンをさらにクリックするとIDを編集できる。ここでは500を設定している。

同じように港側のクランプにも500番を設定した。

宇宙船は二か所以上の港を移動する。つまり、係留する可能性のある港側のクランプは全部同じIDを割り振るのがコツだ。違った値を割り当てても良いが、その分回路は複雑になる。

例えば、このケースでは軌道衛星上の宇宙港と、母星の地表にある港のクランプのIDとしてそれぞれ500を割り当てている。軌道衛星上と母星はマップが別なのでクランプの値が重複していても正しく動作する。

このクランプの仕様を理解するのに筆者は大分苦しんだが、これを読んでいるあなたはすんなり理解できただろうか？もしすぐに理解できたなら非常にうれしい。

加速の自動化​

宇宙船が惑星間を移動する際には、係留状態から離陸状態になり、その後加速状態なる。離陸状態の宇宙船は速度がゼロなので一切移動しない。ロケットエンジンやIon Engineが動作して加速状態になった宇宙船は一定の時間経過によって目的地に到着し、速度がゼロになる。

離陸シグナルを定数回路からSpaceship consoleに送信することで離陸するとすでに説明した。実はそれだけでは宇宙船は移動しない。宇宙船が加速を開始するにはSpaceship consoleに対して目標となる速度を入力する必要がある。

というわけで、宇宙船に新しい定数回路を配置して回路ネットワークに接続した。

速度を指定する定数回路では、タコメータのようなシグナルを選んで値として目標速度を設定する。船の最大速度は船自体の大きさやエンジンの数によって決まるので、ここで設定した値の速度で必ず船が飛ぶという訳ではない。

設定された速度を目標に頑張ってエンジンを動かすだけだ。つまり、無理な目標を設定しても、エンジン性能の限界を超えた速度がでることはない。

なお、離陸していない宇宙船は速度を設定しても単に無視する。係留状態のままエンジンをふかしたりはできないのだ。

目的地設定の自動化​

離陸と着陸、それに加速を定数回路のON/OFFで操作できるようになったので、次は少し複雑な回路を組んでみよう。

条件回路自体の使い方について詳しく知りたい人は、factorio@jp Wiki の 回路ネットワーク を見て欲しい。

まずは、目的地の自動設定回路を組み込むために、宇宙船を少し拡張した。

この回路について説明する前にSpaceship consoleが出力するシグナルについて理解しておいた方が良いだろう。様々なシグナルが出力されているので一つずつ説明していく。

まず全体としては、例えばこんなふうにシグナルが出力されている。

左から順に説明する。

Spaceship consoleのアイコンで34が出力されているシグナルは、宇宙船のIDを表している。複数の宇宙船を建造したらこのIDが意味を持つようになるが、管制システムでも作らない限り使い道は無いと思う。

タコメーターのアイコンで-2が出力されているシグナルは、宇宙船の速度を表している。0未満は特別な値で、-1は宇宙船が停止していることを意味する。-2は港に係留していることを意味する。

定規のような目盛りのアイコンで-2が出力されているシグナルは、宇宙船に設定された目的地と現在地の距離を表している。0未満は特別な値で、-1は到着済み、-2は係留済み、-3は目的地が設定されていないことをそれぞれ表す。

惑星に木星のようなわっかがついているアイコンで475が出力されているシグナルは、宇宙船に設定された目的地を表している。これは、設定されたり入力された値がそのまま出力されているので、注意して欲しい。また、目的地の種類ごとにアイコンは変わる。

アルファベットのDアイコンで100が出力されているシグナルは、宇宙船の周りにある小惑星や隕石の密度を表している。このキャプチャを取った時には港に係留されている状態なのだけども、何か高密度な隕石の中にいると判定されているようだ。唯一使い方の分からない数字でもある。

アルファベットのAアイコンで475が出力されているシグナルは、宇宙船が係留されている時のみ出力される。これは係留された宇宙船の現在地を表す。

では、宇宙船の現在地とはどういうことだろうか。Space Explorationで拡張される機能の中にUniverse Explorerという機能がある。これを使うと、探査衛星を打ち上げて発見した惑星や太陽、アステロイドベルトなどを一覧できる。

例えば、筆者がやっているゲームではNauvisが母星である。母星をマウスでクリックして選択状態にすると、選択した要素の詳細情報がウィンドウの右上あたりに表示される。

では、母星の詳細情報を確認してみよう。色んな事が書いてあるが、今重要なのは、Automation signal という値だ。ここでは474となっている。つまり、宇宙船を母星の地表面に係留するとSpaceship consoleにおいてAの値が474になるということだ。ちなみに、目的地として使う際には、数字の左側についているアイコンも同じものにする必要がある。

続いて、母星の軌道衛星を見てみよう。ここでも注目するのは、Automation signalだ。軌道衛星を表すアイコンと共に475という数字が読み取れる。つまり、Spaceship consoleの出力シグナルをキャプチャした際に、宇宙船が係留されていたのは母星の軌道衛星上であるというわけだ。

これを踏まえて回路に設定された条件を確認してみよう。

Spaceship consoleから出力されたシグナルは、右側の赤いケーブルから入力されてくる。

右上の条件回路では、現在地が474、つまり母星の地表面に宇宙船が係留されている時チェックシグナルを出力する。右下の条件回路では、現在地が475、つまり母星の軌道衛星上に宇宙船が係留されている時チェックシグナルを出力する。つまり、右列にある二つの条件回路はいずれか一つだけが成立する。

中央上の定数回路では、軌道衛星を表すシグナルで475の値を出力しており、左上の条件回路のみに接続している。中央下の定数回路では474の値を出力しており、左下の条件回路のみに接続している。

左列にある二つの条件回路は全く同じ条件と出力を設定している。つまり、チェックマークのシグナルが1の時に、定数回路と条件回路から入力されたシグナルを全て出力するというわけだ。

回路全体を俯瞰すると、母星の地上に宇宙船が係留されている時は目的地を軌道衛星上に設定し、宇宙船が軌道衛星上に係留されている時は母星の地上に目的地を設定するというわけだ。

着陸と加速の自動化​

宇宙船の現在地に応じて目的地を自動的に決められるようになったので、次は着陸と加速の自動化をやっていこう。

これは特に難しいことは無くて、すでに作りこんだ係留と加速の定数回路のスイッチをONにしっぱなしにするだけだ。これによって、宇宙船から定数回路が一つ減ることになる。

Spaceship consoleの左側にある定数回路が二つになっていることが確認できるだろう。

減った定数回路の中に設定されていたシグナルを、Spaceship consoleのすぐ左隣りにある定数回路の中に統合した結果、このようになる。

どちらかというと、何故着陸と加速という矛盾したシグナルをSpaceship consoleに送りっぱなしにしても正しく機能するのかを理解する方が難しい。

Space Explorationにおける宇宙船には、係留状態、停止状態、加速状態という3つの状態があると少し前に説明した。

まず、クランプアイコンの係留シグナルは、目的地の上空で停止状態の時にしか機能しない。係留状態や加速状態の時は勿論の事、目的地でない場所で停止していても単に無視される。つまり、係留シグナルはSpaceship consoleに送りっぱなしで問題ない。

次に、タコメーターの速度目標シグナルは、目的地以外の上空で停止状態の時にしか機能しない。係留状態でエンジンをフカそうとしても単に無視される。目的地上空で係留待ち状態になっている時も無視される。というわけで加速シグナルもSpaceship consoleに送りっぱなしで問題ない。

入出荷の自動化​

宇宙船の自動運行について説明するのもそろそろ大詰めだ。最後の説明を始める前にそもそも何で宇宙船を自動運行するのか忘れてしまわないように、荷物を載せたり下ろしたりする方法について確認しておこう。

まずは積込みだ。このキャプチャでは右側の大きい箱からインサーターを使って取り出したものを宇宙船内の箱に格納している。ベルトコンベヤを配置するにあたって邪魔になった広域電柱の位置を少々調節した。

次は荷下ろしだ。積込みの際にはつながっていなかったベルトコンベヤの先に地下ベルトを通って物資が輸送されている様子が確認できるだろう。積込みの際に使っていた右側の地下ベルトの先には何もない。

離陸の際に使う液体ロケット燃料は、どこの惑星でも補充できるようにパイプを組むと紛れが無くなって宇宙船の運行状況が安定する。なお、宇宙用のパイプは地上用のパイプと問題なく接続できる。

離陸の自動化​

ここまでは、宇宙船内に配置した定数回路のON/OFFを切り替えることで宇宙船を離陸してきたが、最後は宇宙船を自動的に離陸できるように回路を組もう。

クランプを中心に宇宙船の離陸と関係がありそうな設備をケーブルで接続している。ここでは、宇宙船の電力状況を安定させるために蓄電池（Accumulator）を追加している。

接続されたクランプ同士は、それぞれに入力されたシグナルを相手方に送信する。つまり、宇宙船内部の液体ロケット燃料やIon Stream、蓄電池の残量はクランプを通して外の回路に伝達されるのだ。すごい。

赤いケーブルで接続された各資源の情報がクランプにシグナルとして送信されていることを確認してみよう。このキャプチャでは赤い背景の入力シグナルとして、液体ロケット燃料、Ion Stream、蓄電池の残量割合が送信されている。この例では、Spaceship consoleの出力と、蓄電池の出力に同じAシグナルを使っている。これらが同じ回路ネットワーク内に流れることで合算されてしまうと完全に意味のない値になってしまうので、回路の接続経路で混ざってしまわないよう注意して欲しい。

これらのシグナルを受け取る回路がどんな構成になるのか確認していこう。これが宇宙船の自動運行に関する最後の説明になる。もう少しだけ付き合って欲しい。

まず、宇宙船の離陸条件を検証する回路を宇宙船の外側に置くというアイディアこそが最も重要なことだ（なお、筆者のアイディアではない）。宇宙船の内部に離陸条件を検証する回路を置こうとするとどうしても回路が巨大になってしまうのだ。資源効率や横展開に関わるので、宇宙船は出来る限りコンパクトに実装したい。

次に重要なのはクランプのすぐ左にある条件回路だ。チェックシグナル３つを受け取ったら離陸シグナルを送るようになっている。なお、宇宙船は1tick離陸シグナルを受け取るだけで離陸する。つまり、離陸によって宇宙船が係留状態でなくなるので、左側のクランプから右側のクランプに離陸シグナルは送信されなくなるが、特に問題はない。

ちなみに、宇宙船内に定数回路で離陸シグナルを送れるようにしているのは、緊急避難的に宇宙船を離陸するためだ。自分のキャラクターから遠く離れた場所で宇宙船が動けなくなったとしても、Universe Explorerを使って宇宙船を表示したら定数回路のON/OFFをリモートで切り替えられる。なお、Spaceship consoleの離陸ボタンをリモートで押すこともできる。

残りの３つの条件回路は一つの資源ごとに条件を設定して、それぞれがチェックシグナルを1つずつ送るようにしてある。単一の回路ネットワーク内において複数の回路が同じシグナルを送信すると、そのシグナルの値は合算される。つまり、この回路においては３つの条件が成立した時に宇宙船が離陸するというわけだ。

より条件を複雑にしたければ、条件回路を単に増やしていけばいい。港側に条件回路を配置する構造なので、回路が大きくなってもほとんど問題はない。

というわけで、宇宙船の自動運行に関する説明はこれで終わりだ。残りは、細々としたTipsや回路の改良などを説明していく。

自動運行する宇宙船の改良​

ここまで説明に使った宇宙船を自分がプレイしているゲーム内のリソースを使って改良してみた。

改良点として分かり易いのは、太陽光パネルと蓄電池だ。テックレベルを上げていくとより強力なものが使えるようになる。ここでは色が赤いものに切り替えた。

次に、目的地を自動設定するための回路群をコンパクトにまとめた。二点間を移動するだけの回路であれば、合計10マス程度で実現できる。もしかしたら、これさえも港側で実装できるかもしれない、という気はするもののまだ試してみていない。

ちょっと分かりづらい改良としては、荷下ろしをするためのインサーターに対して、Spaceship consoleからの出力シグナルを接続するようにしたことだ。荷下ろし用の港に宇宙船が係留されている時だけ動作するようにインサーターの条件を設定している。これで意図しないものがベルトコンベヤ上に乗るのを避けられる。

まとめ​

以上がSpace Exploration modにおいて筆者が持っている自動運行に関するノウハウの全てだ。それほど多くの情報がある訳ではないが、丁寧に説明したので文章量としては非常に多くなってしまった。全て読むのはすごく大変だったことだろう。この文章を書きあげるのは勿論すごく大変だった。

宇宙船の自動運行については、筆者自身もまだノウハウを積み上げ始めたばかりで、あまり複雑なことは出来ていない。今後三点間の巡行や、資源の少ない場所への優先的な巡行、条件回路を全て宇宙船の外側に配置するなどの方式に挑戦してみたいと考えている。

ここまで、読んでいただいた読者に感謝するとともに、説明で使った宇宙船を各バージョンごとにブループリントとして記録しておいた。Space Exploration modをすでに導入済みで、このエントリでは説明しきれなかった微細な部分に興味がある方は是非インポートして使ってみて欲しい。

昨日は @kuenishi の「我が家の生活物資事情コストコ編」だ。

もはやこのブログがアドベントカレンダー用のサイトになって久しいが、今年もちょっと役に立つ話をしようと思う。

今回の話題は、在宅ワークにかかる環境整備の話だ。コロナが始まったころには盛んに皆さんが自宅の環境を整備するようなエントリを書いていたが、最近は一回りしたのか結構減ってきたように感じている。

単に私の生活環境が完成して、そちらの方面に対する興味関心が薄れただけかもしれないが。

というわけで、このエントリではすでに完成して久しい私の稼働環境について説明する。もう完成してから一年以上は経過しており、細かい変化はあるものの全体としては変わっていない。

少なくとも私が使い込んでいて間違いなく良いと感じているものを説明していく。

机と椅子

大きい物から紹介していこう。つまり、机と椅子だ。

オフィスチェア（オカムラ コンテッサセコンダ）​

コンテッサは比較的高額な部類の椅子だが、デスクワーカーにとって椅子は体の一部とも言うべき存在なので妥協しない方がいいと私は考えているので、きちんとお金を払って買った。

食事、入浴、排せつ、睡眠以外の時間はほぼこの椅子に座っている。時間にすると毎日8時間～12時間程度だろうか。休日に集中してゲームをしている時などはもっと長時間座っていることもある。

自分に合った椅子を探すというのは比較的専門的な知識が必要になるので、オンラインで買わずに専門家の意見を聞いた方がいいだろう。そういうとき、WORKAHOLIC はおすすめだ。完全予約制ということもあって極めて親身に対応してくれる。高額な商品を買う際には、コンシェルジュサービスにきっちり金を払って正しい知識でもって合うものを紹介して貰うべきだ。単なる消費者として分かっている事と、プロが持っている知見には大きな差がある。

https://www.iamworkaholic.jp/

私の場合は、コロナ初期で混乱状況な時に椅子を買ったこともあり、会社で使っているのとほぼ同じ椅子を買った。つまり、体に合っていないことに対する懸念はなかったので、同じものを最も安価に買えるアートオフィスクリエイトで買った。このサイトを使う上での注意点は「金を払ってない人間には対応が雑」ということだ。例えば、金を払う前に在庫や納期について聞いても通り一辺倒の答えが返ってくるだけで全く意味はない。しかし、一度支払いが済んでしまえば最大限の対応をしてくれる。工場在庫を押さえて、できるかぎり早く商品が届くように手配してくれるし、質問に対する応答も速くて正確になる。

https://e-aocinc.com/SHOP/122324/139843/list.html

電動昇降式デスク（FlexiSpot）​

昇降式デスクを買うなら、絶対に電動式を買うべきだ。理由は簡単、手動だと使うのがめんどくさくなるからだ。

私の場合は、3時間座って作業したら、1時間程度はスタンディングデスクとして使って、疲れたら座る、というような運用で使っている。仕事が少し忙しいような時は、1日に2回、3回上げ下げしているのだが、これは電動昇降式を選んだからこそ出来る生活サイクルである。

ただ、電動昇降式デスクは非常に高価な商品だ。様々なものを探したが、手ごろな価格で電動昇降式のデスクを買えるのは、ほぼFlexiSpotだけだった。当時私が買ったE3はすでに売っていないが後継商品のE7が今は売られている。天板の材質や形状のバリエーションも多いので大いに悩んだ上で購入して欲しい。

https://flexispot.jp/e7-set.html

ケーブルトレー（CB-CT3）​

電動昇降式デスクを買ったら確実に問題になるのはケーブル類だ。

私の場合、ディスプレイ2台に、マイク、USB充電器、USBハブ、キーボードなどがあるため、机の下部がどうしてもケーブルだらけになってしまう。これを解決するために、クランプ式のケーブルトレーを使っている。サンワサプライのケーブルトレーはFlexiSpotと非常に良い組合せで収まるのでおすすめだ。

https://www.sanwa.co.jp/product/syohin?code=CB-CT3

このケーブルトレーを使うとゴテゴテとした電源系のケーブルを足元に散らかすのではなく、机の奥側の裏に収められるので、足元が落ち着いた感じになる。

ディスプレイアーム（エルゴトロン）​

良い机と椅子が揃ったら、次はディスプレイアームだ。ディスプレイアームを導入するとディスプレイの高さや配置の自由度が格段に向上する。特に二枚以上ディスプレイを使うならディスプレイアームの利用を強く推奨する。

ディスプレイの高さや傾きは細かく調整することで眼精疲労や肩こりが低減するので、納得いくまで調整できるようにすべきだ。ディスプレイとキーボードとマウスの位置関係に妥協はない。

ディスプレイアームは、安価なものから高価なものまで色々あるが私が使っているのはエルゴトロンのディスプレイアームだ。最近のディスプレイはデカくて重いことが多いので高品質なものを使うのが望ましい。そういった意味でエルゴトロンは非常に信頼できる。

https://www.amazon.co.jp/dp/B07Q8TJ2KL/

入力デバイス

デスクワーカーにとってキーボードとマウスは自らの意思をコンピュータに伝えるためのデバイスである。

左右分離型キーボード（Mistel BAROCCO MD770 JP）​

全てのテレワーカーは左右分離型のキーボードを使うべきだ。私はそう考えている。

とはいえ、日本では左右分離型のキーボードは商品としての立ち位置を確立できていない。

自作キーボード界隈では左右分離型のキーボードは非常によく見るが、仕事で使う道具として完全に信頼できるものにはなりえない。基盤はむき出しで埃がたまれば火事になる可能性はあるし、はんだ付けが甘ければ期待通りに動作しない。ユーザ自身でファームウェアを書き換える以上、そのソフトウェア品質はそれほど高いとは言えない。

製品として一定以上の品質水準にある左右分離型のキーボードはほとんどが海外製品でつまり英字配列だ。私は、もう30年JIS配列でキーボードを使い続けているので、ここから英字配列のキーボードに乗り換えるという気持ちはほとんどない。

そういうわけで、左右分離型のキーボードでかつきちんとした製品になっているJIS配列の左右分離型キーボードは極めて貴重なものだ。

https://archisite.co.jp/products/mistel/barocco-md770-jp/

JISキーボードを使っていて、まだ左右分離型キーボードを持っていない人は、これを是非買ってみて欲しい。

リストレスト（Genuine Wood Wrist Rest）​

キーボードを分割したら、それに合うリストレストを使うことで手首に対する負担を大きく低減できる。リストレストはモチっとした柔らかいものが好まれているように思うが、実は少しくらい固い方が良いんじゃないかと個人的には感じている。

科学的な根拠のある話ではないが、柔らかいリストレストは、接触面の負荷は低いぶん、それによって周りの筋肉や腱に余分な力がかかってしまうことで、総合すると効果がマイナスなのではないかと疑っている。

FILCOのGenuine Wood Wrist Restは天然木で作られたリストレストだ。これはプラスチックや金属ほど固くはないが、一方で緩衝材のような柔らかさがあるわけでもない。

https://www.diatec.co.jp/shop/new/2003bunri/

大型マウスパッド（HV-MP855）​

キーボードを分割したら、次はマウスをどこに置くかが問題になる。

胸をしっかり開くような形で分割キーボードを配置したらキーボードの真ん中がマウスをおけるような空間になる。

こうなったとき、どんなマウスパッドがいいだろうか。小さすぎるマウスパッドは使いづらいし、中途半端な大きさのマウスパッドはキーボードと干渉するので収まりが悪い。

こういう時は、思い切って大きなマウスパッドを使おう。具体的には幅が90cm以上あるようなやつだ。一般的にはFPSのユーザが好んで使っているようだが、マウスとキーボードを丸ごとマウスパッドの上に置いてしまえばおさまりの悪さなどというものは、そもそも関係なくなる。

そういうわけで、90cm x 40cmあるようなマウスパッドはおすすめだ。

大型のマウスパッドをいくつか買ってみたが、長期間使うには上下左右がきちんと縫い込まれていてほつれないようになっているものがいい。

マウスパッドは大体ゴム製品なので、使い始めてから数か月はちょっと甘いような匂いがするものだが、気になるなら何度か洗濯すると匂いが消える。つまり、ゴムの匂いが苦手なら洗濯可能な製品を選ぼう。

私はゴムの匂いが苦手なので匂いが弱くてかつ選択できるHavitのマウスパッドは非常に気に入って使っている。

https://www.amazon.co.jp/dp/B01M18UR54

マウス（MARATHON MOUSE M705m）​

突然だが、私はトラックボールが苦手だ。仕事で使う分にはあまり問題ないのだけども、マウスを激しく動かすようなタイプ（ハクスラとか、RTSとか、FPSアクションとか）のゲームをする際には、トラックボールだと期待した速度で操作できなくてイライラする。

この数年間は、色んなマウスを試してみたが結局はいつもm705に戻って来てしまう。このマウスを私が使い続ける理由は３つだ。まず、手の中にうまく収まること。私は主に右手でマウスを操作しているが、右手と左手で握手したって、こんなに収まり良くはない。

そして、高速スクロール機能だ。マウス中央にあるボタンをカチっと押すとスクロールホイールが高速に回転するようになる。大量のソースコードやドキュメントをレビューする際には、この高速スクロール無しには業務が成り立たないと言える。

最後は、バッテリーの持ちが異様にいい事だ。今は相当回数充電してヘタったエネループプロでマウスを動かしているが、前回いつ充電したのか思い出せない。少なくとも直近2, 3か月は電池を入れ替えた覚えが無い。アルカリ乾電池なら、半年や一年は電池を交換する必要が無いのだ。なお、前回買った時には、電池より先にマウス本体の調子が悪くなったくらいだ。

https://www.logicool.co.jp/ja-jp/products/mice/m705m-wireless-mouse.910-005303.html

音源

リモートワークで高度な仕事を実現するには、高品質なリモートミーティングが重要だ。

特にマイクとイヤホンの品質が低いと会議における最低限の部分が満たされないので、会議の質が悪くなり易い。

骨伝導式イヤホン（AfterShokz Aeropex）​

私は基本的に電話が嫌いで、その理由は耳をふさいでそこから音を出していると、ほんの2，3時間で酷い頭痛に襲われ何も出来なくなってしまうからだ。

また、密閉性の高いヘッドフォンをしていると、周りの音が聞こえなくなるので、自宅のインターフォンが鳴っていることに気が付かなかったりする。インターフォン程度なら良いが、自宅の周りで何か事件や事故が起きていることに気が付かないようなことは避けたい。

Shokz（私が買った時はAfterShokzだった）の骨伝導イヤホンは、こういった私のニーズを適切に満たしてくれる製品だ。骨伝導イヤホンなので大きな音を出さずとも聞こえるし、耳の穴をふさがないので、周囲の音もちゃんと聞こえる。2台の機器にBluetooth接続できるのでスマホとPCにペアリングして使っている。

私が使っているのはAeropexだが公式には販売終了済

https://jp.shokz.com/products/aeropex

しかし、Amazonではまだ買える。

https://www.amazon.co.jp/dp/B07RQLTFJ5/

マイクとセットになっているOpenCommはずっと気になっているものの、Aeropexが不調にならないので使ってはいない。

https://jp.shokz.com/products/opencommuc

ダイナミックマイク​

イヤホンと対になる道具がマイクだ。

マイクには、自分の声はきっちり拾ってミーティング参加者に伝える一方で、自宅に溢れるノイズは拾わないようにしてもらいたい。USB接続できるコンデンサマイクは、数万円するaudio-technicaやRODEのマイクを試してみたが、どちらも期待するようには動作しなかった。

結局、期待するような動作をしてくれたのは1500円で買えるダイナミックマイクだった。量産効果万歳。

https://www.amazon.co.jp/gp/product/B07PNMRBJS

オーディオインターフェース（evo 4）​

ダイナミックマイクの多くはXLR接続なのでPCに直接は接続できない。つまり、PCとマイクの間に専用の機器を置くことになる。というわけで、オーディオインターフェースを買う必要がある。

オーディオインターフェースは、マイクに比べると少し高額なものが多い。私が使っているのはEvo4というUSB接続するだけでカジュアルに使えるものだ。

https://allaccess.co.jp/audient/evo4/

evo 4は熱意をもっておススメできるというほどではない。もう少しオーディオ初心者でも使い易い構造で安価なものがあるように思う。

マイクスタンド​

マイクと自分の口の距離は近ければ近いほどいい。しかし、一日中ミーティングしているわけではないので、使っていない時は横にどかしておきたい。そういう要望をかなえてくれるのがマイクブームだ。関節がいくつかあってクランプ式のものを選べばFlexiSpotの良い感じの場所に挟んで使えるだろう。私が使っているのはAmazonで買える非常に安価なものだ。消耗品のつもりで買ったが2年以上元気に使えている。

https://www.amazon.co.jp/gp/product/B07F588GVF

電源

ソフトウェアエンジニアは電源と共にあるものだ。良い電源は良い仕事につながる。

私が使っている電源に関連する製品をいくつか紹介しよう。

充電池（エネループ　プロ）​

まずは充電池だ。電池を使う機器にはほぼ、エネループ プロを入れて使っている。例えば、マウスやゲームのコントローラがこれにあたる。

こいつは物理的な大きさは他の電池と同じだが容量が大きいので交換の頻度を下げられるので気に入っている。

https://panasonic.jp/battery/charge/p-db/BK-3HCD2C.html

卓上充電器（Anker PowerPort Atom III Slim）​

スマホを始めとしたガジェットの類はバッテリーを内蔵しているものが多いので、机の上に置いてある最中は充電しておくとよい。私が気に入って使っている高速充電器はAnkerのものだ。

https://www.ankerjapan.com/collections/charger/products/a2045

無停電電源装置（APC RS 550VA）​

この冬は寒い。そして電力が不足している。皆さんは家庭に届いている電圧がちょいちょい100Vを下回っていることに気が付いているだろうか。場合によっては、計画停電なんてこともあるかもしれない。

そうでなくても、最近のGPUは滅茶苦茶電力を食うので、ゲームしながらエアコンやヒーターに電源を入れた途端にうっかりブレーカーが落ちることもあるだろう（実際、私はそうやってブレーカーを何度か落とした）。

大抵の電子機器はちゃんとしたコンデンサを積んでいるので少々の電源断で壊れたりはしない筈だが、パソコンだけはそういうわけにもいかない。ブレーカーが落ちた後にPCをシャットダウンするだけの時間を稼ぐためにUPSを置こう。

APCのUPSならPowerChuteという電源管理用のソフトウェアが付いてくるのでシャットダウンも自動化できる。

https://www.apc.com/jp/ja/product/BR550S-JP/apc-rs-550va-sinewave-battery-backup-100v/

その他おまけ

今年は寅年だったのでネピアのパッケージが本当に最高だった。Amazonの購入履歴によると、11回買っているので、ほぼ毎月買っているようだ。

ネピア 鼻セレブ ティシュ 400枚(200組)x3箱 ネコ科動物パッケージ

https://www.amazon.co.jp/dp/B09N33KMKZ

まとめ

以上が、私が自宅に作りこんだ環境だ。気になることや、もっと良いものがあるという方は、是非教えて欲しい。

テレワーク環境をより良くしたいと考える読者の皆さんに少しでもお役に立てれば幸いだ。

昨日は @drillbits の「作業用 BGM オブジイヤー 2021」だ。

はじめに​

みなさんは、新型コロナ感染症の蔓延による日々の外出が強く制限される生活には、もう慣れただろうか。

僕自身は、元々引きこもりがちで何か理由がない限りは家から出たくないタイプの人間なので、この世の春を謳歌している。

僕が所属する会社は、この状況に対して極めて柔軟に対応してくれているので、両手で収まる程度しか会社に出社せずに済んでいて、ほぼフルリモート生活である。ありがたいことだ。

とはいえ、引きこもり生活において一切の不自由がないとは言い難い。

以前は、腹が減ったら気ままに家から出て飲食店に入ったりしていたものだが、今はそういうわけにはいかない。

勿論、調子がいい日は真面目に飯を作って食うわけだが、一年中調子が良いってわけにはいかないだろう。

何せ MtG の新しい拡張は三ケ月に一回は発売されるし、Steam には毎月のように面白そうなゲームが発売される。既に買ったゲームの拡張がでることもある。

Kindle ストアには僕がまだ読んでない漫画がいくらでも並んでいる。そうそう Netflix に見たい動画が沢山あるけど、どれも手を付けられてない。

たまには仕事が立て込んだりもする。

そういうわけで、手軽に飯を食いたいと考える日は多い。

このエントリでは、手軽な食事として最近活用している冷凍食品のデリバリーサービスをいくつか紹介しようと考えている。

旬をすぐに​

うちでは旬すぐさんと呼んで定期的に利用している。

旬すぐさんを利用する理由の根本的な部分は安価であることだ。つまり、過度な品質を期待してはいない。

とはいえ、食事として満足できるくらいの味ではあるので、月に一回程度は発注している。

そして、旬すぐさんには明確にハズレがある。そう、旬すぐさんを使うにはいくつか抑えるべきポイントがあり、それを外すと酷いものがくるのだ。

まず、揚げ物類は絶対にダメだ。恐らくこれは冷凍食品というものが揚げ物と相性が悪すぎるということであって、旬すぐさんだけの問題ではないのだろう。

次に、「～～丼」のようなおかずとごはんが合成された状態でパッケージされているものもダメだ。話にならない。

最後に、「～～汁」や「～～スープ」のような汁ものを頼むのもご法度だ。具の少ない何か残念なものが届く。ガッカリしたくなければ頼まないことだ。

どうしても汁ものが飲みたければ、フリーズドライのスープを Amazon で箱買いすべきである。

細かいのが色々入ってるセットは楽しいがおススメはしない。

何が自分に合ってるのか探すには色々食べられるのでいい。しかし、冷凍庫の中でかさばる。

旬すぐさん攻略の鍵​

旬すぐさんで注文すべきは肉団子系と煮込み系だ。鳥団子やハンバーグ、つみれや、もつ煮込み、そういったものを頼むと外れない。

あと、指定時間通りに温めて綺麗に解凍される等と考えてはいけない。30 秒や 1 分程度指定時間より長めに温めることだ。肉団子や煮込みはそういうことをしても問題は起きない。

そして、商品を食うたびに忘れてはいけないことがある。「旬すぐチャンス」だ。これは 2 次元バーコードをアプリで読込み、ガチャを回し当たると白飯が無料で貰える。

「旬すぐチャンス」が付いている商品とそうでないものがあり、どういう基準でそれらが付与されているのか僕には分からないが見逃さないようにすることだ。

商品購入時には「旬すぐチャンス」が付いているかどうかは表示がある。ガチ勢の皆様におかれましては、狙っていくといい。

先ほど、丼系はおすすめしないと書いたが、単品の白飯は結構いい。特に無料で貰えることを考えれば十分な品質の白飯が届く。

とはいえ、白飯は炊き立てが旨いし、うちには炊飯器があり米を炊くことはそれほどの手間ではないので、旬すぐさんの白飯に直接金を払ったことはない。

フライパンそうめん​

今年かなりネットでバズっていたので、フライパンでそうめんを茹でる方法についてご存じの方は多いだろう。

そうめんはもう茹でないでください！！

深めのフライパンにお湯を沸騰させ、そうめんを入れて10秒だけかき混ぜたら火をすぐに止めてフタをするだけ。数分後にはちゃんとそうめんになっています！

沸騰させ続けるよりもヌメリが少なく、つるんと美味しい仕上がりに

何より、暑くないのが良いです！！ pic.twitter.com/SvoO3zAYwX

— Swind/神凪唐州@作家・名古屋めし料理家・ライター (@swind_prv) June 25, 2021

この方式は本当に便利で再現性が高く旨いそうめんが食える。完全に最高。

そして、うちでは茹でたそうめんを水洗いした後に、温めた旬すぐさんをかけて食っている。これは手軽で滅茶苦茶旨い。

僕としては和風の鳥団子系をそうめんにのせるのが気に入っている。

茹で野菜​

冷凍食品を食うくらいのメンタルだが野菜を茹でるくらいのパワーが残ってることはある。

そういう時は、一口大に切ったブロッコリーを雑に旬すぐさんに混ぜて食うと栄養バランスが大きく改善するのでおすすめだ。

CHEFBOX​

定期利用というかサブスクリプション契約して使っているのが CHEFBOX だ。

CHEFBOX は凄いサービスで、何が届くのかを具体的に指定できない。紙製の弁当箱の中に冷凍されたおかずと主食が入った状態で届く。

サービス契約する際に、苦手なものやアレルギー、飯部分をブロッコリーにするかどうかを指定できる程度である。

そうすると、定めた期間ごとに旨い冷凍の弁当が届く。

僕が CHEFBOX を食うのは、特に疲れ切っていたり、気になる事があったりして、飯について全く何も考えたくない時だ。

何も考えたくないが、旨いものは食いたい。そういう矛盾した精神状態というのが、僕には時々ある。みなさんには、そういうことは無いだろうか？

そういう時にカップラーメンを食ってしまうと立ち直れなくなってしまう。そうなってしまうと、人生について考え直すふりをしながら、何時間も口を半開きにして twitter で猫画像をファボり続けるような廃人が誕生することになる。

勿論、今の僕には CHEFBOX があり精神が安定的な状態なので twitter で猫をファボり始めても 30 分程度で満足して現実に戻ってこれるので問題ない。

要は CHEFBOX は旨い上に栄養バランスに優れているので、極めて高い満足が得られる。満足した腹を抱えて冷静になったところで、風呂に入り歯を磨いて布団で寝られる。

以前は、密閉されていない状態で届くのが不満だったが、パッケージが改善されて密閉された状態で届くようになった。

最初の届いた時の見栄えは、以前のパッケージが良かったように思うが、初回だけの話だ。継続的に頼むなら新しいパッケージの方が断然いい。

具体的にはこんなふうにパッケージされている。

で開くとこうなる。

完全に旨い。飯の写真は無いが五穀米なので腹もちがよいので間食する頻度を低減できる。

不満があるとすれば、少し味付けが濃いことだ。とはいえ、カップラーメンほどの濃さがあるという訳ではなく完全に好みの問題だ。

スターゼンカナダ産冷凍バラスライス​

最後はピンポイントな商品の紹介だ。これは冷凍バラ肉を一切れずつ丸めてあるので、滅茶苦茶使い易い。

スライスの生肉を、ジップロックに入れて冷凍することが多いのだけども、この丸まった豚肉の便利さは是非みなさんに体験して欲しい。

鍋だろうが、炒め物だろうが、煮ものだろうが、雑に袋から食いたい量だけ出して使えるというのは非常に素晴らしい冷凍肉体験だ。

スライスされていて火が通り易いので調理前に電子レンジで解凍してから使う必要もない。

まとめ​

このエントリでは、日常使いの旬すぐと、ちょっといいものとして食べている CHEFBOX を紹介した。

オマケとして冷凍バラ肉も紹介したが、これはこれで実にいいものなので、このエントリを読んだ人は試してみて欲しい。

恐らく近所のスーパーで買えるだろう。

それでは、みなさま良い年末を。

Docusaurus とは​

Docusaurus は、Facebook がリリースしているソフトウェアやライブラリのランディングページ用静的サイトジェネレータだ。 React ベースで実装されていて、デフォルトのテーマが結構いい感じなのでリファレンスやマニュアルをホストするサイトでは使い易いと話題になることが多いので使ってみたくなった。 例えば、React NativeやJestはDocusaurusでランディングページが実装されている。

Eleventyも少し試してみたが、機能性がプリミティブ過ぎて辛いので早々に諦めた。サイトのデザインを細部までこだわるなら Eleventy の方が良いだろう。

良くなったこと​

Table Of Contents が見やすくなった​

右側のサイドメニューに見やすい形で TOC が表示されるようになったのには非常に満足している。 特に現在読んでいる部分の色が変わっていくのが特に気に入っている。

今までは、markdown ファイルの一部として TOC を書いていたので、一番先頭に TOC があるのみである程度スクロールしてしまうと TOC が見えなくなっていた。 モバイルで見ると TOC は表示されなくなってしまったが、そこはデメリットとして受け入れることにした。

Progressive Web Apps に対応した​

Docusaurusでは公式な PWA プラグインがリリースされているので非常に簡単に対応できた。

Hexoにもhexo-pwaがあるので対応できる。

Code ブロックにコピペ機能が付いた​

Code ブロックを書くだけで、そのコードのコピペができるようになったのは凄く便利だと感じている。

Code ブロックの上にマウスカーソルをホバーすると右上のあたりにコピーというボタンが表示されるので、押すとクリップボードにコードがコピーされる。

console.log("Hello, World");

失われたこと​

AMP 対応​

Hexoにはhexo-generator-ampがあるので簡単に AMP 対応できたが、Docusaurusにはそういう仕組みが無いので簡単には対応できない。

関連エントリの表示機能​

Hexoにはhexo-related-popular-postsがあるので簡単に関連エントリを出せたが、Docusaurusにはそういう仕組みが無いので簡単には対応できない。

Docusaurus に対する不満​

Infima が扱いづらい​

Docusaurusが使っているInfimaという CSS Framework は、正直かなり奇妙な動作をする。

例えば、Spacing の css として以下のようなものが定義されている。

.margin-top--none {
  margin-top: 0 !important;
}

.margin-left--xs {
  margin-left: 0.25rem !important;
}

.padding-vert--md {
  padding-top: 0.5rem !important;
  padding-bottom: 0.5rem !important;
}

.padding--lg {
  padding: 2rem !important;
}

詳細な仕様は Spacing を確認して欲しいが、正直言って私には奇妙に感じる。

モバイル対応でパフォーマンスが悪い​

React のランタイムがゴソっとダウンロードされるのでファーストページビューにかかる時間が非常に大きい。

単なる静的コンテンツを並べているだけのサイトで 600ms とかかかるのはやり過ぎ感は否めない。

検証に使ったツール​

新しくサイト構築をしたら最新のベストプラクティスに従った作りになっているかを検証するツールを使う。

今回は、この三つのツールを使ってみた。基本的には PageSpeed Insights だけ使えば良いと思う。

• PageSpeed Insights
• WebPageTest
• GTmetrix

WebPageTest には CSP ヘッダがねぇぞって怒られるんだけども対応は諦めた。 Google Analytics を使ってる状態でちゃんと CSP ヘッダを使おうとすると nonce を付けないといけないが、そのためのサーバを用意したくなかった。

来世では頑張っていくという気持ちはある。

まとめ​

ブログを書きたいなら、自前でブログサイトを実装するのではなく SaaS を何か使いましょう。

例えば、はてなブログとか、Medium とか、世の中色々ある。

自前でブログサイトを実装するのは手段が目的になるタイプの人間だけにおすすめしたい。

はじめに​

皆さんこんにちは。世界は疫病に覆われ行動変容を余儀なくされていますが、いかがお過ごしですか？

私は元々引きこもり体質で、家からできる限り出たくないタイプの人間なので我が世の春を謳歌しています。

このエントリでは、私が今年一年かなりの時間を使ったゲームである Factorio を拡張して便利にしてくれる MOD の紹介をします。

Factorio​

そもそも Factorio というゲームをご存じでしょうか？

Factorio は、SF 的な世界観のゲームです。ゲームは不時着した宇宙船の横に一人だけで佇む主人公がいる所から始まります。（オンラインマルチプレイもあります。）

この不時着した惑星では、何故か鉄や銅、石炭といった資源が地表面に露出しており簡単に鉱石として掘り出せるのです。

そうやって掘り出した鉱石を溶かして機材を作り、設備を作り、それらを組み合わせて最終的には母星に対して SOS を送るためのロケットを打ち上げる。

そんな巨大なシステムを運用するには自動化が必須です。そうです、Factorio は自動化するゲームなのです。

興味が沸いてきたら、公式 Wiki のクイックスタートガイドを読んでみてください。

すぐにでも遊んでみたいという気持ちになったら、まずはデモ版があります。サイトは英語ですが日本語の UI で遊べますよ。

• Factorio のダウンロードページ

初心者がゆっくりやっても 50 時間くらいでロケットは打ちあがると思います。

もしこれが楽しいと感じられるなら、もう後は何百時間でも引きこもっていられるでしょう。

何故でしょうか？それは、とても成熟した MOD のサポートと、それを提供するコミュニティがあるからです。

特に大型 MOD と呼ばれるタイプのものは、ゲームを何段階も複雑にします。

PyMods​

私は今、PyMods という一連の MOD をインストールして Factorio を遊んでいます。

この MOD は、Factorio をとてつもなく重厚長大にしてくれるものです。

どんな内容なのかは、以下のエントリを読むと雰囲気が掴めます。

• Factorio - PyMods @ 2020-07-18

少なくとも Factorio で一度以上はロケットを打ち上げたことが無いと何を言っているか全く分からないでしょう。

そして、今日紹介するのは、PyMods をやるようなプレイヤー向けの MOD です。

Train Supply Manager（TSM） とは何か？​

一言で言うと、Factorio における列車の運行制御を効率化するための MOD です。

列車の運行制御を効率化する MOD としては、LTN - Logistic Train Networkが有名です。

こちらは日本語での解説文書や、解説動画が沢山揃っているので、探せば情報をすぐに見つけられるでしょう。

このエントリで紹介する TSM は LTN に比べるとかなり新しい MOD でユーザ数が少ないためか、日本語での情報がほとんどありません。

前述の、PyMods を紹介している ossan が書いたエントリがほぼ唯一の文書と言っていい状況です。

• Factorio @ 2020-08-27
  • TSM を選んだ理由が説明されているエントリ
• Factorio - Train Supply Manager (TSM) @ 2020-09-04
  • TSM の使い方を説明したエントリ。ちょっと分かりづらい。

このエントリでは、私が TSM を理解する過程で ossan の説明では分かりづらかった部分や誤解した部分を再構成して説明します。

TSM を理解するにあたって、私が一番に誤解していたポイントは、Train Supply Manager の Supply が何を指すか？です。

これを、当初私は貨物列車に積載された資源を Supply するのだと勘違いしていました。

しかし、TSM はそのように動作しません。TSM が Supply するのはあくまでも Train つまり列車です。

そして、TSM は列車の停車駅および、そこでの待機条件を自動的に挿入したり削除したりするだけの MOD です。

これが、LTN との根本的な違いであり、TSM の動作が LTN に比べて軽い理由です。

TSM の使い方​

ここからは、TSM の使い方を説明します。ここでは、Factorio において鉄道を使いたくなる典型的な状況に沿って説明します。

ちなみに、Factorio で TSM を使い始めるには MOD としてインストールした後に、ゲーム内で TSM というテクノロジーを研究してください。

TSM の典型的な利用状況​

資源の採掘地と消費地が離れており、消費地では常に資源が要るわけではない、という状況です。

この状況では、列車は待機用の駅で出荷を待ちます。とは言え、大抵の場合に出荷すべき資源は溢れているので待機時間は限りなくゼロに近いでしょう。

待機駅にいる列車は、資源を出荷したい駅に移動して鉱石などの資材を積み込みます。

その後、当該資源を要求されるまで別な待機用の駅で待つことになります。資源を満載して待っている列車は、消費地から呼び出されればすぐにそこへ向かって移動していきます。

まずは、駅の配置を全景しておきましょう。5 つの駅が配置されていますね。

駅の配置​

TSM は列車の運行制御を行う MOD なので駅の配置から始めます。

空の列車用 Supplier Train Stop の設置​

貨物を何も積載していない列車が停車する駅を配置します。地図上では、中央上部で EmptySupplier と表示されています。

大きくSの字が刻印されている Supplier Train Stop を設置しましょう。

TSM において要求待ちをする列車が停車する駅が Supplier Train Stop です。これは、TSM 独自のオブジェクトです。

出荷用 Requester Train Stop の設置​

次は、貨物を積載するために列車が停車する駅を配置します。地図上では、右側で IronProvider と表示されています。

大きく R の字が刻印されている Requester Train Stop を配置します。これは、TSM 独自のオブジェクトです。

加えて Requester Train Stop の隣に Train Requester を配置します。ランプのような見た目をしていますが、これは、TSM 独自のオブジェクトです。

そして Train Requester の隣に Decider combinator （条件回路）を配置します。このオブジェクトは Factorio に標準搭載されているものです。

Train Requester と Decider combinator を配置したら、それらと駅をケーブルで接続します。

列車に積み込みたい貨物が入った箱と Decider combinator もケーブルで接続しましょう。

出荷用 Requester Train Stop における信号制御​

Requester Train Stop における回路ネットワークを構成したので、次はそれらを流れる信号制御を設定します。

まずは、Decider combinator をクリックして信号制御のダイアログを表示します。

ここでは、iron ore が 1000 個より多く箱に入っている場合に、緑のチェックシグナルを送出し続けると設定しています。

条件式における不等号の向きに注意してください。

次は、Train Requester をクリックして信号制御のダイアログを表示します。

ここでは、緑のチェックシグナルが入力されたら列車を要求する信号を送出すると設定しています。

条件式における列車アイコンと緑のチェックシグナルの位置に注意してください。列車アイコンが左辺です。

これで、EmptySupplier に待機している列車を IronProvider に要求する準備ができました。

荷物を積載した列車用 Supplier Train Stop の設置​

IronProvider で貨物が積載された列車が停車して、その貨物を消費したい駅からの要求待ちをする駅を配置します。地図上では、中央下部で FullSupplier と表示されています。

大きくSの字が刻印されている Supplier Train Stop を設置します。

TSM では、このように荷物が積載された列車が待機するので、要求に対して迅速に応答できるのです。

荷下ろし用 Requester Train Stop の設置​

最後は、貨物の消費地を設置します。地図上では、左側で IronConsumer と表示されています。

大きく R の字が刻印されている Requester Train Stop を配置します。

この例では、分かりやすさのために、供給用車両が待機している駅と消費地の駅を 1:1 で対応させています。

実際の運用では Supplier Train Stop 1 つに対して Requester Train Stop を複数設置できますし、その逆も可能です。

このように列車を必要に応じて行ったり来たりさせるような設定を自動的に行うことが TSM の主たる機能です。

荷下ろし用の Requester Train Stop でも、Train Requester と Decider combinator を配置しケーブルで接続します。

荷下ろし用 Requester Train Stop における信号制御​

荷下ろし用の Requester Train Stop でも信号制御を設定します。

まずは、Decider combinator の設定をしましょう。

ここでは、箱の中に入ってる iron ore が 200 個を下回ったら、緑のチェックシグナルを送出し続けると設定しています。

不等号の向きが出荷用の駅とは逆になっているので注意してください。

Train Requester の設定は出荷用の駅と同じです。

これで、FullSupplier に待機している列車を IronConsumer に要求する準備ができました。

燃料補給用 Train Stop の設置​

列車が走り続けるには、燃料の補給が必要です。

最初に列車を動かし始めるための燃料は手作業で充填しますが、その後は自動的に充填したいですよね。

それに対して、TSM では FuelStop1 という名前の Train Stop を設置すると、必要に応じて列車の巡回ルートの中に燃料補給駅を組込んでくれるのです。

燃料補給の閾値を変えたいなら、Mod settings の Map タブに設定があります。

列車に充填されている燃料の数が、Minimum Refuelling Amount を下回ると燃料補給駅に停車します。

列車の巡回ルートを設定する​

駅を配置したので、次は列車を配備しましょう。列車は、EmptySupplier より少し手前に配置するのがコツです。

列車をクリックすると巡回する駅の設定画面が表示されます。駅の設定画面における初期状態は何も設定されていません。

これに対して、巡回させたい Supplier Train Stop を設定します。今回は、EmptySupplier と FullSupplier です。

これらの駅で列車がどう振舞うかは TSM が決めますので、最初の設定状態としては、それぞれの駅では列車が永久に停車するよう設定します。

ここでは、待機条件（wait condition）を Circuit で不特定の資源が 0 個未満である時、停車し続けるという風に設定しています。

プログラミングなら、while(true){}と書いているようなものですね。

この画像では、運行制御が Manual になっていますが自動運行を開始する際には燃料を充填したうえで Automatic にします。

貨物積載待ち列車用の Supply Source Priorities を設定する​

Supply Source Priorities とは、各 Supplier Train Stop に停車している列車の振る舞いを定義し、優先順位付けする設定項目です。

TSM の設定で最も複雑で難しい部分は、この Supply Source Priorities の設定です。これを理解して乗り切れば後は、自由自在に列車を自動運行できますよ。

ここからは、TSM 固有の UI を使って設定します。TSM のメニューを表示するには画面の右上あたりにある列車アイコンのボタンを押しましょう。

TSM のメニューを表示したら、左から三番目にあるオレンジ色の上向き矢印をクリックして、Supply Source Priorities のダイアログを表示します。

ここでは、Resource と Id と Station List を設定します。

Resource には、Supplier Train Stop から発車した列車が Requester Train Stop で停車する際に参照する貨物の種類を設定します。ここでは、iron ore を設定しました。

Id には、Resource と組合せて Train Requester が、Supplier Train Stop を一意に識別するためのアイコンを設定します。ここでは、Empty を意味するE を設定しましたが、単に名前付けするための設定なので何でもいいです。

次は、StationList の-- Select -- ボタンを押すと表示されるダイアログで Wait Conditions（待機条件）を設定していきます。

ここで設定できる条件は、どれか 1 つでも満たすと待機状態を終了する（OR）か、全てを満たすまで待機状態を継続する（AND）です。

二行目の Include は、貨車の状態が空（Empty）か満タン（Full）を条件にしたい時、チェックボックスを有効化します。

三行目の Inactivity は、設定された数値の期間列車に対して操作が行われないことを条件にしたい時、チェックボックスを有効化します。単位は秒です。

四行目の Wait timer は、設定された数値の期間が経過したことを条件にしたい時、チェックボックスを有効化します。単位は秒です。

五行目の Count は、Supply Source Priorities で設定した Resource が貨車の中にどれだけあるかを条件にしたい時、チェックボックスを有効化します。単位は個数です。

それでは、Wait Conditions を設定してみましょう。

ここで設定する Wait Conditions は、EmptySupplier に停車していた列車が要求されて IronProvider に移動して停車している間にどのように振舞うかを設定しています。

貨物の積み込みを行うので貨車が満タンになれば作業を終了して、次の駅に移動して欲しいので、Include は Full です。

次に、駅の箱に入っている資源が枯渇した場合にも正しく動作できるよう Inactivity を 5 秒に設定しています。これによって、iron ore が箱から無くなって 5 秒経過すると列車が発車します。

そして、貨車に積み込まれた iron ore の個数が 1000 個を超えたら列車が発車するように、Count を > で 1000 に設定しています。

お気づきのことと思いますが、この条件は最初の Include と内容が重複しています。貨車には 1000 以上の iron ore を積載できますが、この設定によって 1000 個の iron ore が積載された時点で列車が発車します。

最後は、ここで設定した Wait Conditions を適用する駅を選択しています。今回は、貨物を何も積載していない列車が停車する駅である EmptySupplier ですね。

Wait Conditions を全て設定したら、最後は Save ボタンを押します。

これで、貨物を積み込むための列車が停車している駅である EmptySupplier の設定が終了しました。

出荷用の駅に列車を呼ぶために Train Requester を設定する​

TSM の設定はいよいよ大詰めです。ここでは、Supply Source Priorities で設定した駅から列車を呼び出すための設定をしていきます。

まずは、EmptySupplier で待機している列車を、IronProvider に呼び出す設定をしましょう。

TSM の専用メニューにある左から二番目の Train Requester ボタンを押すと Requesters の一覧が表示されます。

ここでは、IronProvider で設定した Train Requester に何も割り当てられていないことが表示されていますね。

Requesters で、e ボタンを押すと Train Requester に Priority Schema を設定するダイアログが表示されます。

ここでは、iron ore を搭載するため EmptySupplier に待機している列車を呼び出したいので左側に iron ore を、右側にEを設定しています。

これによって、列車が以下のように動作します。

• IronProvider に設置されている Train Requester が Decider combinator からの信号によって有効化されると、
• EmptySupplier で待機している列車が IronProvider にやってきて停車します。
• 駅でインサータなどが動作した結果、Supply Source Priorities に設定された Wait Conditions が満たされたら、
• 列車は FullSupplier に向かって発車します。

貨物荷下ろし待ち列車用の Supply Source Priorities を設定する​

荷物を満載した列車が停車している駅である FullSupplier についても設定していきましょう。

まずは、Supply Source Priorities ですね。

Resource には、Supplier Train Stop から発車した列車が Requester Train Stop で停車する際に参照する貨物の種類を設定します。ここでは、iron ore を設定しました。

Id には、Resource と組合せて Train Requester が、Supplier Train Stop を一意に識別するためのアイコンを設定します。ここでは、Full を意味するF を設定しました。

サクサクいきましょう。次は、FullSupplier 用の Wait Conditions（待機条件）を設定していきます。

貨物の荷下ろしを行うので貨車が空っぽになれば作業終了です。そうしたら、次の駅に移動して欲しいので Include は Empty を選んでいます。EmptySupplier で設定した内容とは逆ですね。

次に、荷受け用に用意された駅の箱が満タンになっても正しく動作できるよう Inactivity を 5 秒に設定しています。これによって、iron ore を貨車からインサータが取り出さなくなって 5 秒経過すると列車が発車します。

この Wait Conditions を使用する駅は、FullSupplier でしたね。

荷下ろし用の駅に列車を呼ぶために Train Requester を設定する​

これが最後の設定です。TSM の専用メニューにある左から二番目の Train Requester ボタンを押して Requesters の一覧を表示します。

IronConsumer で設定した Train Requester に何も割り当てられていないことが表示されていますので、Priorities Schema を設定します。

iron ore を貨車に積んで FullSupplier で待機している列車を呼び出したいので、左側に iron ore を、右側にFを設定しています。

お疲れさまでした。これで TSM の設定は完了です。

TSM で運行制御された列車の動作確認​

列車がどのように動作していくのか確認していきましょう。

まずは、列車に燃料を積んだ上で運行制御を Manual から Automatic に変更します。

そうすると、EmptySupplier 駅の少し手前に配置した列車が動きだします。ここでは、まだ TSM は動作していません。

EmptySupplier に列車が停止すると、TSM によって IronProvider への運行がスケジュールされます。

EmptySupplier で設定した Supply Source Priorities の Wait Conditions が適用されていますね。

IronProvider に停車した列車に iron ore が積み込まれていきます。

iron ore が 1000 個貨車に積載されることで Wait Conditions を満たした列車は、IronProvider を発車し FullSupplier を目指します。

FullSupplier に列車が停車すると、TSM によって IronConsumer への運行がスケジュールされます。

FullSupplier で設定した Supply Source Priorities の Wait Conditions が適用されていますね。

IronConsumer に停車した列車から iron ore が積み出されていきます。

iron ore が全て出荷されることで Wait Conditions を満たした列車は、IronConsumer を発車し EmptySupplier を目指します。

最初の駅に戻ったので、後は燃料が不足するまで同じことを繰り返します。

燃料が不足する場合​

IronConsumer で停車中に燃料が不足している状態になったらどうでしょうか？

FuelStop1 への運行がスケジュールされます。

iron ore が全て出荷されることで Wait Conditions を満たした列車は、FuelStop1 を目指します。

FuelStop1 へ無事到達した列車は燃料の補給を受けます。

燃料が満タンになったので、EmptySupplier を目指して発車します。

上手くいかないときの確認点​

TSM には、それなりにややこしい部分があります。始めて使うときは細かい作業ミスによって、列車が思うように動いてくれないこともあるでしょう。

私自身、勘違いや作業ミスで列車が動かないことが多数ありました。

ここでは、私が実際に遭遇した作業ミスと対応策をまとめましたので、必要に応じて参照してください。

列車が走りださない​

列車は様々な理由で止まったまま動かなくなります。

燃料を確認する​

列車が動かない時は、まず燃料を確認しましょう。

列車をクリックして表示される画面の Fuel（燃料）タブで、木材や石炭などを充填します。

列車の運行設定を見直す​

駅の再配置などで駅名が変わってしまったり、線路を付けたり外したりしているうちに列車が目的の駅へ運行不能になることはよくあります。

列車の Schedule（スケジュール）タブで、駅を再設定してみましょう。

TSM を使うのであれば、Supplier Train Stop を二つ設定するだけです。

ちなみに、TSM によって自動挿入される運行計画は消してしまっても、TSM の管理下で動き始めればまた追加されます。

Requester Train Stop の 状態を確認する​

Requester Train Stop には、最初から Constant combinator（定数回路） が組み込まれており、列車がその駅に停車しているかどうかを管理しています。

マニュアル操作で列車を Requester Train Stop に停車させたり、Requester Train Stop に停車している列車を作業途中に回収すると、Constant combinator の値がおかしくなったまま修復されないことがあります。

そういう時は、思い切って Requester Train Stop を再配置してみましょう。大体、それでなおります。

Train Requester が光らない​

Train Requester が光っていない Requester Train Stop には決して電車はやってきません。

Decider combinator (条件回路) の設定を見直す​

よくあるミスは、Decider combinator の不等号の向きが誤っていたり、評価しようとしている資源のアイコンを間違えていることです。

出荷用の駅では、箱に入っている資源の量が一定量を超えていることが条件になるので、不等号としては大なり（>）を使います。

逆に、荷下ろし用の駅では、箱に入っている資源の量が一定量を下回っていることが条件になるので、不等号としては小なり（<）を使います。

Train Requester の設定を見直す​

Train Requester に設定する列車アイコンの位置を間違えることもよくあります。左側に列車アイコンを設定してください。

列車が一瞬で発車してしまう​

列車が、どの駅でも停車して荷物が動き始める前にさっさと電車が走り出してしまうことがあります。

Supply Source Priorities の Wait Conditions の設定を見直す​

列車がすぐに走り出してしまうパターンでは、Supply Source Priorities の設定が誤っていることが多いので内容をよく確認しましょう。

Wait Conditions は、その条件が満たされると列車が発車します。私は、その条件が満たされている間は列車が停車していると誤解していて苦しみました。

おまけ：おすすめの便利な MOD たち​

最後に私が普段使っている MOD の中であまりゲームに強い影響がない便利な MOD を紹介します。

名前の横にある ★ の数 はおススメ度です。

• ★★★ 明確におススメ。チュートリアルが終わったあたりで導入してもいいくらい
• ★★ 一度くらいロケットを飛ばした後にはおススメ
• ★ 大型 MOD を導入したらおススメ

ゲームバランスに影響が無いもの​

ゲームバランスに対して影響のない MOD で特におすすめできるものです。

Factorio 自体はかなり洗練された UI のゲームではありますが、これらの MOD を導入することでさらに快適に遊べるようになります。

★★★ Alien Biomes​

Alien Biomesは、単調な森と荒地ばかりの Factorio に豊かな色彩をもたらしてくれる MOD です。

これを導入したゲームではマップを上を歩き回って新しい資源を探すのが非常に楽しい体験になります。

★★★ Bottleneck​

自動化という作業における解決しなければならない本質的な問題は、ボトルネックの発見と解消です。

Bottleneckは、生産設備の動作状態を赤、黄、青の三色で見やすく表示してくれる MOD です。

赤や黄色が表示されている設備は何らかの問題があって正しく動作していません。改善しましょう。

★★ FNEI​

FNEI は、アイテムのレシピや特定のアイムを使って作れるものを調べられる MOD です。

PyMods では作れるアイテムが非常に多いのでかなり重要な MOD です。

★ Helmod​

Helmod はアイテムの生産ライン計画を立てるための MOD です。

最終成果物に至るまでのステップ数が 5 段階くらいを越えたあたりから記憶しておくのは難しくなります。また使っている素材の種類が多いとそれぞれについて、生産工程が必要になりますので、短期記憶だけで工場のラインを構築するのは不可能です。

また、生産したい部材の生産量に応じて生産設備をいくつも並行稼働する必要がありますが、Helmod を使えば単位時間あたりの出力を設定するだけで、生産ライン上の設備をいくつ用意すればいいのか自動的に計算してくれます。

ゲームバランスに影響があるもの​

ここで挙げる MOD はゲームバランスに影響が少なからずあるものです。

とはいえ、PyMods のようにゲームバランスが根本から変わるようなものではなく、ちょっとした不満やストレスが解消されるようなものです。

★★★ Squeak Through​

Factorio の資材には大別するとベルトコンベア上を流れる固体と、パイプの中を流れる流体があります。

MOD を全く導入していないとしても、ベルトコンベア上は自由に歩けます。しかし、パイプは一切通過できないのです。

工場が大規模化してくると、流体を使うために所せましとパイプを並べる必要が出てくるのですけども、パイプを横切れないせいで、作業効率が非常に悪いのですよね。

そういう地味なストレスをSqueak Throughは、パイプを横切れるようにすることで解消してくれます。

最早、これなしに Factorio を遊ぶことなど考えられません。パイプを引いたせいで工場の中を遠回りするのは特に楽しい体験ではないのです。

★★ Long Reach​

工場の規模がある程度大きくなって、部分的な作り直しを始めると画面を遠景にして設備を沢山同時に置いたり撤去したくなります。

そうしたとき、Long Reachを導入すると、手の届く範囲を広げられます。

私は、大体 200 くらいの距離で普段使っています。

序盤から使ってしまうと、人力でアイテムを運んでしまいがちになり自分自身がベルトコンベアの一部になってしまう危険があるので ★★ です。

★ Adaptive Movement Speed​

実は Factorio には、レンガブロック系のアイテムを床に敷き詰めることで、その上を移動する際の速度を向上する機能があります。なので、工場の敷地内を歩き回るだけなら移動速度を上げる必要はほとんどありません。

しかし、PyMods のような大型 MOD を導入すると工場がとてつもなく巨大になります。その上、貴重な資源を探すために遠出する必要があります。

そういう状況では、Adaptive Movement Speedで、移動速度を上げるとゲームプレイが快適になります。

★ Factorissimo2​

Factorissimo2は、マップ上に工場用の建物を配置して、それをマトリョーシカのように入れ子にできる MOD です。

建物の中に配置したベルトコンベアや生産設備をまとめて拾い上げてアイテムとして運ぶこともできます。ある種のモジュール化が実現できる MOD という訳です。

まとめ​

このエントリでは、Factorio における鉄道の運行を自動制御する MOD である TSM を紹介しました。

MOD を全く入れていない Factorio において鉄道の能力は明らかにオーバースペックで、実際ほとんど使わなくてもロケットを打ち上げられます。

しかし、PyMods や Bob's Mods といった大型 MOD を導入すると話は全く変わります。それは工場が Mega Base と言われるくらいに大きくなるからです。

COVID-19 対策のワクチン接種が始まりましたが、少なくともこの冬の間は、それが有効に機能して COVID-19 が封じ込められるという所まではいかないでしょう。

つまり、必要最低限の外出だけで日々生活する必要があるのです。こういった状況では Factorio のように延々と作業できるゲームは非常に有効です。

このエントリが、大型 MOD を導入して Factorio を遊ぶ皆様の助けに少しでもなれば幸いです。

明日は、hirotaka hata です。

はじめに​

TypeScript は大変に素晴らしい言語で、僕の手によくなじむ。そのせいか最近はめっきり TypeScript ばかり書いている。

今回のエントリでは、僕がこの一年くらいの間に磨いた TypeScript のテンプレートプロジェクトについて説明する。かなり何度も使って必要十分なものだけを含めるようにしている。

しかし、僕の知識の偏りがそのままになっているので、万人に合うというわけではないだろう。

とはいえ、開発環境の初期構築はかなり面倒な作業なので参考にして貰えれば嬉しい。

細かい説明なんかよりもコードを見た方が早いってハードコアな方は、こちらへどうぞ。

• taichi/ts-template

OS とハードウェア​

テンプレートプロジェクトの説明をする前に、まずは僕の使っているハードウェアと OS について説明しておく。

Thinkpad X1 Carbon 2016 年モデルに Windows10 をインストールしてある。ハードウェアスペックは、こうだ。

• CPU i7 6600U @ 2.6GHz
• メモリ 16GB
• ストレージ SAMSUNG NVMe SSD 950 PRO 512GB

流石に三年も経つと同等のスペックのものがかなり安価に購入できるようになってきていると感じる。

この環境で、PC 版の LINE と Slack と VS Code と GitKraken を動かしているが十分に快適だ。

事前準備​

このテンプレートプロジェクトでは、事前に必要なソフトウェアとして、

• git
• Node.js
• yarn
• Visual Studio Code (VS Code)

が必要だ。それぞれインストールしておいて欲しい。

僕と同じように OS として Windows を使っているなら scoop を使って簡単にインストールできる。

尚、scoop については以前に書いたので、そちらを参考にどうぞ。cf. Scoop で Windows における開発環境構築を最適化しよう

ついでに git の GUI クライアントとしては、GitKraken がおすすめだ。

テンプレートプロジェクトについて​

それでは、早速プロジェクトの内容について説明していこう。

エディタ​

まずは、みんなが大好きなエディタの話題から取り上げるとしよう。

今、TypeScript の開発環境として一番強力なのは VSCode だ。

何せ VSCode 自体が TypeScript で書かれているので、機能不足を感じたら TypeScript で拡張が書ける。

加えて、入力補完やシンタックスハイライトも大変に優れている。

一部の機能については language server protocol 経由で他のエディタでも使えるというのも大変に素晴らしい。

また、開発も非常に活発で毎月のように最新版がリリースされる。リビジョン番号が上がってすぐはバギーで、一週間もしないうちに毎回パッチが降ってくるのがまた可愛い。

マイクロソフトらしく互換性に気を使ったリリースをしてくれるので、お気に入りの拡張がいきなり動かなくなることもほとんどない。

VSCode といえば拡張だけども、僕は別に拡張を山盛りして使っているわけではない。どんどん新しいものを入れてはいるが、使わないやつはどんどん消している。

なので、僕のローカルで長い時間生き延びた拡張だけをテンプレプロジェクトには推奨拡張として設定してある。

丁度いいので僕のおススメ拡張を軽く説明しておこう。

TSLint​

VS Code の TSLint 拡張は、エディタ用に作ったメモリ上の AST を流用してコード検査を行うので、コンピュータ資源を効率的に使える。

なので、動作が非常に高速で快適だ。これについては、後でも取り上げる。

REST Client​

ウェブアプリケーションやウェブに対して何か要求を送信するようなアプリケーションを作っているなら、こいつはマジで最高の拡張だ。

UI がシンプル過ぎるので一見すると、とっつきにくさはあるけども、分かってしまえばどうということはない。

どう使うのかを説明する。まずは、.http とか.rest みたいな拡張子のファイルを作って中に HTTP リクエストを書く。HTTP リクエストというのは、こういう感じだ。

GET https://www.google.com/

その行の上に Send Request というリンクが出てくるので、それをクリックする。

そうするとその HTTP リクエストが送信されて、結果を隣のタブで見られる。

ただ、それだけのものだ。HTTP ヘッダや POST ボディを付けたりもできる。

最近の HTTP リクエストは、GraphQL みたいに改行を伴う HTTP リクエストや Authorization ヘッダーをちゃんとつけないといけなかったりで、curl だけだとちょいとつらい。

以前から Chrome 拡張のPostmanを愛用しているが、REST Client が非常にお手軽なので気が付いたらこちらばかり使っている。

Regex Previewer​

正規表現を使うコードはソフトウェア開発において、ある種の油断というか矛盾というか、もやっとしたものが集約されやすい部分だ。

小規模な正規表現をチラっと使っているうちは特に問題がないのだけども、その小規模というのが曖昧で感じ方に大きな個人差がある。

正直言って、Regex Previewer を使って動作確認しないといけないような正規表現は小規模であるとは言えないだろう。

書いた本人は簡単なつもりで書いていても受け取った人間が、それを簡単だと感じるとは限らない。

そういう時、Regex Previewer はマジで便利だ。二週間前の自分は他人って話もある。

ノリノリで書いた正規表現のどこかに抜け漏れがあるんだけどヤバ過ぎてよく分からない、なんて愉快な事に遭遇したことは無いかな？僕はある。

EditorConfig for VS Code​

改行コードとタブやスペースをエディタ関係なく同じ結果になるよう調整できるツールが EditorConfig で、それの VSCode 版だ。

特に Windows ユーザと Mac ユーザが混ざっている開発チームでは、ちゃんと調整しておかないと地獄のようなことが起きるので、こういうツールで統一するのが望ましい。

ただし、改行コードやインデントを何にするかは、EditorConfig が決めてくれる訳ではないので十分に揉めてくれたまえ。

gitignore​

VSCode のエクスプローラ機能には、なぜ gitignore するメニューが標準でついて無いのかよくわからない。

頻繁に使うわけではないけど、無いと困る。これは、そういうちょっとしたツールだ。

パッケージ管理ツール​

パッケージ管理ツールとしては、デフォルトの npm もひところに比べると随分早くなったように感じる。しかし、やっぱりまだ yarn の方がキビキビ動く。

特にプロキシの内側にいるとそれを強く感じる。npm だとそもそもモジュールのダウンロードが終わらないことすらあるんだよね。

最近は、pnpm という新しいやつも出てきたけど、yarn ほど早くもないし便利でもないので使っていない。

蛇足だが、yarn は npm scripts を短いコマンドで実行できるところも気に入っている。

モジュールバンドラ​

モジュールをくっ付けたり圧縮したりするのに何を使うのか？というのは比較的ややこしい問題だよね。

一番人気なのは恐らく webpack だろう。ただ、こいつは凄い勢いで破壊的変更が入ってくるのでついていくのが大分しんどい。

二回メジャーバージョンアップに付き合ったが、正直もうやりたくない。はっきり言って、出来ることが同じままで名前を変えるみたいなことを頻繁にやらないで欲しい。 僕らはアプリケーションを開発しているのだから、ビルドスクリプトのメンテナンスに大きな工数をかけたくない。

どうしても webpack を使うなら、Next.js みたいに内部に webpack を抱え込んでいるツールにお任せしてしまうのが良いんだろうなぁと今は考えている。

設定ファイルをゴリゴリ書かなくてもそれなりに上手くバンドルしてくれるツールとして、Parcel が今はお気に入りだ。

Parcel 自体には設定ファイルが無く、設定が必要な時はその依存するツールの設定ファイルを読み込んで使うという動きをするのが大変に優れている。（例えば、TypeScript をビルドするときには、tsconfig.json を勝手に見つけて使う）

webpack に比べるとコード量も少ないしやっていることもシンプルなので、一度分かってしまえばどうということもない。

まぁ、シンプルであってイージーではないので、一度分かるまでが大変なのは間違いない。

適用範囲も広くウェブのフロントエンドから、AWS の Lambda 関数、バッチ処理と色んなケースで使える。一回分かれば色々使えるというのは、大変にありがたい。

破壊的変更の少ないバージョンアップをしてくれるので、ビルドスクリプト自体を延々とメンテナンスする必要もない。

Lint ツール​

TypeScript で真っ当に使える Lint ツールは３つある。

まずは、コンパイラのオプションを記述できる tsconfig.json で、新規のプロジェクトでこれに strict: true を必ず設定する。これによって、TypeScript を使ったプログラミングにおけるメリットを最大限に享受できる。

悩ましいのが、typescript-eslint を使うか、TSLint を使うかだ。

将来的に JavaScript の Lint は、eslint に集約されていくという事には同意する。しかし、それは今すぐという訳ではない。というのが僕の考えだ。

僕が TSLint を使い続けている理由はいくつかある。

tslint-microsoft-contrib が最高すぎる​

一番大きい理由はこれだ。僕のテンプレートプロジェクトでは、この巨大なルールセットから不要なものを無効化する形で TSLint のルールを構成してある。

TypeScript には、歴史的経緯により沢山の落とし穴があり、それらに対する十分な知識を僕は持っていないのだ。

なので、自動的に検出できるプログラミング上のミスは出来る限り沢山見つけてほしい。

例えば、僕は Promise のインスタンスを await し忘れるみたいな単純なミスも結構やってしまう。このルールセットなら即座に Lint エラーになるので不要なドはまりを避けられる。

また、tslint-microsoft-contrib は宣言の省略を基本的に許していない。つまり、これに従ってコードを書いていると、コード全量の三割から四割くらいが型宣言になってしまうことさえある。

慣れないうちは、冗長に感じるかもしれないがコードベースが大きくなるに従って、型の情報がコードを理解する強力な助けになることを実感できるだろう。

VS Code の TSLint 拡張が最高​

VS Code の TSLint 拡張は非常に高速に動作する。Lint ツールがエディタ上で迅速に動作するというのは開発作業における必須条件だ。

何故なら、Lint エラーは出力されてから出来る限り短い時間内に対処しなければ、結果的に対処されないことが多いからだ。CI サーバでエラーにしてから対処するのでは遅すぎる。

加えて、僕は自動的に解消できるエラーは全てファイル保存時に解決するという方針でコードを書いている。 セミコロンの自動入力や import 文の並び替え、タブからスペースへの変換などは頻繁に実行されるので、ちょっとでも引っ掛かりがあると、それぞれは短くても積み重なってストレスの原因になる。 なお、ファイルの保存は 15 秒に 1 回よりも早いペースで行っている。

TSLint 拡張は極めて迅速に動作するが、eslint 拡張は同じ速度感で動作しない。

僕としては、Lint エラーは基本的に全て手元で出来る限り早く手元で解消すべきだと考えているので、手元での動作が悪いツールは避けている。 もし、eslint 拡張が今の TSLint 拡張と同様の速度で動くようになったら、乗り換えるだろう。

テスティングフレームワーク​

テスティングフレームワークとしては、依然として AVA を使っている。

今からテスティングフレームワークを選ぶなら大方 Jest だろう。テスティングフレームワークとして求められる機能が全部入っているのだから選び易い。

好みの問題だが、僕は expect タイプのアサーションメソッドが本当に嫌いだ。これを使ったテストコードは英文のように読めなくもないが、実際には英文ではない。

また、やたらめったら比較のためのメソッドを覚えなければテストコードが書けないのも辛い。

加えて、 describe によるテストの構造化はスローテスト問題の発症を早めると僕は考えている。

TypeScript で用もないのに関数やラムダ式を延々と入れ子にするようなコードを気楽に書かせるべきではない。

そして、僕が Jest を使いたくない決定的な理由は、テストの実行が AVA に比べて数倍遅いからだ。

AVA については、以前のエントリにも書いたので、気になる方はそちらを呼んで欲しい。cf. Modern JavaScript 概観、そして Electron へ

便利ライブラリ​

次は、最近気に入ってよく使っている便利なライブラリを紹介しよう。

アプリケーション設定を記述する​

アプリケーションの設定を読み出すためのコードを書くのは正直面倒だ。

とはいえ、 process.env から直接読み出してしまうと、全部が文字列になってしまって型システムもへったくれもない。加えて、その設定を使う時まで設定エラーを見つけられない。

要は、設定を構造化して読みやすくまとめた上で、アプリケーション起動時に設定情報が全て正しく構成されているのかチェックしたいのだ。

こういう要件を満たす便利なライブラリが convict だ。型定義ファイルがよく出来ているので型付けされた設定を記述できる。ただ、これ単独だと環境変数の定義が若干面倒なので、dotenv を組み合わせて環境変数への設定をファイルにしている。

convict と dotenv を組み合わせて使う方法については、少し長くなりそうなのでここでは説明しない。もしどうしても説明が欲しいということであれば、twitter なり対面なりで、要望して貰えればエントリを書くかもしれない。

環境変数を積極的に使うやり方は便利だが、少し気を付けて使って欲しい。

例えば、CloudFormation なんかでアプリケーションをデプロイする際には、環境変数の中身をテンプレートに記述しなければいけなくなる。

そういう状況では、環境変数から設定情報を取り出して使うのは望ましくない。Secrets Manager みたいな場所から読んできた値を設定するようにした方がいいだろう。

convict では load メソッドを使うと、そういう状況に対応できる。

複雑な非同期処理を簡単に書く​

Node.js のランタイム上で動作するコードにおいて非同期処理を免れるのは非常に難しい。

とはいえ、async/await だけを使ってあらゆる非同期処理を書くのは大分つらい。

例えば、50 件ずつバッファリングされたデータが非同期で複数回送信されてくるのを一件ずつ処理する。みたいなコードを想像して欲しい。GitHub API の Paginationみたいなやつだ。

こういう時に使うべきライブラリとして知られているのは RxJS だ。しかし、RxJS を一たび採用するとあらゆる部分に影響を及ぼす。

RxJS を使ったコードの動作を最適化するには、RxJS を出来る限り広く使わざるを得ないのだ。

そして、RxJS の学習コストは極めて高い。

これに対して、出来る限り少ない学習コストで複雑な非同期処理を記述できるライブラリがstreaming-iterablesだ。RxJS ほどのボキャブラリは無いけども、それなりに難しいこともできる。

ライブラリに定義されている関数は generator はふんだんに使っていることを除けば単純なので理解し易い。

そういうわけで、RxJS に大きな学習コストを今すぐにはかけたくないが、複雑な非同期処理を書く必要があるなら streaming-iterables を試してみて欲しい。

ロギング​

ロギングライブラリというのは、作りやすいので氾濫し易い。

ただ、作りやすいこととちゃんと使えるものが作れることには余り関係がない。というか、まともなロギングライブラリを書くのは本当に難しい。

つまり、まともに動くロギングライブラリを見つけるのは難しい。だからといって、自前で実装するのは望ましくない、

というわけで、今の一押しロギングライブラリはpino だ。

こいつは、ログのデフォルト出力が JSON になってるあたりクラウドサービスを組み合わせた運用監視を想定した作りになっており大変に素晴らしい。

いざとなれば手を入れて使える程度に処理はコンパクトにまとまっているので、他のロギングライブラリに乗り換えるのも難しくはない。

少し前まで winston をせっせと使っていたが、内部で使っている logform で実装されている奇妙な遅延ロードの仕組みにドはまりして以来使うのをやめた。

なお、その問題に関する Issue はこれ。https://github.com/winstonjs/logform/issues/66

開発関連の SaaS​

最後に、テンプレートプロジェクトが利用を前提としている開発用 SaaS を軽く紹介する。

GitHub Actions​

以前はビルドが失敗した OS に SSH や RDP 接続できるので、CircleCI や AppVeyor を使っていたが、今は GitHub Actions に移行しつつある。

移行における最初のモチベーションは、マルチ OS 対応だ。GitHub Actions は裏で Azure Pipelines が動いているので、Linux と Mac と Windows を気兼ねなく使える。

特に、node のランタイムと OS の組み合わせでマトリクスビルドが超簡単に構成できるのには感動した。

Linux と Windows の両方でビルドするために、複数の CI 用設定ファイルを書いていたのだから、本当にありがたい。

また、イベント毎にワークフローの設定ファイルを分割するという方針も大変に良い。

更に、複数の構成で共通的に使う処理は、Action という形でモジュール化できるので、ワークフロー定義が肥大化するのを防げるようになっている。

Action は Docker を使えばなんでも出来るし、気軽に書くなら JavaScript や TypeScript でも書ける。リポジトリ内に Action を配置して動かせるので泥臭い処理の共通化を気兼ねなくできる。

ワークフロー定義の中で使える変数や、 if 文は少々奇妙なところもあるが、そこは我慢のしどころだ。

つい最近自分のプロジェクトで使うために TypeScript で書いた Action はこれだ。このコードを読めば、TypeScript を使って Action を作るとどういう感じになるのか概観できるだろう。

• approved-event-action

Renovate​

依存ライブラリを自動的に更新するツールは、僕も以前に作ったことがある。しかし、Renovate はそれらを大きく上回る便利さだ。

特に自動マージ機能や、検査対象ライブラリのフィルタ機能、設定を他のリポジトリから読み出す機能なんかが大変に素晴らしい。

モジュール毎に分けてプルリクエストが飛んでくるというのもマージし易くて良い。

勿論、CI をちゃんとセットアップしておけば、その結果を見てマージするのか判断してくれる。

類似するサービスをいくつか試してはみたが、結局 Renovate が一番最高ということになった。

それとは別に、GitHub が提供してくれるManaging security vulnerabilities の機能は有効化している。

加えて、yarn audit をデイリービルドの中で実行している。

まとめ​

今回は、僕が作った TypeScript のテンプレートプロジェクトについて長々と説明してきた。

最近は、ユーザインターフェースを作るようなコードは余り書いていないので、そちらの要素技術には言及できなかったのが少し悔やまれる。

テンプレートプロジェクトには入れていないが、aws-cdk はマジでお気に入りだ。

例えば、@aws/dynamodb-data-mapperでアノテーションしたオブジェクトをそのまま aws-cdk の construct として扱えるようなちょっとしたコードを書く程度には使い込んでいる。

内容に関する提案や、誤りの指摘、要望などがあるなら、Twitter などで連絡してくれると大変に嬉しいので気軽にメッセージを送信して欲しい。

TypeScript に限らず JavaScript 関連のフロントエンド界隈は、流れが随分と速いので余り無理せずについていきたい。そういう皆さんの助けに少しでもなれば良いなと考えています。

明日は、@drillbits です。

はじめに​

去年は、筋トレを始めた話を書いた。

この一年くらい途中で二回ほど離脱した時期もあったが、どうにかこうにか筋トレを継続できている。

と言う訳で、今日は僕が筋トレを継続できているという話をする。

現状確認​

身長や体重など​

殆ど何も変わっていない。素人がチョイチョイと一年くらいトレーニングした所で何かが変わったりはしないのだ。

体重は３～４ kg くらいは増加したように思うが、これがトレーニングの成果なのかはちょっと良く分からない。具体的に今の体重は、66kg±1kg くらいだ。

まぁ、３０代も後半なので衰えてないということだけでも評価して欲しいという気持ちはある。

尚、健康診断の結果における γGTP の値は大きく改善して 96 から 33 に下がった。まぁ、酒を飲まずにその時間をトレーニングに割り当てたのだから、そこだけは改善して貰わなければ本当に困るのだが。

トレーニング頻度と時間​

今は大体、週に３回から４回フィットネスジムに行き、週に１回程度クライミングジムに行っている。

行くたびに全身のトレーニングをするのは体力的にきつすぎるので、今は３回を１セットにして全身トレーニングするようにした。

つまり、胸の日、脚の日、背中の日だ。

胸の日​

胸の日は大体ベンチプレスを中心に体の前面を鍛えるようなイメージでやっている。

レッグレイズや、ハンマーカール、アームカールなどだ。ベンチプレスが空いてない日は、ダンベルプレスなどで代用している。

ジムに半球のボールのようなものに背中を付けてレッグレイズできる器具があるのを発見して以来、レッグレイズで腹筋を鍛えるのは少し自分の中で流行っている。

ベンチプレスは、最大で 40kg くらいなので、まだまだ初心者だと言える。成人男性の平均的な重量らしい。

脚の日​

脚の日はレッグプレスに向けて準備をするようなイメージでトレーニングしている。

ヒップアダクションやヒップアブダクションから初めて足が温まってきたらレッグプレスをやっている。最後にレッグエクステンションだ。

しかし、今は午前中にトレーニングをしている都合上、ギリギリまで追い込んだりはしていない。非常に残念だが歩けないと会社には行けないのだ。

そういう訳で、レッグプレスは 60kg くらいしか上げられない。脚の筋肉は体の中でも特に大きいのだから、もっと大きな重量を上げたいものだ。

背中の日​

背中の日はデッドリフトをする日だ。ストレッチをしっかりとやったら、まずデッドリフトをやる。軽いところから始めて重量を上げている。夕方にやるほどのパフォーマンスを朝に出せるだけの技量はまだ無いので、少し軽めだ。それでも、60kg 前後はあげられる。

その後に、ロー系の種目を一つ二つやって、背中の上側の筋肉を鍛えている。ラットプルダウンはどうにも苦手意識が抜けない。

なお、チンニングはやっていなかったら、あっという間に出来なくなった。本当に悲しい。背中の日はチンニングをやっているが、出来ても三回か四回くらいだ。３月くらいには１０回とかできてたのに…。

一年継続して分かったこと​

まず、文章にすると当たり前すぎて笑ってしまうような話だが、ウェイトトレーニングを継続すると重いものを持ち上げる技術が身につく。つまり、継続的に筋トレすると、筋トレが上手になる。

つまり、ウェイトトレーニングで得た筋肉がすぐに他のことに役立つわけではない。

ただし、フォームがしっかりと身につかないと負荷をかけらずにケガをすることになる。そして、その前提条件として体の柔軟性が一定以上必要だ。

一週間に一回程度は理学療法士のトレーナーにストレッチを手伝って貰うことで少しずつ体が柔らかくなってきた感じはある。

子供の頃から体が固く、立位体前屈で-10cm 以上を記録したことは無かった。つまり、立った状態で体を前に倒して、手が地面に付いたことがない。

最近は-5cm くらいをウロウロしているので、現在が人生で最も柔軟な体をしていると言えなくもない。

継続するのは難しい​

恐ろしいことに、筋トレで得られる筋肉は、日常生活ではほぼ全く使わないので、筋トレをしないとあっという間に失われる。

つまり、筋トレにおいて最も重要な要素は継続だ。しかし、みんな分かっていると思うが、筋トレを継続するには、とてつもない労力が必要になる。

僕の場合は、ジムに行くことに物凄い精神力を使う。ジムに行ってしまえば後は問題ない。ストレッチやら筋肉痛やらで痛かったりするが…。

色々試してみたが、どうやら継続的にジムに行くことを考えると、ジムに行く時間を夕方以降にするのは、どうやら無理っぽいということが分かってきた。仕事やら宴会やら、勉強会やら色々ありすぎて、ジムに行かない日がすぐに出来てしまう。そして、仕事終わりは精神力が失われていることが多いのでジムに行くための気力が無いことが多い。

そういう訳で、僕は午前中に短時間ジムへ行ってから働くことにした。今は二十四時間使えるジムが増えているので、こういう選択も取れるというのは大変素晴らしい。

お陰で夜寝るのがやたら早くなった。以前は、25 時くらいから就寝準備するような生活だったが、今は 22 時半には就寝準備している。遅くまで宴会をした日でもなければ、日付が変わる前に確実に寝ている。

知らなかった副作用について​

トレーニングでちゃんと追い込むと、風邪を引きやすくなる。特に脚のトレーニングをしっかりやった翌日や翌々日は風邪を引く。

体は疲労するし、筋肉痛を治すために体の栄養素が回されるわけで、免疫系が一時的に低下するのは理にかなっている。

つまり、筋トレが終わった後の手洗いうがい、歯磨きは本当に大事だ。

尚、風邪を引いて何日か筋トレに行かないと、獲得するのにかかった時間の半分くらいの速度で筋力は衰える。

期待した効果について​

健康な肉体を手に入れるという意味では、肉体が劣化する速度を低減できているようには感じているが、より若返っているというほどではない。

集中力を取り戻すという意味では、かなり取り戻せているように感じている。一日くらいなら大酒食らった後に徹夜でボードゲームするくらいのことは出来るところまで戻した。

週末に Magic Arena で 8 時間くらいノンストップで遊び続けるみたいなこともできている。

情報収集の方法​

筋トレやら健康やらの話は、兎に角デタラメな情報がネット上には溢れている。よくわからんサプリの類を売るために作られたアフィリエイトサイトみたいなやつが検索エンジンを完全に汚染しており話にならない。

そうは言っても、僕が読む限り真っ当なことが書いてあるように感じられるサイトはいくつかある。それが以下の二つだ。

• リハビリ memo
• 東原兄弟＠筋トレと栄養のサイエンス | Science for the Benefit of Muscle

僕自身は医療に関する専門教育を受けたことがあるわけでは無いので、彼らの書いてあることの正しさを検証する方法は持っていない。皆さん自分で判断して欲しい。

使っている器具​

基本的にはジムで運動しているので、家ではあまり何もやっていない。

ただ、ストレッチだけは家でも気が向いたらやっている。

色々器具の類は買った気がするが、結局継続的に使うものは限定される。

今でも使ってる器具はマジでおススメなので、使っていないなら是非試して欲しい。

• ストレッチポール
• ランブルローラー

飲んでいるサプリメント​

次は僕が今飲んでいるサプリメントの紹介だ。別に成果が出ていると言える訳ではないが参考なればと考えている。

ペプトプロ​

加水分解カゼインというやつだ。これは値段が少々高いがマジでおススメである。

「ガリは飯を食い忘れ、デブは飯を食ったことを忘れる」

というが、僕は完全に前者だ。一度に食える飯の量も少ない。別に体が動くなら半日くらい飲まず食わずでも特に辛さを感じたりしない。間違いなく健康には悪いだろうが。

そういうタイプにとって、ペプトプロはマジでおススメだ。こいつは水にすごく綺麗に溶けるので満腹感が一切ない。水分による膨満感は少しあるが、普通のホエイプロテインを飲んだ時とは比べ物にならない。

プロテインはタンパク質に過ぎず、他の食事をとらなくても良いという訳ではないのだから、プロテインをとることが、他の食事を邪魔しないというのは幸いなことだ。

Amazon で変な業者のやつが買えるが、公式サイトで買う方が安いし確実だ。

• ペプトプロ

最近パッケージが変わって、ベリーブラスト味が無くなってしまったのが問題だと感じている。

今はまだ、過去に買ったベリーブラスト味を新しいノンフレーバーに少し混ぜて飲んでいるが、これが無くなったらフレーバードロップを買おうと考えている。

オプチメン​

男性が必要なビタミンを中心とする栄養素の類が全部入ってるマルチビタミンと言われるようなタイプのサプリメントだ。錠剤が少し大きくて飲みづらいことを除けば一切の不満が無い。

こいつを毎食一錠くらいずつ飲んでいる。これを飲み始めてから数か月で InBody で計測できる体内のミネラル量が適正な量まで改善した。

• オプチメン

CCD​

トレーニング用のドリンクとしては、後で説明するパープルラスを足して飲んでいる。

ポカリスエットよりも甘さが弱いのと口の中のべたつきが少ないので気に入っている。単に砂糖といえば砂糖なので、粉飴でも良いのではないかと思うが、こちらの方が味も良い。

水でも十分に溶けるし泡立ちも無いが、35 度くらいのぬるま湯だとかなりきれいに溶ける。

• CCD

パープルラス​

こいつは EAA に加えて、ベータアラニンが含まれているのでトレーニング中のパフォーマンスが改善するらしい。CCD に加えて飲むと味が物凄く良くなるので気に入っている。

俗にいうアラニンショックという飲んでから、手足の先がちょっとピリピリするような感覚が飲み始めて二週間か三週間くらいはあった。しかし、今はもうない。量を増やしてみたりもしたがアラニンショックを感じられなくなった。栄養状態が良くなるとアラニンショックは無くなるらしい。

• パープルラス

プロテインクリスプ​

プロテインバーというやつだ。こいつは会社の自席に箱を置いて毎日一本ずつおやつとして食べている。何種類か味を試したが、チョコレートクランチが一番好みの味だった。

アメリカのお菓子なのに、甘みが穏やかなのが大変素晴らしい。

自席でペプトプロを飲んでいる時期もあったが、シェーカーの始末が面倒なのでやめてしまった。

コンビニで買ったペットボトルの水に漏斗で粉を注いで飲んでいた時期もあったが、やはり面倒になってやめてしまった。

• プロテインクリスプ

クレアチン​

クレアチンを定期的に摂取すると短時間で強度の高い運動においてパフォーマンスが改善するらしいので、せっせと飲んでいる。こいつは白いカプセルで一回二錠なのでちょっと大変だ。

何せオプチメンと合わせて毎食三錠もサプリを飲んでる状況なのだ。

以前よりパフォーマンスが改善しているかと言われると、なんとも言えないところなので特におすすめはしない。

• クレアチン

クリルオイル​

毎日とっている訳ではない。食事のなかで脂質が少し足りないかもしれないと感じた時にとっている。これ自体は、特に旨くも無ければまずくもない。

黒いカプセル錠なので極めて見た目が悪いが、見た目は少々悪くてもまぁ、問題は無いだろう。

• クリルオイル

まとめ​

という訳で、当初思ってたほどに体がデカくなったりはしていないが、継続的に筋トレできるようにはなったという話を書いた。

週三回安定してジムに行くということそのものがまだまだキツい感じはあるので、成果らしい成果が出るにはまだまだ時間がかかるだろうが、ゆっくりと確実にやっていきたい。

明日は、@shibu_jp です。

• 公式サイト
• Kickstarter の告知ページ

まず、Kickstarter の告知ページにある動画を見て欲しい。

幻想的な雰囲気のなか二足歩行し言葉を交わす森の動物達が最高にかわいい。

このゲームは、動物の町を作るゲームで、ルールの難しい部分は全部カードに書いてあるワーカープレイスメントだ。

1 プレイにかかる時間は４人で遊ぶと２時間前後。初めての時は、３時間弱かかる。

初期セットアップすると大体こういう感じになる。

ゲームの構造​

大まかなゲームのルール​

詳細なルールはルールブックを読んで欲しいが、雑に図示するとこうなる。

非常にシンプルな構造のルールである。

プレイヤーが自分の手番になったら出来るのは３種類のアクションしかない。

• ワーカーの配置
• カードのプレイ
• 季節の準備

ワーカーの配置​

ワーカーの配置では資源を得るか、得点を得るかを選べる。最終的には得点が欲しいのだけど、その前に資源を膨らませたい。

イベントカードで得点するには、あらかじめカードをプレイしておく必要がある。

• 通常のイベントカードは特定のカードタイプを指定枚数プレイすれば獲得できる。
• 特別なイベントカードは指定されたカード２枚をプレイすると獲得できる。

秋のみプレイできる旅アクションは、余った手札とワーカーを勝利点に変えられる。

このゲームはそれぞれの季節を出来る限り長くプレイする方が得点が大きくなり易い構造をしているが、旅アクションで高得点するには、他のプレイヤーよりも早く季節を進める必要がある。

カードのプレイ​

カードのプレイでは、建物カードか動物カードがプレイできる。

建物カードは、それぞれのカードによって小枝、松ヤニ、小石が必要になる。動物カードは、ベリーでプレイできる。もし、対応する建物をプレイ済みならベリーを払わなくてもいい。

カードのタイプは５色あり、それぞれ効果が機能するタイミングが違う。

• 茶は、盤面にあるカードやワーカーに触れるカードが多い。状況を変えられるのでプレイが少し難しい。
• 緑は、直接的に資源が発生するか、資源をその場で消費して何かするカードが多い。難しさはほぼ無く、見れば分かるものが多い。
• 赤は、カードをプレイした後にワーカーを配置することで機能するカードだ。派手な効果が多く、他のプレイヤーに使われてしまう可能性のあるものもある。
• 青は、条件が満たされると誘発する受動的なカードだ。例えば、建物をプレイした際に誘発する。効果が発生する回数が多いので、誘発忘れの無いようにプレイしよう。
• 紫は、特別な得点カードだが、盤面の状況によって獲得できる点数が違うので、強いことも弱いこともある。上手く自分の盤面とかみ合えば大きな得点になるのでプレイの指針になる。

季節の準備​

季節の準備はプレイ済みのワーカーを取り戻すアクションだ。

春と秋は緑の効果が発動する。夏は共有エリアからカードが獲得できる。

このゲームの面白いところは、全員が共通の森で町を作るゲームだが時間の流れは、それぞれ違うことだ。誰かが春のままなのに、誰かは秋が終わるといったことは起こりうる。

また、ワーカープレイスメントにおける最重要資源であるワーカーは季節の準備アクションでしか手に入らない。

大まかなゲームのプレイ構造​

ルールとは別にゲームプレイの構造を図示してみた。ルールがシンプルなのでプレイ構造も非常にシンプルだ。

ゲームの中心にあるのは、カードのプレイである。その準備として資源の獲得があり、その最終目的として得点の獲得がある。

一部の例外的な状況を除けば、ワーカーをプレイできる回数は全員同じである。

そこで獲得した資源によってプレイしたカードの相乗効果によって、より多くのカードをプレイ出来れば、多くの得点を得られる。

しかし、イベントカードは盤面に最初から提示される共有資源であるため、他のプレイヤーよりも効率よく条件を満たすことが望ましい。

類似するゲームは何か？​

• アグリコラ
  • 僕が最初に遊んだワーカープレイスメントはプエルトリコだが、繰り返し遊んだのはアグリコラだ
  • Everdell は最新のワーカープレイスメントゲームだ、但しアグリコラ程に繰り返しプレイできる強度を持っているわけではない
• ドミニオン
  • 元 MtG プレイヤーには心の底から刺さるゲームでパックを開けなくても類似した体験ができるので最高だった。今は Arena でしっかり MtG を毎日２時間くらいは遊んでいるので、引退した筈が復帰しているのであった…
  • 自分の町はデッキであり、そこに含まれるカードでコンボを作るという部分が似ている
• 世界の七不思議
  • ドラフトでカードセットを作るゲーム
  • 建物毎に無償で呼べる動物が設定されており、そのルールを上手く使うことで資源効率を上げられる部分が似ている

おすすめポイント​

このゲームのおススメポイントをまとめるとこうだ。

• イラストがとにかくかわいいし、コンポーネントの作り込みが半端ない
• 中心となるルールは単純でゲームの難しい部分は全部カードに押し込んである
• ワーカーで取った資源をカードにつなげて、そこから出力される資源で次のカードをいかに出すかを考えるのが楽しい
• 他のプレイヤーの状況を見ながら資源の拡大再生産する速度を調節するのが楽しい
• 資源の増加と速度調節はトレードオフなので正解はなく、終わった後に出来る動物の町を見て、もう一度プレイしたくなる

和訳ルールの入手方法​

• DUBDUB さんによる和訳ルール
• U 壱さんたちによる和訳カードの画像データ

ゲームのおすすめな遊び方​

1. 最初のゲームはビギナーバリアントで遊ぼう

• everdell-spring-forward-beginner-variant
• サイコロを振って初期資源が貰えるのと、ルールがややこしいカードは全部除外して遊ぶってだけだ。
• カードのルール解釈に振り回されることなく、ゲームルールと展開の把握に集中できる。

2. 通常ゲームは２ゲーム目から FAQ を手元において遊ぼう

• FAQ
• 公式ルール
• 5 人プレイ用のバリアントルールもあるよ

3. プレイヤーが十分に慣れてきたら２デックバリアントを試そう

• everdell-2-deck-7-wonders-style-variant
• 大雑把に説明すると、生産系のカードを前半だけ、得点系のカードを後半だけに登場するよう制限されるので、ゲームの展開がまろやかになる。

買い方​

• Amazon.com に Collector's Edtion と 通常版の在庫もある。
• Tabletop Direct Canada だと Standard Edtion が買える。everdell-standard-edition
• PledgeManager で買うと 2019 年 9 月出荷。pearlbrook-the-first-expansion-for-everdell/participate/

Standard Edtion をとりあえず買える方法で買って、PledgeManager で次の拡張と Collector's Edition のコンポーネントをまとめて発注するというのが良いかもしれない。

来年の 9 月まで待てるなら Collector's Edtion と拡張をセットで買っても良いと思う。

まとめ​

最近遊んだゲームで気に入っているのは、テラフォーミングマーズだ。

しかし、Everdell をジャケ買いしてからは、完全に意識を支配されていると言っても過言ではない。

最初に Everdell をプレイした日は、そのまま連続してプレイし続け朝を迎えたくらいだ。

僕が観測する範囲では、Everdell は日本に１０個くらいしか入ってきていないのでは無いかと思う。

本当に雰囲気が良くて面白いゲームなので、みんな是非輸入して遊んで欲しい。

ここ最近は、SUN が Oracle に買収されて Java 自体の開発に関する状況が大きく変わってきている。

安定的に動作することを期待されている Java が他の言語みたいにどんどん変化するって方向に変わりたいようだ。 新しいもの好きな人々にとっては話題が多いのは素晴らしいことだろうが、アプリケーションが確実に動いて欲しいと思ってる人々にとっては困った話だ。

僕は SIer の従業員なんで、安定的に動作するってことが Java や JVM の素晴らしさだと考えている。

とはいえ、大きく変化してるってんなら、ちゃんとキャッチアップしておかないと困ったことになるのは自分だ。

そういう訳で、今回は eclipse を使って Spring Boot のアプリケーションを開発するための環境構築について説明する。

エントリの変更点​

最初にこのエントリを公開した時には、MockMvc と TestRestTemplate を使ってテストを書くように説明していた。 ところが、@making がより良い方法として、WebTestClient を使う方法を教えてくれたのでそちらを使うように書き換えた。

@making に感謝。

Spring Initializrを使わないの意図的です？
formatなんでもいいならspring teamがメンテナンスしているやつもありますhttps://t.co/po9eFXLRcK
MockMvcが嫌ならはWebTestClientはどうでしょうか？ (spring-boot-starter-webfluxも追加が必要ですが） pic.twitter.com/9fprDo7ySA

— Toshiaki Maki (@making) August 9, 2018

開発環境​

Thinkpad X1 Carbon 2016 年モデルに Windows10 をインストールしてある。

ハードウェアスペックは、こうだ。

• CPU i7 6600U @ 2.6GHz
• メモリ 16GB
• ストレージ SAMSUNG NVMe SSD 950 PRO 512GB

少し高級かもしれないけど開発者用のマシンとしては普通だよね。

アプリケーションのインストール​

基本的には Scoop を使ってインストールしていく。Scoop については、以前のエントリを参照して欲しい。

• Scoop で Windows における開発環境構築を最適化しよう

JDK のインストール​

まず、Java 用の Bucket を Scoop に追加する。

scoop bucket add java

Bucket を追加したので、ローカルディスク上にある Bucket の情報を更新する。

scoop update

次に、Bucket に登録されている JDK を調べる。

scoop search jdk

大体こういう感じで出力されるだろう。

'java' bucket:
    ojdkbuild (10.0.2-1)
    ojdkbuild10 (10.0.2-1)
    ojdkbuild8 (1.8.0.181-1)
    ojdkbuild9 (9.0.4-1)
    openjdk (10.0.2-13)
    openjdk10 (10.0.2-13)
    openjdk11 (11-25)
    openjdk12 (12-5)
    openjdk9 (9.0.4)
    oraclejdk-lts (8u181-b13)
    oraclejdk (10.0.2-13)
    oraclejdk10 (10.0.2-13)
    oraclejdk11 (11-25)
    oraclejdk8-ea (8u192-b02)
    oraclejdk8 (8u181-b13)
    oraclejdk8u (8u181-b13)

今となっては OpenJDK と OracleJDK に大きな差分は無いので、OpenJDK を使えばいい。

というわけで、OpenJDK をインストールする。

scoop install openjdk

Java のインストールが成功しているか確認するために、バージョン番号を標準出力する。

java -version

インストール作業をした時期によって細かい部分は違うだろうが、大体こういう出力がされる。

openjdk 10.0.2 2018-07-17
OpenJDK Runtime Environment 18.3 (build 10.0.2+13)
OpenJDK 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

マジでどうでもいい話だが、今は --version でもバージョン情報を得られる。

Gradle のインストール​

Gradle をインストールするのは、プロジェクトを最初に作る人間だけでいい。

何故なら、プロジェクトを作った後は使う Gradle のバージョンを揃えるために Gradle Wrapper という仕組みを使うからだ。 要はプロジェクトディレクトリの直下に gradlew.bat とかある、あれを使うって事。

Scoop で Gradle をインストールする。

scoop install gradle

これで、ソースコード付きの Gradle がローカルインストールされる。 もし、ネットワークの帯域を節約したいなら、実行バイナリだけが含まれている gradle-bin をインストールしてもいい。 その場合、何かトラブルが起きた時には念力デバッグが必要になる。

Gradle のインストールが成功しているか確認するために、バージョン番号を標準出力する。

gradle --version

大体こういう風に出力される。

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/C:/Users/taichi/scoop/apps/gradle/current/lib/groovy-all-2.4.12.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

------------------------------------------------------------
Gradle 4.9
------------------------------------------------------------

Build time:   2018-07-16 08:14:03 UTC
Revision:     efcf8c1cf533b03c70f394f270f46a174c738efc

Kotlin DSL:   0.18.4
Kotlin:       1.2.41
Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.11 compiled on March 23 2018
JVM:          10.0.2 ("Oracle Corporation" 10.0.2+13)
OS:           Windows 10 10.0 amd64

Java9 以来発生している警告で、Java10 を使っている限り出力される。Gradle5 になれば出力されなくなるらしい。cf. Upgrade to Groovy 2.4.12 for full Java 9 compatibility

ワークアラウンドとして JAVA_OPTS 環境変数を以下のように設定しておく。

--add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED

eclipse のインストール​

次は、eclipse のインストールだ。Scoop を使ってインストールしても良いがチューニングの経過を保存し易いように zip アーカイブをダウンロードして使う。

以下のページから Windows 64-bit のリンクをクリックしてダウンロードする。

• Eclipse IDE for Java Developers

Eclipse Installer はマジで素晴らしい仕組みだとは思うが、GUI 操作が多すぎて何度もインストールしたり捨てたりするような使い方には向いていない。

ダウンロードした zip ファイルを適当なディレクトリに展開すればインストールは完了だ。

eclipse のチューニング​

eclipse.ini​

メモリの上限を変更しつつ、class の検証オプションを無効化する。 あまり変なプラグインは使っていないことが前提になる。

-Xmx8g
-Xverify:none

自由にプラグインを追加したいなら、 -Xverify:none にはリスクがある。 クラスファイルが想定していないような書き換えが行われることで、そこから派生して情報漏洩したり、知らないうちに DDoS 攻撃に参加させられてしまうかもしれない。

eclipse のデフォルトだと G1GC を使う事になっている。 しかし、メモリが最大 8G 程度のアプリケーションで G1GC を使うのはちょっとオーバーヘッドが大きすぎないか？と思っている。 ただ、CMS やパラレル GC との差分を調べる気力が無いので、そのままにした。

設定のチューニング​

General の Show heap status を on

メモリが不足していたら分かるようにするためだ。バケツボタンを押して GC をトリガーすることもできる。

General > News の Enable automatic new polling を off

General > Startup and Shutdown の 大半を off

General > Workspace の Text file encoding を UTF-8

MS932 のままでコードを書くと、本当に沢山のトラブルに巻き込まれることになる。

Install/Update > Automatic Updates の Automatically find new updates and notify me を off

Java のコーディングを便利にするチューニング​

Java プロジェクトを一つ作る。中身はなんでもいい。以下の設定が終わったら、当該プロジェクトは消す。

Java > Appearance > Type Filters に java.awt と javax.print を追加

Java > Editor > Content Asist > Advanced で 不要な入力補完機能を off。上と下に二つ同じ項目があるので、要注意。

• Java Proposals (Task-focused) は Mylyn 系の機能なので明確に不要
• SWT Template Proposals は SWT 用なので明確に不要
• Adaptive Template Proposals は 使ってみて邪魔なら後で off にする
• Code Recommenders 系は、かなり重いので off にすると快適になる

Java > Editor > Save Actions で Perform the selected actions on save を on

コードのフォーマットや import 文の整理などというのは、人間がやることではないのだよ。

Java > Editor > Typing で Automatically insert at current position の Semicolons を on これで、行のどこでセミコロンキーを押しても正しい位置にセミコロンが入力される。

Java > Installed JREs でローカルに複数の JRE や JDK をインストールしているなら登録する。

便利なプラグインの導入​

google-java-format プラグイン​

ソースコードのフォーマットは、どんなルールでやろうが一貫性のあるルールなら好きなようにすればいいが、その作業自体は人間がやることではない。

エディタなり IDE なりに自動的にやってもらうものだ。

eclipse にもフォーマットの機能はあるけど、他の IDE やエディタを使っている人とその内容を共有するのが難しいのが問題だ。 それに eclipse のデフォルト設定だと最近のコア API やライブラリが採用しているスタイルのコードが読み易くにフォーマットされないという問題もある。

IntelliJ みたいな他の IDE と設定を共有できてまともに使えるコードフォーマッタは、僕が知っている限りでは google-java-format くらいしかない。

と言うわけで、google-java-format プラグインを導入しよう。

まずは、リリースページに行って、最新の jar ファイルをダウンロードする。google-java-format-eclipse-plugin_x.x.x.jar みたいなやつがそれだ。

• google/google-java-format/releases

ダウンロードしてきた Jar ファイルを eclipse の dropins フォルダにコピーする。その後、eclipse を再起動するとプラグインがインストールされる。

• The dropins folder and supported file layouts

プラグインがインストールされたら、Java > Code Style > Formatter のFormatter Implementationコンボボックスで、 google-java-format を選ぶ。

最後に、eclipse デフォルトのフォーマッタと google-java-format を使った時の見た目がどう変わるのか確認しておこう。

どんなふうになっていると見易いかってのは、個人の主観によるところが大きいとは思うので、みんな見比べてみて欲しい。

eclipse のデフォルト設定​

google-java-format​

ターミナルを起動するプラグイン​

EasyShell というプラグインを eclipse に導入すると、eclipse のプロジェクトビューから直接ターミナルが起動できる。

Help メニューから Eclipse Marketplace を起動して、検索エリアに EasyShell と入力すれば見つけられる。

EasyShell のインストールが終わったら、コンテキストメニューの設定を変更する。

EasyShell > (1) Menu から、一行目を選んだ状態にした後、Edit ボタンをクリック。

Filter に Power と入力すると、その一行下のセレクトボックスに Open - PowerShell (Plugin) と表示される。この状態で OK を押す。

こんな風に変わる。

Run with Command Prompt は使わないので、左側のチェックボックスを外している。

プロジェクトの作成​

Java プロジェクトの作成​

次は、eclipse で Java プロジェクトを作ろう。ここでは、説明のために first-spring-boot とする。 module-info を作るか聞かれるかもしれないが、 Don't Create を選んでいい。

プロジェクトが出来たら、Java プロジェクトのコンテキストメニューから EasyShell > Open PowerShell Here と選び PowerShell を起動する。

起動した PowerShell で、以下のコマンドを実行する。

gradle init

これで、プロジェクトの直下に Gradle 関連のリソースがいくつか作られる。

• gradle フォルダ
• build.gradle
• gradlew
• gradlew.bat
• settings.gradle

eclipse 側に戻って、Java プロジェクトのコンテキストメニューから Configure > Add Gradle Nature を選ぶ。 これで、eclipse が当該プロジェクトを Gradle プロジェクトだと認識するようになる。

最後に Java プロジェクトのプロパティで Gradle の設定を変える。

まず、Override workspace settings のチェックボックスを on にする。 次に、Automatic Project Synchronization のチェックボックスを on にする。

何故、こんなややこしい手順で Gradle プロジェクトを作っているのかというと、eclipse の Gradle プラグインが内部に抱え込んでいる Gradle が古いからだ。

最後に、さっき起動した PowerShell で Gradle 標準のソースコードディレクトリを作る。

mkdir -p src/main/java mkdir -p src/main/resources mkdir -p src/test/java mkdir -p src/test/resources

eclipse の外側でディレクトリを作ったので、Java プロジェクトのコンテキストメニューから Refresh を実行する。

次に、src ディレクトリのコンテキストメニューから Build Path > Remove from Build Path を選ぶ。

更に、さっき作ったディレクトリを全部展開する。コントロールキーを押しながら左クリックを四回繰り返して四つのフォルダを選択状態にした上で、 コンテキストメニューから Build Path > Use as Source Folder を選ぶ。

Gradle のビルドスクリプトを初期設定する​

eclipse で build.gradle を開き以下の内容をコピペする。

plugins {
	id 'java'
}

repositories {
	maven {
		url 'https://maven-central-asia.storage-download.googleapis.com/repos/central/data/'
	}
	jcenter()
	mavenCentral()
}

sourceCompatibility = targetCompatibility = 1.10

tasks.withType(AbstractCompile)*.options*.encoding = 'UTF-8'

repositories ブロックでは、Google が用意している Maven Central リポジトリのミラーを参照するようにしている。 これは、僕がいるネットワーク内だと大抵の場合、Apache が運営しているものよりも高速にライブラリをダウンロードできるからだ。

• Maven Central mirror hosted on Google Cloud Storage

今回は Java10 で作業しているので、 sourceCompatibility は 1.10 にしている。別に 1.8 くらいでも全然問題ない。

末尾にかなり奇妙なコードが書いてあるが、これはソースコードのエンコーディングを全て UTF-8 で統一するまじないの一種だと考えてくれればいい。

尚、Gradle 側には eclipse プラグインは特に導入しない。

設定が正しくなされているかを確認するために、PowerShell で以下のコマンドを実行する。

.\gradlew build

ここからは、Gradle Wrapper を使って作業するのでプロジェクトディレクトリの直下にあるシェルスクリプトを使っている。 特に問題が無ければ、以下のように出力される。

BUILD SUCCESSFUL in 1s
1 actionable task: 1 up-to-date

JUnit5 を導入する​

次は、JUnit5 を Gradle に導入しよう。

test {
	useJUnitPlatform()
	systemProperty('java.awt.headless', true)
	jvmArgs '--add-opens=java.base/java.lang=ALL-UNNAMED', '--add-opens=java.base/java.lang.invoke=ALL-UNNAMED'
}

dependencies {
	testImplementation 'org.junit.jupiter:junit-jupiter-api:5.2.+'
	testRuntimeOnly    'org.junit.jupiter:junit-jupiter-engine:5.2.+'
}

JUnit5 を Gradle で使うには、 test ブロックで useJUnitPlatform() を呼ぶ必要がある。

ユニットテストの実行中は、AWT を使う気が無いのでシステムプロパティの java.awt.headless を有効化している。

Gradle のインストール辺りで触れたリフレクション周りの警告が出ないようにするワークアラウンドをここでも追加している。 Gradle5 になれば、このオプションは要らなくなる。

dependencies ブロックでは、JUnit5 のライブラリを二つ追加している。

詳細な使い方や、ライブラリの意味なんかは JUnit 5 User Guide を参照して欲しい。

テストコードの動作確認​

テストコードが上手く動作するか確認しておこう。

src/test/java フォルダに、 FirstTest クラスを作成する。

以下のコードをコピーした後、当該フォルダを選択してペーストすれば eclipse がファイルを作ってくれる。

import static org.junit.jupiter.api.Assertions.assertEquals;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

public class FirstTest {

	String message;

	@BeforeEach
	public void setUp() throws Exception {
		this.message = "Hello";
	}

	@Test
	public void hello() throws Exception {
		assertEquals("Hello", this.message);
	}
}

JUnit4 では、@Before だったものが JUnit5 では、 @BeforeEach に変ったので注意しよう。

ちなみに僕は @Before を付けた setUp メソッドが何回やっても実行されずにドハマりした。

まずは、 eclipse でこのテストコードが動かせるか確認しよう。

このコードのコンテキストメニューから、 Run As > JUnit Test と選択する。

上手く動作すればテストビューでグリーンバーが見られる。

次に、Gradle でこのテストコードが動かせるか確認しよう。

.\gradlew test

必ず失敗するようにテストコードを変更して動作確認するのも忘れずに。

Spring Boot を導入する​

さて、本丸の Spring Boot 導入だ。

まずはシンプルに Spring Boot で開発するのに最小限必要な依存性を追加したビルドスクリプトがこれだ。

plugins {
	id 'java'
	id 'org.springframework.boot' version '2.0.4.RELEASE'
	id 'io.spring.dependency-management' version '1.0.6.RELEASE'
}

repositories {
	maven {
		url 'https://maven-central.storage.googleapis.com'
	}
	jcenter()
	mavenCentral()
}

sourceCompatibility = targetCompatibility = 1.10

tasks.withType(AbstractCompile)*.options*.encoding = 'UTF-8'

bootJar {
    baseName = 'first-spring-boot'
    version =  '0.1.0'
}

test {
	useJUnitPlatform()
	systemProperty('java.awt.headless', true)
	jvmArgs '--add-opens=java.base/java.lang=ALL-UNNAMED', '--add-opens=java.base/java.lang.invoke=ALL-UNNAMED'
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-web'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'

	testImplementation 'org.junit.jupiter:junit-jupiter-api:5.2.0'
	testRuntimeOnly    'org.junit.jupiter:junit-jupiter-engine:5.2.0'
}

まず、 Gradle の Spring Boot プラグインを導入している。 plugins ブロックに増えた二行がそれだ。

これによって、ビルドスクリプトの中で bootJar ブロックが使えるようになった。baseName と version は必須なので適当な値を設定しておく。

最後に依存ライブラリとして、 spring-boot-starter-web と spring-boot-starter-test を追加して完成だ。

Spring Boot アプリケーションの作成​

Spring Boot アプリケーションとして動作確認するためのコードを用意する。

以下のコードを src/main/java フォルダに eclipse でコピペすれば、パッケージも込みで自動的に作ってくれる。便利！

package hello;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {

  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
}

package hello;

import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

  @RequestMapping("/")
  public String index() {
    return "Greetings from Spring Boot!";
  }
}

Application クラスのコンテキストメニューで、 Run As > Java Application を選択するとサーバが起動する。

Console ビューに出るログが止まった辺りでブラウザを使って http://localhost:8080/ にアクセスしよう。

上手く動作しているなら、

Greetings from Spring Boot!

とブラウザに表示される。

Gradle を使ってアプリケーションを起動するなら、

.\gradlew bootrun

で、同じように実行できる。

Spring Boot アプリケーションをテストする​

次は、テストコードを書いてみよう。

まずは、サーバを使わずにコントローラをテストする。 その前に Spring WebFlux をテスト用の依存性に加えておく。

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-web'

	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'org.springframework.boot:spring-boot-starter-webflux'

	testImplementation 'org.junit.jupiter:junit-jupiter-api:5.2.0'
	testRuntimeOnly    'org.junit.jupiter:junit-jupiter-engine:5.2.0'
}

dependencies ブロックだけ抜粋したが、 spring-boot-starter-webflux がそれだ。 Spring WebFlux はリアクティブアプリケーションを構築するための新しい枠組みだが、全てが非同期指向になるため使う場所を選ぶ。 具体的に言うと、JDBC を使うアプリケーションでは適用できない。

今回は、Spring WebFlux の一部である WebTestClient という便利な API をテストのときだけ使う。

こいつは、何が素晴らしいって僕の嫌いな Hamcrest に依存している MockMvc を使わなくて良くなる上に、 ユニットテストとインテグレーションテストを同じ API 体系の中でテストできるのだ。使わない理由はない。

package hello;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.SpringBootTest.WebEnvironment;
import org.springframework.http.MediaType;
import org.springframework.test.context.junit.jupiter.SpringExtension;
import org.springframework.test.web.reactive.server.WebTestClient;

@ExtendWith(SpringExtension.class)
@SpringBootTest(webEnvironment = WebEnvironment.MOCK)
public class HelloControllerTest {

  WebTestClient client;

  @Autowired HelloController target;

  @BeforeEach
  public void setUp() throws Exception {
    this.client = WebTestClient.bindToController(this.target).build();
  }

  @Test
  public void getHello() throws Exception {
    this.client
        .get()
        .uri("/")
        .accept(MediaType.APPLICATION_JSON)
        .exchange()
        .expectStatus()
        .isOk()
        .expectBody(String.class)
        .isEqualTo("Greetings from Spring Boot!");
  }
}

スッキリとテストを書けるのが分るだろう。テストの実行方法は既に説明したとおりだ。

次は、サーバを起動してテストするインテグレーションテストだ。

package hello;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit.jupiter.SpringExtension;
import org.springframework.test.web.reactive.server.WebTestClient;

@ExtendWith(SpringExtension.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class HelloControllerIT {

  @Autowired WebTestClient client;

  @Test
  public void getHello() throws Exception {
    this.client
        .get()
        .uri("/")
        .exchange()
        .expectStatus()
        .isOk()
        .expectBody(String.class)
        .isEqualTo("Greetings from Spring Boot!");
  }
}

ローカルのサーバに接続して行うインテグレーションテストなら、更にコードは短くなる。

Spring Boot を調整する​

さて、一通りテストまで動いたので Spring Boot アプリケーションは開発できるようになったと言いたい所だが、まだ続きがある。

動作するサーブレットコンテナを変える​

Spring Boot がデフォルトで使うサーブレットコンテナは Tomcat だ。まぁ、猫さんはみんなに人気があるので仕方がない。

しかし、猫さんは動作がモッサリなのでキビキビ動く Undertow にサーブレットコンテナを切り替えよう。

dependencies ブロックだけを抜粋して説明するが、こういう風になる。

dependencies {
	implementation ('org.springframework.boot:spring-boot-starter-web') {
		exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
	}
	runtimeOnly 'org.springframework.boot:spring-boot-starter-undertow'

	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'org.springframework.boot:spring-boot-starter-webflux'

	testImplementation 'org.junit.jupiter:junit-jupiter-api:5.2.+'
	testRuntimeOnly    'org.junit.jupiter:junit-jupiter-engine:5.2.+'
}

まず、 spring-boot-starter-web の自動的な依存性から spring-boot-starter-tomcat を取り除く。これで Tomcat が自動的に使われることはなくなる。

次に、spring-boot-starter-undertow を依存性に追加して、Undertow が自動的に使われるようにする。

小さいアプリケーションだと差分は小さいけど、アプリケーションが大きくなると起動時間というのは、生産性に大きく関わってくる部分なので少しでも速くしたいよね。

JUnit4 と Hamcrest を推移的な依存性から排除する​

JUnit4 と JUnit5 は、名前が似たクラスやアノテーションが多く存在している。

JUnit5 を使うと決めたプロジェクトの依存性の中に JUnit4 が含まれていると、クラス名が一意に定まらないせいで eclipse が上手く入力補完してくれないことがある。

Hamcrest については、特に使いやすくもなければ分かり易くもないと考えている。 assertEquals で済む話を static import を駆使して何か英語のように読めなくもないものをコードとして書く代わりに沢山の API を覚えるとか手段と目的が逆転してしまっている。 ユニットテストをするために覚える事は少なければ少ないほどいい。

というわけで、JUnit4 と Hamcrest には感謝を伝えると共に完全排除しよう。

dependencies {
	implementation ('org.springframework.boot:spring-boot-starter-web') {
		exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
	}
	runtimeOnly 'org.springframework.boot:spring-boot-starter-undertow'

	testImplementation ('org.springframework.boot:spring-boot-starter-test') {
		exclude group: 'junit'
		exclude group: 'org.hamcrest'
	}
	testImplementation 'org.springframework.boot:spring-boot-starter-webflux'

	testImplementation 'org.junit.jupiter:junit-jupiter-api:5.2.+'
	testRuntimeOnly    'org.junit.jupiter:junit-jupiter-engine:5.2.+'
}

と言っても、やることは簡単だ。spring-boot-starter-test の推移的依存性から junit と org.hamcrest を外すだけ。

Springfox (Swagger) を追加する​

現代的なアプリケーションの実装において、API アクセスを全く想定しないってのは色々無理がある。 別に全く知らないどこかの誰かに向けて API を用意しようって話をしたいわけじゃない。

ユーザインターフェースを SPA っぽくしようってだけでも API アクセスは必要だし、 郵便番号から住所を引くみたいなちょっとしたウィジェットを動かすだけでも API アクセスしたくなるものだ。

とはいえ、できる限り少ない手間で API アクセスできるようにしたいし、ドキュメントや API アクセスの実験をする環境は欲しい。

そういう訳でSpringfox (Swagger)の登場だ。

動いたテストコードからのみドキュメントを作るみたいなアプローチなら、Spring REST Docs を使うのも悪くない。

Springfox を導入するのは凄く簡単だ。

ビルドスクリプトの dependencies ブロックに二行追加して、エントリポイントのクラスに設定をちょっと書くだけ。

Springfox 関連のライブラリを追加したdependencies ブロックはこんな感じだ。

dependencies {
	implementation ('org.springframework.boot:spring-boot-starter-web') {
		exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
	}
	runtimeOnly 'org.springframework.boot:spring-boot-starter-undertow'

	implementation 'io.springfox:springfox-swagger2:2.9.2'
	runtimeClasspath 'io.springfox:springfox-swagger-ui:2.9.2'

	testImplementation ('org.springframework.boot:spring-boot-starter-test') {
		exclude group: 'junit'
		exclude group: 'org.hamcrest'
	}
	testImplementation 'org.springframework.boot:spring-boot-starter-webflux'

	testImplementation 'org.junit.jupiter:junit-jupiter-api:5.2.+'
	testRuntimeOnly    'org.junit.jupiter:junit-jupiter-engine:5.2.+'
}

springfox-swagger2 には、ビルド時に必要になるクラスがごっそり入っている。

springfox-swagger-ui は、ブラウザでアクセスできる GUI アプリケーションだ。

ビルドスクリプトを変更したら、次はエントリポイントのクラスだ。こんな感じになる。

package hello;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;

import springfox.documentation.builders.PathSelectors;
import springfox.documentation.builders.RequestHandlerSelectors;
import springfox.documentation.spi.DocumentationType;
import springfox.documentation.spring.web.plugins.Docket;
import springfox.documentation.swagger2.annotations.EnableSwagger2;

@SpringBootApplication
@EnableSwagger2
public class Application {

  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }

  @Bean
  public Docket api() {
    return new Docket(DocumentationType.SWAGGER_2)
        .select()
        .apis(RequestHandlerSelectors.any())
        .paths(PathSelectors.any())
        .build();
  }
}

import 文を除く変更点は二つ。 @EnableSwagger2 をクラスに追加したのと、@Beanのついたapiメソッドを追加したことだ。

この状態でアプリケーションを起動して、http://localhost:8080/swagger-ui.html にアクセスすれば、API のドキュメントやテスト環境を試せる。

ああ……ブラボー……

まとめ​

今回は、JDK のインストールから始めて Spring の開発環境を一通り揃えるところまでを説明した。

最近の Java 開発では、IDE として IntelliJ を使うことが多くなってきているような気がするけども、eclipse もまだまだ便利だ。

ただ、eclipse には動作を鈍重にしてしまうような罠が多い。その最たるものが Web Standard Tools(WST)だ。 サーバを起動する機能とかあって便利そうに見えるけど、こいつを入れた途端、eclipse が全体的に遅くなる。

Spring Tool Suite (STS) も推移的に WST をインストールするので、STS を使うという事は不快な eclipse を使うということに直結する。

Spring Boot ならアプリケーションを main エントリから起動できるので従来の J2EE サーバへのデプロイ的な作業はいらない。 つまり、WST が持っているサーバ管理機能みたいなものはそもそもいらないのだ。

STS で唯一便利な機能は、RequestMapping を一覧する機能だが、これも Springfox を追加してしまえばより見やすいものが得られる。

正直言えば、最近は JavaScript ばかり書いているので、VS Code で Java も書きたいのだけど、VS Code の Java 拡張は 2018 年 8 月現在だと、まだまだまともに使えるレベルに無い。 内部的には eclipse の機能が動作するし、設定ファイルとして eclipse らしさが露出してくるのでむしろ困惑する…みたいな状態だ。

僕としては Java のコードを書くなら eclipse が最高だと思っているんだけど、あなたはどうだろうか？

このエントリで説明しなかったこと​

色々あるんだけども、みんなが余り知らなそうなものや、おススメを列挙しておく。

ライブラリ​

• Doma
• Micrometer
• Immutables
• Hoverfly Java
• ZT Process Executor

ツール​

• Error Prone
• CFR - another java decompiler
• PIT

現代人は突き詰めると砂糖と塩と油に脳をやられている。

現代人が短絡的に喜ぶ食事を考えた時、砂糖と塩と油の不快感を感じさせずに大量摂取させられる料理が幸福感をおおむね最大化する（要出典）。

今回は、その中で砂糖と油を効率よく摂取させられる、簡単で邪悪なおやつを紹介したい。

僕が今日説明する邪悪なおやつとはラスクである。しかも、パンの耳をつかったやつだ。

そもそも、食パンというのはかなり不健康な食い物だとされている（要出典）。

その中でも、特にパンの耳は極めて危険な部位で、パンの悪い部分が濃縮されていると言える。しかし、だからこそ旨い。

基本の手順​

まず、パンの耳で作るラスクの基本的な調理方法について確認しておこう。 ラスクにするパンの耳は、はっきり言って何でもいい。しかし、ダブルソフトみたいに柔らかすぎるやつはダメだ。 同じヤマザキなら、超芳醇みたいなやつがいい。

• パンの耳を食い易い一口大に切る。
• パンの耳がカリっとするまで油で炒める
• 砂糖をパンの耳の上から振りかけて、弱火でゆっくり加熱しながらパンの耳と溶けた砂糖が絡むように混ぜる
• 焦げない程度に炒めて、外側が固くなったらクッキングシートをしいた皿に並べて冷ます

ラスクの基本的な作り方はこれだけだ。 人類の堕落要素である炭水化物と油と砂糖だけで構成される極めて純度の高い邪悪さを持つ食い物であることが分かって貰えるだろう。

砂糖は上白糖だろうが、三温糖だろうが、グラニュー糖だろうが、なんでも良い。 油も大体なんでもいい、オリーブオイルがおススメだが、サラダ油でもグレープシードオイルでもいい。ゴマ油は上級者向けなのでおススメしない。 油を食う料理なので、開封したての酸化していない油を使った方が旨いが、些細な問題だ。

ついでにちょっとしたコツを書き加えておくと、油は一気に使うんじゃなくて、パンの耳を炒めながら三回くらいに分けて使うといい。 全部のパンの耳に油がいきわたるようにすると、味が安定する。

何となく分かっているだろうが、これだけでは特においしいラスクにはならない。 基礎は大事だが、それだけで事を為せるわけではないのだ。

食感の改善​

ところで、旨いラスクとは、どんなものだろうか？ 外側は少し堅めで、中はサクサクと崩れるようなのが旨いラスクだと僕は考えている。

ちなみに、パンの耳を切って炒めるだけでは、そのような食感を得る事は難しい。 何故なら、パンの耳には多くの水分が含まれているからだ。

つまり、この水分を除去すればサクサクとした食感を生み出せる。 水分を排除する簡単な方法は何だろうか？まさかオーブンでラスクを真面目に焼くとか、レンジで水分を除去しながら加熱するとかはやりたくない。

例えば、袋を開けたまま部屋の中に放置することが考えられるが、これはおススメできない。 何故なら衛生的でないからだ。特に今のような梅雨の時期はパンがカビる。 カビたパンを食って大丈夫な人間はそう多くない、僕だってそうだ。腹をこわす。

梅雨の時期に食パンを比較的安全に保存する方法がある。そう、冷凍だ。 そして、冷凍した後にレンジで解凍したパンは残念なことに水分が抜けてボソボソとした食感になる。 つまり、冷凍保存してマズくなったパンは、ラスクに転用するとおいしいのだ。

では、手順を確認しよう。

• 冷凍したパンの耳をレンジで解凍する
• パンの耳を食い易い一口大に切る。
• パンの耳がカリっとするまで油で炒める
• 砂糖をパンの耳の上から振りかけて、弱火でゆっくり加熱しながらパンの耳と溶けた砂糖が絡むように混ぜる
• 焦げない程度に炒めて、外側が固くなったらクッキングシートをしいた皿に並べて冷ます

冷凍保存によって抜けた水分の代わりに油を埋めるのが、このラスクの肝だ。 十分に油を吸い込んだパンの耳を丁寧に炒めると、油が水分を排除するのでサクサク感を得られる。

これが、最初のラスク。スタートアップラスクである。

キマる調味料​

スタートアップラスクは、自分ひとりで食べるなら兎も角、友人や家族にドヤれるようなものではない。

ラスクの食材と調理法はシンプル過ぎる。つまり、調理する人間の技量が結果に直接影響する。 我々が求めているのは、そういうのではない。とはいえ、おやつなのであんまり手間をかけたくはない。

そこで、ラスクに使う定番のキマる調味料を紹介しよう。シナモンだ。 アッパー系の香辛料でカレーやお菓子によく使われる。ラスクでも砂糖の三割から五割程度の容量でシナモンを混ぜた上でパンの耳に絡めるとよい。

ついでに、油もキマるやつに変えよう。そう、みんな大好き有塩バターだ。パン一枚分の耳あたり 10g くらい使うと素晴らしい味わいになる。 素晴らしいことに有塩バターの塩味が、砂糖の甘味をより引き立ててくれるのだ。

シナモンとバターを使ったラスクの手順はこうだ。

• 冷凍したパンの耳をレンジで解凍する
• パンの耳を食い易い一口大に切る。
• バターをレンジで温めて完全に溶かす
• パンの耳がカリっとするまで溶かしたバターで炒める
• シナモンと砂糖を適当な器で均等になるように混ぜる
• 砂糖とシナモンの混合物をパンの耳の上から振りかけて、弱火でゆっくり加熱しながらパンの耳と溶けた砂糖が絡むように混ぜる
• 焦げない程度に炒めて、外側が固くなったらクッキングシートをしいた皿に並べて冷ます

これがキマるラスク。アッパーラスクだ。

そうは言っても昼間に食うようなアッパーラスクに後ろ暗さなどある筈もなく、大体平和な味であって特に危険はない。 ところで、堕落した人間がおやつを食べるのは、果たして昼間だけなんだろうか？

断じて否！

堕落した人間は日が落ちた後、深夜におやつを食べる。しかし、アッパーラスクに深夜性はない。 いや、夜に食っても旨いが闇夜の味わいではないのだ。

中毒性のある調味料​

アッパーラスクに中毒性はなく、明るい昼間の味わいだ。 僕らが求めているのは、もっと中毒性のあるやつだ。一度食べたら忘れられず何度でも食いたくなるラスク。

こじゃれたレストランで出てくるが、実際にはかなり邪悪なあいつを自宅で簡単に作る方法は無いだろうか？

勘の良いあなたなら、次に出てくる食材を予想できるだろう。そう、ニンニクだ。 ニンニクはチューブに入ったペースト状のやつを使うと楽だが、自分ですりおろしてもいい。 パン一枚分の耳に対して 10g 程度のバターを使うことは変わり無いが、雑に溶かしたバターとニンニクを混ぜてガーリックバターを作る。

と言うわけで、ニンニクを使うラスクの手順はこうだ。

• 冷凍したパンの耳をレンジで解凍する
• パンの耳を食い易い一口大に切る。
• バターを溶かしてガーリックバターを作る
• 弱火でガーリックバターを使って、パンの耳がカリっとするまで炒める
• 焦げない程度に炒めて、外側が固くなったらクッキングシートをしいた皿に並べて冷ます

客に出す時は、見た目上のこじゃれ感が増すので乾燥バジルをガーリックバターに混ぜて使うと良いだろう。

これが、昼間の味わいであるラスクを反転させた邪悪なラスク、ジャンキーラスクである。 ジャンキーラスクは、飲酒を伴わない食事には合わないと考えてよい。ワインやビール、ウイスキーなどの洋酒と併せると簡単に堕落できるだろう。 もし、飲酒しながらジャンキーラスクを食べるなら、ガーリックバターを作る際に小さじ１程度食塩やクレイジーソルトを足すと、更に良い味になる。

まとめ​

アッパーラスクとジャンキーラスクは、ある種のフレームワークでありガイドラインとなるものだ。 砂糖や油の組み合わせや、パンの種類を変えることで、よりオリジナリティのあるラスクを作れるだろう。 例えば、アッパーラスクであれば、ホイップクリームをつけながら食べると更にエネルギッシュな味わいが得られる。 ジャンキーラスクに是非追加して欲しいのは、粗挽きの黒胡椒だ。 ラスクに手をつける直前にミルで胡椒をふりながら食うと病みつきになる。

これを読んだあなたが新しいラスクの境地を開き、より多様性のある食生活に至ることを願って結びとする。

最近、様々な分野でチャットツールのビジネス利用が試行されていますね。 筆者の会社でも例に漏れず多くの部門が Slack を利用したり、Microsoft Teams の検証をしています。 筆者は 20 年近く様々なチャットツールを使ってきました。1:1 のチャットツールだけでなく、複数人で使うチャットツールも様々な状況で利用しています。 そもそもインターネットを利用する筆者の主たる目的の一つは確実にチャットです。 一方で、会社に本格的なチャットツールを導入する過程で分かってきたのは、多くの人は思ったよりチャットツールに慣れてない、ということです。

このエントリでは、最近 Slack や Teams のようなチャットツールを使い始めた組織に所属するみなさんに向けて、チャットツールをより快適に使うための考え方や Tips を紹介します。

ここで紹介する知識は、筆者からの提案であり何らかの理想やマナーではありません。 これらの知識の中には、あなたの考えや組織に合わないものが確実に含まれているでしょう。それらは単に無視して下さい。 もし、あなたのチーム内におけるルールや運用を見直すきっかけになるなら、それは大変素晴らしいことです。 筆者としては、このエントリを読んだ皆さんが、ここで提示した知識を自分なりに改良して利用して貰えれば良いと考えています。

全般的な使い方編​

多要素認証(MFA)を有効化しよう​

チャットツールは様々なレベルの情報を扱う場所です。あなたのアカウントをより強力に防護するため必ず多要素認証(MFA)を有効化しましょう。

• 2 要素認証を設定する

Slack の場合、有償のワークスペースでは管理者が MFA をユーザに対して強制できますが、無償のワークスペースでは強制できません。 多くのユーザは強制されない限り MFA を有効化しない傾向にありますが、特に理由が無ければ有効化しましょう。

おすすめのアプリケーションはAuthyです。複数のスマホや PC で二要認証の鍵を共有しているので、一つくらいなら一時的に紛失しても対応できます。

定時の設定​

退勤したら仕事用のチャットツールを見たり使ったりするのは基本的にやめましょう。 どこに居ようが、仕事用のチャットツールを見ているなら、それは労働時間とみなされるべきです。稼働時間をむやみに増やすのは、望ましくありません。 そのためには、定時を過ぎたら通知が来なくなるように設定するのが簡単です。

• おやすみモードの設定と通知の一時停止

チャットを一切見ない時間を作ろう​

チャットツールは、慣れてくると中毒のような状態になり易いものです。特に参加者が多く活気のあるチャットでは、常に誰かが発言しています。 そこで発信されるメッセージを全て出来るだけ早く確認しようとすると、それ以外のことが一切出来なくなってしまいます。 そうなる前に、チャットを見ない時間帯を自分で決めるのが良いでしょう。

8 時間拘束の仕事では、毎日合計して 2 ～ 3 時間はチャットを見ない時間を作ると仕事が捗りますよ。

情報のストックとフローという考え方​

チャットツールは、流動的な対話を行うための場所です。チャットツールでの議論の結果は、別途保存した上で探し易い場所に議事録としてまとめ直した方がいいでしょう。 後からチャットの中身を時系列に追って、その内容を順次理解していくのは非常に大変な作業です。 議事録はその時いなかった人が分かり易いように書きましょう。

一番簡単な議事録の共有の仕方は、markdown などのテキストファイルで議事録を書いた上で、チャットツールにアップロードしてしまうことです。

コミュニケーション効率について​

チャットツールによるコミュニケーションは、対面によるコミュニケーションに比べて効率のよい部分と悪い部分があります。

チャットツールは文字によるコミュニケーションツールなので、感情や雰囲気のような感情的な部分は伝わり辛いです。 語尾を工夫したり、リアクションアイコンや、画像を使うことである程度感情を伝えられますが、感情はあまり伝わらないものとしてやり取りした方が、トラブルの発生を未然に防げますし効率的です。

チャットツールを使うなら、対面によるコミュニケーションよりも、応答速度を少し遅めに見積もってやりとりする方がいいでしょう。 会議中や電話中に質問者側が、質問してその回答を聞く前に離席したり、他の会議に行くなどという事はありえませんが、チャットツールならそれができます。

メールマナー及びそれに類するものを排除しよう​

電子メールが普及し、20 年近くが経過するなかで、マナーのようなものが広く普及しています。 例えば、「○○ さん」や「お世話になっております」、「以上、よろしくお願いします」など、情報として意味のない文章がメールの中には多く含まれています。 チャットツールを利用するなら、そのようなマナーを一旦全て無視してコミュニケーションしてみましょう。コミュニケーションの効率が大きく改善することを実感できるでしょう。 情報として意味の無い部分を欠く相手に対して失礼さを感じ、コミュニケーション効率を改善するより礼儀を重視したいのであれば、チャットツールを使うのは諦めてメールを使えばいいでしょう。 本当に効率よりも礼儀が大切なら、毎朝おろしたての墨を使って筆で手紙を手書きした方がよりよいでしょう。

本来、礼儀や礼節というものは不要な争いが起こる可能性を低減することで、効率よくコミュニケーションするための手段であって、目的ではありません。 本来の目的を逸脱し、それ自体が目的化したマナーの類は極めて醜悪なものだと筆者は考えています。

お互い意味が無いと思いつつ、多くの人が受け取っても読み飛ばしている文字列を送付し合うことは、礼儀正しいと言えるのか今一度考え直してもいいんじゃないでしょうか？

リマインダーの使い方​

Slack では / で始まるメッセージを投稿すると、他のユーザには見えない特別な命令として解釈されます。 Slack には、標準で特別な命令がいくつか用意されていますが、 /remind はそういったものの一つです。 メッセージの入力欄に /remind と入力すると基本的な使い方は表示されます。 そこでは表示されないが個人的に有用だと思っている例を紹介します。

• リマインダーを設定する

平日の 1200 にリマインド​

平日の 12 時になったら、自分にだけ Slack がリマインドしてきます。

/remind me "お昼休みです" at 12PM every weekday

終業時間をリマインド​

平日の 17 時になったら、 #kintai チャンネルにリマインドメッセージが自動投稿されます。 自動投稿されるメッセージ内で @here となっているので Slack にログインしており、#kintai チャンネルにいる人全員に通知が飛びます。

/remind #kintai "@here そろそろ退勤時間です。日報を書きましょう。" at 1700PM every weekday

メッセージ編​

ここからは、Slack を使ったメッセージのやりとりにおいて、筆者が気を付けていることを紹介していきます。

メッセージを小分けにする​

長文のメッセージの中には、全体として賛同できるものの個別には同意できないとか、個別には同意できるが全体としては賛同できないといったことはよくあります。 合意形成のためには主張を部分に分けた方が、それぞれに対してより精密な議論ができます。 チャットを使った議論では、文章を過度に装飾したり論理を敢えて曖昧にするようなやり方は合致しません。

長文で何かを主張するのであれば、markdown 等の読み易い形にまとめて配布する方がいいでしょう。 その場合には、ピクトグラムやダイアグラムなどの画像を適宜混ぜることで、読者がより理解し易い形にしましょう。

このようなことが出来るのは、Slack のワークスペース内において全てのメッセージを一意に特定できる ID が割当てられているからです。 Slack ではワークスペース内の全てのメッセージに対して一意になるような URL が付加されます。 その URL は、メッセージの右上にある「・・・」アイコンからクリップボードにコピーできます。

そのメッセージに言及する際に、自分のメッセージ内に URL を含めると、自分が書き込んだメッセージが表示される際に併せて、言及対象となるメッセージが表示されます。

また、個別のメッセージに対して返答できるスレッドという機能によって、個別具体的な議論を行えます。

• スレッドにメッセージを投稿する

Slack のチャンネル内でスレッドが多用されているなら、チャンネルを分けた方がいいかもしれませんよ。

メッセージをリマインドする​

Slack ではメッセージが次々と流れていくので、メールのように敢えて未読にしておくことが難しいことが多いですよね。 依頼されたことや、明確に自分に対して問いかけがあった訳ではないものの、反応しておきたいものの、今すぐには書き込めないという事はよくあります。

そういう時はリマインド機能を使いましょう。リマインド機能はメッセージの右上にある「・・・」アイコンから設定できます。

リアクションを積極的に使おう​

Slack を筆頭に最近のチャットツールには、簡単な応答を行うためのリアクションという機能が実装されています。 単純なお礼、同意や否定、賞賛などはメッセージとして書き込まずにリアクションすると気楽に応答できるようになります。

チャットツールで感情表現しようとするとコミュニケーションが煩雑になるのでオススメはしません。 しかし、常に感情を封じてコミュニケーションするというのも不健康な考え方ですので、リアクションで低コストに感情表現するのがいいでしょう。

ここでは、筆者がよく使っており、Slack に標準搭載されているリアクションアイコンを紹介します。 Slack にはリアクションアイコンを自分で作成して登録できるので、自分達のチームにあったリアクションアイコンを登録するとより愛着が湧きますよ。

• 絵文字でリアクションする
• カスタム絵文字を作成する

肯定、賞賛、承認​

これは、英語圏における thumbs-up というアイコンで肯定や賞賛、承認を表すものです。 ポジティブな反応は、コミュニケーションを円滑にする効果がありますので、積極的に使っています。

類似するものとして、お祝いの要素がより強い tada もあります。クラッカーを鳴らしているイメージですね。

自分には無い考え方や発想に対する賞賛をおこなう際には cool を筆者は使っています。「なるほど！」や、「一本取られた」みたいな使い方です。

同意を表す際には、 ok も使い易いアイコンです。文字として表現されているので、文脈を共有していない相手にも理解され易いのが良いですね。

否定、却下​

ネガティブな反応をすることが、効果的な状況が少ないのであまり使いませんが、そういう時こそお互い精神に悪影響の少ない方法であるリアクションを使いましょう。

一方で、悲しみや辛さに同意することが、コミュニケーションを円滑にする状況もあるでしょう。そういう時に筆者は、cry や skull を使っています。

単純な否定や、同意できないことを表明する際には、 ng も ok と同じ理由で使い易いアイコンです。

確認済、完了済、チェック​

メッセージに対して終了状態を表す際に使うのが check です。 リマインダーに check でリアクションを付けておくと状況を管理し易くなります。

発展的には、Slack に自分で書いたメッセージに check を付けていくことで TODO リストとして使えます。

相槌​

オンラインコミュニケーションにおいては、相手が自分の書いたメッセージを読んでいるのかいないのかが重要な状況はあります。 特に連続してメッセージを送信している際には、誰も見ていないとしたら空回りしているような感じになってしまい辛いことがあります。

そういう風にならないよう、否定も肯定もしないけれどメッセージを見てはいることを相手に伝えるために、筆者は eyes アイコンをリアクションします。 LINE のように既読状況が自動的に管理されるツールは、便利ですが一方で圧迫感もあります。 筆者としては、仕事で使うチャットツールでは、自分に余裕がある時だけ能動的に既読をリアクションできる方がより使い易いなと感じています。

簡易アンケートの作り方​

Slack のリアクションは、同一のリアクションを複数回付けられないので、チャンネル内にいる人に対して簡易的な選択式アンケートを取れます。 メッセージとして選択肢を提示した後に、メッセージを書き込んだ人が one、two、three、four、などのリアクションを付けてしまいます。 アンケートの参加者は用意されたリアクションを選択するだけで回答できます。

• Slack の投票機能

デフォルトグループメンションの回避​

Slack では @here や @gruop を使うと、チャンネル内にいる人全てに通知を送信できます。しかし、これは出来る限り使わないようにしましょう。 理由は、邪魔だからです。当該チャンネルに参加していると言うことは、そこでの話題に興味があるということです。不特定多数へのメンションなど使わなくても見ている筈です。 特に興味があるわけではないが、チャンネルに参加しているという状態の人は、そもそも当該ワークスペースにログインしていません。 結局本来気が付いて欲しい相手には届かず、キチンとチャンネルを見ている人には、過剰な通知になってしまいます。

特に、本人の意志では退室できない #general チャンネルなどのデフォルトチャンネルでは、@here や @gruop を使うのはできる限り避けましょう。

とはいえ、複数のメンバーに対して一々ユーザ ID を指定して通知を送るのは面倒ですよね。 そういう時は、ユーザグループを作成して送信対象を少しでも限定しましょう。

• ユーザーグループを作成する

メンションに対する応答の義務性について​

チャットツールで自分宛にきたメンションに対して、すぐに答えようとするのはやめましょう。 勿論、自分の仕事に余裕がある状況ならすぐに回答すればいいのですが、そうでない時にはメッセージを見るだけにして応答しないことを選ぶと楽になります。 また、メンションを送る側の気持ちとしても、すぐに応答があることを期待しない方が気持ちが楽になりますよ。

チャットツールの電話に対する明確な優位性は、相手の時間を強制的に拘束しないことです。 自分にとっての要件の優先順位と、相手にとっての要件の優先順位が常に一致しているとは限りません。 もし、要件の優先順位においてお互いが最優先事項であると合意できるなら、電話で話した方がより効率よくコミュニケーションできますよ。

プライベートコミュニケーションの回避​

チャットツールを導入すると、多くの人が Slack でいうところのダイレクトメッセージや、プライベートチャンネルを使いたがります。 開かれた空間でのコミュニケーションに対する漠然とした恐怖感のようなものがあるのではないかと筆者は考えています。 ちょっとしたお願い事や、単純な質問をするのに公開の場所でするまでもないと考える人もいるでしょう。 しかし、業務でチャットツールを使っているのであれば、そのお願い事に対する応答や質問に対する回答は、本来チームの共有資産となるべきものです。

もし、特定の個人にちょっとしたお願い事が集中しているのであれば、業務上の資源配分に失敗している可能性があります。 また、単純な質問が様々な人間から繰返し行われるのであれば、プロセスに問題があるかもしれません。 単純な質問が特定の個人に集中していれば問題の芽に気が付くかもしれませんが、質問者と回答者がそれぞれ複数いれば、見逃されてしまいます。 プライベートコミュニケーションは、こういった組織的な問題の気配を全て覆い隠してしまいます。

情報統制などと言って、重要でもない情報に高い機密レベルのラベルを付けるのをやめてみましょう。

引用のやりかた​

Slack には様々な記法があり、メッセージを装飾できます。 詳細な記法については公式のマニュアルを確認して欲しいのですが、議論する上で確実に覚えて欲しい記法が 1 つだけあります。 それが、引用記法です。メッセージの行頭に > (大なり) を使うと引用表現になります。

以下のようにメッセージを書くと

こういう風に表示されます。

• メッセージの書式設定

チャンネル編​

ここからは、Slack のチャンネルについて筆者が気を付けていることを紹介していきます。

general チャンネル利用の回避​

Slack では、ワークスペースに入った際にデフォルトで参加するチャンネルがあります。標準では #general チャンネルです。 このチャンネルは、それぞれのユーザの判断においては退室できない特別なチャンネルなので、ワークスペース参加者全員が絶対に把握しなければならない情報だけをやりとりしましょう。 つまり、ワークスペース自体の運営に関わる話題だけを #general チャンネルでは実施すべきです。

新しい参加者が来たら、挨拶や簡単な情報共有用のチャンネルに誘導してあげましょう。

チャンネルを分類する方法​

Slack にはメールのように受信したメッセージやチャンネルを分類する機能はありません。 しかしながら、積極的に中身を確認したいチャンネルと、そうでないチャンネルはあるでしょう。 特に積極的に確認したいチャンネルは、チャンネルペインの左上にあるスターをクリックしてお気に入りにしましょう。 画面左側のチャンネル一覧ではスターを付けたチャンネルが上に優先的に表示されます。

スター済のチャンネルと入室済のチャンネルの双方において、チャンネルをミュートできます。 チャンネルをミュートすると、未読メッセージ数が更新されず、メンションが来ても通知が来なくなります。

ミュート済みのチャンネルは、チャンネル一覧において最下部に表示されるので、スターとミュートを組合わせるとチャンネルを 4 種類に分類できるのです。

ここでは、 zogzogとgeneralがスター付チャンネルになっています。加えて、generalとpiyopiyoが、ミュート済チャンネルです。

全てのチャンネルに参加しようとするのはやめよう​

Slack は話題毎にチャンネルを作ると効率よくコミュニケーションできるので、ワークスペース内のチャンネルは基本的に増加していきます。

新しく出来たチャンネルの全てに入室するのはやめましょう。 自分の知らない所で他の人が楽しくコミュニケーションしていると気になるかもしれませんが、そこはグッと我慢してください。 チャンネルに参加するからには、積極的に発言しましょう、そうする気にならないなら自分にとって余り価値の無い場所なのかもしれませんよ。

新しく出来たチャンネルに次々入っていると、未読メッセージがどんどん蓄積していき、それを読んでいるだけで一日が終わってしまいます。 これを防ぐために、自分にとってそれほど重要でないと感じたら、まずミュートしてみましょう。通知が来なくなります。

チャンネルを見ないまま一週間ほど経過したら、思い切ってそのチャンネルを退出しましょう。 自分にとって意味や価値の無いチャンネルに入室したままにせず、意味や価値のあるチャンネルでのコミュニケーションと本来の仕事に集中しましょう。

パブリックチャンネルを作ろう​

Slack でチャンネルを作るときは、基本的に誰もが参加できるパブリックチャンネルにしましょう。 パブリックチャンネルなら、その話題に興味がある人が誰でも参加できるし、開かれたコミュニケーションはチーム内に知識を蓄積します。

あらゆる意思決定は公開の場でなされるべきだとは考えてはいませんが、組織内の意思決定をフェアにしたいなら情報公開はその基盤になります。

多くの人が見ている前で、質問したり自分の意見を書いたりするのは、恥ずかしいと感じるかもしれません。 しかし、ダイレクトメッセージやプライベートチャンネルだけを使って狭い範囲でコミュニケーションするより、 多くの人が見ている場所でコミュニケーションする方が得るものが多くなり易いですよ。

チャンネル名の考え方​

Slack ではチャンネルを階層化する仕組みが無いので、命名規則をゆるく作って運用するとチャンネルを探し易くなります。 チャンネル名の接頭辞を工夫すると、そこから話題が類推できるようになります。

例えば、筆者が利用しているワークスペースには、master-git、 master-slackといった master-で始まる各種ツールのちょっとした便利情報を質問したり共有するチャンネルがあります。 似ているチャンネルでは、 qa-jira や qa-cloud といったより質問と回答に特化したチャンネルもあります。 他にも、 社内にある他の部門と協調作業する際にはclb-という接頭辞を付けたチャンネルを作って、そこに他の部門の人を呼んでいます。 併せて、自部門内で協調作業の内容について協議するために sprt- という接頭辞を付けたチャンネルも作ります。

チャンネルの設計パターン​

Slack では話題毎に新しいチャンネルを次々と作るのが望ましいのですが、最初のうちはチャンネルを分割する基準が分らないこともあるでしょう。 そこで、チャンネルを新しく作る際に参考にできるようなガイドラインを紹介します。 この基準は唯一絶対というものではなく、あくまでも参考情報として使って下さい。

筆者が利用しているワークスペースでも、これらの基準に当てはまらないチャンネルは日々増えています。

キーワード基準チャンネル​

一番分かり易いチャンネルの作り方が、特定のキーワードを話題にするチャンネルを作ることです。 恐らく誰もが一番最初にやるだろうから、特に例示などは必要ないでしょう。

例えば、筆者が利用しているワークスペースでは muscle や dinner、lunch といったチャンネルがあります。

他にも、Jira や GitHub のチケット番号をチャンネル名として使っているチームもあります。 議論が紛糾するような状況では、タスク管理ツールのコメント欄では機能性が不足していることが多いので、チャットで議論した後、その議事録をタスク管理ツール側に転記すると、迅速に状況を収束させられますよ。

話者基準チャンネル​

内容ではなく、誰が話すのかを基準にチャンネルを作ると、Slack を使い易くなることがあります。

例えば、筆者が利用しているワークスペースでは、 times_taichi のように times_で始まるチャンネルは、特定の誰か主たる話者として扱うチャンネルです。 ここでは、主たる話者が自分の考えていることや、今困っていることを誰となく垂れ流します。 みんなが見ている自分の庭のような感覚で使うと良いでしょう。筆者は社内向けの Twitter のような感覚で使っています。 また、Slack には様々な機能が増えたり減ったりしていますので、それを余り他の人に迷惑をかけずに試す場所を確保しておくと、Slack への慣れが早くなります。

他の人の話者基準チャンネルに入室しておくのは、その人がちょっとした困りごとに遭遇しているのを見つけた時に、自分が出来る範囲で手助けするためです。 また、本人とって余り重要でないことでも、他の人がそれを見た時に創発的なトリガーになることがあります。

情報共有チャンネル​

RSS フィードを流したり、気になったニュースの URL を貼るためのチャンネルは分けておいた方が良いでしょう。 ただ、何のフィルタリングもせずにニュースサイトの RSS フィードを流すのは、チャンネルの流量が増えすぎるため、参加者の負担になり易く余りよくないやり方です。 ニュースの URL をチャンネルにはる時は、200 文字以内程度のちょっとした意見を一緒に書く方が参加者にとって有意義なものになり易いでしょう。

例えば、筆者が利用しているワークスペースでは tech や gadget といったチャンネルが情報共有に使われています。 techは、かなり雑多なソフトウェア技術に関する話題が流れています。 自分一人だけで Twitter やはてなブックマークのようなサービスを使っていると情報の偏りが出来やすいので、それを是正する意味で非常に便利です。

gadgetは、もう少し趣味に寄ったチャンネルで、新しいスマートフォンや、タブレット、スマートウォッチの新商品やキックスターターの記事が話題になります。 現在はキチンとした研究開発対象として認識されている VR 用のヘッドマウントディスプレイは、最初このチャンネルで話題になりました。

依頼/承認チャンネル​

筆者の部門では、Slack を始め Jira や GitHub など様々な SaaS を利用しています。 当然ですが、ユーザ全員に管理者権限を割当てるような運用はしていません。それぞれの SaaS に対して、管理者を定めて特定の操作が限定されたユーザに集中するようにしています。

その時、管理者権限での操作を依頼するためのチャンネルが、依頼チャンネルです。 依頼者がチャンネルに依頼したい内容を書き込むと、それを確認した管理者が eyes リアクションを付けます。 作業が終わったら heavy_check_mark リアクションを付けるか、作業が終わった旨メッセージを書き込みます。 依頼者は、そのメッセージに pray アイコンを付けて依頼完了です。

これの変形として、管理職が所属員の依頼を承認するチャンネルも考えられます。

例えば、筆者が利用しているワークスペースでは kintai というチャンネルがあり、休暇や遅刻、テレワークの開始や終了などの報告を所属部員が書き込むと承認者たる部門長がリアクションを付ける事で承認しています。

このチャンネルの運用によって承認作業のコストが大きく低減しています。 一般に承認者は管理職であり、その作業時間は非常に貴重なので、この手の承認作業は出来るだけ少ない工数で処理できる事が望ましいでしょう。 また、部門の所属員は、このチャンネルをざっと見るだけで、誰が出社しており、誰がテレワークで、誰が休暇なのかすぐに分かるのでそれぞれの状態に併せたコミュニケーションツールを選び易くなります。

ボットチャンネル​

ワークスペースの中にいるプログラマの割合いが一定を越えている場合、多くのボットがワークスペース内に登録されるでしょう。 また、GitHub や Jira などのツールと連携する際に、無軌道に連携するとメッセージの流量が増えるため使い辛くなります。 そういったことを防ぐため、ボットの動作を一定期間確認するためのチャンネルを用意しましょう。

Slack のボットは権限次第で様々な情報を読み取れますし、そこで読み取った情報をユーザが想定しないサーバに送信することもあります。 機密情報を扱っているワークスペースにおいては、ボットがどんな動作をするのか確認しながら段階的に導入しましょう。

通知チャンネル​

電子メールからチャットツールへ移行する際には、通知先としてもチャットツールを使いたくなるでしょう。 Jira のタスク更新通知や、GitHub のコミット通知、利用している SaaS のサーバ状況を通知してくれるサービス等々。

チャンネル内のメッセージ流量が通知メッセージは、かなり気を付けてフィルタリングしないとメッセージが増えすぎます。 まずは、通知を受信するための専用チャンネルを用意して、そこに通知を流すようにしましょう。 通知対象を十分に絞り込んだ後に、その通知設定を他のチャンネルに適用しても遅くはありません。

リラックスチャンネル​

リラックスチャンネルは説明が最も難しいタイプのチャンネルです。 ここでは、ワークスペース内にいるユーザが息抜きすることを主たる目的にしたチャンネルです。 あらゆるチャンネルでリラックスしてコミュニケーションできることが望ましいのですが、仕事で使う以上、そうもいかないこともあるでしょう。

人数が多ければ、そもそもリラックスしているとは、どういう状態なのか合意を取るのは難しくなります。 そこで、いわゆるマジレス禁止を掲げるチャンネルを作成して、その中では、どのような発言も許容されるものとして運用するのです。

例えば、筆者が利用しているワークスペースでは poem というチャンネルがあり、擬音やオノマトペ、誰かに伝える気の無い思いなどを書き込んでいます。 アスキーアートもよく書き込まれています。

vogue というチャンネルでは、仕事中に発言された名言や迷言を記録しています。 面白さが強く状況に依存しますが、そういうチャンネルを作っておいて後で見返すと非常に楽しいですよ。 筆者が賛同はできないものの強い感銘を受けた発言を、少し古いのですが一つだけ紹介します。

別に Suica が使いたいから買うのではない。Apple が新しい時計を出すから買うのだ。

まとめ​

このエントリでは、主に Slack を念頭において、チャットツールの使い方やその考え方について説明してきました。

繰り返しますが、ここで書いたノウハウは絶対的な基準となるべきものではなく、 あなたにとって受け入れ易く都合のいい部分だけを、取り入れて貰うことを意図して書いています。

全くのゼロからルールを作り出すのは非常に困難な作業ですが、 基準となる文書がありそれを基準に議論するのであれば比較的容易にできるものです。

このエントリを読んだ今までチャットツールをあまり使ってこなかった人が、 出来るだけ早くチャットツールに慣れて使いこなせるようになることを願っています。

はじめに​

僕はまごうこと無き運動不足である。週に一回は肩こりの症状を緩和するためにクライミングジムに通ってはいるが、それほど真剣にやっている訳ではないので、三級程度で二年くらい足踏みしている。

しかし、最近は体力の衰えを明確に感じるようになってきた。それは、集中力の低下や、好奇心の低下となって確実に表れている。以前なら、体力任せにコードを書き続けられたが、今はもう全くそんな事ができる気配もない。

と言う訳で、今日は僕が筋トレを始めたという話をする。

去年は筋肉を溶かす話をしたが、今年は筋肉を作る話をするってわけだ。

筋トレを始めた理由​

まずは、筋トレを始めた理由から説明していこう。と言っても、実にありふれた話だ。

人間ドックで警告を受けた​

一番直接的な理由は、会社から年に一回福利厚生の一環として提供されている人間ドックの受診結果が著しく悪かったからだ。特に、尿酸値と γ-GTP の値で警告を受けた。

医者との面談で「かなりお酒を飲まれるようですが控えてはいかがでしょうか？」等と言われて、頭の中に最初に思いついた反論が「いや、そんなに酒を飲んでいるつもりはありません」だったのだ。何かおかしいと思って一旦言葉を飲み込んで考えてみると、これは完全に酒を飲み過ぎている人間の言葉である。

観測的事実を根拠とする指摘に対して、そのつもりは無い等と根拠なく言うのは問題を解決しないどころか悪化させる。

実際、僕はかなり酒を飲む。友人との宴会もあるし、それが無ければ一人でも飲み歩いている。自宅では酒を飲まないが、それはあるだけ全部飲むまで止められないからだ。

ボルダリングが上手くなりたい​

次に思い当たる理由は、趣味のボルダリングだ。僕がボルダリングを始めたのは、もう 6 年か 7 年前だ。月に 3 ～ 4 回のペースでジムに通っている。最初の 1 ～ 2 年は、どんどん難しい課題がクリアできて成長を実感できたものだが、最近はめっきり技能が向上しておらず、正直、少し飽きてきた。

ジムに行く回数をもう少し増やせば、技能が伸びるとは思うものの、そんなに真面目にやる気になる感じでもない。と言う訳で、筋肉量を別途増やすことで間接的にクライミングのパフォーマンスを向上できたらいいかもしれないと考えた。

友人の肉体が見違えた​

次は、友人の@ymotongpooが、この一年半くらいで、物凄い量のトレーニングをした結果、ガチムチになったのを見たからだ。彼は元々体格が大きく骨格がしっかりしているため、少なくとも僕よりは才能があるだろう。

しかし、筋トレを始める前の彼は正直、かなりダラけた体格をしていた。それでも、適切なトレーニングによって結果を出したのを見て、自分でもやってみようという気になったのだ。

常駐しているチャットには、筋トレに関するレビューや情報交換を専門に扱っているチャンネルもあり、そこでの成果が彼の肉体だ。

筋トレに期待する効果​

次は、筋トレによって僕が何を得たいのかを明確にしておく。

より健康的な肉体を得る​

基礎代謝を向上し、筋肉量を増やすと共に体脂肪率を落とす。

これによって、将来起こりうる内臓疾患や、椎間板ヘルニアなど姿勢が悪い事や筋肉量が不足することによっておこる疾患を予防したい。

僕は、基本的に一日中座っている仕事しているし、極めて腰に悪い座り方をしている。この姿勢を改善するにも体幹の筋肉が足りないので、妥当な姿勢を維持できないのだ。かなり長い期間、この悪い姿勢を続けているので、その癖を抜くのもすぐには出来ないだろう。結果的に、本来なら緩やかなカーブを描いている筈の背骨がかなり真っすぐになってしまっている。これを改善するには、まず最低限の筋肉が必要だ。

こりをほぐしてくれるようなマッサージ店や整体に行くことで、状況を一時的に改善できるだろうが、そもそも日々の生活や自身の肉体を改善しなければ、永久に整体師や鍼灸師にお世話にならざるを得ない。それは、望ましくない。

集中力を取り戻す​

筋肉量を増やすことで、失った体力と共に集中力を取り戻したい。僕は、好奇心と集中力によって活動しているので、もし、それらが完全に失われると活動出来なくなってしまう。

最近は集中力が失われることで、楽しいと思えることの幅が狭くなっているように感じる。以前から知っており、刺激は少ない代わりに、何か安心感のあるコンテンツを好んで摂取するようになったような気がするのだ。

何故集中力が失われたのかというと、それは体力が落ちているからだと考えている。

プログラマとしてのキャリアが長いので、様々なことを知ってはいるし、日々の仕事はそれでこなせる。しかし、ソフトウェアの業界は 20 年程度で全てを見渡せるほど狭くはない。つまり、問題なのは僕自身であり、集中力の欠如によって新しい知識を得られなくなりつつあるのだ。これは、僕の価値を相対的に減じることになるので望ましくない。

もっと新しい知識を獲得し、できる事の幅を広げ、より多くの挑戦をしたい。それを支えるのは体力であり、集中力であり、湧き出る好奇心だ。

筋トレを始めて分かったこと​

前提となる話は一通り終わったので、ここからは今現在の話をしよう。

まずは、現在の僕がどんなステータスなのかを把握して欲しい。

トレーニング記録​

僕が使っているアプリケーションで確認できるトレーニングの記録がこれらだ。

最古のトレーニング記録​

2017/10/16

オリジナルメニュー

終了日時
2017/10/16

チェストプレス
セット1 25.0kg x 3回
セット2 25.0kg x 3回
セット3 25.0kg x 3回 / 1RM 27 kg MAX!
消費カロリー
2.0kcal

レッグプレス
セット1 75.0kg x 5回
セット2 75.0kg x 5回
セット3 75.0kg x 5回 / 1RM 84 kg MAX!
消費カロリー
4.9kcal

ハックスクワット
セット1 40.0kg x 5回
セット2 40.0kg x 5回
セット3 40.0kg x 5回 / 1RM 45 kg MAX!
消費カロリー
4.9kcal

ロータリートルソー
セット1 20.0kg x 5回
セット2 20.0kg x 5回
セット3 20.0kg x 5回 / 1RM 22 kg MAX!
消費カロリー
3.8kcal

シーテッドプーリーロー(シーテッドロウ)
セット1 40.0kg x 5回
セット2 40.0kg x 5回
セット3 40.0kg x 5回 / 1RM 45 kg MAX!
消費カロリー
3.8kcal

合計消費カロリー
19.5kcal

体組成

測定日時
2017/10/16
身長
175.0cm
体重
62.0kg

最新のトレーニング記録​

2017/12/08

平日基本トレーニング

終了日時
2017/12/08 21:46

ウォーキング
セット1 1500m / 15分
消費カロリー
57.9kcal

ヒップアダクション
セット1 110.0kg x 10回
セット2 110.0kg x 10回
セット3 110.0kg x 10回 / 1RM 138 kg MAX!
消費カロリー
7.7kcal

ヒップアブダクション
セット1 115.0kg x 10回
セット2 115.0kg x 10回
セット3 115.0kg x 10回 / 1RM 144 kg MAX!
消費カロリー
7.7kcal

ワイドグリップチンニング
セット1 10回
セット2 7回
セット3 7回
消費カロリー
7.2kcal

チンニング(懸垂)
セット1 4回
セット2 4回
消費カロリー
2.4kcal

シーテッドプーリーロー(シーテッドロウ)
セット1 27.3kg x 10回
セット2 34.1kg x 10回
セット3 34.1kg x 10回 / 1RM 43 kg MAX!
消費カロリー
7.7kcal

チェストプレス
セット1 15.0kg x 10回
セット2 20.0kg x 10回
セット3 20.0kg x 10回 / 1RM 25 kg MAX!
消費カロリー
6.9kcal

ラットプルダウン
セット1 27.3kg x 10回
セット2 34.1kg x 10回
セット3 34.1kg x 10回 / 1RM 43 kg MAX!
消費カロリー
7.7kcal

レッグプレス
セット1 50.0kg x 10回
セット2 50.0kg x 10回
セット3 50.0kg x 10回 / 1RM 63 kg MAX!
消費カロリー
10.0kcal

プランク（スタビライゼーション）
セット1 40秒
セット2 40秒
セット3 40秒
消費カロリー
9.3kcal

ハンマーカール
セット1 6.0kg x 10回
セット2 6.0kg x 10回
セット3 6.0kg x 10回 / 1RM 8 kg MAX!
消費カロリー
7.7kcal

合計消費カロリー
132.5kcal

体組成

測定日時
2017/12/08 21:54
体重
63.8kg

ほぼ全ての種目で平均的な成人男性未満の身体的能力である。 これで分かるのは、僕が筋トレ初心者であり、大した成果がでている訳でないということだ。 やり始めた頃より重量が減っている種目が少なからずあるが、これは正しいフォームで狙うべき筋肉だけを使うようになった結果、高い重量で負荷をかけられなくなったからだ。

体重は、二か月で 2kg 弱増加しているが、体内の水分状況などで容易に変わるレベルなので、ほぼ変わってないと言える。尚、増加していること自体は問題ない。

高度な体組成計での計測も行っているが、筋肉量は特に増加していないし、体脂肪率も 18%前後で、ほぼ変化していない。つまり、二か月くらいでは、体組成計で観測可能な変化は起こらないということだ。

一方で、筋肉量は増えていないにも関わらず体にかけられる負荷の量は確実に増えている。特にチンニング（懸垂）は顕著だ。始めた時は、ワイドグリップチンニングは出来なかったが、今では 10 回くらい出来るようになった。

二か月程度でも簡単な技能を獲得することはできるし、筋肉の使い方を正しく理解し、使いこなすだけで、ある程度は成長するということだ。

筋トレの面白いところ​

今は大体週に四回くらいスポーツジムでマシントレーニングをして、週一回はクライミングジムに行っている。

つまり、週に五回は何らかのジムに行っているのだ。何故、こんなにジムに行っているのかといえば、単純に面白いからだ。

自らを理解する楽しみ​

一番面白いのは、自分自身にとって最も身近な道具である自らの肉体について沢山の発見があるからだ。適切なトレーニングを積んでいない者は、自分の体を思い通りには動かせない。トレーニングを始める前は、そもそも自分の体を思い通りに動かせているかなんて考えもしなかった。つまり、自分の体に対する理解の解像度が著しく低かったのだ。

例えば、ジムに通い始めたころは、まず、広背筋がビタイチ言うことを聞いてくれなかった。シーテッドプーリーロウやラットプルダウンと言った広背筋を鍛える筈のマシンを使っても、フォームが誤っていることに加えて、広背筋を使えていないために、上腕二頭筋や上腕三頭筋と言った腕の筋肉が疲れてしまうのだ。

その状態から、パーソナルトレーナーを週に一回お願いして、三十分程度マッサージして貰ったうえで、フォームを細かくチェックして貰いながら丁寧に負荷をかけた。そうして五週間くらい経った頃だろうか、それは起きた。

何かがパチリとハマった感じがして、今まで動いている気がしなかった広背筋が少しだけ動くようになったのだ。かけられる負荷が突然 13kg 程度から 25kg 程度まで倍増、その日からはシーテッドプーリーロウで、腕より先に、広背筋の方が疲れるようになったのだ。その後も、ジムにいくたびに扱える負荷は増えている。

筋トレはこういう体験が次々とやってくるのだ。分からなかったことが分かるようになったり、出来なかったことが出来るようになる体験は、何にも代えがたい。

筋トレの成果として得たいものが、筋トレをしながらでも得られているので、良好なフィードバックサイクルが回っていると言える。

マイクロチューニング的な楽しみ​

筋トレでは、実に多くのものを数値化して管理できる。体重や体脂肪率、筋肉量といった項目は家庭用の体組成計で計量できるし、僕が行っているジムにはInBodyという、より本格的な体組成計があり、細胞内水分やミネラルといった異様に細かい項目まで計測できる。

これらを一々記録して眺めるのは、とてつもなく楽しいものだ。自分にかける負荷の量は、自分で決められる。睡眠時間や食事の内容、その日の仕事ぶり、精神的な状況、様々な要因で変化する。

この記録した数字は、自分の振る舞いによって改善していく。この楽しさは、foreach とイテレータのどちらが速いのか調べたり、テストのコードカバレージを改善するのと非常に良く似ている。

情報収集する楽しみ​

筋トレに関する情報は、インターネット上に山ほどあふれている、それこそスポーツ医学としてキチンと研究されたものから、怠惰な人間を狙い撃ちするような疑似科学まであり、玉石混交だ。これらをより分けるべく、沢山のドキュメントを読むのは実に刺激的である。

この二か月で僕が知った情報のうち、筋トレを始めたばかりの頃にすぐ知りたいと思っていたものを少し列挙してみよう。

どのプロテインが良いの？​

筋トレの成果を得るには、摂取する栄養の改善が欠かせない。例えば、プロテインだ。ホエイだの、ソイだの、カゼインだの色々ある。それぞれ効果が違うし値段も違う。多くのメジャーな日本メーカの製品はどれも高額だ。何と海外から輸入した方が輸送量込みでも安くなったりする。

例えば、MyProteinというイギリスのメーカは、Steamみたいな勢いで毎日セールをしており、そのおかげでやたら安くプロテインを買える。ただ、MyProtein のプロテインは味がとんでもなく甘い。イメージとしては、ぬるくなったマックシェイクと同じような甘さを想像して貰えばいい。ナチュラルチョコレート味を一度だけ試したが、僕には合わなかった。

僕が今飲んでいるプロテインは、バルクスポーツという日本のメーカが作っているプロテインだ。ここは、MyProtein と同程度の価格だが、あまり甘くない。そして、袋のチャックが頑丈だ。僕が気に入っている味は、アーモンドチョコレート、イチゴミルク、バニラアイスだ。最近バニラアイス味を 6kg 程買った。

僕が飲んでいるのはホエイのアイソレートプロテインというやつだ。ホエイプロテインは牛乳から作られるプロテインで、アイソレートプロテインは乳糖が殆ど含まれないので、お腹にやさしい。

プロテインは、体重 x2.2g をめどに摂取するのが望ましいと言われている。僕の場合、140g 程度だ。なので食事とは別に一日三回二スクープずつ飲んでいる。起床後、就寝前、トレーニング直後だ。

プロテイン以外のサプリは？​

トレーニング中に栄養不足にならないよう飲むドリンクもある。CCDとBCAAを、10:1 で配合したものを 500ml 程度の水で溶かしてトレーニング中に飲んでいる。

何でこんなものを飲むのかと言うと、筋トレ中は大量にエネルギーを消費するのだが、そこでエネルギーが不足するとヤバいことに筋肉を燃料として使う。筋肉を増やすべくトレーニングしているのに、その筋肉が減るこのヤバい状態をカタボリックと言う。カタボを防ぐには、CCD のようなドリンクですぐにエネルギーになる炭水化物を適宜補給するのが望ましい。

他にも、普通に食事をしていると不足しがちなビタミンをOptimum Nutrition, オプティ-メン ®という錠剤からとっている。オプティ-メンは、Amazon を含む様々な EC サイトから購入できるのだけど、値段が随分違う。もし、オプティ-メンを買うなら、iHerb で買うべきだ。

そうそう、トレーニング後に飲んでいるプロテインには、疲労回復を早める効果を期待してグルタミンを混ぜている。

僕はまだ飲んでいないが、アルギニン、シトルリン、クリルオイル、デキストリン、クレアチン、HMB など筋トレをやっている人にオススメされているサプリは多い。これまた、どれも成分表示に細かい数字が沢山並んでおり、これを眺めて価格と成分量でコストパフォーマンスを比較するのは愉悦そのものと言っていい。

筋トレの辛いところ​

勿論、筋トレが楽しいことばかりだと主張するつもりはない。辛い事だってある。

筋トレを始める前は、筋肉に負荷をかける作業そのものが辛いと考えていたが、どうも、そうではないことが分かってきた。

食事もトレーニングに含まれる​

筋トレで本当に辛いパートは、食事だ。

僕は、基礎代謝が低いので極端な話、休日は一日一食で十分に活動できる。活動と言っても、PC の前に座ってコードを書いているかゲームをしているだけで、一日の総移動距離が 10 メートルくらいだが。仕事をする日でも、一日二食も食べれば、特に問題無く活動できる。

しかし、筋トレの効果を最大化するなら、もっと多くの食事が必要だ。僕は胃が小さいので一度に沢山は食べられない。つまり、食事の回数を増やすしかない、プロテインなどのサプリを摂取するのとは別に、一日三回は食事をするのが望ましい。それくらい簡単だろって思えるあなたは素晴らしい、僕より筋トレの才能がある。

特にトレーニング後の食事が僕にとってはきつい。まず、トレーニング前にパフォーマンスアップとカタボ予防で、おにぎりを一つ食べている。更に、トレーニング中に CCD と BCAA のドリンクを二時間で 500ml 程飲んでいる。そして、二時間程度のトレーニング直後にプロテインを飲む。2 スクープを 300ml 程の水で溶いて飲んでいる。運動をした直後なので、空腹感は一切ない。

プロテインの吸収効率を上げるには炭水化物とセットにするのが望ましいので、プロテインを摂取したら直ちに、晩御飯を食べるのが望ましい。栄養バランスが出来る限り良いものを食べようとすると、どうしても量が多くなる。多量の食事を空腹感なしに摂取するのは、正直苦痛でしかないが慣れるしかない。

例えばこういう感じの食事している。これは、大戸屋の彩り野菜と炭火焼きバジルチキン定食だ。腹さえ減ってれば、本当に旨いのでおススメしておく。

トレーナーのストレッチで激痛​

体が固いままではトレーニングにならない。そして、体が一定以上固いと自分ではストレッチできない。この状況を打開するには、専門知識を持つトレーナーにストレッチを手伝って貰うのが望ましい。

これが、とんでもなく痛い、というか痛くて毎回軽く泣いている。肩甲骨の裏辺りを押されて激痛。首の裏側辺りを押されて激痛。ストレッチポールの上で胸を押されて泣く。仰向けで、足をゆっくり持ち上げられただけで顔が歪むほど痛い。

週一回、30 分程度のマッサージを受けているが、マッサージを受けた日は、トレーニングのパフォーマンスは確実に向上するし、体の柔軟性は少しづつ改善している。

例えば、仰向けで足を上げるストレッチは最初 30 度くらいしか上がらなかったが、二か月かけて 60 度くらいまで上がるようになった。なお、90 度程度は誰でも上がるらしい。

三か月くらい続ければ、徐々に痛みは無くなって気持ち良くなるなどと言われているが、現状全く信じられない。しかし、今はそれを信じるしかない状況だ。少しでも早くマッサージ時の痛みを低減するために自宅でもストレッチを毎日やっている。

使っている器具やアプリケーション​

次は、これから筋トレをやってみようって人に、僕が使っている道具の類を紹介する。

これは、周りの筋トレを沢山やっている友人たちに教えて貰って集めた情報だ。

トレーニング器具​

プッシュアップバー​

いわゆる腕立て伏せするためのアレだ。自宅トレーニングでは少ない種目を短時間だけやるようにしているので、広範囲に負荷をかけられる腕立て伏せは効率がよい。ちなみに、他にやってる種目はプランクとスクワットだけだ。

Captains of Crush(キャプテンズ・オブ・クラッシュ) ハンドグリッパー​

握力を鍛えるハンドクリッパーだ。僕は握力が 30kg 前後なので、ガイドというレベルのやつをニギニギしている。

こいつは、トゲトゲしていて少しくらいの汗では滑らないので非常によい。単一の商品で、より上位のレベルが定義されており、攻略している感がある。

最高位の No.4 は世界で 5 人しか閉じられないとか、意味の分からん感じなのがまた良い。伝説の武器か何かなのかな…

ストレッチ器具​

ストレッチポール​

ウレタンの長い棒。類似商品でやたら安いのが色々あるが、あれらは全て柔らかすぎるのでダメだ。兎に角、一人で背中をマッサージする方法は少ないので、ストレッチポールは非常に良いものだ。

風呂上がりにこの上でゴロゴロしている。

ランブルローラー​

トゲトゲの短い棒。これは、短くて取り回しがし易いので、ストレッチポールではマッサージし辛い部位をストレッチするのに使う。こっちは、安い類似品でも相応の効果が得られるらしい。

骨盤職人​

ザ・激痛。体が柔らかくなってくると気持ちいらしいが、僕はまだその境地にいない。パーソナルトレーナーにマッサージして貰わなかった日は、風呂上りにこいつで色んな所を刺激している。

その他​

FITNESS ARCHIVE（フィットネス アーカイブ）​

ワークアウトの記録用アプリケーションは、10 個くらい試してみたが、フィットネスアーカイブが一番良かった。

アプリケーション内に組み込まれていない種目も、自分で定義できるのは本当に素晴らしい機能だと思う。

ただ、内部にため込んだ情報を一括で外に出力する方法が無いので、流行りの機械学習にかけたり統計処理するなら、何かひと手間必要になる。

SoundSport Free wireless headphones​

完全ワイヤレスイヤホンというやつだ。少し大きくて不格好だが、首の周りにケーブルが無いのでジムでも安心して使える。最初はランニング用の首回りだけはケーブルのあるワイヤレスイヤホンを買おうとしていたのだが、友人に勧められてこちらにした。

新宿、渋谷、東京など巨大なターミナル駅の改札付近にいると、ブチブチ切れて大変不快だが、ジム内では快適だ。トレーニング中は寝っ転がったりするので、少しでもケーブルがあると、危なかったり不快だったりする。それが無い完全ワイヤレスイヤホンは、大変素晴らしい。

後、通信が切れた後に何もしなくても数秒で復帰してくるので、非常に使い易い。再充電しなくても 5 時間くらいはバッテリーが持続するのでトレーニング中にバッテリーが無くなってしまうこともない。

音質については、僕が音痴なのでよく分からない。少し高額な商品だが、ジムの中で音楽を聴くなら、こいつはマジでおススメだ。

まとめ​

このエントリでは、この二か月間で僕が学んだことを出来るだけ全て書くようにした。

ジムに行った方が良いというのは分かっていても、そもそも契約が面倒だと思ったり、何かちょっとしたことでジムに行かなくなってしまうことはあるだろう。僕も以前はそうだった。

しかし、状況を整理し、目的意識をはっきりさせ、細かい記録を取り、認知の解像度を上げることで、筋トレを楽しめる状態になった。この調子なら当分継続できそうだ。

この記事を最後まで読んだあなたはどうだろうか？

僕がよく知っている業界は SI だが、これに限らずソフトウェア開発の現場には、過酷な現場…いわゆるデスマーチが多いと言われている。

一方で、そのような過酷な現場を渡り歩き生き残ることでしか、良いプログラマになる方法は無いと言った考え方もある。僕の個人的な経験則からすると、この理屈はある程度合っていると思う反面で、合っていて欲しくないという気持ちは強い。

高い技術力をもつプログラマの全てがデスマ職人という訳ではない。

デスマーチに巻き込まれたと気が付いた時の妥当で基本的な戦術は撤退戦だ。何か理由をつけて逃げ出すのが望ましい。つまり、休職なり退職なり、異動なりして、その職場から離れるのが望ましい、出社拒否も良い。しかしながら、何か様々な理由があって、そこから逃げ出せないことはあるだろう。

僕はもう長い事デスマーチに関わることなく生きられているが、徐々に忘れつつあるので、若いころに獲得したデスマーチを生き残る方法論について記録しておく。

最初に断っておくが、これから経験則に基づく医学的根拠のない知見を披露する。あなたが、それに基づいて行動した結果について僕は一切の責任を負わない。

デスマーチとは何か​

ソフトウェア開発におけるデスマーチとは、おおむね終わる見込みが無いのに、様々な思惑がかみ合うことで何故か資金が投入され続けるプロジェクトのことである。

資金を獲得する際には、比較的過酷な努力目標が設定されるため、そこで稼働する労働者に対して高負荷を与えることが多い。

本稿ではデスマーチ（以後、デスマ）を生き残る技術について説明したいので、デスマが何であるかについては３６協定の限度時間を参照しておく。基準が厳しすぎると感じるかもしれないが、時間外労働をさせる場合の基準時間に抵触するプロジェクト、つまり一ケ月で時間外労働が４５時間を超えるプロジェクトは全てデスマであると考えるべきだ。

あなたが若かったり、経験豊富であったり、プロジェクトの人間関係が良好であったりと、様々な副次的な要件が満たされることによって、そのようなプロジェクトにいるにも関わらず特に危険を感じていないかもしれないが、それは大変幸運なことだと考えるべきである。

病院を確認する​

デスマに巻き込まれたかもしれないと感じたら、あなたが最初にやるべきことは病院を確認することである。

勤務先と自宅のそれぞれから最も近い病院の住所と電話番号をスマホの電話帳に登録しよう。 最低限、内科があればいい。消化器科や脳神経外科がある病院があるならより望ましい。 自宅にいる際に倒れた状態からインターネットで病院を探すことはできないだろうが、スマホを操作して電話するくらいはできるかもしれない。その差が生死を分けることもある。

デスマにいる間に虫歯になることは多いので、歯医者も確認しよう。 半年以内に歯科検診を受けていないなら、とりあえず歯医者には行くべきだ。

腹痛や頭痛などの痛みや、睡眠障害を感じたら即座に病院へ行くことだ。薬局で買える鎮痛剤や睡眠導入剤を安易に使ってはいけない。

栄養ドリンクの飲み方​

最近はコンビニや薬局などに栄養ドリンクのようなものが大量に並んでいる。具体的な商品名は避けるが、羽が生えるだの、なんだのと色々書いてある。まず、こういうものを飲むのをやめよう。

人間はおおむね、砂糖とカフェインを一定量以上摂取するとテンションが上がるように出来ている。 よく分からないが効きそうな薬品名が書いてあるかもしれないが、コンビニで買えるようなものはおおむね砂糖とカフェインが大量に入っているので、元気になると考えるべきだ。

まず、覚えておいて欲しいのだが、人間は体内の水分が３パーセント程度失われるだけで眠くなる。つまり、軽度な眠気への対応策としては水を飲むべきだ。いきなりコーヒーだのお茶だのカフェインが入ったものを飲まない方が良い。

ポカリスエット​

テンションを上げられる砂糖が多く含まれており、水分を簡単に補給できて簡単に手に入る飲み物がある。

ポカリスエットだ。栄養ドリンクの類を飲み始める前に、まずはポカリスエットを飲んで欲しい。これで足りなくなってきたと感じたら、次の段階だ。

ヘルシア緑茶​

砂糖の次はカフェインだ。カフェインが大量に含まれており砂糖が余り含まれていない飲み物がある。

ヘルシア緑茶だ。ポカリスエットで水分と砂糖を取って足りないようならカフェインを追加する。 気を付けて欲しいのは、カフェインは刺激物なので胃にくる。一時期、眠くならないからと言ってヘルシア緑茶をデカいボトルで毎日ガブ飲みしていたことがあるが、結果的に胃に穴が開いて苦しむことになった。

リポビタン D​

ポカリとヘルシアをがぶ飲みする生活に慣れてきただろうか。しかし、プロジェクトは終わらず相変わらず負荷は高いままだ。そうなったとき、初めて値段が安い栄養ドリンクに手を出そう。 茶色のガラス瓶に入ってないようなのは、基本的に光で分解するようなナイーブなものは含まれてないので、全部雰囲気ドリンクである。

効果が高いとは言えないが、それなりにまともで値段が安い栄養ドリンクの代表例がリポビタン D だ。

シリーズには色々あるが、最初は兎に角安価なものを買うこと。気合いを入れて高価なものをいきなり買うのは避けるべきだ。体が不足を感じるまでは、ドリンクの価格を上げるべきではない。

ユンケル黄帝液​

空いたリポ D がディスプレイの下辺りにズラっと並ぶ姿がアタリマエみたいな雰囲気の生活になってきた頃には、もう効かなくなっているだろう。恐らく一日に何本もリポ D を飲んでいる筈だ。

そうなってしまったら、次のドリンクに手を出すしかない。次は、ユンケル黄帝液だ。

薬局で一際輝くパッケージに入っており、様々な商品がある上に、結構値段の高いアレがユンケル黄帝液だ。

これも、飲み方はリポ D と同じだ。とにかく安いやつから飲んでいくべきだ。いきなり高価なものに手を出すと、効きすぎて鼻血を大量出血することになる。デスマでは粘膜が弱くなるので、強い栄養ドリンクをいきなり飲むと、その効果を出血によって失うことになる。そういうことは望ましくない。

まぁ、栄養ドリンクをガブ飲みしながら働いている状況が、そもそも望ましくないのは言うまでもないが。

栄養ドリンクと睡眠の関係​

きちんと睡眠するには、体力を少々残しておかなければならない。老人が早起きなのは体力が無いので寝続けられないのではないかと思う。

プロジェクトが佳境を迎え、うっかり３０時間とか長時間にわたって稼働した結果、疲労の蓄積がピークを迎えると、疲れすぎて眠れなくなる。３時間睡眠を何週間も続けていても同様だ。

重要なことなので繰り返しておく、人間は疲れすぎると眠れなくなる。

栄養ドリンクを飲んで体力を一時的に回復すると、急激な眠気に襲われる可能性がある。理想を言えば、眠いなら寝てしまった方が良いのだが、そうも言ってられない状況だってあるだろう。

自分の疲労がピークを越えており、うっかり間違って１６時間とか眠ってしまうことを避けたいなら、栄養ドリンクのランクを下げることを考慮にいれよう。起きて働き続けられる程度にのみ回復するのだ。

睡眠について​

長期間に渡るデスマを生き残るには、睡眠の技術は欠かせない。

ショートスリーパーを自称し２時間や３時間程度の睡眠でも十分に活動できる等と強がるものを沢山見てきたが、そういう人間はあっという間に様子がおかしくなる。 本人が単におかしくなって退場するだけなら良いが、睡眠不足でおかしな事になっている人間がプロジェクトの中に居座ると、周りの人間に悪影響を及ぼす。

睡眠不足な人間は言動や行動が極端になるので、極限状態では発言力を行使し易いのだ。そうやって行使された様々なことは、当然ながらプロジェクトに悪い影響を与える。

そうならないよう、毎日最低でも６時間程度の睡眠時間を確保しよう。

椅子寝​

デスマと言えば椅子寝だ。何故、椅子で寝るのだろうか？

まず、床で寝るのは不衛生だからだ。外の道路や、トイレの中を歩き回った靴で踏みしめた床が衛生的である筈がない。次に、床は固いので上手く眠れないからだ。カーペットが敷いてあったところで、それは変わらない。最後に、地面で寝ると体が冷えすぎるからだ。体が冷えると眠れないだけでなく、風邪をひきやすくなる。

長時間の稼働では、免疫力が低下するので風邪をひきやすくなる。プロジェクトルーム内で風邪などの感染症を引き起こした人間が発生すると、連鎖的に人が倒れる。 忙しいからデスマなのに、病人が大量発生すれば状況は当然悪化するだろう。

椅子を並べて寝る際に気を付けるのは、背中の関節、特に腰に無理がかからない状態を探そう。 椅子寝をするなら、体を変な風に固定したりするのはやめよう。非常に危ない。背面部分に足を通したりすると、寝返りをうってしまった時に、上手く床に落ちられず大けがをすることになる。

寝る際には全身が床とおおむね平行になるようにすること。机の上に突っ伏して寝ていいのは１５分までだ。 それ以上は、疲れが取れたりはしないし、腰や肩に強い負担がかかるので望ましくない。

加えて、靴や靴下はちゃんと脱いで寝た方が疲れがとれる。足を圧迫しないほうがいい。

最後に、足首の高さは心臓よりも高くなるように調整しよう。漫画の雑誌などを３冊程度積むとよい。 下半身の血液が寝ている間に上手く循環すると疲れが取れやすい。

床寝​

既に説明したが、床で寝るのは基本的に望ましくない。

しかし、寝やすいソファや椅子がないこともあるだろう。そうした場合、どうしても床で寝ざるをえないことはある。

床で寝るのならまずは、コンビニで段ボール箱をもらってこよう。サーバが梱包されていた段ボール箱でもいい。 畳一畳程度の空間に潰した段ボール箱を並べ、その上で寝る事だ。厚みが５ cm 程度になるのが望ましい。薄い段ボールなら、３～４枚重ねる必要があるかもしれない。 段ボール箱は、紙の中に空気の層があるので、体が冷えづらいし、床で直接寝るよりは衛生的にマシだ。

段ボール箱を敷いたうえで寝袋を使うなら、より良いだろう。

体の衛生状態を確保しよう​

ここまでは、家に帰らないことを前提に話をしてきたが、家に帰れるなら出来る限り帰ったほうが良い。

家に帰れるなら忘れずにやって欲しいことがある。

疲れていると家にたどり着くなり、布団に入って寝てしまいたいと思うだろうが、睡眠による回復の効率を最大化するなら、就寝前に歯を磨いて風呂に入るべきだ。

たった３分歯を磨き、３０分風呂に入るだけでいい。

歯を磨く​

口腔内の衛生状態が悪化すると、風邪をひきやすくなるので、毎日歯を磨こう。

栄養ドリンクの類は、大体が酷い匂いがするので、それに慣れてしまわないためにもきちんと歯を磨くことは大切だ。

デスマで虫歯になったとしても、会社がそれを補填することは無いだろう。永久歯は虫歯になってしまえば、容易に失われるし、その治療費は高くつく。

普通の歯ブラシで磨いても良いが、疲れていると時間間隔がいい加減になるので、電動歯ブラシを使う方が良い。

僕のおススメ歯ブラシは、フィリップスのソニッケアーだ。

歯間ブラシとしては、ジェットウォッシャードルツを愛用している。

歯磨き粉は、刺激が少なく味が余りないものが好みなので、チェックアップスタンダードを使っている。

歯磨きが終わった後は、コンクール F で仕上げのうがいをする。

風呂に入る​

風呂に入るのは体や頭を洗うためだが、シャワーを浴びるだけでなく、しっかりと湯船に浸かるのが望ましい。

人間は体温が下がり始める時に、眠り易くなる。湯船に使って一時的に体温を上げると、簡単にその状況を作り出せる。

そして、就寝前に風呂に入るのは、スマホや液晶モニタの光から自分の目を遠ざけるという目的もある。強い光を見た直後に上手く眠るのは難しいので、風呂にはいることでそのインターバルを確保するのだ。 つまり、風呂上りにソシャゲをやったりメールをチェックしてはいけない。

自宅の掃除をする​

デスマの最中だとしても、１週間から一度、悪くても１か月に一度くらいは丸１日ないし２日休める日ができるだろう。

まずは、十分な睡眠を確保すべきだが、人間は熊などの冬眠できる哺乳類と違って寝溜めすることはできない。起きたらインターネットやテレビを見て時間を溶かすのではなく、掃除をしよう。

具体的には、水回りの掃除をすべきだ。水回りとは、トイレ、風呂、キッチンのことだ。

特にトイレと風呂は汚れやすいので、休みの日に掃除をする。これは、肉体的な意味での衛生状態を確保すると共に精神的な意味での衛生状態を確保する意味もある。

疲れ切って帰ってきた家のトイレが汚いと、メンタルは確実にすり減るからだ。少しくらい汚れていても平気な人間がいることは否定しないが、精神状態がおかしくなった人間の家の水回りは確実に不衛生だ。

まとめ​

デスマーチを生き残るには、何にせよ肉体と精神の健康を維持することが肝要だ。

このような知識を使うことなく一生をまっとうできることが望ましいが、そうでないことはあるだろう。

どんな場所でも、ほんのちょっとしたボタンの掛け違いでデスマーチは突如として現れる。

読者の皆様が、そのような状況になっても正気を保ったまま、そこから逃げ出せることを祈っている。

Windows には他の OS には無い致命的な問題が一つあった。そう、OS 標準のパッケージマネージャが無いことだ。

Windows10 ではPackageManagementという大変素晴らしい OS 標準のパッケージマネージャが搭載された。

これでコマンドラインだけで開発環境をガンガン作れるに違いない。そう考える人がいてもおかしくはない。正直、僕だってそう思いたい。

PackageManagement の問題点​

僕は PackageManagement のアーキテクチャが難しすぎる事は大きな問題だと考えている。このエントリを是非読んで欲しい。

• Introducing PackageManagement in Windows 10

もうね、何でこんなに大変なことになってるのかと。

いや、歴史的経緯を鑑みつつ、OS に標準搭載されるパッケージマネージャが持つべき仕組みをキチンと備えた妥当な設計になっているじゃないか、と強い調子で言われれば説得力があるようにも思える。

じゃあ、この素晴らしい抽象度で実装された PackageManagement 様におかれましては、それはそれは様々なバリエーションの動作をするんですよね？というと、実態はそうじゃない。

現在の PackageManagement は、雑に言えばChocolateyの何かややこしいラッパーでしかない。確かに、PowerShell Galleryには、沢山のモジュールがあるよ。あれ、便利なモジュールどんだけあんの？

僕としては、直接 Chocolatey 使えば良いと思うんだよね。ジッサイ。

「OS に標準搭載されたボキャブラリでアプリケーションをインストールし、アンインストールできることは大変すばらしい事だ！」

アア、ハイ、ソノトオリデスネ。

Chocolatey の問題点​

Chocolatey 使ってて、まずダルいなって思うのは、UAC のポップアップ。コマンドラインで作業してるのに突然現れてマウスでクリックしないと先にすすめなくなるアレ。マジでイライラする。

Windows10 はマルチユーザ OS だけど、ユーザの切り替えなんてやってねぇよ。というか、複数の環境が必要なら Docker なり、Hyper-V なり使ってる。だからね、現在のユーザローカルにだけコマンドのパスが通れば良いんだよ。

次にダルいなって思うのは、結構な頻度でアンインストールが失敗すること。インストールが綺麗にできる以上に、大事なのはアンインストールが綺麗にできることだ。

いやいや、MSI 形式のインストーラの問題だろ、それって言われれば、確かにちゃんと切り分けてないから、これは言いがかりかもしれないけどね。

ある程度の規模感で Chocolatey 使おうと思うと、ローカルリポジトリ的なものが欲しくなると思うんだけど、それを用意するのがとんでもなく面倒なのも辛い。確かに、How To Host Feed辺りをちゃんと読めば出来るよ。

面倒すぎるんで、僕としてはあんまやりたくない感じの手順だけどね。

というわけで、僕の個人的な趣向としては Chocolatey が嫌いだ。避けようが無くて使う事があるのは否定しないが、出来る限り使いたくないとさえ思っている。

Scoop について​

というわけで、今週のおススメはScoopだ。

Scoop を使うべきか？​

まず、最初に言っておく。Scoop は真っ当なパッケージマネージャではない。そして、linux 文化圏にいるけど、色々理由があって今は Windows を使ってるって人間に向けて開発されている。

Scoop がどういう思想で作られているかみたいな話は、公式の Wiki に書いてある。

• So What?

これを読めば、自分が Scoop を使うべきなのかは、ある程度ハッキリと理解できるだろう。

Windows しか使わないし、linux 文化圏のやり方を Windows 上でやることに意義を感じないなら、Scoop を使う必要はない。

そして、Scoop は開発環境を構築するためのツールだ。開発環境構築を楽にすることに強くフォーカスしているおかげで、色んなことがシンプルで簡単になっている。細かいことは、あまり考慮していない。

Scoop の何が素晴らしいか​

ユーザのローカルディレクトリに何でもインストールするので、あのうざったい UAC ポップアップが出ない。

C:\Users\taichi\scoop\shims

みたいなディレクトリにコマンドをガンガン投げ込むスタイルだ。Scoop をインストールした時にこのディレクトリが PATH に追加される。

次に、ローカルディレクトリにファイルを展開していくスタイルなので、アンインストールが安定して動作する。特に難しい事をやってないので、それほど失敗する余地が無いってことなんだろう。

そして、Scoop でインストール可能なアプリケーションのメタデータは git リポジトリで管理している。だから、Scoop 標準のメタデータストア内に、欲しいものが無いなら比較的簡単にオレオレ Scoop リポジトリを作れる。

Scoop のダメなところ​

Windows インストーラ文脈にのっていないこと​

一番ダメなところであり、素晴らしいところは、Windows のインストーラに関する文脈に全く乗っていないところだ。つまり、Scoop を使ってインストールしたアプリケーションは、Windows 標準のアプリと機能から参照できない。ただし、これはmainバケットからインストールしたものに限る。

mainバケットは、scoop がデフォルトで参照するアプリケーションリポジトリで、extrasバケットは、追加のコマンドを実行することで参照できるリポジトリだ。

中身をきちんと確認していないがphpというバケットもある。流石の PHP だ。最近は、javaというバケットもあり、その中に oraclejdk と openjdk の両方が入っている。

extrasバケットには、exe や msi といった Windows のインストーラに関する文脈に乗っているものが含まれている。例えば、oraclejdk をインストールするなら、あの忌々しい UAC ポップアップが普通にポロリーンだ。

最新版しか使えないこと​

アプリケーションは基本的に最新版しか使えないし、細かくリビジョンを切り替えることは出来ない。みんなが大好きな pyenv だの nvm だのといった仕組みとは違うってことだ。

Scoop ではメジャーバージョンが違うものは、違うアプリケーションとして管理している。例えば、

scoop install ruby

とすると、今なら 2.4.1-2 が入るし

scoop install ruby19

とすれば、今なら 1.9.3-p551 が入る。

両方入れた時に、rubyコマンドで実行されるバイナリを切り替えるには、 scoop resetというサブコマンドが用意されているので、それを使って切り替えればいい。詳細は公式マニュアルを見て欲しい。

• Switching Ruby and Python Versions

細かいバージョンの差異に伴う再現テストなんて、ローカルでやらずに CI サーバでマトリックステストすれば良くない？僕としては、そういう気持ちです。

ちなみに、scoop を使えば、みんなが大好きな anaconda もコマンド一発でインストールできるよ。僕は使わんけど。

さぁ、Scoop を使おう​

Scoop のインストール​

こんな所まで長文を読んだって事は、Scoop を使おうって気になったってことだろうから、Scoop をインストールしてみよう。

Powershell3 以上の環境で、こういうコマンドを実行する。Chocolatey のインストールと大体一緒だよね。

iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

エラーが出てインストールできないなら、こういうコマンドで、ExecutionPolicy を少し緩めて欲しい。

Set-ExecutionPolicy RemoteSigned -scope CurrentUser

これで、scoop コマンドが実行できるようになった。

Scoop でアプリケーションをインストール​

じゃあ、試しに node でもインストールしてみようか。その前に、Scoop のバケットを検索してみよう。

scoop search node

今の時点では、こういう感じの出力がなされる。

'main' bucket:
    eventstore (4.0.2) --> includes 'EventStore.ClusterNode.exe'
    nodejs-lts (6.11.3)
    nodejs (8.5.0)
    sliksvn (1.9.7) --> includes 'svn-populate-node-origins-index.exe'

あなたは最新の node をガンガン使って行く Node ジャンキーだろうか？それとも、しっかりと動作する LTS 版を好むタイプだろうか？

僕は、もちろん Node ジャンキーなので、最新版の nodejs を使いたい。こういうコマンドを入力しよう。

scoop install nodejs

こういう感じの出力がなされて、最新版の nodejs がインストールされた。

Installing 'nodejs' (8.5.0).
node-v8.5.0-win-x64.7z (8.7 MB) [=============================================================================] 100%
Checking hash of node-v8.5.0-win-x64.7z... ok.
Extracting... done.
Linking ~\scoop\apps\nodejs\current => ~\scoop\apps\nodejs\8.5.0
Persisting bin
Persisting cache
Running post-install script...
'nodejs' (8.5.0) was installed successfully!

素晴らしい。

Scoop でアプリケーションをアンインストール​

次は、アンインストールだ。今入れたばかりのアプリケーションを何でアンインストールするのかって？

それは、僕がインストールジャンキーだから、というのは冗談で単に説明のためだ。

予想できると思うけど、こういうコマンドでアンインストールできる。

scoop uninstall nodejs

こういう感じの出力がなされて、さっきインストールしたばかりの nodejs がきれいさっぱりいなくなった。

Uninstalling 'nodejs' (8.4.0).
Unlinking ~\scoop\apps\nodejs\current
Removing ~\scoop\apps\nodejs\current from your path.
Removing ~\scoop\apps\nodejs\current\bin from your path.
'nodejs' was uninstalled.

キマるぜぇ！！

Scoop で複数バージョンをインストールしたい​

どうしてもローカルに複数バージョンのアプリケーションをインストールしたいって呪われた性癖を持つ人はいると思う。

そういうあなたには、versionsバケットというものが用意されている。こういうコマンドを実行すると、最新版ではないアプリケーションの情報を検索できるようになる。

scoop bucket add versions

これで、もう一度 node を検索してみよう。

scoop search node

ようこそ、バージョニング地獄へ。

'main' bucket:
    eventstore (4.0.2) --> includes 'EventStore.ClusterNode.exe'
    nodejs-lts (6.11.3)
    nodejs (8.5.0)
    sliksvn (1.9.7) --> includes 'svn-populate-node-origins-index.exe'

'versions' bucket:
    nodejs010 (0.10.48)
    nodejs012 (0.12.18)
    nodejs4 (4.8.4)
    nodejs6 (6.11.3)
    nodejs7 (7.10.1)
    nodejs8 (8.5.0)

安心してくれ。どのメジャーバージョンでもコマンド一発で最新版が入れ放題だ！

もっと Scoop を知りたい！​

公式の Wiki を見てほしい。すごく丁寧にドキュメントが書かれていて、知りたい事はなんでも分かるようになっている。

• https://github.com/lukesampson/scoop/wiki

まとめ​

僕は、かなり Linux 文化に染まっているとは言え、GNU 信者ではないのでゲームができない Linux デスクトップを使ったりはしない。普通の Windows ユーザだ。

なので、Bash on Windows に喜んだりする一方で、ある程度は PowerShell を使って作業したい。

とはいえ、いくら設計に優れていても、ややこしいだけのものを我慢して使いたくはない。

こういう気持ちに同調してくれる Windows ユーザは多い筈だ。コマンドラインベースで、開発環境のセットアップを自動化したいが、どうもしっくりこないって人は多いんじゃないかな。

そういうあなたは、是非 Scoop を試してみて欲しい。

僕が以前書いたModern JavaScript 概観、そして Electron へは、読んで貰えただろうか？

あれは初学者には全く向いてないエントリだ。

あのエントリは、僕の理解したモダンな JavaScript 全体について概観することを目的としているからね。

あれを読んで、「今の JavaScript ってこんなに大変なのか…」と感じた人は多いだろう。

しかし、ある程度のソフトウェアを開発するために技術全般を概観しようとすれば、ああいう分量になるのは致し方ない。

と言う訳で、今回はちゃんと初心者向けのエントリを書いた。

少し多く感じるかもしれないが、丁寧に説明しようとしたからだと好意的に解釈して欲しい。

開発環境​

Thinkpad X1 Carbon 2016 年モデルに Windows10 をインストールしてある。

ハードウェアスペックは、こうだ。

• CPU i7 6600U @ 2.6GHz
• メモリ 16GB
• ストレージ SAMSUNG NVMe SSD 950 PRO 512GB

少し高級かもしれないけど開発者用のマシンとしては普通だよね。

Node をインストールしよう​

Windows に Node をインストールする方法は色々あるんだけど、scoop を使ってほしい。

Scoop をインストールするには、以下のコマンドを Powershell で実行する。

Set-ExecutionPolicy RemoteSigned -scope CurrentUser
iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

scoop のインストールが終わったら、以下のコマンドを入力する。

scoop install nodejs

そうすると、細かいバージョンやディレクトリ名は違うかもしれないが、こういうメッセージが出力されるはずだ。

Installing 'nodejs' (8.5.0).
node-v8.5.0-win-x64.7z (8.7 MB) [=============================================================================] 100%
Checking hash of node-v8.5.0-win-x64.7z... ok.
Extracting... done.
Linking ~\scoop\apps\nodejs\current => ~\scoop\apps\nodejs\8.5.0
Persisting bin
Persisting cache
Running post-install script...
'nodejs' (8.5.0) was installed successfully!

これで、最新版の Node がインストールされた。

バージョンアップする時は、Powershell で以下のようなコマンドを実行すればいい。

scoop update nodejs

Node はかなり頻繁に新しいバージョンがリリースされるから、定期的にアップデートして欲しい。

パフォーマンスが改善したり、細かい問題が解決されたりしているかもしれないからね。

VS Code をインストールする​

Node のランタイムをインストールしたら次はエディタをインストールしよう。

世の中 JavaScript を快適に書けるエディタは色々あるけど、今はVS Codeがおススメだ。

ここから、自分の OS に合ったインストーラをダウンロードして実行しよう。

リファレンスをブックマークする​

エディタをインストールしたので、さぁコードを書こうと言いたいところだけど、まだ少しやる事がある。

ちゃんとしたリファレンスサイトをブラウザでブックマークして、困った時はそこを見るようにしてほしいんだ。

• JavaScript / 日本語
• Node
• JavaScript Promise の本
• AVA
• package.json
• VS Code

Mac には、Dashって便利なアプリがあると聞いた覚えがあるのだけど、僕は使ったことが無いので分からない。

プロジェクトを構成する​

プロジェクトをきちんとセットアップするのは、面倒だと感じるかもしれないけど便利なことが多いから少し頑張ってほしい。

まずは、作業用のディレクトリを作ろう。好きなパスにディレクトリを作ってくれればいい。

ここでは、C:/dev/js/projects/js_for_beginner というディレクトリを作った。

エクスプローラで、このディレクトリを右クリックすると Open with Code というメニューを選ぶ。

VS Code が起動したら、Ctrl キーを押しながら@キーを押す。これで、VS Code 内に PowerShell が起動するはずだ。

ここで以下のようなコマンドを入力する。

npm init -y

これでデフォルトのpackage.jsonが生成される。

Babel を導入する​

Node は ES2015 の構文が殆ど使えるので、Babel を使う強いモチベーションはimport文を使いたいかどうかだけなんだけども、まぁ、使いたい。

Babel を導入するために、以下のようなコマンドを VS Code 上に開いた PowerShell で入力する。

npm install babel-cli babel-preset-env -D

このコマンドが終了するとpackage.jsonの中身はこういう風になっているはずだ。

{
  "name": "js_for_beginner",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {},
  "devDependencies": {
    "babel-cli": "^6.24.0",
    "babel-preset-env": "^1.2.2"
  },
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

ここに Babel 用の設定を追加すると、こうなる。

{
  "name": "js_for_beginner",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "source-map-support": "^0.4.14"
  },
  "devDependencies": {
    "babel-cli": "^6.24.0",
    "babel-preset-env": "^1.2.2"
  },
  "scripts": {
    "compile": "babel src --out-dir .",
    "exec": "node -r babel-register src/index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "babel": {
    "sourceMaps": "inline",
    "presets": [
      ["env", { "targets": {"node": 7}, "useBuiltIns": true}]
    ]
  }
}

npm script にcompileタスクとexecタスクを追加した。併せて、babelというエントリを一番最後に追加した。

compileタスクは実行すると、src ディレクトリにある JavaScript がコンパイルされてプロジェクトのルートディレクトリに出力される。

execタスクを実行する、コンパイルせずに直接 src ディレクトリにある index.js を動かせる。

babelエントリのsourceMapsは、コンパイルした JavaScript の末尾にデバッグ用の SourceMap を付加するという設定だ。

presetsのenvは、Node と最新の JavaScript の差分だけをコンパイル時に取り込むようにする設定だ。これによってコンパイル後のモジュールが不用意に大きくなるのを避けられる。

Source Map Support の導入​

Babel を導入するだけだと、エラーが起きた時のスタックトレースが自分の書いたコードと合わないので、source-map-support も導入する。

npm install source-map-support -S

src ディレクトリに、index.js というファイルを以下の内容で作ってみよう。

import "source-map-support/register";
import * as fs from "fs";

console.log(fs.readFileSync("package.json").toString());

throw new Error();

これを動かすには、VS Code の PowerShell で以下のコマンドを入力する。

npm run exec

一行目のimport "source-map-support/register";をコメントアウトした時と、そうでない時でスタックトレースの行番号が微妙に変わるので確認して欲しい。

AVA を導入する​

最後は、テスティングフレームワークの導入だ。これで最後なので頑張ってほしい。

いい加減なスクリプティングで言語を勉強するよりは、テストコードを動かしながら言語を勉強した方がよりよい作法が身につくからね。

npm install ava -D

モジュールをインストールしたら、package.jsonに AVA 用の設定を追加する。

{
  "name": "js_for_beginner",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "source-map-support": "^0.4.14"
  },
  "devDependencies": {
    "babel-cli": "^6.24.0",
    "babel-preset-env": "^1.2.2"
  },
  "scripts": {
    "compile": "babel src --out-dir .",
    "exec": "node -r babel-register src/index.js",
    "test": "ava"
  },
  "author": "",
  "license": "ISC",
  "babel": {
    "sourceMaps": "inline",
    "presets": [
      ["env", { "targets": {"node": 7}, "useBuiltIns": true}]
    ]
  },
  "ava": {
    "files": [ "test/**/*.js" ],
    "source": [ "src/**/*.js" ]
  }
}

npm script のtestタスクの中身を AVA を実行するように変更した。

併せて、AVA がテスト実行する際に、テスト対象コートと、テストコードをどういう基準で探すのかをavaエントリに定義する。

test ディレクトリに、index.js というファイルを以下の内容で作ってみよう。

import test from "ava";

test(async t => {
  let foo = Promise.resolve("foo");
  t.is(await foo, "foo");
});

これを動かすには、VS Code の PowerShell で以下のコマンドを入力する。

npm run test

AVA 自体の説明については、前回のエントリや公式のドキュメントを参照して欲しい

まとめ​

僕の気持ちとしては、Yarn、Flow、ESlint、documentation.jsあたりは必須ですと書きたい。

でも、これらは無くても少し不便なだけでコードが書けない訳じゃないので今回は紹介しなかった。

よりよい環境を目指すんなら、必須だけど初学者にいきなり要素技術を沢山積んでも学習しきれないだけで、意味が無いからね。

そういう揃ってる環境が欲しいなら、僕が作ったjs-boilerplateの master ブランチを参考にして欲しい。

RDB とスキーマレス DB をどういう基準で使い分けるのかを、会社で聞かれた際に答えた雑な回答をメモ書きしておく。

他にも多くの基準があるだろうし、スキーマレス DB というか KVS は様々な実装があり、そのそれぞれが微妙に違うので議論として曖昧な部分はある。

特に、運用面やデータ量がペタバイトクラスになる状況については考慮していない。

僕は SI 戦士なので、最終的には金を無限に突っ込んだ Oracle 先生が最高のデータベースであると考えている。

そういうバイアスのある人間の意見だと思って以下の文章は読んで欲しい。

念頭に置いているデータベースについて​

このエントリを書くにあたって念頭においているデータベースは以下の通り

• RDB
  • Oracle
  • PostgreSQL
  • MySQL
• スキーマレス DB
  • MongoDB
  • Amazon DynamoDB

最初は Redis を DB と書いていたけども、僕の認識違いが明らかになったので DB でない方に移した。

念頭に置いていないデータベースについて​

このエントリを書くにあたって念頭においていないデータベースのようなものは以下の通り

• HBase
• Elasticsearch
• Memcached
• Redis

これらをデータベースだと言う人もいるだろうが、僕はこれらをデータベースとは考えていない。

意見の相違がある方はアンサーエントリを書いて頂けると勉強になるのでありがたい。

スキーマを事前定義するか？​

一番大きな違いは、スキーマを事前定義するのか、事後定義つまり、格納されているデータがスキーマなのである、というアプローチをとるのかが違う。

スキーマを事前定義するためには、ストレージされるデータの構造を厳密に規定しなければアプリケーションを作り始められない。

一方で、スキーマを定義しないのであれば、手に入れたデータを JSON か何かにシリアライズすれば、とりあえず DB に格納できる。

つまり、これから作ろうとするアプリケーションをどれだけ厳密に設計したいか？というのが、最初の使い分け基準になる。

トランザクションを使いたいか？​

次にトランザクションモデルが違う。

RDB では、トランザクションを使えるので複数のデータを追加したり更新する時の整合性を取るのが非常に簡単だ。データの整合性を保障するのはデータベースの役割となる。

一方で、スキーマレスな DB の殆どはまともなトランザクションをサポートしていないので、複数のデータを追加したり更新する時の整合性を取るのはアプリケーションコード側でやらなければいけない。

トランザクションモデルの違いは、DB に格納するデータ構造の違いにも表れる。

RDB では、ユーザや、部署、会社のようないわゆるマスタデータは、それぞれ正規化して独立したテーブルにするのが望ましいとされる。これは、ユーザと部署と、その連関テーブルを同時に更新するのが容易いからだといえる。

一方で、スキーマレスな DB では、一つのビジネストランザクション内で必要なデータは一つの塊として保存してしまうのがよい。

データは正規化されている訳では無いので、複数のビジネストランザクション間で、同じ筈のデータが同じでなくなってしまう可能性はある。それが問題になるようなアプリケーションではスキーマレス DB を使わなければいい。

これから作るアプリケーションにおいてトランザクションは必要か？必要ない場合に、データが非正規なままでも問題が置き辛いようなアプリケーションか？が二番目の使い分け基準になる。

高度なクエリ言語を使いたいか？​

3 つ目の使い分け基準の話は、DB の実装によって違うのでおおまかな話になるが、クエリの複雑さの話だ。

RDB では標準化された極めて高水準で高機能な SQL を使える。集合論に基づいて設計された SQL は DB というデータの集合を操作するために最適化された構造をしている。

一方で、多くのスキーマレス DB には、それ程高水準なクエリ言語は搭載されていない。

ちょっと日付で範囲クエリが使えるだけで優位性があるとみなされるレベルだ。

多くの場合は、KVS 等と言われるように、DB に格納されているモデルの特定のフィールド、つまりキーを基準に 1:1 でデータを取出せるだけだ。集合に対する操作が必要なら、アプリケーションコードの中で、map だの reduce だのと言った関数を駆使することになる。

データの量が十分に少なければ、アプリケーションコードで集合を操作すること自体が問題になることはないだろう。

一方で、データの量が大きい場合、つまりメモリに乗り切らない程度に大きくなる場合、アプリケーションコードとして適正に動作する集合操作のコードを書くのは飛躍的に難しくなる。一度に操作しきれないので、部分的にファイルに書きだしたり、DB からデータを少しずつ取り出しながらソートしたりといったコードを書くのは、恐ろしく難しいので出来れば避けるべきだ。

更にデータ量が大きい場合、つまりデータベースを分散化せざるをえない程度に大きくなる場合には、さらに別な手段を考える必要がある。これは、ビッグデータ界隈の話になるので、そちらについては言及しない。

まとめ​

以上をまとめると、RDB とスキーマレス DB の使い分けの基準は３つ

• スキーマを事前定義するか？
• トランザクションを使いたいか？使わない場合、それに伴うデータモデルのあり方を許容できるか？
• 高度なクエリ言語を使いたいか？