読書「楽々ERDレッスン」

読んだ本

楽々ERDレッスン

読むに至った経緯

今までRDBMSやDBテーブル設計に関わる機会がなかったため、基礎的な部分から実践的な勘所まで把握したいと思い、評判の良さそうな本書を読んでみました。

感想

読書「継続的デリバリーのソフトウェア工学」

読んだ本

継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣

読むに至った経緯

  • 「LeanとDevOpsの科学(Accelerate)」を読もうと思ったときにCI/CDの知識がなかったので読みたかった
  • 工学というタイトルがついてるので実践的で再現可能なプラクティスが得られるのではという期待
  • 過去に品質工学というジャンルに興味を持って面白かったので、ソフトウェア工学という切り口も良さそうな気がした
  • 継続的デリバリーは未読

気になった部分のメモ

  • 第14章が特に面白くて、それまでの章で説明してきたことを統合して語っているので、各章のトピックがどのようにソフトウエア開発で適用されるのかイメージしやすくなった

  • Martin Fowlerが「本書に寄せて」という文章を書いており、どのように本書を読めば良いかガイドになった

    • "本書の焦点の当て所がIT分野におけるデリバリに限られる、ということ...つまり、ソフトウェア開発の全工程ではなく、コミットから本番稼働の段階までにしか目を向けていないという点...にも注意が必要である"
      • それでも十分な説得力があり信頼できるレポート、という文脈で語られていると理解した
      • 個人的にデリバリ領域のプラクティスに疎かったので、むしろ良かった
  • P.xxvii 「はじめに」
    • 初年度(2014年)の研究成果として次のことが判明したと書いてある
      • "「ソフトウェアの開発とデリバリのパフォーマンスは、統計的に有意な形で測定可能である」"
      • "「高業績の(ハイパフォーマンスな)組織はソフトウェアの開発とデリバリを、他社よりかなり優れた方法で継続的に行っている」"
      • "「組織のソフトウェア開発能力が、収益性、生産性、市場占有率を左右する」"
      • "「組織文化と技術的プラクティスも重要であり、両者がパフォーマンスに与える影響度も測定できる」"
  • P.31
    • "「組織のソフトウェアデリバリのケイパビリティ（能力、機能）は、組織に競争上の優位性をもたらす」"
  • P.32
    • "「製品開発に実験的な姿勢で臨める能力が、継続的デリバリに寄与する技術的プラクティスと高い相関をもつ」"
  • P.74
    • "自社の事業に必須の差別化要因をもたらす中核的・戦略的なソフトウェア製品やサービスを創出・発展させうるケイパビリティ（機能、能力）への投資が重要となる"
  • P.75
    • "5.2 注力すべきはデプロイとテストの容易性"
  • P.93
    • "7.1 リーンマネジメントのプラクティス"
  • P.108
    • "9.1 デプロイ関連の負荷"
  • P.124
    • "製品や機能の開発から顧客対応に至るまでの全工程の業務フローを可視化して把握するチームの能力"

感想と関連情報

今後

  • 将来に備えて、知識が不足している部分の理解を深める
    • DevOps
    • 継続的デリバリ
    • リーンマネジメント
    • バリューストリームマップ
    • DX Criteria

参考

読書「漢字 生い立ちとその背景」「白川静 漢字の世界観」

ソフトウェア開発の仕事を始めて経験が浅かった頃に、上司が「かしたんぽ」という聞きなれない単語を使いました。ソフトウェアに不具合があった場合は、タダで不具合修正しないといけない契約になっているようだと理解しましたが、「かしたんぽ」という言葉がわからなかったため、自分で調べました。

「瑕疵担保責任」という言葉があることが調べてわかって、受託開発する上で重要な概念であると理解しました。さらに「瑕疵」の漢字の意味については、以下のやねうらお氏のブログ記事のコメント欄でようやく理解することができました。 - https://yaneurao.hatenadiary.com/entry/20041204/p1

そのコメント欄の中で白川静氏の名前を初めて知り、いつかは自分も漢字について学びたいなと思いました。その後、内田樹氏のブログでも白川静氏の名前が出てきて、ますます白川静氏への興味が湧きました。 - http://blog.tatsuru.com/2006/11/06_1234.html

今年に入ってたまたま白川静氏の特設サイトを見つけました。 - https://www.ritsumei.ac.jp/features/shirakawashizuka10/

サイトを読み込むうちに面白くなったので、書籍を読むことにしました。 - 漢字 生い立ちとその背景 - 白川静 漢字の世界観

いきなり岩波書店の「漢字」を読んでも理解が追いつかないだろうと思い、松岡正剛氏の「白川静 漢字の世界観」を入門書として読みましたが、それが正解でした。

本の感想は割愛して、瑕疵担保責任について補足します。「2020年4月1日より改正民法が施行され、受託開発（請負契約）における受託者の瑕疵担保責任の法概念は廃止され、契約不適合責任と名称を変えています。」とのことです。次のサイトがシステム開発の具体的説明となっていて参考になりました。 - https://jitera.com/ja/insights/464 - https://hnavi.co.jp/knowledge/blog/system-development-defect-warranty-liability_sales/

また、IPA資料も参考になりそうです。 - https://www.ipa.go.jp/digital/model/model20191224.html

仕様を最初に確定しないアジャイル開発はどうするのが良いか気になりましたが、PDFには以下のように記載されています。 - 第一版及び追補版 DX推進のための見直しにおける民法改正を踏まえた整理にあたって 「アジャイル開発など DX 時代に有効とされる開発スタイルに対応したモデル 契約の作成については、部会下に設置された「DX 対応モデル契約見直し検討 WG」にお いて検討が進んでいる。」

その検討結果が以下のサイトに記載されています。 情報システム・モデル取引・契約書（アジャイル開発版） - https://www.ipa.go.jp/digital/model/agile20200331.html

これから内容を確認して知識のアップデートをしたいと思います。

読書「LeanとDevOpsの科学(Accelerate)」

LeanとDevOpsの科学[Accelerate]

背景

  • 和田卓人氏の「質とスピード」という講演資料で当該書籍から引用していて読まねばと思っていた
  • ソフトウェアの保守性を向上させる取り組みを主導していたので、質の向上により開発速度が増すという実感はあった
  • しかし、継続的デリバリやDevOpsという観点について全然知らなかったので、書籍を読んで理解する事にした

