「さわって学ぶクラウドインフラ Amazon Web Services 基礎からのネットワーク & サーバー構築 改訂3版」を読みました

今日は、「さわって学ぶクラウドインフラ Amazon Web Services 基礎からのネットワーク & サーバー構築 改訂3版」を読みました。
ハンズオン形式で、わかりやすくてとっても面白い本でした！

kindleだと無料ですよ！！！！！！！

Amazon Web Services 基礎からのネットワーク＆サーバー構築　改訂3版

対象者

• インフラにあまり詳しくない方
• AWSを使って、自分でネットワークやサーバーを構築できるようになりたい方
• （基本情報レベルのネットワークの知識を予め持っていると、途中解説にあるIPアドレスやサブネットマスクなどの説明がより具体的に理解できると思いました！）

注意点

⑴ 私が見落としただけかもしれませんが、本書はAWSアカウントを取得していること前提で進むようです。幸い私はS3を使ったことがあってすでにアカウントを持っていたのですが、持ってない人は自分で調べてアカウントを作ることになりそうです。

⑵ 本書は最新版ですが、Amazonあるあるでしょっちゅう管理画面の文言やボタンが変わるので、AWSコンソールを初めて使う方は驚くと思います。（「インスタンスの作成」→「インスタンスの起動」になってたり...ボタンのいちが微妙に違ったり...）（kindle版だと更新されてるんでしょうか？）

⑶ 初めてAWSを使う方は大丈夫だと思いますが、EC2のインスタンスは起動しているだけで、Elastic IPは持っているだけで料金がかかってしまうようです。私は昔S3を利用したことがあって無料枠ではなく、だらだらと教材を進めてしまったので、知らないうちに7ドルかかっていました（笑）使わない人は消しましょう！！

本書でできること

AWS上にWebサーバー、DBサーバーとWordPressを立ち上げることができます。

こんな感じのアドレスにアクセスすると、
http://ec2-18-182-47-48.ap-northeast-1.compute.amazonaws.com (もう消しちゃったので今はアクセスできません)

自分だけのブログを世界に発信することができます。

ちょっとハマったこと

３章　ファイアーウォールを設定する

ファイアウォールを設定し、Apacheのテストページが表示される章にて。
ここから開けると思ったら開けず...

そうではなく、ちゃんとIPアドレス"だけ"を打たないと`http://自分のIPアドレス`になっていて開けませんでした（笑）
ブラウザではこう表示されてたので騙されました...。

５章のtelnet接続

バージョンの新しいMAcにはtelnetがないとの記述があったので、Homebrewでインストールしました。

本書を通じてわかったこと

今まではネットワークやサーバーについて、ドキュメント上の絵や線だけでの理解だったり、基本情報や本などで知識として知っているだけでした。

まずはじめに、入社当時一番最初にやったssh接続の意味がようやくわかりました😂
次に、ユーザーがサイトにアクセスしてからそのリクエストがどのようにサービスにアクセスするのか（DNSによる名前解決）や、AWSでどんな風にサーバーを構築していくのか実際に手を動かして学ぶことができました。

自分が立てたサーバーにWordpressをインストールしただけでもうブログが作れてしまったのは驚きでした！

ただポチポチ作っていくだけでなく、何をしているのかしっかりとした解説をされた上での操作説明だったので、とてもわかりやすかったです。
AWSでネットワーク&サーバー構築をしてみたい人にとてもオススメの本です！！

この知識を土台にして、次はDockerやkubernetesを学んでいこうと思います！

Amazon Web Services 基礎からのネットワーク＆サーバー構築　改訂3版

「プロダクションレディマイクロサービス」を読みました

今回は、「マイクロサービスわからないよ〜」となっている私に対して、SREさんがオススメしてくださった「プロダクションレディマイクロサービス」を読みました。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

対象読者

• モノリスを分割して、「次はどうしよう？」と思っている人
• 0からマイクロサービスを構築し、最初から安定性、信頼性、スケーラビリティ、耐障害性、パフォーマンスを備えたマイクロサービスを作りたいと考えているソフトウェアエンジニアとSRE
• マイクロサービスの基本概念、マイクロサービスアーキテクチャ、最新の分散システムの基礎を知っている人（知らないけど読みました）

この本で学べること

• マイクロサービスの一般的、汎用的な考え方
• 安定性、信頼性、スケーラビリティ、耐障害性、パフォーマンスを備えたマイクロサービスとはどんなサービスなのか、その抽象的な概念
• マイクロサービスを改善、標準化するためにはどうすれば良いか、現実的・具体的に理解できる

この本に書いてないこと

• 各章で取り上げられている個々のテーマについて、具体的に「何を使ったらいいか」「何をすればいいか」までは書かれていない。

1章　マイクロサービス

