[2022年4月号] Software Design(技術評論社) サマリー+個人メモ

Software Design の2022年4月号について、

ざっくり内容紹介
個人的に気になった記事やポイント

をまとめている記事です。

サマリー記事の一覧はこちら。

特集①：はじめてのFlutter
特集②：本質から学ぶGit
Extra Feature
Column
Software Design 2022年4月号

特集①：はじめてのFlutter

ついにSoftware DesignでもFlutterが登場。メインでは触っていなけどほそぼそとキャッチアップは続けている数少ない技術スタックなのでおさらいの意味でもとてもちょうどよい感のある特集。
- 有名どころの本誌でも掲載されたことはもちろん、自分の身の回りでも明らかな普及（流行り）があるのを感じている。特定のスコープにフォーカスして食える仕事を探していきたいタイプには間違いなくうってつけの領域であると思われる。需要に対して競争率もかなり低いので今は本当に美味しいポジションだよね。
Flutterが選ばれる理由
- クロスプラットフォームであるということ、Dart、ほかのプラットフォームとの比較
  - 改めて思うけどDartは（バランスのちょうどよい感含めて）本当にいい言語だと思う、叶うのならもう身の回り全部Dartで統一できればなーと常々思っていたけどその思いを新たにした
  - ほかのプラットフォームとの比較
    - ホットリロード
      - なんというか、もともとの比較で言えば革新的だったのはわかるんだけど、今はフロントエンド系ではかなり当たり前になっちゃったよね。DevToolsが素晴らしいのはとてもわかる
    - 習熟しやすさ
      - ソースコードが読みやすいとあったがそれはDartならわかる。Flutterは僕はかなりキツイと感じてたけどこれ誰も思ってないのかな？（WidgetでかっこがネストしまくるのだけがFlutterを好きになれない最後の障壁だった）
        
        「障壁」なら「好きになる」なのか？どっちでもいいかｗ
      - オープンソースであることやドキュメントが整備されていることも書いてあった、これは本当に同意。
    - 多機能性
      - 主にpub.devのことを差していた
Widgetを使いこなして時短UI構築
- 開発の実践的内容がメイン
- VSCodeでの解説にちゃんと紙面が割かれていたことに感動した。前はAndroid Studio一択的な風潮があったけど、最近はそうでもない感じしますよね。僕はそもそもAndroid Studioが好きになれなかった…
状態管理
- StatefulWidget
- Riverpodの解説もあった
実践！Flutterでモバイルアプリを作ろう
- こっちのほうがより実際のアプリ開発！という感じの章
- なんかいつもは思わなかったけど今回気付いたこととして、モノクロの紙面だとコードきついなと。何を今さらという感じなんだけどなんかFlutterのソースはシンタックスハイライトないと余計しんどく見えた。なんでだろう…。（ネストにコンプレックスある？笑）
クロスプラットフォーム向けにデプロイ
- ビルドからデプロイ、CI/CD用のテストまでかなり実践的な内容が網羅されていた。肉付けさせるベースとしてはいつも通り使いやすい教材だなと思います。でも今なら日本語の記事とかもいっぱいあるのかな。

特集②：本質から学ぶGit

コミットの記録、リポジトリの状態確認のやり方
- 基本的な内容の総ざらい。最近まで「マンガで分かるGit」みたいな特集がずっとあったので、それらと合わせると新入社員などにもいいかもですね（自分も今新人にGitを教えないといけない状況なので実は困っている…）
ブランチやリモートリポジトリの扱い
- GitHub登場
- どうでもいいけど例がまだmainではなくmasterだったのがちょっと意外でした
本質から学ぶGitコマンド
- コミットハッシュ
- Gitオブジェクト
  - commitオブジェクト
    - treeのハッシュ値、Authorの情報、Commiterの情報、コミットメッセージなどが含まれる
  - treeオブジェクト
    - コミットのハッシュ値と同じく最初の4桁で特定できる場合は4桁で使用できる
    - オブジェクトの中身で最初に出てくる数字は、
      - 100644：通常の実行不可能なファイル
      - 100755：実行可能ファイル（なんのこと？）
      - 120000：シンボリックリンク
      - とのこと。どういう決まりなんだ…
  - blobオブジェクト
    - ハッシュ値についてはほかと同じ