気になった部分の抜粋とメモ

  • Martin Fowlerが「本書に寄せて」という文章を書いており、どのように本書を読めば良いかガイドになった
    • "本書の焦点の当て所がIT分野におけるデリバリに限られる、ということ　〜つまり、ソフトウェア開発の全工程ではなく、コミットから本番稼働の段階までにしか目を向けていないという点〜にも注意が必要である"
      • それでも十分な説得力があり信頼できるレポート、という文脈で語られていると理解した
      • 個人的にデリバリ領域のプラクティスに疎かったので、むしろ良かった
  • P.xxvii 「はじめに」
    • 初年度(2014年)の研究成果として次のことが判明したと書いてある
      • "「ソフトウェアの開発とデリバリのパフォーマンスは、統計的に有意な形で測定可能である」"
      • "「高業績の(ハイパフォーマンスな)組織はソフトウェアの開発とデリバリを、他社よりかなり優れた方法で継続的に行っている」"
      • "「組織のソフトウェア開発能力が、収益性、生産性、市場占有率を左右する」"
      • "「組織文化と技術的プラクティスも重要であり、両者がパフォーマンスに与える影響度も測定できる」"
  • P.31
    • "「組織のソフトウェアデリバリのケイパビリティ（能力、機能）は、組織に競争上の優位性をもたらす」"
  • P.32
    • "「製品開発に実験的な姿勢で臨める能力が、継続的デリバリに寄与する技術的プラクティスと高い相関をもつ」"
  • P.74
    • "自社の事業に必須の差別化要因をもたらす中核的・戦略的なソフトウェア製品やサービスを創出・発展させうるケイパビリティ（機能、能力）への投資が重要となる"
  • P.75
    • "5.2 注力すべきはデプロイとテストの容易性"
  • P.93
    • "7.1 リーンマネジメントのプラクティス"
  • P.108
    • "9.1 デプロイ関連の負荷"
  • P.124
    • "製品や機能の開発から顧客対応に至るまでの全工程の業務フローを可視化して把握するチームの能力"

感想

今後

  • 将来に備えて、知識が不足している部分の理解を深める
    • DevOps
    • 継続的デリバリ
    • リーンマネジメント
    • バリューストリームマップ
    • DX Criteria

参考

アジャイル開発への道

目的

  • アジャイル開発に習熟したい
  • 自身の経験の棚卸し
  • 役に立ちそうな情報の整理
  • アジャイル開発を成立させる要因について自身の見解を持ちたい
  • 注意)記載内容は、あくまで個人の経験に基づく主観です

背景

  • 2020年にスクラム開発にチャレンジ中のプロジェクトにPMとして合流した
    • その時はプロジェクトがうまく進んでなかった、具体的には...
      • 2weekのスプリント期間にタスクが終わらない
        • 終わらなかった作業を別タスクとしてチケット化して継続開発してた
      • スプリントが終わった時点で動作するソフトウェアがない
        • スクラッチから開発したので動作するまでの実装量が多かった
        • GUI画面が多かったしUI/UX考えながら作ってた
        • 別システムとの通信部分が実装されないと主要な機能が動かないシステムだった
      • PBI(Product Backlog Items)が100個くらいあった
        • 作りたい機能の数が多そうに思うが普通なのだろうか？
          • 受託開発の見積もり規模算出のために必要だった
        • PBI全部にストーリーポイントを振ってた
      • ストーリーポイントの見積もりが妥当かどうか判断つかなかった
        • 経験を積んで見積もり精度が上がれば良い？
      • スプリント期間に対応中のタスクの半分は課題があって進みが悪かった
        • タスクに着手してから新しい事実がわかってストーリーポイント通りに開発できない事が頻発してた
      • スプリント振り返りを途中からやめた
        • KPT法で振り返りを実施していた
        • 議事録から推測するに、学びはあるが改善につながる分析・行動への落とし込みまでできてなかった状況
        • 開発が遅れてたため、振り返りの時間を開発に充てる方針となった
      • リリースマイルストーンに対して開発が順調でなかった
        • ベロシティが改善すれば間に合うという説明をしていたが、改善の見通しが立ってなかった
    • 3ヶ月ほど様子見したが最終的にスクラムやめてウォーターフォール開発に変更した
      • 開発計画を立て直した結果、顧客の要望に沿ったリリースができた
  • その後3年くらいクリーンアーキテクチャ・ドメイン駆動設計・テスト駆動開発などに取り組んだ結果アジャイルっぽくなった
    • アジャイル開発を実現させるために支配的な問題は、スクラムのプラクティスではなくて設計スキル不足だと思うようになった
  • チームの熟練度があがりドメインの知識も獲得したので、アジャイル開発に再チャレンジしようという意見が出てきた

問題事象の分析

  • スクラムをやめたあと、なぜ上手くいってないのか色々と分析した
  • そもそも難しいプロジェクトだった
    • 3プロジェクト(3つのシステム開発)を並行して進めるプロジェクトだった
    • 初めての顧客、初めてのドメイン知識となるプロジェクトだった
      • 会社としても新規事業領域だった
      • ブリッジSEとして出向している人がいて連携が取れる体制になってはいた
    • 複数のサブシステムを連携させる複雑なシステムだった
    • 3つのうち2つのプロジェクトは別会社が過去に開発したソースコードをベースに仕様追加・変更するプロジェクトだった
      • いわゆるレガシーコード
  • 良い設計について語れる人がベテラン１名しかいなかった
    • ベテランについていけるほど設計スキル・経験がある人は自分も含めていなかった
  • PLはプロジェクト運営経験が少なかった
    • スクラムガイド通りに運営することを目的化している雰囲気がうかがえた
    • チームが混乱していた時に立て直すための仕切りができていなかった
    • プロジェクトにどんな課題があるか整理されておらず、またチームに共有されてなかった
      • プロジェクト課題の分析・対策が着手できてなかった
      • プロジェクト課題の優先順位づけがされてなかった
  • 良かった点
    • チームメンバーが意欲的で協力的だった
      • 当時のPLや若手メンバーは自主的にスクラムについて勉強してた
      • 振り返りや勉強会でチームメンバーに対してスクラムの情報共有もされていた
      • スクラムのプラクティスは一通り取り組めていた
    • スクラムの運用ツールも用意されてた
      • Atlassianツール(JIRA,Confluence)を使ってスクラムを運用してた
      • ソースコード管理がGitではなくSVNだったのは残念だったが、そのことを課題と感じることはなかった
    • 顧客の担当者の方がとても優秀かつ意欲的・協力的だった
      • プロダクトオーナーとして密なコミュニケーションを主体的にとってくれた
      • デイリースクラムやりましょうと言ってくれて、毎日ミーティングでコミュニケーションとってくれた
      • ウォーターフォールに変えた後も、プロジェクトが安定するまでデイリースクラムを継続した
      • 率直な意見交換をしてくれた
        • アジャイル開発をとてもよく研究されているようで自身の見解を話してくれて参考になった
        • 設計改善のためにアーキテクチャや設計技法の導入を強く推進してくれた
        • 顧客はソフトウェアエンジニアではないのに、自分より設計技法について詳しかったのは反省点
        • それ以来、自分も継続的に勉強するようになった
        • プロジェクト課題を設計改善で解決するという視点は衝撃的だった