対象読者に、マイクロサービスの基本概念、マイクロサービスアーキテクチャ、最新の分散システムの基礎を知っている人と書かれていたのですが、知らない人向けに1章に入門を書いてくださっていました。

• モノリスとマイクロサービスの違い
• マイクロサービス環境のことをマイクロサービスエコシステムと呼び、4層のレイヤがあること
• マイクロサービスを導入する際の組織的な課題

4層のレイヤの考え方は初めて知りました。漠然と色々な技術がバラバラになっているイメージがあったので、レイヤごとに分類できることを知って、マイクロサービスが具体的に何で構成されているのか少しイメージが湧きました。

2章　本番対応

マイクロサービスを標準化するための課題、本番対応の8つの標準についてです。

マイクロサービスアーキテクチャの採用によって、開発者は言語やライブラリ・開発ツールなどを自由に決められるようになりました。では、どのように各々のサービスが成功したかどうか測定すれば良いでしょうか？

そこで使われるのがサービスの可用性についてのSLA（サービスレベル契約）です。
99%の時間に利用可能なサービスにするぞ、というような目標を立てます。

さらに「本番対応」として、8つの原則を定量化し、アクション可能な要件として測定可能にします。
それが、安全性、信頼性、スケーラビリティ、耐障害性、大惨事対応、パフォーマンス、監視、ドキュメントです。
2章では、この8つの原則の要件について述べられていました。

次の章から、各々の原則をさらに詳しくみていきます。

3章　安定性と信頼性

安定性と信頼性を備えたマイクロサービスを作るための原則についてです。

• 開発サイクル
• デプロイパイプライン
• サービス間の依存関係
• サーキットブレーカーの配置
• マイクロサービスが使われなくなったときの対処法

など。

4章　スケーラビリティとパフォーマンス

スケーラブルでパフォーマンスが高いマイクロサービスを構築するための原則についてです。

スケーラブルでパフォーマンスが高いマイクロサービスとは、同時に大量のタスクやリクエストを処理できるだけでなく、それらを効率よく処理でき、将来のタスクやリクエストの増加に対する備えがあるマイクロサービスです。

• 質的な成長の判断基準（速さ）/ 量的な成長の判断基準（アクセス数）
• トラフィック管理について
• リソース（CPU、メモリ、データストレージなど）の効率的な使い方
• マイクロサービスエコシステムにおけるデータベースの選び方

など。

5章　耐障害性と大惨事対応

大惨事に対する備えができた耐障害性のあるマイクロサービスを構築するための原則についてです。

• 単一障害の除去
• 大惨事や障害の一般的なシナリオ
• 障害の検出と修正方法
• 回復性テスト(単体テスト、結合テスト、エンドツーエンドテスト)
• 障害が起こったときの組織レベルでのインシデント
• 機能停止処理の方法

など。

6章　監視

マイクロサービスの監視と標準化によって監視の複雑化を避ける方法についてです。

• 主要メトリック（主要メトリックとは、アプリケーション、マイクロサービス、システムの健全性、状態、動作を必要十分な形で説明するこれらのものの性質のこと。）
• ロギング（何をロギングするか）
• アラート（適切なしきい値、その後のアクション）
• オンコールについて

など。

7章　ドキュメントと組織的な理解

マイクロサービスの適切なドキュメントの問題と、開発チームと技術組織全体でアーキテクチャと組織運営の理解を深める方法についてです。

• ドキュメントにはこんなこと書くといいよ
• 組織のみんなが理解できるようなもの書こうね

など。

まとめ

最初オススメいただいたときは、インフラやマイクロサービス特有の用語がたくさん出てくるので読めるか不安でしたが、P177から、用語集がまとまっていてとても読み進めやすかったです！

まず、私はマイクロサービスを完全に誤解していて、今までの自分のタスク範囲はマイクロサービスのたったの一部分であったことに気づきました。今までは、マイクロサービスの全体像がイメージできなかったり、サービスがバラバラになるからデプロイとか依存関係とか難しそうだと漠然とした不安を抱えていましたが、 この本で抽象的な概念と用語が理解できました！

超ざっくりですが、これからの仕事のミーティングでは、「あ、今マイクロサービスのこの部分の話をしているんだな」→「一般的にはこういうことが満たされていればいいサービスなんだな」というようなことを意識しながら話が聞けるようになると思いました🙆‍♀️ 来年からは、この本片手に会議に参加したいと思います💪

さて、抽象的な概念を知ることができたので、「具体的に何を使ってこれらの要件を実現させていくのか？」ということを考えてみようと思います！そしてその前に、もう少しインフラを勉強しようと思いました。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

ここまで読んでいただきありがとうございました！

今年のエンジニアとしての振り返り2020٩( ᐛ )و