- 変更管理の仕組み
  - すべてのコミットには自分自身のコミットハッシュと1つ前のコミットハッシュが含まれていて、この差分で変更が検知される
  - Gitのコミットツリーと呼ばれる
  - ブランチとはこの特定のコミットハッシュを指すだけのもの
    - 実は git log --graph --oneline などとやるとそのコミットグラフというものが見られる
- チーム開発/OSS開発におけるマナー
  - こういう「抽象的だけど具体的に知りたいこと」って能動的に情報収集するのが最も難しく感じられる。たまたま見つけたものをこうやってメモっておく意義は実はこういうところにあるのかも…
  - あなたのコミットは大きすぎる可能性が高い
    - １つの目的に対して１つのコミット
    - 禁止ワードは「～のついでに～も」
    - 例えば本当に小さなタイポを見つけたときつい他のコミットに入れちゃうけど、それでも分けるのが正しい姿
  - コミットメッセージちゃんと書こう
  - コミットはレビューを前提に作る
- コントリビューションマナー
  - オープンソースであっても、あくまでもそのプロジェクトはオーナーの持ち物であることを忘れない
  - いきなりプルリク作る前にまずは issue を出そう

Extra Feature

Log4j2の脆弱性とはなにか？
- NISTの脆弱性情報データベースで「10.0 Critical」という破格のスコアがついた
- Log4j（1系）の問題点
  - ログの出力テンプレートを変数を使って自由にカスタムできる、ここがLookup機能と呼ばれていたところ
  - 変数には環境変数以外にもbase64やDNSやらLDAPやらから取ってくることも可能
  - メッセージ本文を示す %msg がカスタム設定ファイル内だけではなく実際のログ本文でも変数展開されていたのが問題だった、しかもJNDI（Javaでディレクトリサービスなどにアクセスするインターフェース）を変数で指定するとそのまま使えてしまった
  - Log4jがrootユーザーで動いていた場合事実上サーバーの全ての掌握が可能だった（というかそれが本当に起きていたから大問題だった）
- 問題発生前後の時系列
  - 発覚前は省略
  - 発覚後、「Log4jの1系やそれの代替になっているLogbackでも同様の問題があるのでは？」と殺到し、結果的にどちらもかなりの危険度の脆弱性が見つかったがこれはLog4j2のもとの問題とは本質的に別物だった
  - 一連の騒動でひとくくりに扱われてしまったが実際は別個のものだったため、現場としては対応を二転三転迫られることになりさらに混乱することとなった
- 原因
  - 広がり方が非常に運が悪かった
    - 修正中の問題に対して数人が（悪意なく）拡散させてしまい、なおかつ悪用の応用が簡単である上にその実証用コードまで付随されていたためにまたたく間に問題になった
    - ゼロデイ脆弱性なのにマスコミなどで大々的に報道されたために被害が拡大、エンジニアじゃない権威ある人も騒ぎを起こすようになってしまった
  - 影響範囲の調査が不十分だった
    - さきほどの関連モジュールなどの調査、ここはコミュニティ側で全然検証できていなかったとのこと
  - で、広範囲だった
    - 説明するまでもなく、巨大な影響範囲があった
    - 「使っているかわからない」「使ってないと思ってたけど使ってた」などがさらに問題と疲弊を呼んだ
      - 門外漢なのだけど、依存パッケージ的なこと？
      - 数ページ後に「Javaには複数のログライブラリがありフレームワークごとに任意のものが選ばれている、場合によっては複数個混在していることも珍しくない」との記述あり。

Column

ハピネスチームビルディング「リモートワークのつらさを共感して楽しいに変える」
- 新連載シリーズ、タイトルからして既に自分は全くペルソナではない…（リモートワーク最高！最高！！）
- 内容はよくある「寂しい」とか「孤独感」など、それに対して一定のルールを設けて解消していこうというもの、特に目新しいことも書いていなかった
  - リモートワークに対する自分の考えは以前から少しずつまとめている膨大な量の下書きがあるくらい色々思うところがあるのでここでは特に触れない