課題設定

  • ウォータフォールでの計画作成やプロジェクト課題解決は得意だったので、プロジェクトの混乱は解決した
  • 仕様追加に時間がかかる、バグが多い、機能追加の影響でバグが出る、開発期間が長いなどの課題が残った
  • ソフトウェアの設計改善により課題を解決する方針とした

結果

  • 設計改善により、ソフトウェアの理解容易性・修正容易性・テスト容易性が改善された
  • 開発期間が短縮された
  • バグも減った
  • 仕様変更も容易になった
  • 自身の設計スキルはとても向上した
  • チームメンバーも設計を理解して開発できるようになった
  • 設計スキル向上や開発体験向上によりチームメンバーが喜んでくれた

参考

まとめ

JavaScriptを学ぶ

目的

  • JavaScriptを手に馴染ませたい
  • 基本的な文法や作法についても理解したい

取り組んだこと

感想

  • 一通り文法や作法を理解しつつ手を動かせたので抵抗感は少なくなった
  • スラスラとJavaScriptを書くためにはひたすら手を動かすのが良さそう

追加の取り組み

結果

  • JavaScriptについて背景や経緯の把握ができた

参考

AWS BUILDERS ONLINE SERIESセッションを視聴した感想

概要

AWS BUILDERS ONLINE SERIESのアジェンダ

視聴ページ

ちょうどAWSを使ったモダンなアプリケーション開発をAmplifyを通じて学習中だったので、参加を申し込みました。以下のセッションをリアルタイムで視聴しました。自分のレベルにちょうど合っていて大変ためになりました。

  • BOS-08: はじめてのコンテナワークロード - AWS でのコンテナ活⽤の第⼀歩
  • BOS-09: はじめてのサーバーレス - AWS Lambda でサーバーレスアプリケーション開発
  • BOS-10: AWS ではじめるオブザーバビリティ - システムのどこで・何が・なぜ起こってるのかを理解する
  • BOS-11: AWS Amplify ではじめる Webアプリケーション開発

感想

BOS-08: はじめてのコンテナワークロード

  • 業務でコンテナ使ったことなかったので、概要が掴みやすい内容で良かった
  • コンテナ利用の目的や背景の説明が丁寧だった点が良かった
  • コンテナサービスを個別に取り上げて説明してくれて良かった
  • コンテナ実行の基本的なフローの説明によりサービス構成がイメージしやすくて良かった
  • AWS App Runnerはちょっと難しかった
  • 「構築済みのインフラにすぐにデプロイ」するのがApp Runnerの役割と理解した
  • AWS Amplifyもすぐにデプロイできるが、Amplifyの場合はコンテナを使ってない(バックエンドサービスにコンテナサービスは見当たらないので)
  • AppRnnerの開発者ガイドを見ると「AWS App Runner は、ソースコードまたはコンテナイメージから AWS クラウド内のスケーラブルで安全な Web アプリケーションに直接デプロイする」と書いてある。
  • ソースコードからデプロイするならAmplifyと同じだろうか？

BOS-09: はじめてのサーバーレス

  • サーバレスとは？から説明してくれて良かった
  • 従来のWeb３層アーキテクチャとの対比の説明があって良かった
  • Amazon API Gateway/DynamoDB/S3は使ったことがなかったので説明があって良かった
  • AWS Lambda/DynamoDBの実装デモで具体的なイメージが理解できた
  • Lambda関数にDynamoDBへのアクセス権限を付与する操作が見れて良かった
  • Lambda関数がHttpリクエストを受け付けるための実装が見れて良かった
  • POST/GETコマンドに対する処理をLambda関数内部に実装していた
  • Lambda Function URLsの設定操作を見れて良かった
  • S3コンソール画面で設定の一例として紹介があったのも良かった
  • ハンズオンが色々あるようなので、そこから始めたい

BOS-10: AWS ではじめるオブザーバビリティ

  • 基本的なところからオブザーバビリティについて説明してくれて良かった
  • 従来の監視と現代の監視の違いがイメージできた
  • メトリクス・ログ・トレースという考え方はなかったので知れて良かった
  • Amazon CloudWatch / AWS X-Rayの役割がイメージができた
  • デモがあることで具体的な使い方がイメージできた

BOS-11: AWS Amplify ではじめる Webアプリケーション開発

  • Webアプリケーションとその開発方法から説明してくれてありがたい
  • 「制限のない拡張性 - CDKで任意のAWSサービスを追加」という部分について自分で試せるようになりたい
  • Amplifyプロジェクトのディレクトリ構成規約があるの気づいてなかったので知れて良かった
  • 公式DocにProject Structureの説明があったの気づいてなかった
  • testブランチで開発してmainブランチにプルリクしてマージする時のAmlifyの挙動をデモで見れたのが良かった
  • Amplify Gen 2 Workshopというのがあるので、試すと良さそう

まとめ

  • 参加して良かった
  • アンケートに回答してセッション資料をもらえた
  • 資料を見返してブログ記事を書くのにとても役に立った
  • 各セッションのアーカイブ動画も公開中なのでデモでの操作画面とか見返せて良い
  • チュートリアルやハンズオンがたくさんあることがわかったので試したい