みなさんこんにちは！宮水です。

今年も2020年エンジニアとしての振り返りをやっていきたいと思います！

2019年の振り返りはこちら！
今年のエンジニアとしての振り返り2019٩( ᐛ )و - 宮水の日記

頑張ったこと① 英語

今の会社のプルリクエストが英語で書いたり読んだりするので、毎日15分は必ず英語を勉強するようにしていました。
1年続けてみて、書くことはまだまだ苦手ですが、以前よりは読むことが苦痛ではなくなりました！

英会話

3ヶ月くらいは、毎日英会話をしていました。英語を喋る機会がないので、すぐ辞めてしまいました笑

英単語

BooQsという英単語アプリを3ヶ月くらい続けました！
文法は結構勉強したんですけど、語彙力がなかったのではじめてみたら、本当に多くの英文が読めるようになりました🙆‍♀️
www.booqs.net

スタディサプリEnglish

スタディサプリEnglish TOEICを受講していました！
毎日少しずつ頑張れるので続けやすかったです。

頑張ったこと② 読書

今の会社に入ってから本当に視野が広がって、昔読んでもわからなかった様々な本が概ね理解して読めるようになりました。
これが本当に嬉しくて、たくさん本を読むことができました。
特にオライリーの本にずっと抵抗があったんですけど、今年から楽しんで読めるようになってきました。

フロント系

• りあくと

oukayuka.booth.pm

• プログラミングTypeScript

プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発

• Atomic Design ~堅牢で使いやすいUIを効率良く設計する

Atomic Design ～堅牢で使いやすいUIを効率良く設計する

• TypeScript エクササイズ（リポジトリ無くなってた...😨）

読書とは少し違うのですが、会社で使われているJSライブラリのREADMEを読むイベントもしました。
44個も...！レビューをしていただいた上司の方、同僚の皆様、本当にありがとうございました！！
JSライブラリ紹介 カテゴリーの記事一覧 - 宮水の日記

Ruby/Rails系

• Everyday Rails（Rspecの本）
• Effective Ruby

Effective Ruby

• パーフェクトRuby on Rails（古い方）

パーフェクト Ruby on Rails

• チェリー本

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Software Design plus

• オブジェクト指向実践ガイド

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

• Webフロントエンド　ハイパフィーマンスチューニング

Webフロントエンド ハイパフォーマンス チューニング

• リファクタリングRuby

リファクタリング:Rubyエディション

アジャイル/スクラム系

• アジャイルな見積もりと計画づくり

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

• スクラムブートキャンプ

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

• アジャイルサムライ

アジャイルサムライ――達人開発者への道

Vim

• マスタリングVim

マスタリングVim

組織とかメンタル系

• オプティミストはなぜ成功するのか

オプティミストはなぜ成功するか

• ずけずけいう力

ＧＲＥＡＴ　ＢＯＳＳ（グレートボス）　―シリコンバレー式ずけずけ言う力

• 達人プログラマ

新装版 達人プログラマー 職人から名匠への道

そのほか

• マスタリングTCP/IP

マスタリングTCP/IP　入門編（第6版）

• Webを支える技術

Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus

• なるほどUnixプロセス

tatsu-zine.com

• テスト駆動開発

テスト駆動開発

• 初めての GraphQL

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

• デザイン入門教室

デザイン入門教室［特別講義］　確かな力を身に付けられる ～学び、考え、作る授業～ (Design ＆IDEA)

• プロダクションレディマイクロサービス

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

• さわって学ぶクラウドインフラ Amazon Web Services 基礎からのネットワーク & サーバー構築 改訂3版

Amazon Web Services 基礎からのネットワーク＆サーバー構築　改訂3版

頑張ったこと③ 個人開発

Escola（プログラミングスクール口コミサイト）

ありがたいことに、今年の初めにある会社様から売却するお話をいただきました。
でも、はじめて作ったまともなサイトで愛着もあり、サイト自体、売上も大したことがなかったので、お断りしてしまいました。

www.escola-pro.com

その後、新しいメンバーを迎えていろんな機能を作ろうと思ったのですが、お互い時間が取れず残念ながらうまくいきませんでした。
2年くらい続いたサイトでしたが、そろそろ閉鎖しようと思います。

多くの方に口コミを書いていただいたこと、リプやDMで「Escolaのおかげでいいスクール選びをすることができました」と言っていただけたこと、とあるプログラミングコミュニティの方からコラボのお誘いをいただいたこと、Twitterで「ツイートで起業」にノミネートされてたくさんの方にリツイートしていただき2位に選んでいただいたこと、本当にたくさんの方にお世話になりました。本当にありがとうございました！！そして、Escolaを一緒に育てようとしてくださった初期メンバーや、コミュニティの方、最近の開発メンバーもありがとうございました！

