2021年良かった本10選

暮れも押し迫ってきたので、毎年恒例の企画です。

今年は選ぶのにかなり苦労しました。

というのも、今年はいろいろ読み過ぎて上半期に買った本をすっかり忘れていたからです。

そういえば、今年はいつも本を読んでいたね。
見かけるたびに新しい本を買っていた気がする。

うん。

なので、その分コアなおすすめが出揃いました。

よし!

それでは、2021年の「よかった本」カウントダウン!



英文法のトリセツ 中学レベル完結編

今年の初めに英語と仲直りしようと何度目かの決意をして読んだ本。 もはや僕が解説するまでもなく、この『トリセツ』シリーズは10年以上売れ続けているロングセラーである。

ではなぜ今さらこの本を紹介するかというと、この最終巻だけレベルが違うから。 つまり、前2作は問題なく読破できても、今作になって挫折する危険性が高く、中身の良さに気付けないまま本棚にしまい込んでしまった人もいるのではないかと思い、その良さを再認識していただきたく、敢えて載せた次第である。

一方、『中学レベル卒業編』は、『じっくり基礎編』『とことん攻略編』で(話を簡単にするため)敢えてごまかしてきた話としっかり向き合い、多くの伏線を回収している。

それだけに、きちんと理解した上での読後感はひとしおである。 英語やり直し組の大人の方にもぜひお勧めしたい。

大学入試 うんこ英単語2000

DUO(デュオ)セレクト: 厳選英単語・熟語1600』を何周もしすぎていい加減飽きてきたので、つい魔が差して買ってしまった。

この本の最大にして唯一の特徴は、例文すべてに「うんこ」が配合されていることである。 そのため、単語とその意味だけを覚える学習スタイルには合わず、例文を楽しむ余裕のある(受験勉強に追われない)大人こそ買うべき本だろう。

例文のクオリティが無駄に高く、英作文でパクれそうな便利な言い回しが普通に出てくる。 ウンコさえ除けば。

ただし(DUOほどではないが)文法知識が足りていないと読解がきついかも知れないので、ライトな大学を目指す高校生がネタで買うと本気で後悔するかも知れない。

仕組みと使い方がわかる Docker&Kubernetesのきほんのきほん

この本の最終到達レベルは、『さわって学ぶクラウドインフラ docker基礎からのコンテナ構築』と同じくらい(kubectlコマンドの基本的な使い方を抑えるところまで)で、正直なところどちらも甲乙つけがたい。

この本は、コンテナ、ボリューム、Pod、サービス、……といった、混乱しがちな概念を擬人化と絵解きでわかりやすく説明している点・docker compose や Kubernetes の設定ファイルの意味するところをひとつひとつ読者に解き明かしている点が嬉しい。

初学者は、いきなり長大な yaml ファイルを写経させられると「よくわからないことをやらされている感」が蓄積してモチベーションが砕け散るので、そういうことが起こらないようになっているだけでもだいぶ敷居が下がる。

かわいい表紙と裏腹に、「強者コラム」という玄人向けの挿話なんかもあり、新人エンジニアだけでなく非インフラ系アプリケーション開発者が読んでも十分に楽しめるし為になる。

初めてのWebGL 2 第2版 ―JavaScriptで開発するリアルタイム3Dアプリケーション

WebGL 2(と、シェーダ言語 ESSL)の基礎的な内容を解説した貴重な1冊。 夏休みに買って、夢中になって読んだ。

難易度は高めというか、予備知識としてレンダリングパイプラインの働きや大学初年級レベルの線型代数を理解していないと、ちょっとついていくのはしんどいかもしれない(ぶっちゃけ、ところどころ数式が怪しい点があり、僕も検算しながら読み進めた)。

解説が難解な割に到達レベルはあまり高くはないものの(せいぜい剛体にテクスチャを貼るくらい)、しかし、プラットフォームを選ばず Web ブラウザで動作する 3D アニメーションを一から作っていく感覚はなんとも言えず楽しい。