参考

AWS ハンズオン資料

AWS-Amplifyのクイックスタートアプリの詳細調査(AppSync,CDK)

AWS-Amplifyのクイックスタートで開発したアプリのシステム構成

バックエンドリソース一覧

AWS::AppSync

概要

公式ページの説明は次のとおり。

ウェブとモバイルのフロントエンド

安全でサーバーレスで高性能な GraphQL と Pub/Sub API を使用して、アプリをデータやイベントに接続

1 つのネットワークリクエストで、1 つまたは複数のソースやマイクロサービスからデータにアクセスできますAPI を 1 つのマージ済み API に結合します。

サーバーレスの WebSocket を通じて、任意のイベントソースからサブスクライブしたクライアントにデータを公開することで、魅力的なリアルタイムエクスペリエンスを実現します。

セキュリティ、監視、ロギング、トレースが組み込まれています。低レイテンシーを実現するオプションのキャッシュ。

API へのリクエストと、接続されたクライアントに配信されたリアルタイムのメッセージに対してのみお支払いいただけます。

仕組み

AWS AppSync は、サーバーレスの GraphQL および Pub/Sub API を作成し、単一のエンドポイントを通じて安全にデータの照会、更新、公開を行うことで、アプリケーションの開発を簡素化します。

AppSync - GraphQLシステム構成図

https://rydeenworks.github.io/assets/2024-07-18_appsync_graphql.png

AppSync - Pub/Sub APIシステム構成図

https://rydeenworks.github.io/assets/2024-07-18_pubsub_api.png

クイックスタートアプリの実装(AppSync GraphQL API)

コンセプト説明ページのDataセクションに次の説明がある。

「The @aws-amplify/backend library offers a TypeScript-first Data library for setting up fully typed real-time APIs (powered by AWS AppSync GraphQL APIs) and NoSQL databases (powered by Amazon DynamoDB tables). After you generate an Amplify backend, you will have an amplify/data/resource.ts file, which will contain your app's data schema. The defineData function turns the schema into a fully functioning data backend with all the boilerplate handled automatically.」

つまり、@aws-amplify/backendを使うことで、resource.tsのスキーマ定義に応じたGraphQL APIが自動的に用意される。

resource.tsでTodoというスキーマを定義している。

const schema = a.schema({
  Todo: a
    .model({
      content: a.string(),
    })
    .authorization((allow) => [allow.owner()]),
});

App.tsxでcreateTodo/deleteTodo/fetchTodoなどTODOタスク操作を実現している。

  function deleteTodo(id: string) {
    client.models.Todo.delete({id});
  }

clientはApp.tsxで以下のように実装している。

const client = generateClient<Schema>();

generateClientはAmplifyライブラリ側の実装となるが、ソースコードを見ると次のようになっている。 node_modules/@aws-amplify/api/dist/esm/API.d.ts

import { CommonPublicClientOptions, V6Client } from '@aws-amplify/api-graphql';
/**
 * Generates an API client that can work with models or raw GraphQL
 */
export declare function generateClient<T extends Record<any, any> = never>(options?: CommonPublicClientOptions): V6Client<T>;

コメントに書いてあるとおりclientを使うことで、GraphQLのAPIを隠蔽してモデルを操作できるという事。

前掲のConceptページには以下の記載がある。 「On your app's frontend, you can use the generateClient function, which provides a typed client instance, making it easy to integrate CRUD (create, read, update, delete) operations for your models in your application code.」 つまりCRUD操作ができる。それ以上に複雑なことを実現する場合は、何らかの機能拡張が必要となる。おそらくAWS::CDKを使ってAWS::Lambdaで個別に機能実現していくのではないだろうか。

クイックスタートアプリの実装(AppSync Pub/Sub API)

以下ソースコードのsubscribe/unsubscribeがPub/Sub API呼び出しに該当する。 subscribeしておくと、1つ目のWebページでTodoタスクを追加すると、 2つ目のWebページにもリアルタイムでTodoタスクが追加される挙動にできる。

  useEffect(() => {
    console.log("useEffect::user=" + user);
    if (user) {
      fetchTodos();
    }
    const subscribe = client.models.Todo.observeQuery().subscribe({
      next: (data) => {
        console.log("useEffect::Todo.observeQuery()>>>setTodos");
        setTodos([...data.items]);
      },
    });
    return () => {
      console.log("useEffect::unsubscribe()");
      subscribe.unsubscribe();
      setTodos([]);
    }
  }, [user]);

Build & connect backend > Data > Subscribe to real-time eventsページに詳しい説明が載っている。

AWS::CDK

概要

デベロッパーツール

AWS クラウド開発キット

使い慣れたプログラミング言語を使用したクラウドアプリケーションリソースの定義

仕組み AWS Cloud Development Kit (CDK) は、一般的なプログラミング言語を使用してアプリケーションをモデル化し、クラウド開発を加速します。

上記の文章だけだとイメージがつかめませんでした。

開発者ガイドページ - AWS CDK とは何ですか?によると、「AWS Cloud Development Kit (AWS CDK) は、 AWS CloudFormationクラウドインフラストラクチャをコードで定義し、それをプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。」とのこと。

AWS CloudFormationはリンク先に以下の説明がありました。

管理ツール AWS CloudFormation Infrastructure as Code でクラウドプロビジョニングを高速化する 仕組み AWS CloudFormation は、インフラストラクチャをコードとして扱うことで、AWS およびサードパーティーのリソースをモデル化、プロビジョニング、管理することができます。

管理ツールとしてのAWS CloudFormationをAWS CDKでラッパーして開発者でも使いやすくしたのだと理解しました。

AWS CDKの開発者ガイドページに以下の文章と図があったので、引用します。 「AWS CDK は、TypeScript、JavaScript、Python、Java、C#/.Net、Go をサポートしています。これらのサポートされているプログラミング言語のいずれかを使用して、コンストラクトと呼ばれる再利用可能なクラウドコンポーネントを定義できます。これらを組み合わせてスタックとアプリを作成します。次に、CDK アプリケーションを AWS CloudFormation にデプロイして、リソースをプロビジョニングまたは更新します。」