こんなに思い出深いプロダクトは今後なかなか作れないんじゃないかなと思っています！

らくらくゴルフ（ゴルフ場予約検索サイト）

今年のお正月にReactの勉強をかねて、夫と一緒にらくらくゴルフというサービスを作りました。
www.rakuraku-golf.com

夫がAPI側を作って、私がフロント側を担当しました。はじめての共同作業アプリ、とても楽しかったです！いいお正月でした。

ゴルフメドレー（ゴルフ練習場口コミサイト）

今年はさらにEscolaと並行して、全く別の新しいプロジェクト「ゴルフ練習場の口コミサイト」をリリースしました。
golf-medley.com

ゴルフ場コンサルタントのPOからお声かけいただいて、私たち夫婦と3人で作成しました。
今年は練習場リリースに留まりましたが、来年はがっつり収益のでるプロダクトに育てていきたいです！

こういった記事を出していただいたり、ゴルフ雑誌に私たちのインタビューが載ったり、貴重な体験をさせていただきました。
gridge.info

技術的なお話をすると、Atomic Designを用いた設計、TypeScriptとReactの環境構築、Next.js、RailsをAPIモードで使用する...など新しいことに挑戦しました。私はとにかく新しいことをキャッチアップするのが苦手なのですが、夫からいろんなことを学ばせてもらいました。

頑張ったこと④ 教材のリリース

ゴルフの教材リリース

先ほど載せた「らくらくゴルフ」を題材にしたReact, AWS Lambda, DynamoDB, API Gatewayを使った開発の教材もリリースしました。
本当に多くの方にご購入いただき、ありがとうございました！！
www.techpit.jp

できなかったこと

達成できたこともあったけど、できなかったこともありました。

去年はじめてOSS活動や競プロに挑戦して、その楽しさを知り、今年はもっと挑戦するぞ！と思ったのですが、他に勉強することが多すぎて今年やることからは除外しちゃいました...。
また、個人開発が楽しくて資格も何も取る気にならなかったし、TypeScriptの教材を作っていましたがだんだん内容に自信が持てなくなって途中で辞めてしまいました。

1年って本当にあっという間ですね。

今年の感想

今年の4月で、エンジニア4年目なんですよね...。
4年目ってもっといろんなことができるようになってると思っていたので、現実とのギャップから凹むこともたくさんありました。
新しい言語や技術も自分なりにすごく頑張って詰め込みましたが、要領が悪くて全然仕事についていけませんでした。

でも、やっと成長曲線のブレイクスルーとなる点に辿り着けたのではないかと思っています。
あと2年くらいこのまま頑張れば、一人前のエンジニアになれる気がします。私は私のペースで頑張ります✨(NiziU)

引用：成長曲線 | NPO法人MIOスポーツクラブ | MIO東近江

来年の抱負

来年はサーバーサイドがメインになると思うので、再びRailsを復習したり、GraphQL、Prisma、設計、マイクロサービスの勉強をめちゃめちゃ頑張りたいと思います！！

今年もいろんなことに手をつけすぎてしまった感があるので、個人開発のゴルフメドレーに注力して、ちゃんと収益のでるプロダクトにしたいです。来年も頑張るぞ！

「オプティミストはなぜ成功するか」を読みました

こんにちは。宮水です！

今回は「オプティミストはなぜ成功するか」という本を読みました。
オプティミストとは、「楽観主義者」という意味です。
自己啓発本はどれも似たような内容なのであんまり好きではなくなっていたのですが、こちらの本は非常に納得させられる内容だったのでブログにしました。
コロナ禍もあって私なりに最近色々と落ち込むことがあり、その際に会社の方にオススメしていただいたので読みました。

オプティミストはなぜ成功するか

楽観主義を身につけるということは、世の中をむやみに明るく見ることではなく否定的でない考え方を学ぶことだ

この本のざっくりまとめ

第１部　オプティミズムとは何か

オプティミストとは、「楽観主義者」のことです。
第１部では、著者がどうやって「楽観主義者」の研究に行き着いたかが書いてあります。
最初は「人はどうして無気力になるのか？」と研究していたのですが、無気力になる人がいる一方、一定数「何があっても絶対に諦めない人」がいることに気がつき、研究を進めていきます。

第２部　オプティミズムが持つ力

楽観主義者の人の仕事ぶりや、楽観主義者の子供達の成績を調査したら、やっぱりオプティミストの方が成績がよかったねって話です。
（この章は面白くなくて途中で読むのやめました 笑）

変身―ペシミストからオプティミストへ

では、どのようにしてオプティミストの考え方を身に付けるのか？その具体的な方法が書いてあります。
この章が、根性論が一切なくて素晴らしいです。

落ち込むことがあったときにどう自分に説明するか

