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

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

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

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

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

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

特集①:Visual Studio Code 最大活用

  • キホンを知ろう
    • 概要説明とともにGitHub関連の内容がわりと重要視されて書かれている、時代を感じる
      • Microsoftクラスの企業が買収したあとに機能や利便性がちゃんと向上した見事な例のひとつがGitHubだと思う、稀有なケース
  • 見た目をカスタマイズしよう
    • "editor.tokenColorCustomizations" らへんの体系的な情報まとめ記事はずっと枯渇状態が続いているので今回の特集で期待していたけどやっぱりなかった、みんなシンタックスハイライトにもっとこだわりないの???(色んな人の画面見てもほぼデフォルトのカラースキーマすら変更してない人が多くていつも驚く)
  • コーディングがぐっとはかどる定番機能
    • 補完
    • コマンドパレット
    • ほか
      • さすがに知らないことなかった
  • チーム開発で役立つ機能
    • Git関係
      • 毎度気になるけどVS Code内蔵(もしくは周辺の拡張機能)のGit使ってる人ってどのくらいいるんだろう
      • GitLens
      • Git Graph
  • 導入がカンタンで開発効率爆上げな機能
    • ワークスペース
      • これも使ってる人みない…(自分は多用)
        • ディレクトリツリーの開いている状態が保存されるときと消えるときの法則が未だに掴めてない(バージョンアップするたびになんとなくの法則性が変わることもよくある)
    • Setting Sync
      • 地獄に堕ちろ定期
    • Remote Containers
      • この間はじめて使ってみたけどかなりお手軽でよかった
    • Live Share
      • 共同編集のやつ、次使ってみたいと思っている

特集②:失敗しないマイクロサービス

  • サービス分割の克服
    • ドメイン駆動設計
      • 「アプリケーションの設計をする際に、大きすぎるビジネスをそのままアプリケーションにしてもうまくいかない」
      • 「業務の切れ目に沿ってアプリケーションも分割し、各々の領域の言葉で実装されるべきだ」
      • 2つの分類
        • 戦略的モデリング
          • ビジネスのサイズ分割
          • わけるときに「イベントストーミング」をする
            • ユーザーの体験から切れ目を見つけてドメインに分けていく
        • 戦術的モデリング
          • どっかいった???
  • サービス間通信の克服
    • RPI(Remote Procedure Invocation)
      • 同期型の代表例、RestやgRPCを含む
    • Messageging
      • Kafkaとかが含まれる、SNS-SQSやGCP Cloud Pub/Subも入ると思う
      • 冪等性の検討が重要
    • これら2つは「同期か非同期か」でちょうどわけられる、メリットデメリットはよく知られている通り
      • いうてパブリッククラウドの各種メッセージングサービスはともかく、Kafkaはいきなりじゃとてもじゃないけど無理だった、相当ハードルは高い(一回導入しようとしてちょっと触ったけど「…?」みたいな感じでそのときは終わった)し、マネージドじゃないミドルウェアはは管理運用はかなりしんどい
    • サービス間でのデータ結合
      • CQRS(Command Query Responsibility Segregation)
        • コマンドクエリ責務分離とは、データの更新系処理と参照系処理に分けて、それぞれの実装ごとにサービスコンポーネントとデータストアを用意する、らしい
          • 要はリードとライトですっぱり分けようってことかね
          • これらのデータの同期をどうするかという問題にもメッセージングミドルウェアが活用されるとのこと
      • 今後メッセージング系の仕事をするときここはもう一度読み直したい
  • 運用の克服
    • マイクロサービスごとに色んな言語を選択できるのはとても強いメリットだが、それら全体を俯瞰する必要性も出てくる
    • なんか色々書いてあるけど要は「継続監視しよう」の一言の内容に見える
      • メトリクス
      • ログ
      • トレース

Extra Feature

  • OSSコントリビューターへの道
    • 執筆者:mattnさん
    • Gitではない少し変わったバージョン管理システムでVimのコントリビュートに初めて参加したエピソード
    • GitHub上でのコントリビュート、自分自身のOSS活動のエピソード
    • コミットで気をつけること
      • インデントを既存のコードにあわせる
      • 命名規則をあわせる
      • コメントの粒度をあわせる
    • コミットやPRの粒度
      • 「解決したい問題1つ」に対してPR1つ、その中で修正箇所ごとにコミットをわける、という普通の感じ
        • 「修正箇所ごとに」が結局人によってしまうところはあるけどね
      • 指示がなければ基本的に force push は行わない
  • 今さら聞けないSSH 後編
    • 後編は入門者に特段知ってもらう内容でもない感じ
      • ポート転送
      • プロキシの多段SSH
      • SSHエージェント
    • トラブルシューティング編の「~/.ssh/known_hostsで保持しているホスト鍵が変わった」は読んでおいてもらおう
      • verboseモード -v -vv -vvv 詳細度

Development

  • オンラインホワイトボード「Miro」徹底活用術 第1回「Miroをはじめよう」
    • 去年うちのスクラムでもいきなりこれが登場してきてなんだこれと思っていたけど、流行のツールだったことをそのあと知った
      • Software Designでも取り上げられるあたり、たぶんエンジニアの間で今相当使われるようになっていると思われる
    • 特徴
      • 上下左右無限のホワイトボード
      • 無料で十分使える
      • iPad対応
    • 会社支給のクソ雑魚Windowsだとかなりしんどい、操作の性質上からもMac必須に思える
  • AWS活用ジャーニー「AWS IAM」
    • 新連載、代表的なサービスの紹介コーナー
    • 基本説明メイン
    • パスワードポリシーはどこまで厳しくするべきか
      • MFAありなら8文字以上
      • MFAなしなら14文字以上
  • 使えるAIの作り方「AIの設計図は人が描く」
    • この誌面が書かれているのはかなり前のはずなのでStable Diffusionはまだ出てないくらいじゃないかと思うけど、内容的には恐ろしいほどの革新がやってくる直前に書いたもの、という感じになっちゃったのかな(別に内容が陳腐化しているなどということはまったくなく、普遍的な技術などについて触れられていた)

    そのほか

    • ITエンジニア必須の最新用語解説「Carbon Language」
      • Googleのエンジニアが開発したオープンソースのC++後継言語
        • Rustがあるのにね
          • そういえばこの記事執筆の前日(2022/9/20)、Linux 6.1でRustの採用が決まった
        • 同等(以上)のパフォーマンス
        • C++とのシームレスな相互運用性
        • C++経験者が馴染みやすい穏やかな学習曲線
          • これは明らかにRustが意識されてるなw
      • まだ実験的プロジェクトの段階
        • 内容を見る限りC/C++の課題解決→Rust→Rustのさらなる課題解決、って流れなのかな?
        • 2024~2025年にバージョン1.0目標

    Software Design 2022年10月号

    この号の分のみ単品で読みたい方は、普通にAmazonで買うのがおすすめ。
    紙 or 電子書籍で選べます。

     

    22
    0
    248
    0
    3
    みるみ
    Follow Me!
    みるみみるめも筆者

    ブロガー、エンジニア。

    詳しいプロフィールはこのページで色々書いてます。もやってます。

    みるめも
    コメントが正常に送信されました。承認されるまで表示されませんので二重投稿なさらないようご注意ください。