https://rydeenworks.github.io/assets/2024-07-19_aws_cd_app_stack_construct.png

CDKアプリケーションの説明ページに以下の文章と図がありました。 「CDK アプリをデプロイすると、次のフェーズが実行されます。これはアプリライフサイクルと呼ばれます。」

https://rydeenworks.github.io/assets/2024-07-19_aws_cdk_app.png

以上の内容から、おおまかなイメージは理解しました。

AWS AmplifyでのCDKの使い方コンセプト

Connecting to AWS beyond Amplifyにコンセプトが書いてあります。

「Gen 2 is layered on top of AWS Cloud Development Kit (CDK)—the Data and Auth capabilities in @aws-amplify/backend wrap L3 AWS CDK constructs. As a result, extending the resources generated by Amplify does not require any special configuration. The following example adds Amazon Location Services by adding a file: amplify/custom/maps/resource.ts.」とのことで、resource.tsを追加して記述するとAmazon Location Servicesがアプリに追加できるようです。 つまり、CDKを意識せずにアプリにサービス機能を拡張できるようです。

感想

AppSyncとCDKはイメージつかめました。 他のサービスも調査することでシステム全体構成を描けそうです。

参考

特になし

AWS-Amplifyのクイックスタート続き(認証周り実装見直し)

AWS-Amplifyのクイックスタートで残った課題

問題の事象

  • Sign in した直後に表示されるTODOタスクが、前回ログインしていたユーザのものになる
  • 再現率100%

問題の回避策

  • Webページをリロードすると当該ユーザのTODOタスクが表示される

課題

  • クイックスタートのソースコードが正しくて、自身の実装がクイックスタート通りに実装できてないのか確認する
    • 確認した結果クイックスタート通りに実装できていた
    • つまりクイックスタートのソースコードはユーザごとにデータを保持する機能仕様に対応できてない模様
  • クイックスタートの実装内容を見直して修正する
  • アプリが利用しているライブラリやフレームワークの機能仕様・機能設計の理解があいまいで何が問題なのか特定できてないのが課題
    • useEffect処理(subscribeとsetTodos)について内容を理解する
    • Authenticator処理について内容を理解する

ライブラリ・フレームワークの調査

  • React
    • userEffect
      • useEffectのAPIリファレンス
      • 「コンポーネントが DOM に追加されると、React はセットアップ関数を実行します。」とのこと
      • クリーンアップ関数が未実装だったので、unsubscribeする関数を返すようにする
      • console.log()を仕込んで実際の挙動を確認したところ、１度Webページを更新するとセットアップ→クリーンアップ→セットアップと呼び出されていることがわかった
      • React18でStrictModeの場合は意図的に二重にコンポーネントをレンダリングしているからセットアップが２回呼ばれるらしい
    • useState
      • todoデータを状態として保持する役割
      • 初期値は空っぽの配列
      • setTodos関数でデータを更新する
      • データを更新すると再レンダリングする
      • subscribeでTodoデータの更新を検知するとsetTodos関数を実行する設計
  • Amplify
    • Amplify Data
      • 「TypeScript を使用してデータモデルを定義すると、Amplify がリアルタイム API をデプロイします。この API は AWS AppSync によって実行され、Amazon DynamoDB データベースに接続されます。」とのこと。
      • AWS AppSyncページを見ると、「GraphQL と Pub/Sub API を使用して、アプリをデータやイベントに接続」とのこと
      • Amazon DynamoDBは「サーバーレス NoSQL フルマネージドデータベース」とのこと
      • Amplify Data 公式DocのSubscribe to real-time updates ではuseEffectでsubscribe/unsubscribeするソースコード例が載っていた
      • バックエンドからTodoタスクを読み出すソースコード例も公式Docにあった -> Read data from your backend
      • ユーザごとにTodoタスクを保持するデータ設計なので、ユーザがサインインに成功したら該当ユーザのTodoタスクを表示する機能仕様になるはず
      • Todoタスクを読み出す実装を追加する必要がありそう
    • Authentication
      • Amplify Auth 公式Doc
      • 「Amplify Auth はAmazon Cognitoを利用しています。」とのことなので認証機能の詳細はCognitoを理解するのが良さそう
      • Amplify Dev Center > UILibrary > Authenticator > Advanced Usega にuseAuthenticator Hookというのがある
      • 今回の課題は認証時の実装作法についてなのでuseAuthenticatorを理解すれば良さそう

クイックスタートの実装内容の調査

  • todoデータはsubscribe時にしか更新されないのが課題なので、ユーザ認証されたタイミングでsetTodosする設計に見直す
  • useAuthenticatorに以下のログを仕込んでroute/authStatus/usernameの認証時の値の振る舞いを明らかにした
  const { user, signOut } = useAuthenticator(
    (context) => {
      console.log("useAuthenticator onChanged. route=" + context.route + " authStatus=" + context.authStatus + " user:" + context.username);
      return [context.user];
    }
  );
  • useAuthenticatorを調査した結果、userが有効な値の時にTodoタスクを読み出す設計にした
  • useEffectのdependenciesとしてuserを設定し、user更新時にuseEffect時の処理を実行する設計とした
  • useEffectのクリーンアップ関数でunsubscribeした
  • useEffectのクリーンアップ関数でTodoタスクを空配列にした
    • 空配列にしないと別のユーザのTodoタスクが一瞬表示されたため
    • unsubscribeするということはデータ更新しないということなので、空配列にする設計は妥当だと思う
  useEffect(() => {
    console.log("useEffect::user=" + user);
    if (user) {
      fetchTodos();
    }
    const subscribe = client.models.Todo.observeQuery().subscribe({
      next: (data) => {
        console.log("useEffect::Todo.observeQuery()>>>setTodos");
        setTodos([...data.items]);
      },
    });
    return () => {
      console.log("useEffect::unsubscribe()");
      subscribe.unsubscribe();
      setTodos([]);
    }
  }, [user]);

結果

  • 課題は無事解決できた
  • ライブラリやフレームワークの理解が深まった
  • 3日間くらいログやDocで調査しつつフレームワークの動作モデルを正しく理解するのに費やした

感想

  • AWS Amplifyでシステム構築した上で理解を深めるという作戦は狙い通りにうまく行った
  • 引き続きアプリ機能を拡張しつつ理解を深めたい