IoTデバイス×Webアプリでホームネットワーク AWS クラウドサービス開発テクニック

IoT 連携という面白い切り口に特化した本である。

クラウドサービスに AWS を用いる以外は、IoT デバイスも利用言語も各章で異なるオムニバス形式で構成されている。

さすが AWS 社の社員が書いただけあって、各種サービス(IoT Core, Amplify, Greengrass 等)を巧みに組み合わせておもちゃを作るさまは、まるで大人版のつくってあそぼを見ているようだった。

どこから読んでも面白いのだが、一抹の危機感もある。 本書を読めば、たとえば昨今のコロナ禍で需要が高まりつつある「混雑状態の見える化」などが意外と手軽に手作りできてしまうので、これまでそういうソリューションを売っていた業界の人たちは、きっと内心「参ったなぁ」と思うのではなかろうか。

Pythonではじめる数理最適化: ケーススタディでモデリングのスキルを身につけよう

先の『IoTデバイス×Webアプリでホームネットワーク AWS クラウドサービス開発テクニック』を読み、アイディアだけでは潰されるということが分かったので、もう少し下地を固めたいなぁと思い買った。

本書で触れる話題は、「学校のクラス編成」や「輸送車両の配送計画」など、実践的で興味深いものが多い。 これらはなかなかシステム化が進まず、勘と経験に頼った属人的業務になっていないだろうか。

現実の問題に対して、数理最適化という手法がどのように適用されるのか。 また、具体的にどのように実装されるか、といった実践的内容がまとまっており、なるほど、こういうアプローチがあるのかと目から鱗が落ちた。

なお、『初めてのWebGL 2 第2版 ―JavaScriptで開発するリアルタイム3Dアプリケーション』ほどではないが、本書も高校の数学II程度の予備知識を要する。

マンガでわかる微分方程式

先の『Pythonではじめる数理最適化: ケーススタディでモデリングのスキルを身につけよう』を読み、時系列で変化するデータの未来予知を数理モデルで解決してみたくなり手を出した本。

常微分方程式というと、絢爛豪華な計算テクニックに目が行きがちだが、この本は微分方程式が現実の世界でどう役立つのかに焦点を当てており、マンガという親しみやすい媒体も相まってラクに読める。

この本は、期末試験や院試が迫った時期にあわてて読むものではない。 コロナ禍でやることが無くなった社会人が教養のために読むと、かつて学んだ微分方程式と現実世界に橋が架かっているように見えるだろう。

デス・ゾーン 栗城史多のエベレスト劇場

かつて、くりのぶかずという登山家が多くのメディアから注目を浴びた。

冒険の共有というスローガンで多くのスポンサーから支持を集め、一見順風満帆そうにも見えたが、ある時を境に登山家たちから次第に疑惑の目を向けられるようになる。 そして、彼の主張する無酸素・単独登頂という実績も、一般的な登山界の基準にそぐわないものとして、界隈から黙殺された。

晩年はエベレストに何度も挑んでいたようである。 無酸素登頂を謳ってこそいたが、毎度のごとく酸素ボンベが必要になる標高にそもそも達しないうちから下山を繰り返しており、ネット上では「プロ下山家」と呼ばれるようになっていった。 スポンサーも離れていったことだろう。

やがて彼は焦りを募らせたのか、実力に見合わない無謀な目標設定を繰り返すようになり、最期はエベレストの最難関ルートの南西壁に挑もうとして敢えなく滑落死した。

最後の挑戦は、誰がどう見ても取り返しのつかないものであった。 彼はいったい何故、引くに引けなくなったのか──。

彼を取り巻く社会を鋭く分析した一冊であり、あらゆる言外の教訓に満ちている。

現代経済学の直観的方法

広範な経済学のエッセンスが凝縮されており、さらに切れ味の鋭い口調で綴られている。

残念ながら僕は経済学のことがまったく分からないので、本書の面白さを的確に伝えるリテラシーは無いが、往年の名著『ゲームプログラマになる前に覚えておきたい技術』の語り口を彷彿させる。

