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

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

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

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

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

特集①：シェルの基本大全
特集②：後悔しないAWSデータベースの選び方
特集③：不思議の国のSE用語
Software Design 2022年6月号

特集①：シェルの基本大全

シェルとは
- 言葉の定義として「OSの核となるカーネルへ命令を伝えるためのもの、またはインターフェース」などをよく聞くし実際にも本文の最初はそのようになっているが、文脈としてUnix系列のもののみしか差さない（例えばコマンドプロンプトは該当しない）ときもあるように見える。あやふや？
  - 今気づいたけどPowerShellくんはそういえば名前にシェルが冠されていたね…
シェルとかコマンドの使い方とかの内容
- パイプ
  - 2>&1
  - |&
- ;
- &&
- || （失敗したら）
- チルダ展開
- glob
- ブレース展開
  - {xx,xx,xx}などでくくると文字列として展開される
    - なにに使うの？シェルスクリプト用？？
      - 違った、例えばこういうこと： mkdir dir{A,B}{1..3} → ls → dirA1, dirA2......
- パラメータ展開　＄{NAME}
  - 展開されたあとそのまま直後の文字列とかと併用できる。あまり深く考えたことなかったけど、この書式はいろいろなところで見かけるわりに使う場所によって微妙に細かい違いあるよね（CloudFormationとかTerraformなどなど）
  - デフォルト値を設定できる：${parameter:-word}
  - その他いっぱい！詳しくは本誌を見て（メモの意味）
- 履歴展開：！シリーズ
シェルスクリプトの使いどころ
- 特に最近は「Pythonでよくない？」を多く見かけるし実際自分もそう思っていた
  - シェルスクリプトの強みは移植性とオペミス防止とのこと
    - 移植性：要は使える環境が多いということ（組み込み、コンテナ、クラウドetc....）
    - オペミス防止：ユーザーがターミナルで実行するコマンド量を減らせるということのようなんだけど、イマイチ説得力に欠けるというか何を言いたいかわからなかった。他のプログラミング言語によるスクリプトの実装とどういう差がある？？
文法とか
- しぇばん！
  - ありがちなミス
    - #!/bin/sh：shはシンボリックリンクなことがほとんどで、例えばdashなどになってしまう（正しくは例えば #!/bin/bash など）
- シェル変数
  - 基本的に型はなく、全て文字列として扱われる
  - 代入の書式で = の前後に空白を入れるとエラー（batchfileもそうだっけ？）
    - 理由は最初の文字列以降をコマンドの引数として扱うから。なるほど。（じゃあWindows側も同様の仕様だと納得がいく）
- 環境変数
- if文
- case/while文
- for文
- 関数
安全対策
- 筆者さんいわく「この記事を読んだみなさんに最低これだけは覚えてほしい」ということで「危なそうなときはちゃんと処理を止める」ことを推奨している
- 通常のプログラミングの感覚と同じだと危機感が足りなそう（やっていることはアプリケーションの実装ではなくOSに直接関わる操作であることを忘れない！）
- そのための対策集：
  - set -euo pipefail：setコマンドによってシェルの設定を変える。エラー発生時と未定義変数の使用時に実行を止めてくれる機能。しぇばん！のあとに書く。
  - ShellCheck：いわゆるLinter？
シェルについて深く知る
- ログインシェルとインタラクティブシェル
  - ログインシェルはログイン後に最初に起動し、環境変数の設定やログイン時のみに実施したい処理などが担当
- 設定ファイル
  - /etc/profile
  - bashrc
  - bach_profile, bash_login, .profile
macOSとの色々な事情
- DarwinはNeXTSTEP（ジョブズが追い出されたあとに作ってそのあとAppleが買収したやつ）と4.4BSD派生のFreeBSD、Mach 3.0（当時のMacのこと？）などをミックスしたオープンソースソフトウェア。オープンソースだったのか…
  - で、カーネルが xnu というやつ。そして名前はまさかの…　再帰的頭字語！ X is Not Unix！！
    - この後別のところでGNUについて触れられるシーンがあるが、「Unixとは違う」の「違う」は「超えた」というメッセージである（かも）とのこと。ちなみにXNUとGNUどっちが先~~どっちがパクリ~~かは不明
  - 実際はほぼPOSIX準拠（互換性があるという表現のほうが正しいのかもしれない）だし、macOSがUnixライクOSであるという考え方は間違っていないとのこと（筆者はこれ推しらしい）
- 同じ名前のコマンドでも違うこと
  - MacのgrepではPCREがない、これはわりと有名ですよね
- Appendixとしてdotfilesの管理手法などについて紹介があった、のちに検討する機会があれば参考にしよう

特集②：後悔しないAWSデータベースの選び方

よく話題になるNoSQLとRDBMSの話。自分は概ね正しい理解をできていると思っているが（相応のツラい体験をしてきた…）、ここに何がどう書かれているのかは楽しみにしていた
- 1章はさらっと双方の概要説明で終わり、2章はRDSの導入ガイド、3章はDynamoDBの説明
- 3章でいくつか気づいたところメモ：
  - ホットキー（パーティションキーの集中）はLSIやGSIで特に注意する、日付やカテゴリなど限定されやすいものは要注意（思っているパフォーマンスに深刻な影響を与える）。固定値とかは論外（さすがに聞いたことないけど…）
DynamoDBに適した要件
- 大規模アクセス、同時読み込み同時書き込み
- パーティションキーを分散できる場合
  - これって正規化されたデータ構造なら一般的に同じ傾向にならない？といつも思う
- IoT向け：多数のセンサーデータのアップロード、その後Kinesisなどを使ってのストリーミング、ここまでできるとかなり気持ちよい
- トレンドのフロントエンドアーキテクチャに則る場合：AmplifyやAppSyncの使用。Firebase (Firestore)の流行りとほぼ同じ文脈で使ってよさそう（AWSとGCPにおける対応しあうサービスだし）
DynamoDBが適さない例
- RDBMSが適している場合
  - この書き方はずるくない？とこれもいつも思う
- 横断的な処理が必要な場合
  - 全体の検索などには向かない。これは本当にそう思う。あと全体データを頻繁にリスト化したいのが苦手というのもここに入る気がする（scan多用のアンチパターン）。
  - もしやるならOpenSearchなどを検討する
- 厳密な一貫性が必要な場合
  - 例えば金融のバックエンドに厳密なトランザクションがないNoSQL使うかという話ですよ、そりゃ使いませんよねという話ですよ
    - 一応DynamoDBにも一部トランザクション機能はあることは留意しておく
4章でがっつり「どちらを選ぶべき？」みたいのがあるかと思ったらこの特集自体が終わった…