参考

AWS-Amplify入門

入門の動機

  • ASW Amplifyというものがあることを知った
  • フロントエンド開発者に対してバックエンドやインフラ構築を半自動的に提供する体験をできそうなので試したくなった
    • AWS Amplify コンセプト抜粋「AWS Amplify Gen 2 は、バックエンドの定義に TypeScript ベースのコードファースト開発者エクスペリエンス (DX) を使用します。Gen 2 DX は、ホスティング、バックエンド、UI 構築機能とコードファーストのアプローチを備えた統合された Amplify 開発者エクスペリエンスを提供します。Amplify を使用すると、フロントエンド開発者は、アプリのデータモデル、ビジネスロジック、認証、承認ルールを完全に TypeScript で表現するだけで、クラウドインフラストラクチャをデプロイできます。Amplify は適切なクラウドリソースを自動的に構成し、基盤となる AWS サービスをつなぎ合わせる必要がなくなります。」

入門の仕方

クイックスタートの実行結果の調査

  • 特に問題なくデプロイまでできた
  • Amplifyコンソール画面の当該アプリの「デプロイされたバックエンドリソース」から78個のバックエンドリソースが自動的に構築されたことが確認できた
  • バックエンドリソースを整理することでシステムイメージが深まりそう
  • amplify_outputs.jsonはgitignoreにコミット対象外ファイルとして定義済みだった
  • TODO削除機能を追加してlocalhostで動作確認したら デプロイ環境で追加したTODOが表示された
  • mainブランチ用バックエンドがローカル開発でも使われる(amplify_outputs.jsonが同じなので)
  • TODO削除機能をmainブランチにpushしたら自動的にデプロイされて削除機能が使えた
  • アカウントセットアップは少し手こずったができた
  • サンドボックスも作れた
  • ユーザごとにTODOアイテムを持つように修正するとサンドボックスに自動的に反映されてデプロイされるようだ
  • チュートリアル通りだとユーザごとのデータ取得のタイミングがおかしい気がする
  • サインインした直後は以前のユーザのタスクが表示されるのがおかしい
  • useEffectのタイミングでsetTodosするのが設計としておかしい気がする
  • useAuthenticatorフック を使えば良いのでは？
  • Authenticator周りは追加で調査する

感想

  • AWS Amplifyを使うことで、AWS::AppSync、AWS::CDK、AWS::Cognito、AWS::IAM、AWS::Lambda、AWS::S3、AWS::SSM、AWS::StepFunctionsがバックエンドリソースとして動いた
  • これらのシステム動作イメージをつかみたい
  • これをベースに独自アプリ作れそうな気がする
  • コード修正してGitHubにpushするとビルド・デプロイまでされる体験はとても良い
  • 知識なしにアプリ開発に集中できる体験が特に良い
  • アプリ開発しながら必要な知識をつければ良さそうな点も良い
  • この体験のためだけに課金する価値ある

参考

特になし

React入門

入門の動機

  • UIフレームワークは技術の変化が早くて追っかけられてなかったが一度最新の状況を理解しておきたい
  • 業務でも個人開発でもUI開発のパラダイムを理解することで良い開発ができそうな感覚を持ったため
  • スマホアプリ・デスクトップアプリ・フロントエンドに依存しない共通したUI開発のベストプラクティスの引き出しを増やしたい
  • Flutterアプリ・WPFアプリ・Kotlinアプリいずれにしても最新のパラダイムの理解が必要な感覚があった
  • Webアプリケーションのクライアント側の挙動を概要レベルで語れるようにしておきたい
  • フロントエンドという領域や職種に対するイメージをアップデートした方が良さそうなくらい進化している(気がする)
  • Reactは標準技術と言えるくらい普及している(気がする)

入門の仕方

  • 雑誌 WEB+DB PRESS Vol.129 の特集「Reactの深層 変わる常識と変わらない思想」の記事に目を通して、Reactの本質的な思想とVer18以降の設計方針が理解できた
  • 手を動かしたくなったので公式ページのReactを学ぶに着手した
  • チュートリアル：三目並べ は、最後まで実装してイメージつかめた
  • Reactの流儀 は、ひととおり目を通した
  • 内容的には違和感はなく、慣れればしっくりきそうな気がする

感想

  • 雑誌の特集記事がイメージはつかむのに役立った
  • 三目並べのチュートリアルも雰囲気を把握するのによかった
  • バックエンド側との連携とかページ遷移とか理解したい
  • Start building with Next.js が良いのかもしれない
    • スタイリング: Next.js でアプリケーションにスタイルを設定するさまざまな方法。
    • 最適化: 画像、リンク、フォントを最適化する方法。
    • ルーティング: ファイル システム ルーティングを使用してネストされたレイアウトとページを作成する方法。
    • データ取得: Vercel でデータベースを設定する方法と、取得およびストリーミングのベスト プラクティス。
    • 検索とページネーション: URL 検索パラメータを使用して検索とページネーションを実装する方法。
    • データの変更: React Server Actions を使用してデータを変更し、Next.js キャッシュを再検証する方法。
    • エラー処理:404一般的なエラーおよび見つからないエラーを処理する方法。
    • フォームの検証とアクセシビリティ:サーバー側でのフォーム検証の方法とアクセシビリティを向上させるためのヒント。
    • 認証: アプリケーションに認証を追加する方法NextAuth.jsおよびミドルウェア。
    • メタデータ: メタデータを追加し、アプリケーションをソーシャル共有用に準備する方法。
  • React foundations は後でやりたい

参考

読書「働くみんなの必修講義 転職学 人生が豊かになる科学的なキャリア行動とは」

キャリア構築手段としての転職

  • 大学卒業後20年ほどソフトウェア開発業界で働いてきた
  • この先20年もソフトウェア開発業界で活躍したい
  • そのために戦略的にキャリア構築する必要があると仮説を立てた
  • キャリア構築の手段として転職を1つのオプションと考えた
  • 転職活動について色々と調査活動をして知見や学びを得たので個人のメモとして残す