「楽観主義者」であるオプティミストの反対は、「悲観主義者」ペシミストと言います。
楽観主義者と悲観主義者は色々と思考が異なります。

永続的 / 一時的

悲観主義者は、何か悪いことが起きたときその悪い出来事が永続的に感じてしまいますが、楽観主義者は一時的なものだと考えます。
「私はもう立ち直れない」（悲観的）/「私は今疲れている」（楽観的）

良いことが起こったときは逆です。
「今日はついている」（悲観的）/「私はいつもついている」（楽観的）

特定 / 普遍的

悲観主義者は、何か悪いことが起きたときその悪い出来事が普遍的なものに感じてしまいますが、楽観主義者は特定のものだと考えます。
「先生は皆不公平だ」（悲観的）/「〇〇先生は不公平だ」（楽観的）
「不愉快だ」（悲観的）/「彼は不愉快なやつだ」（楽観的）

良いことが起こったときは逆です。
「私は数学がよくできる」（悲観的）/「私はよくできる」（楽観的）

外交的 / 内向的

悲観主義者は、何か悪いことが起きたときその悪い出来事が内向的なものに感じてしまいますが、楽観主義者は外交的なものだと考えます。
「私にはポーカーの才能がない」（私が原因、悲観的）/「私はポーカーでついていない」（ポーカーのせいにする笑 楽観的）

良いことが起こったときは逆です。
「チームメートが活躍してくれたおかげだ」（悲観的）/「私が活躍したおかげだ」（楽観的）

憂鬱なときの、男女の思考の違い

女性は男性の2倍もうつ病の患者数が多いそうです。

なぜかというと、女性の方が「反芻」を起こす傾向にあるからだそうです。
どういうことかというと、女性は鬱状態になったとき「なぜ自分がうつ病になったのか」を考えますが、一方で男性は運動をしたり仕事に打ち込んだり、「行動」によって気分を紛らわせる傾向にあります。

男性は、落ち込んだときに気分転換によって負の感情を断ち切るのが上手で、女性は悶々と考え込んでしまう傾向にあり、それが女性にうつが多い原因ではないかと言われているそうです。男性でも、よくよく考え込んでしまう人はいらっしゃるのではないでしょうか？

困ったことがあったときの考え方のクセを直す

どのようにして楽観主義を身に着けるのか？ここでは一つだけ紹介します。
以下のフレームワークを使います。

困ったこと:
思い込み:
結果:
反論:
元気付け:

悲観主義者は「結果」の部分で終わってしまうので、そうではなくてその思い込みに対する反論と自分を元気づけるところまで考えます。
たとえば私だったらこんな感じ。

困ったこと: 最近仕事内容が全く理解できない。
思い込み: 〇〇さんは同じくらいの歳のときにもっとうまくやってるのに、私はなんてバカなんだろう。この仕事は向いてないんじゃないか。
結果: もう辞めてしまった方が周りの人や自分のためなんじゃないかと思い、退職を検討する。
反論: 私は現に、3年間もエンジニアを続けている。それに今回のプロジェクトの構成は初めてやるものだし、わからないことが多くて当然じゃないか。
今までだって、初めて触る技術があっても勉強して少しづつ克服してきたし、きっと今回も時間が経てばそのうち理解しているだろう。
元気付け: ここで諦めたら、もっと後悔することになると思う。わからないことをちゃんと整理して、理解することに集中しよう！

みたいな感じです。自分で書いててめっちゃポジティブな気持ちになってきました。

オプティミストが正義って訳でもない

オプティミストが正義！みたいな書き方をしてきたんですが、いつでもそういう訳ではありません。
楽観的過ぎると慎重にならなさ過ぎたり、重大なことを先延ばしにしてしまったり、わがままになってしまったり、悪い面もあります。
悲観主義者は楽観主義者よりも現実を把握するのが得意ですし、安全管理や設計、契約交渉などには悲観的な観点も必要です。

最後に

今までも、結論だけ似たような自己啓発本を読んできました。
「人や環境は変えられなくても、自分は変えられるよ！」とか、「自分が変われば人生が変わるよ！」とか。そんなのには正直うんざりでした。
でも、この本はとても納得させられる内容が多く、さらに実践的で非常によかったです。

最近コロナ禍もあって、普段ならどうってことない試練が乗り越えられず、憂鬱な気分が続いていました。
「〇〇だし、エンジニアなんて無理だったんだ、もうこれ以上はコード書けない...」なんて思い込みは、もろに「悲観主義者の永続的/普遍的/内向的」の三拍子揃ってました。この本を通して、自分が落ち込んでるときの考え方のクセを冷静に見つめ直すことができました。