我々は資本主義社会に暮らしており、継続的に経済成長を続けなくてはならないという十字架を背負っている。 ではなぜ、成長し続けねばならないのか、そこに「金利」というキーワードを用いた明解かつ弁舌さわやかな著者の論が光る。

読み進むたびに「ふむふむ、なるほど」と抵抗なくその物語が染み込むあたり、それが『直観的理解』たる所以なのだろうと思う。

ぜひ、タイトルの硬さに臆することなく手に取っていただきたい。

だめっこどうぶつ (11) (バンブー・コミックス)

17年の長きに亘る連載が、ここに完結した。 子供の頃から愛読していた身としては一抹の寂寥感を抱く。

この作品は、狩が苦手で群れを追われた独りぼっちのダメなオオカミが、安住の地を見つけ、友達を増やしながら少しずつ成長していく物語である。 絵柄は子供向けだが、セリフにはルビが振られておらず、哲学めいた問いが随所に挟み込まれる大人向けの作品である。

ストーリー自体は在って無いようなものだったが、最終的にはある意味ハッピーエンドだった。

めちゃくちゃ面白いというわけではなかったが、この作品と出会えたこと、そして完結を見届けられたことは神と関係者すべてに感謝するものである。

うる野くん、楽しいひとときをありがとう。


というわけで、今年も10冊を紹介しました。

だいぶチョイスが偏ってるね……。

本当は、紹介したい本が他にもあるのですが、レベル的に僕の及ぶところではない本なんかもあって、残念ながら選外になっちゃったものもありました。

たしかに、 OAuth本とか、戦略ゲームAIとか、買ったけど読み終えてない本とかがまだまだあるね

それらも追い追い消化できたらと思います。

さしあたり、今年はこんなところで。

みなさま、よいお年をー。

儚い金魚と地に満つネズミ

こんにちは。 Apple Watch Series 7を予約した たーせるです。

それはさておき、先日、おともだちと LINE でこんなやりとりをしました。

昔、でめきんが大好きでしたが、ひぶなよりも弱く、すぐに死んでしまうのでした」
なんて酷な」
儚きものが好き」
ハツカネズミなど」

三者から見てあまりにもわかりにくいのでちょっと補足すると、でめきんのような儚い小動物が好きだという僕に、友人がハツカネズミもオススメだよと言っている謎シチュエーションです*1

ちなみにハツカネズミはちっとも儚くないと思うので却下です。

ハツカネズミは、20日で倍々に増えると聞いたことがあるような……。

めちゃくちゃ繁殖力が強いらしいですね……。

ネズミ算っていう言葉があるくらいですから。


そんなわけで今日は、ハツカネズミは儚いどころかやべぇ生き物だぞというのを数理的にシミュレーションしていきたいと思います。

*1:これだけ行間の空いた支離滅裂なやりとりでも会話が成立していることに我ながら驚きです。

続きを読む

【お便りコーナー】性能測定だいきらい

こんにちは。

モデルナワクチン(2回目)の副反応でダウンしているたーせるです。

体調は悪いくせに退屈で仕方ないので、先日、同業のアプリケーション開発者の方からいただいたお便りを紹介してみようと思います。

性能測定大嫌い…笑

何をもって性能いいって言うのかさっぱり分からない。

同業者からのお便り

性能測定ってなに?

たとえば Web アプリの場合、ページ遷移した際に初期表示が完了するまで○秒以内、みたいな性能指標があるんだよ。

ふむ。

こういうのは、非機能要件として最初に取り決めておく。

で、アプリが出来上がってきた頃に、要件を満たす十分な性能が出ているかを確認するんだ。

え、でもそれって「OK」って判断するの難しくない?

2〜3回ストップウォッチで実測して「ハイ大丈夫です」なんてさんなことを言うわけにはいかないよね?

そうだね。

続きを読む

【Anguler × Wijmo】ブラウザのサイズに FlexGrid を連動させるための 2つのポイント (Ver. 2021J v2)