業務経歴やスキルの棚卸し

  • 転職サイトに登録するため
  • 業務経歴やスキルなどを明確にすることで、マッチする企業からスカウトをもらうため
  • 履歴書や業務経歴書を作成するため
  • 転職理由や志望動機など自身の転職の軸を整理するため
  • 自身の目線から語れるが、企業の目線から客観的に見ることができない課題があったと、今なら感じる
  • 企業目線からのアドバイスをくれるという点で、たまたま登録したサイトは良いサービスだったのだと感じる

キャリア構築の模索は一人では厳しい

  • 転職サイトから支援したい旨の申し出があったので試しに話をしたら、とても良い体験だった
  • 転職活動のノウハウや経験が蓄積されており、転職のブラックボックス感が減って見通しが良くなった
  • こちらのキャリアやスキルについて客観的なアドバイスや企業ニーズについて教えてくれた
  • マッチする職種・企業などの求人も紹介してくれた
  • 自分一人の力で孤独に転職活動するのは無理
  • サポートの方のホスピタリティにとても助けられたし、頑張ろうと思えた
  • 企業側のカジュアル面談の担当者はみなさん優秀で、エンジニア採用への力の入れ具合がうかがえた
  • 面接担当の方とコミュニケーションする中で、自分の志向や強み、挑戦したいことなど、転職要件の輪郭が定まってきた
  • できること、できないこと、やりたいこと、でスキルを分類するようにサポートの方にアドバイスをもらった
  • できることベースでマッチさせつつ、やりたいことを狙う作戦をサポートの方にアドバイスいただいて、腹をくくれた気がする
  • できることベースで求人応募すると、面接担当の方との話が噛み合ってる感がとても増した
  • 家族からも要望をヒアリングした
  • ワークライフバランスとキャリア構築の両立を目指せると良いと感じた

ポッドキャスト「グリテンラジオ)」

  • 転職活動について語ってるポッドキャストを探して見つけた
  • 転職活動のリアルな話が聞けて、転職活動のブラックボックス感がさらに減った
  • 転職活動してなくても、IT業界の一般常識とか市場感という意味で聞き続けると良い気がする
  • 採用する企業側の事情もみえたことで、カジュアル面談への緊張感とかモチベーションがコントロールできるようになった
  • この頃に転職活動について語ってくれる人が10名くらい(サポートの方、グリテンラジオのお三方、カジュアル面談の担当者、家族)になって、活動のイメージが深まってきた感じがあった
  • グリテンラジオは17話分聞いて、今も継続して聞いている。学びが多いし、話の内容が面白い。
  • グリテンラジオの中で書籍「転職学」が紹介されてて購入した

書籍「働くみんなの必修講義 転職学 人生が豊かになる科学的なキャリア行動とは」

目次

  • はじめに
  • オリエンテーション　なぜ「転職学」が「人生の必修」なのか
  • 第1講 まずは転職の方程式「D × E ＞ R」を学ぼう
  • 第2講 「自己認識」を高めれば転職力も高まる
  • 第3講 孤独になるな！「転職相談」の大切さ
  • 第4講 日本人と「大人の学び」の心理分析
  • 第5講 地方転職から副業まで「流行りの転職」の虚実
  • 特別集中講義 日本の転職の歴史学
  • 第6講 新しい組織に馴染む科学的な方法
  • 第7講 これだけは知りたい「ミドルの転職」
  • 最終講 「辞めた会社」との付き合い方とは

感想

  • 転職プロセスの全体像について知識をつけるのに最適
  • 本に出会うまでは転職活動の見通しの悪さによるしんどさやストレスがあった
  • 書籍では統計的・客観的に転職プロセスを分析して講義という形式に仕立ててくれており、心の負担が軽くなった
  • 個人的には読書は著者との出会い・語らいにカウントしている
  • 良い書籍に出会えるとコスパ・タイパが大変よいし、この書籍もそうだった
  • グリテンラジオと書籍「転職学」のおかげで多角的に転職活動を見れるようになった
  • あとは自分の軸や要件を整理すれば良いのでは？というところまで学びが蓄積できた気がした

Androidアプリ 「World Ama Shopping」のご紹介

本記事の概要

各国Amazonサイトの商品を調べるときに簡単に調べられるように Androidアプリ「World Ama Shopping」を開発・リリースしました。 簡単に各国Amazonサイトの商品を調べられます。

f:id:rydeenworks:20210305194250p:plain

本記事では以下を説明します。

  • アプリの使い方
  • 各国の商品の違い(利用例)

アプリの使い方

入手方法

GooglePlayからインストールします。

https://play.google.com/store/apps/details?id=com.rydeenworks.amago

Get it on Google Play

アプリの説明

メイン画面

f:id:rydeenworks:20210305194358p:plain

AmazonURL

検索対象のAmazonサイトを表示します。タップすると"Select Country"画面に遷移して、Amazonサイトを選択できます。

Search Word

検索したいキーワードを入力できます。

Sort Order

Amazon商品検索結果の並び順を指定できます。

GoTo Amazonボタン

Amazonサイトで商品検索を実行します。

各国の商品の違い(利用例)

"Emacs"で検索してみました。各国で違いがあって面白いです。

f:id:rydeenworks:20210305194433j:plain

f:id:rydeenworks:20210305194455j:plain

f:id:rydeenworks:20210305194521j:plain

f:id:rydeenworks:20210305194543j:plain

f:id:rydeenworks:20210305194603j:plain

f:id:rydeenworks:20210305194624j:plain

f:id:rydeenworks:20210305194643j:plain

映画監督「大林宣彦」作品をAmazonプライムビデオで観る(2021年１月時点)

以前、こういう記事を書きました。

rydeenworks.hatenablog.com

Amazonプライムビデオで視聴できる大林宣彦監督作品が以前の記事から変わってますので、2021/1月の状況を整理しました。 私は気になっていた初期作品『HOUSE ハウス』を観る事ができました、面白かったです。

Amazonプライムビデオで視聴できる大林宣彦監督作品

注)情報は2021年1月10日時点のものです。実際の情報はAmazonプライムビデオのサイトで確認してください。(タイトルからプライムビデオページへリンクしてます)