自分が自分のことを否定すると、そのネガティブさが周りの人にも伝わってしまって何もかもがうまくいかなくなるような気持ちになります。
何事もバランスですが、きっとこの「楽観主義者」の考え方を実践していれば、人生がもっと楽に、楽しく思える場面が増えると思いました٩( 'ω' )و

ここまで読んでくださりありがとうございました！

オプティミストはなぜ成功するか

Element implicitly has an 'any' type because expression of type '"test1"' can't be used to index type '{}'. Property 'test1' does not exist on type '{}'.ts(7053)

こんな感じのテストを書こうとしていました。

//     { test1: 'test1', 'test2.title': 'test2' } みたいなデータが返ってくる関数をimport
import messages from 'translations/messages';

describe('messeages', () => {
  it('return flattened ja.json data', () => {
    expect(messages['test1']).toEqual('test1');
    expect(messages['test2.title']).toEqual('test2');
  });
});

するとこんなエラーが出ました。
お前がimportしたオブジェクトの中身がなんなのかよくわからんぞ的なことが書いてあるんだと思います。

Element implicitly has an 'any' type because expression of type '"test1"' can't be used to index type '{}'. Property 'test1' does not exist on type '{}'.ts(7053)

こうしたら解決しました。
オブジェクトが持っているkeyの型を定義してあげる必要がありました。

import messages from 'translations/messages';

const test_messages: { [key: string]: any } = messages; // ここをプラス

describe('messeages', () => {
  it('return flattened ja.json data', () => {
    expect(test_messages['test1']).toEqual('test1');
    expect(test_messages['test2']).toEqual('test2');
  });
});
<||

自動生成されたファイルのESLintのエラーでハマったのでメモ

TypeScriptとReactの環境構築中

eslintの設定をしていたら、自動生成されたファイルのlintエラーにめっちゃハマった。

5:1 warning Missing return type on function @typescript-eslint/explicit-module-boundary-types

App.tsx

import React from 'react';
import logo from './logo.svg';
import './App.css';

//ここをfunctionをやめて型をつけた
const App: React.FunctionComponent = () => {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.tsx</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
};

export default App;

136:8 warning Missing return type on function @typescript-eslint/explicit-module-boundary-types

140:9 error Promises must be handled appropriately or explicitly marked as ignored with the `void` operator @typescript-eslint/no-floating-promises

143:23 error Unsafe member access .message on an any value @typescript-eslint/no-unsafe-member-access

serviceWorker.ts

type Error = {
  message: string;
};

//   warning  Missing return type on function @typescript-eslint/explicit-module-boundary-types
// functionからconstの書き方に変えた
export const unregister = (): void => {
  if ('serviceWorker' in navigator) {
    navigator.serviceWorker.ready
      .then((registration) => {
       //  error    Promises must be handled appropriately or explicitly marked as ignored with the `void` operator  @typescript-eslint/no-floating-promises
　　// 何も指定しないと返り値が any になってしまうので何か明示しましょうねというエラー（らしい）
        void registration.unregister();
      })
       // テキトーに型をつけてあげた
      .catch((error: Error) => {
       // error    Unsafe member access .message on an any value @typescript-eslint/no-unsafe-member-access
       // テキトーに型をつけてあげた
        console.error(error.message);
      });
  }
};

6:9 error Unsafe assignment of an any value @typescript-eslint/no-unsafe-assignment

7:9 error Unsafe assignment of an any value @typescript-eslint/no-unsafe-assignment

7:23 error Unsafe call of an any typed value @typescript-eslint/no-unsafe-call

全体的にVSCodeで宣言先をみて型をつけてあげた。

// eslint-disable-next-line @typescript-eslint/no-unsafe-assignment にしている部分は、試行錯誤した結果ライブラリの型はどうしようもなかったからこうした。

App.test.tsx

import React from 'react';
import { render } from '@testing-library/react';
import App from './App';

interface getByTextFunc {
  getByText: (arg1: RegExp) => string;
}

test('renders learn react link', () => {
  // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment
  const { getByText }: getByTextFunc = render(<App />);
  const linkElement: string = getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});

雑ですみません\( ˆoˆ )/

「アジャイルサムライ達人開発者への道」を読みました。

今回は、「アジャイルサムライ達人開発者への道」を読みました。

アジャイルサムライ――達人開発者への道

なぜ読んだのか

• EMにおすすめされたので！
• スクラムの元となるアジャイルの考え方について楽しく学びたかったから。

対象読者

• どんな人でも

• エンジニア初級者にとっては、プロジェクトを進めるにあたって持っておきたい心構えを非常に多く学ぶことができると思います。
• エンジニア中級者・上級者にとっては、初心に返るのにとてもいいと思います。

この本で学べること

• アジャイルプロジェクトの準備とキックオフをうまくやる方法。プロジェクトの意義や目的をはっきりさせ、誰のために何をするのか明確にする。