こんにちは。

今日も GrapeCity 謹製の万能 UI コンポーネントライブラリ・Wijmoウィジモ に関するお話です。

中でも僕は FlexGrid というデータグリッドコンポーネントをいたく気に入っています。

さっそく本題に入りましょう。

本日の検証環境

  • Angular 12.2.5
  • Wijmo 2021J v2 (5.20212.812)

課題: ブラウザのサイズに応じて FlexGrid を伸縮させたい

今日は、ブラウザのウィンドウサイズに応じて Wijmoウィジモ の FlexGrid を伸縮させる方法についてご紹介していきます。

下図は、本日の完成品をブラウザの開発者ツールで表示させた結果で、FlexGrid の占有領域が水色のけいとして表示されています。

ブラウザのサイズを変えると、FlexGrid のサイズが連動して伸縮していることが分かりますね。

完成イメージ
完成イメージ

動機付け: これができないと何が困るか

ここからしばらく、モチベーションを上げるための前口上が続きます。 手っ取り早くやり方だけ知りたい方は、この記事の真ん中あたりまで早送りしましょう。

まずは、一般的な組み込み方に従って FlexGrid を UI に組み込んだ場合に起こりうる問題点について説明します。

下図を見ると分かるとおり、データ量が多い場合、FlexGrid の高さがブラウザのサイズを超えてしまい、ページ全体にスクロールバーが表示されてしまいます。

左の図は初期状態、右の図はスクロールバーを下に動かしたときの状態です。 なにが問題かお分かりでしょうか。

スクロール前スクロール後
好ましくない例: スクロールによってグリッドの見出しが隠れる

そう、右上の図からお分かりのとおり、ページ全体をスクロールしたことで、見出しやFlexGrid のヘッダ行が画面外に隠れてしまいました

ヘッダが隠れたせいで、いま見えているデータ項目が一体何なのか、ぱっと見、わかりづらいよね。

しかも、ヘッダが隠れちゃったせいで、ソートやフィルタ操作が簡単にできなくなっちゃった

そうそう。

もしフィルタしたくなったら、毎回わざわざスクロールを元の位置に戻さなきゃいけないね。



一方、FlexGrid をウィンドウ内に収まりそうなサイズに固定した場合も、それはそれで問題があります。

百聞は一見にかずですので実例をお見せしましょう。 もしも下図を見てなにかを察し、「あぁ…… 広げたい……」と思ったアナタは私と同じ感性の持ち主です。

好ましくない例
好ましくない例: FlexGrid の高さ固定

なにこの余白

大きいモニタのときは、ウィンドウをぐっと拡大して、たくさんのデータを一度に見たいのに……。

FlexGrid のサイズを固定しちゃうと、ウィンドウのサイズによってはページ内に無駄な余白がいっぱい出来ちゃう。

しかも、ユーザが自由にグリッドの高さを変えることはできない。

ボクがエンドユーザだったら、さすがにもうちょっと何とかできませんか? って言うと思う。

…ね?

なんとかしたくなってきたでしょ?

もしも、FlexGrid のサイズがブラウザと連動すれば、こうした操作上の小さなストレスを取り除くことができます。

グリッドをどんなにスクロールしてもヘッダ行が定位置に表示されていますので、常に手の届く場所からソートやフィルタといった操作ができるようになります

スクロール前スクロール後
好ましい例: スクロールしてもグリッドの見出しが隠れない

また、より多くの情報を一度に見たければ、ブラウザを広げれば良いだけです。

拡大前拡大後
好ましい例: ブラウザと連動してグリッドの表示領域が拡がる

この挙動が実装されるだけで、アプリの手触りは劇的に良くなりますので、一手間かける価値があると思いませんか?

ところが、僕がわざわざこうして日記に書くくらいですから、話はそう簡単ではないのです。

公式情報だけではうまくいかない