タイトル 視聴可能 予告編
HOUSE ハウス ○ あり
ふりむけば愛 △ あり
金田一耕助の冒険 △ あり
ねらわれた学園 △ なし
転校生 ー ー
時をかける少女 △ なし
天国にいちばん近い島 △ なし
少年ケニヤ △ なし
廃市 △ あり
さびしんぼう ○ あり
姉妹坂 △ あり
彼のオートバイ、彼女の島 △ あり
日本殉情伝 ... ー ー
異人たちとの夏 △ あり
ふたり △ あり
青春デンデケデケデケ △ あり
風の歌が聴きたい ー ー
理由 ー なし
転校生 －さよなら あなた－ △ あり
この空の花 -長岡花火物語 △ あり
野のなななのか △ あり
花筐／HANAGATAMI ○ あり

○：Amazonプライムビデオの定額サービスで視聴可能

△：有料レンタル等で別途料金がかかるが視聴可能

ー：Amazonプライムビデオで視聴できないもの

大林宣彦監督作品の入り方(どの作品から観るか)

もちろんご自身の好みで観れば良いと思います。

Amazonプライムビデオで予告編が無料で見られるものがありますので、予告編を見て好みの映画か判断するのも良いと思います。

普段あまり映画(特に邦画)を見ない方は長時間の映画や難解な映画は避けた方が良いと思います。

上記３つが大林宣彦監督作品として入りやすいと思いますので参考にしてください。

参照

図書館の予約を便利にするアプリの紹介

私は図書館をよく利用するのですが、大林宣彦監督は本も出しています。読みたい本が図書館にあるかAndroidアプリ 図書さがし(Google Play)で簡単に調べることができて便利です。

使い方は紹介記事を見てください。 rydeenworks.hatenablog.com

ブラウザブックマークによるGTDのinbox整理方法について

本記事で解決する事

GTDではinboxに情報収集するという考えがあります。 inboxにどんどん情報を収集した結果、情報を整理できずに活用できなくなってしまう事があると思います。 本記事ではinboxの整理を上手くやる方法について紹介します。

本記事の概要

本記事ではGTDの5ステップのうち、ステップ1-3をブックマーク機能を使って実現する方法を説明します。

  • STEP1 CAPTURE - あなたの気を引くものを捕らえる ->ブラウザからブックマークする
  • STEP2 CLARIFY - それが何を意味するのか明確にする ->ブックマークを定期的に見直す
  • STEP3 ORGANIZE - それをあるべき所に整理する -> ブックマークを定期的にしかるべきフォルダに移動する

この運用のメリットは次のとおりです。

  • ブックマークするだけで CAPTURE できる
  • ネットから得た情報はブックマークで一元管理するルールにできる
  • ブックマークはアカウントに紐づくのでスマホ・ノートPCなど端末に依存せずに参照できる

ブックマークでinboxを簡潔に運用する事で、ステップ1−3のサイクルが回るようになります。

本記事の著者について

もともと手帳術のようなものが好きで20年くらい続けています。 その過程でGTDを知って、自分なりのやり方をブラッシュアップし続けています。 メモ帳を電子化する事で手帳術を強化できないかと考えて、Emacsとorg-modeも5年ほど愛好しています。

f:id:rydeenworks:20191027224859j:plain

STEP1 CAPTURE - あなたの気を引くものを捕らえる

準備

ブックマークのフォルダ構成を決めておく事が大事です。 フォルダ構成を決めておかないと、GTDをスピーディに運用できないからです。

フォルダは1つのinbox、複数の整理用フォルダを用意します。整理用フォルダは、過去記事のgoal.org「私生活の大事な事や目標など実現したい事」の構成に合わせます。

私の場合、トップフォルダは以下のようなイメージです。 ブックマークが多くなってきたらサブフォルダを作ってください。

フォルダ名 役割
inbox 最初に入れる場所
goal 自分の人生を通して極めたい事の参考資料
life-work 個人的な研究・プロジェクトの参考資料
maintenance 人間関係・資産・自分自身のメンテナンスの参考資料
rice-work 今の仕事に役立つ事の参考資料

ブックマークする

ネットサーフィンしていて気になる記事を見つけたらブックマークします。 ブックマークは全てinboxに保存します。

以上でステップ1は終わりです。

STEP2 CLARIFY - それが何を意味するのか明確にする

準備

inboxに貯めたブックマークは時々は棚卸しましょう。 1ヶ月、3ヶ月、半年、1年などのタイミングが良いと思います。 なぜなら、少し時間を置いてブックマークを見直すと、やっぱり不要な情報だと冷静に気づけるためです。

準備として以下が必要です。

  • 時間 - ブックマークを整理するための1時間程度のまとまった時間
  • 整理方針 - 「私生活の大事な事や目標など実現したい事」とその優先順位
  • 整理する強い意思

ステップ2の運用

棚卸しの目的はGTDの以下のプロセスの実行です。

それが実行可能なら次のアクションやプロジェクトにする。そうで無ければ、捨てるか、参考資料にするか、保留にする。

私の経験上、ブックマークは「参考資料」か「捨てる」のどちらかです。「次のアクション」や「プロジェクト」にはせずに、目的のための「参考資料」とした方が運用しやすいためです。同様の理由で「保留」にはせずに、目的に役立つかどうかで「参考資料」か「捨てる」かどちらかにします。これでinboxを空にできます。

ステップ2と3はセットで行います。 ステップ2はステップ3の準備と考えて良いと思います。

STEP3 ORGANIZE - それをあるべき所に整理する

ブックマークの整理

ステップ2で整理方針が決まれば、ステップ3でinboxのブックマークを整理します。

分類 整理方針と照らし合わせた結果 処理
参考資料 目標や実現したい事に役立つ情報 ブックマークを移動する
捨てる 不要な情報 ブックマークを削除する

以上で終わりです。

参考

GTDの5ステップ

https://gettingthingsdone.com/what-is-gtd/

オススメの本

全面改訂版 はじめてのGTD ストレスフリーの整理術

全面改訂版 はじめてのGTD ストレスフリーの整理術

図書館の予約を便利にするアプリの紹介

私は図書館をよく利用するのですが、上記の本は図書館から借りました。本も「参考資料」としてブックマークしています。本が図書館にあるかAndroidアプリ 図書さがし(Google Play)で簡単に調べることができます。このアプリは私が開発しました。

詳しくは以下の記事をご覧ください。 rydeenworks.hatenablog.com