• 要求を集めて、見積もり、計画を立てる方法。それもわかりやすく、風通しよく、誠実なやり方で。

• ものすごい勢いで成果を上げていくための手法。プロジェクトを手入れの行き届いた機械のようにして、質の高いリリース可能なコードを生み出し続けられるようになるためにはどうすればいいか。

序章

「アジャイル」はフレームワークであり、心構えであり、ソフトウェアを無駄なく、早く届ける手法であるとのこと。

第１部 「アジャイル」入門

第１部では、アジャイルなソフトウェア開発の全体像と、アジャイルチームがどう機能するかを説明します。

第１章 ざっくりわかるアジャイル開発

• お客さんにとって「価値ある成果」とは何か

それは「毎週動くソフトウェアを届ける」こと

• 毎週価値ある成果を届けるために大切なこと

①大きな問題は小さくする
　毎週成果を届けられるように。
②本当に大事なことに集中して、それ以外のことは忘れる。
　ドキュメントや実施計画書はあくまでも動くソフトウェアを補完するものでしかない。
③ちゃんと動くソフトウェアを届ける
　そのために、こまめにテストする
④定期的にお客さんからフィードバックを求める。
　間違っていたら軌道修正するために。
⑤必要とあらば進路を変える。
　プロジェクトではいろんなことが起こるので、計画を柔軟に変更する。
⑥成果責任を果たす
　彼らの資金の使い道を示すことができたら、成果責任を果たしたことになる。

• プロジェクトの3つの真実

1. プロジェクト開始時点に全ての要求を集めることはできない
2. 集めたところで、要求は必ずと言っていいほど変わる
3. やるべきことはいつだって与えられた時間と資金よりも多い

第２章 アジャイルチームのご紹介

第２章は、「アジャイルなチームとはどんなチームか」についてです。

アジャイルチームは肩書きも役割も関係なく、分析、設計、実装、テストといった開発工程が途切れることなく続くということは良く知られていると思います。
でもそれ以上に、"責任"という言葉がたくさん出てきました。プロジェクトを他人事とせず、自分のこととして、責任を持って成果を出していける人。改善案を出していける人。そんな人がアジャイルなチームには必要なんですね。

第２部

第２部は、便利なツールやフレームワークの紹介です。

第３章　みんなをバスに乗せる

プロジェクトが失敗する理由は、主にみんなのゴールやビジョンがあってないから。
それを合わせるために、インセプションデッキというものを使用する。

第４章　全体像を捉える

さらにビジョンを明確にしていくために、エレベータピッチやパッケージデザイン、やらないことリストなどを作っていきます。コラムにあった、「エンジニアが実際の現場に行ってその地域にあった車を作った」といういい話も印象的でした。

第５章　具現化させる

3章と4章で「なぜここにいるのか」ビジョンのすり合わせができたので、5章では「どうやって実現させるか」をみていきます。

• リスクと向き合う

実現させるにあたって、まずはじめにやることは、「リスクとの向き合い方」です。
チーム内でリスクについて認識合わせを行い、予め手を打っておくことです。

• 荒ぶる四天王（時間、予算、品質、スコープ）との向き合い方

どれも最優先にはできないので、スコープを諦めてもらう場合があること、優先順位が同じになるものを作らないこと。
スコープ設定や計画に何ヶ月も時間をかける必要はないことなどが書かれていました。

第３部

アジャイルな計画づくりの基礎を扱います。ユーザーストーリー、見積もり、それから現実に合わせて変えられる計画の立て方を解説します。

第６章　ユーザーストーリーを集める

６章は、ユーザーストーリーについてでした。

• 文章よりface-to-face

- ユーザーストーリーはお客さんにわかりやすいように
データベースにコネクションプールを導入する→現状の10秒かかるページの読み込み速度を2秒まで縮める

• 制約をつける

ウェブサイトはサクサク表示する→サイトのページはどれも2秒以内に読み込めること

第７章 見積もり：あてずっぽうの奥義

７章は見積もりについてでした。

• 見積もりで欲しい答えは一つ

このプロジェクトをやり遂げられるのか？

• 仕事のサイズがどれくらいの大きさなのか

基準より大きいか小さいか「相対サイズで見積もる」のがアジャイル見積もりと計画作りの真髄。

• プランニングポーカー

> 1人の専門家より、複数の素人の平均の方が正しい（！）という研究結果もある。

やり方：
1 顧客がストーリーを読み上げる
2 開発チームが見積もる
3 開発チームで議論を重ねる
4 再び開発チームが見積もる

第８章 アジャイルな計画づくり：現実と向き合う

８章は、現実と向き合う方法です。

• 時間が足りないときは