一応、GrapeCity 公式のナレッジベースに「コントロールの高さを%で指定する方法」というソレっぽい情報が公開されているものの、残念ながらこれだけではうまく動かないケースの方が多いのです。

特に、<div> に適用したスタイルの height プロパティを % 単位で相対指定した場合に、以下の状況でFlexGrid が親要素のサイズを突き破り、ブラウザの表示領域からはみ出してしまうことがあるのです。

  • うまくいかないケースの一つは、ページ内にヘッダやフッタ、見出しなど、FlexGrid 以外の HTML 要素が同居しているとき
  • もう一つは、<router-outlet> などで埋め込んだ子コンポーネントの中で FlexGrid を使用しているとき

次節で具体例を説明しましょう。

よくある失敗例

下図はよくあるダメな例です。 右側の開発者ツールを見ると、<wj-flex-grid> の親<div> に対して height: 100%; とサイズ指定していることが確認できます。

にもかかわらず、ページ全体にスクロールバーが表示され、FlexGrid がはみ出してしまっていることが分かります。

よくある失敗例
よくある失敗例: FlexGrid がはみ出している

この状態で、DOM から <wj-flex-grid> 要素だけを削除すると、親<div> は意図した通り画面ぴったりの高さ (449.19px) になります。 もちろんスクロールバーも表示されません。

DOM から wj-flex-grid 要素を除去した状態
DOM から wj-flex-grid を除去した状態

明らかに FlexGrid が反抗して親のサイズを突き破っているのです。

ここが非常に厄介なポイントです。

そういえば、以前もこんな要件が挙がったよね?

そのときはどうしたの?

当時どうしても、この height 突き抜け問題が解決できなかったので、window.onresize イベントのたびに、強制的に FlexGrid の高さを自前で再計算して height を書き換えていたっけ。

えー…… ちからわざにも程があるな。

今回編み出した方法は、CSS の設定だけで FlexGrid の高さがブラウザに連動するようになるので、覚えておくといつかきっと役に立つよ。


ソリューション: CSS を駆使して FlexGrid の反抗を制する

今回のポイント

今回のポイントは、たった 2つです。

  1. ページ全体のレイアウトを、CSS 3 の FlexBox で組むこと
  2. <wj-flex-grid> と、その親の <div> のスタイルには、それぞれ以下のとおり position プロパティを明示的に設定すること
    • <wj-flex-grid> には、position: absolute を設定する
    • div には、position: relative を設定する
ポイント1: ページ全体のレイアウトは CSS 3 の FlexBox で組む

まず第一に、レイアウトの組み方です。

話を簡単にするため、下図のような簡単なレイアウトを考えましょう。


CSS レイアウト

緑色の矩形領域にはページの見出しが、水色の矩形領域には FlexGrid が、それぞれ配置されることを想定しています。

FlexGrid の高さは、親要素の高さからヘッダやフッタなど他のコンポーネントの高さを引いた値になります。 見出しの高さはブラウザのサイズにかかわらず常に一定ですが、FlexGrid の方はブラウザをリサイズすれば伸び縮みする点に注意しましょう。

手始めに、ページ全体に適用する CSS を見てみましょう。

style.css

html, body {
  width: 100%;
  height: 100%;

  margin: 0;
  padding: 0;
  border: none;
}

<body> のサイズをウィンドウに一致させるため、widthheight に 100% を設定しています。 また、念の為、余白(margin, padding)や境界(border)をリセットしています。

これは、CSS でレイアウトを組む際のじょうとう手段ですので、おなじみの方も多いでしょう。

続いて、Flex レイアウト用のスタイルを書いてきます。

app.component.css

.main-container {
  display: flex;

  flex-direction: column;  /* 縦に並べる */
  flex-wrap: nowrap;       /* はみ出しても折り返さない */
}

.header-container {
  flex: 0 0 auto; /* 勝手な伸び縮みは許さない */
}

.grid-container {
  width: 100%;
  height: 100%;

  flex: 0 3 auto; /* 縮むことは許すが勝手に伸びることは許さない */
  overflow: auto;
}