いつまでも最初の計画に執着しない。やることを減らすのがアジャイルチーム。

• マスターストーリーリスト

プロジェクトでこなすべきToDoリストのこと

• リリースを定義する

チーム内でリリースの定義を決めておく

第４部

プロジェクト運営。立てた計画を、お客様が実際に使えるソフトウェアとして具現化するための作戦を学ぶ。

第９章　イテレーションの運営：実現させる

• テストは開発と一緒

　プロジェクトの最後にならないと全体として動作するかわからない状況に甘んじない

• ユーザーストーリーの詳細は、必要な分だけを、必要なときに分析する

• カンバン

　プロジェクトの進行状態を"誰でも"把握できるツール。

• ”価値のあるプロジェクト”

　分析、開発、テストといった作業を一つにまとめあげてこそ。

第１０章　アジャイルな意思疎通の作戦

• ストーリー計画ミーティング

　これから取り組むストーリーの準備が整っているか、顧客と一緒にストーリーの準備が整っているか確かめる。開発チームが見積もりの数値を確認したりするのもこのタイミング。

• イテレーション計画MTG

　開発チームと顧客が一緒になって次回のイテレーションの作業を計画する。ベロシティを確認し、次に取り組むストーリーを整理する。

• デイリースタンドアップ

　昨日やったこと、今日やること、困っていることを毎日チームに共有する。10分くらいに収めるのがコツ。

• 建設的にフィードバックするコツは"だけど" と言う言葉を避けること。

第１１章　現場の状況を目に見えるようにする

• 状況を見えるようにしておくには

　ストーリーボード、リリースボード、ベロシティとバーンダウンチャート、インセプションデッキなどがあればOK

• 共通の言語

　プロジェクトで使う言葉を共有する。開発チームも顧客もわかる言葉を使う。
「エリック・エヴァンスのドメイン駆動設計」を読むこと。

第５部　アジャイルなプログラミング

第１２章　ユニットテスト：動くことがわかる

• ユニットテストがあれば、プロダクトに変更を加えても期待どおりであることを確認することができる。

• 変更を加えるたびに手動でシステム全体のリグレッションテストを実行する手間が省ける。

第１３章　リファクタリング：技術的負債の返済

• 技術的負債は気づいたら背負っている。そうなる前にこまめにリファクタリングする習慣をつけておく。

• 大掛かりなリファクタリングはするべきでないときもあるが、それ以外はいつでもリファクタリングするべき。

第１４章　テスト駆動開発

• テスト駆動開発をする。

　ルール１：失敗するテストを一つ書くまでは新しいコードを一切書かない。
　ルール２：「危なっかしいところ」を全てテストする

• 既に実装されたコードがあると考えながら、先にテストを書くと良い。

第１５章　継続的インテグレーション：リリースに備える

• ビルド時間は10分以内に留めるのが望ましい。

• ビルドを大切にすること。ソフトウェアはいつも動くようにしておこう。

• リリースに備えるとは、心構えのこと。今日書いたコードは今日テストしてリポジトリに統合する。バグがあれば即座に直す。「あとで直す」と先送りにしてはダメ。

感想

ずっと読んでみたかった名著、アジャイル・サムライ読み終わりました！

プロダクト開発の本質を突きながら、所々ユーモアがあって楽しく読み終わることができました。いやー... 2年前に読みたかったです。
先日「アジャイルな見積もりと計画づくり」という本を読んだのですが、それよりももっと"概念"というか、抽象的なアジャイルのお話でした。

エンジニアになったばかりの人は必ず読んでおいた方がいい本だと思います。

「もっと細かいことわからないと見積もりできないよ！」
「時間がないからリファクタリングは後にしよう」
「テストも後にしよう...」
「CIってなに？よくわからないけど、動いてるからヨシ」
「え！？そんな機能あるなら早くいってよ！」
「このコード、どっから変更したらいいんだ...」

全部私が今までの開発で通ってきた失敗でした... orz
もし、私が2年前にこの本を読んで多少なりともアジャイルの考え方を理解していたなら、もう少し良いアプローチ方法や問題への対処法を考えらえたはずです。

それにしても、アジャイルな考え方って素敵ですよね。この世の仕事って、なかなかアジャイルな考え方で進められる内容の仕事って少ないと思います。
これからどんな新しい機能ができて、どんなコードにしておけばいいかなんて誰にもわからない。
そんなこれから起こる未来にできるだけ対処していくための先人たちの知恵って、めちゃくちゃかっこいいですね。

色々書いてありましたが、一番大切なことは「顧客にとって本当に価値のあるプロダクトを安定して届ける」ということですね。
いろんな事情があると、だんだんと忘れがちになってきますが、このマインド（User Firstな気持ち）を忘れずにこれからも開発に取り組んでいきたいと思います。