header-container クラスは、flex-grow プロパティにも flex-shrink プロパティにも 0 を設定しています。

Flex レイアウトは通常、親要素のサイズが変わると自分自身の影響を受けて、自分もサイズを変えようとします。

ただし、見出しのようにサイズ固定のコンポーネントは、ブラウザのサイズに釣られてメタボになったり潰されたりすることは許されないので、flex-growflex-shrink も 0 を設定して、そういう外圧に抗うわけです。

一方、grid-container クラスには、flex-grow プロパティに 0、flex-shrink に 3 が設定されています。

これは、本来のサイズを超えて勝手にデカくなることは許さないといういましめのために flex-grow には 0 を設定しているのです。

しかし、本当は高さ 100% まで大きくなりたいけれど、もし他のコンポーネントが場所を取るならばそちらに譲りましょうという慎ましさのため、flex-shrink に 3 を設定し、勝手に大きくなることは許されないけど、他の影響を受けて潰されるのはOKという設定にしているのです。

ポイント2: <wj-flex-grid> とその親の <div> には、それぞれposition プロパティを設定する

この対策だけでは不十分で、FlexGrid を包むコンテナ<div> には position: relative; を、FlexGrid そのものには width: 100%;, height: 100%; に加えて、position: absolute; をそれぞれ付加します。

app.component.css(抜粋)

.grid-container {
  width: 100%;
  height: 100%;

  flex: 0 3 auto;
  overflow: auto;

  position: relative; /* 追加 */
}

.grid{
  width: 100%;
  height: 100%;

  position: absolute;
}

ここまでやって初めて、<wj-flex-grid> が親<div> のサイズに押さえつけられるようになります。


最後に、HTML を示します。

app.component.ts

<div class="main-container">
  <div class="header-container">
    <h2>FlexGrid</h2>
  </div>
  <div class="grid-container">
    <wj-flex-grid class="grid" 
                  [itemsSource]="gridData" 
                  [showMarquee]="true" 
                  [itemFormatter]="itemFormatter"
                  headersVisibility="Column">
      <wj-flex-grid-filter></wj-flex-grid-filter>

      <wj-flex-grid-column header="ID" binding="id" [width]="60">
      </wj-flex-grid-column>

      <wj-flex-grid-column header="商品名" binding="product" [width]="200">
      </wj-flex-grid-column>

      <wj-flex-grid-column header="受注日" binding="date" [width]="120">
      </wj-flex-grid-column>

      <wj-flex-grid-column header="金額" binding="amount" [width]="100" format="c">
      </wj-flex-grid-column>
    </wj-flex-grid>
  </div>
</div>

これで、ブラウザに連動して高さが変わる FlexGrid が完成しました。

繰り返しになりますが、こうした小さな一手間で、だいぶアプリケーションの完成度というかエンドユーザの手触りが変わってきますので、Wijmo を使っている皆様におかれましては、ぜひ参考になさってください。

おまけ1

ちなみに、<router-outlet> で埋め込んだ子コンポーネントの中で FlexGrid を使用した場合も、同様の手法で要件を満たせます。

参考までに、<router-outlet> 入りのサンプルコード動作するデモGitHub で公開しています。

おまけ2

今日のネタは、なぜか土曜日の夜中にいきなりふと思いついて、午前4時頃まで試行錯誤していました。

Angular × Wijmo はじめの一歩 FlexGrid 編 (Ver. 2021J v2)

こんにちは。

システムアーキテクト兼フロントエンド担当のたーせるです。

最近「どうしてもシングルページアプリケーションにデータグリッドを組み込みたい」という UI 要件が持ち上がったため、Angular と Wijmoウィジモ の組み合わせを採用しようと企んでいます。

f:id:tercel_s:20210911213648p:plain:w400
データグリッド

このブログでもときどき取り上げていますが、Wijmo はデータグリッドやグラフ、果ては地図まで、非常に高機能で複雑なコンポーネントがひととおり揃った有償の UI ライブラリです。

特に業務アプリケーションの開発では、発注元から「Excelのような操作性」を要求されることがあり、個人的にはデータグリッドを利用するだけでも Wijmo を採用する価値があると考えています。

ただ、一部の開発メンバからは「過去に、開発中のアプリケーションに Wijmo を組み込もうとして苦労したことがある」という声も聞こえてきました。

よくよく話を聞くと、そもそも Wijmo の正しい使い方が分からず、結局ようでぐちゃぐちゃな実装をしてしまった ── という苦い経験がトラウマになっている模様。

Wijmo 組み込み基本動作のおさらい

そこで今日は、初めての人でも安心して Wijmo に触れるよう、FlexGrid の基本のキホンを手を動かして学んでみようと思います。

細かい話はさておき、この記事を読み終える頃には Angular アプリケーションにベーシックなデータグリッドを組み込めるようになりますし、簡単なカスタマイズ要件であれば対応できるようになります。

特に、itemFormatter は、セルの外観をカスタマイズするための重要なテクニックの一つですので、ぜひ覚えておきたいところです*1

*1:同様の手法として、formatItem や、よりパフォーマンスに優れた CustomCellFactory といった別の手段がありますが、最も簡便な手段はやはり itemFormatter になります。

続きを読む

僕とWebGL 2とLaTeXと

なんだ、この金子みすゞのようなタイトルはw

話せば長くなるのですが、、、

夏休みは家に引きこもってWebGL 2のお勉強をしていました。

1週間くらいでここまでできるようになりました。


続きを読む

docker-compose で、Node.js と MySQL のコンテナ間連携を行う

f:id:tercel_s:20210125195054p:plain

今年度に入った頃から複数の開発案件に並行で関わるようになり、さらにこのところ私事においても煩忙を極めていたため、物事をじっくりアウトプットできずにいた。

ようやっと4連休を手に入れたので、リハビリも兼ねて簡単な演習を行ってみよう。

今回のテーマ

今回、何をやりたいかというと、大きくは以下2点です。

  • Node.js 製のアプリケーションと MySQL をそれぞれコンテナ上で動かす
  • それぞれのコンテナを docker-compose で連携させる
動機づけ

そもそもコンテナとは、隔離されたアプリケーション実行環境であり、「よそのコンテナを意識しなくてよい」という思想が根幹にあると考えています。

一方で、システムの規模が大きくなると、アプリケーションやデータベースなど、役割ごとにコンテナを切り分け、それぞれを相互に連携させたいと思うのも自然な発想です。

Dockerfile はなんとか書けるようになったが、はてさて複数のコンテナ同士を連携させるにはどうしたらよいだろうか、という課題に対する自分なりのメモです。

……本来は桜の季節に投稿するはずでしたが、モチベーションが足りずに今頃になってしまいました。

目次

  • 今回のテーマ
    • 動機づけ
  • 目次
  • 実験環境
  • はじめの Node.js アプリケーション
    • Node.js プロジェクトの作成
    • Express のインストール
    • index.js の作成
    • Node.js アプリのテスト実行
    • Dockerfile, .dockerignore ファイルの作成
    • Docker イメージの作成
    • コンテナ版 Node.js アプリケーションの実行
  • MySQL をコンテナで動かす
    • コンテナ起動時に指定できる環境変数
    • ボリュームの作成
    • M1 Mac における注意点
    • MySQL コンテナに入る
    • ネットワークを作る
    • MySQL コンテナをネットワークに参加させる
  • Node.js アプリケーションを MySQL に繋ぐ
    • MySQL に接続するためのパッケージのインストール
    • index.js の編集
    • Node.js アプリケーションのコンテナイメージのビルドと起動
  • docker-compose によるオーケストレーション
    • docker-compose のインストール
    • docker-compose.yaml の作成
    • docker-compose の実行
  • ここまでのまとめ
続きを読む

Copyright (c) 2012 @tercel_s, @iTercel, @pi_cro_s.