一から勉強させてください

最下級エンジニアが日々の学びをアウトプットしていくだけのブログです

マイクロサービスをやっていく上で参考にしたい記事

Microservices

ブログ納めとしてマイクロサービスをやっていく上で参考にした(い)記事をざっくりまとめました。

現状、がっつりマイクロサービスをやっているわけではないけれど、考え方を取り入れたりはしているし、来年の今頃はどこかでがっつりやっていったりもするかもしれない。

記事一覧

James Lewis/Martin Fowlerの"Microservices"日本語訳

THE マイクロサービスとは、的な記事。ここから全てが始まった...(本当か？)

リンク: https://kimitok.hateblo.jp/entry/2014/11/09/211820

"Microservices"を読んだ

上述の"Microservices"を読んだ後に読むと整理されそうな記事。

リンク: https://deeeet.com/writing/2014/09/10/microservices/

マイクロサービス運用の所感 #m3dev

エムスリーさんのマイクロサービス所感。

リンク: https://www.slideshare.net/seratch/microservices-ops

Microservices Architect in DMM Platform

マイクロサービスアーキテクトの話、アーキテクチャ全体の設計から組織設計など網羅的に役立ちそうなことが書かれている記事。

リンク: https://inside.dmm.com/entry/2021/12/05/microservices-architect-in-dmm-platform

マイクロサービスにひそむ複雑さに立ち向かう

より現場の生々しいマイクロサービスを想像できる記事。

リンク: https://qiita.com/behiron/items/017b12ee7ffa6dfeb254

マイクロサービス分割点の見つけ方

経験に基づいてどうやってマイクロサービスの分割点を見つけるかが書かれていて助かる記事。

リンク: https://lab.mo-t.com/blog/extracting-microservices

絵で見てわかるマイクロサービスの仕組み

これは記事じゃないけど、図が多くて良本の予感がしたのでついでに載せる。

絵で見てわかるマイクロサービスの仕組み

絵で見てわかるマイクロサービスの仕組み

Amazon

まとめ

我々の間にマイクロサービスなどという都合のよい言い訳は存在せん。 あるとすればスタンドプレーから生じるマイクロサービスだけだ

経験学習とYWTをベースに、持続可能な個人の振り返り手法について考えてみた

振り返り YWT

チーム開発を行う際、スクラムのような手法に準拠し、レトロスペクティブでKPTなどで振り返りを行うことが多いと思います。良かったこと、良くなかったことを振り返って、TRYするアクションを決め、次のスプリントに活かし、また評価するサイクルを回す感じでしょうか。

これを個人でも継続的にやっていきたいと考えているのですが、闇雲に振り返りをしてもあまり効果を感じられないし、KPTも個人でやるとなるとあまりしっくり来ません。わざわざ時間をとって自分のPROBLEMを列挙するのは辛いです。

そこで今回、経験を学びに変え、次に活かすためのフレームワークである「経験学習サイクル」の考え方や振り返り手法の一つである「YWT」を取り入れて、持続可能な個人の振り返り手法について考えてみました。

経験学習について

経験学習の概要を学ぶ上で良さそうだった「職場が生きる 人が育つ 「経験学習」入門」という本をベースに簡単に内容をまとめておく。

職場が生きる 人が育つ 「経験学習」入門

職場が生きる 人が育つ 「経験学習」入門

Amazon

経験学習サイクル

経験学習サイクルは以下の4ステップを回す。

  • 具体的経験をする
  • その内容を「内省（振り返り）」する
  • そこから教訓を引き出す
  • その教訓を「新しい状況に適用する」

ただし、このサイクルを単純に回すだけでは不十分で、「よく考えられた実践」の中でサイクルを回す必要がある。

よく考えられた実践とは以下。

  • 課題が適度に難しく、明確であること
    • 難しいけど懸命に手を伸ばせば届きそうな目標を持つ
  • 実行した結果についてフィードバックがあること
    • 実施した結果、どこが良くてどこが悪かったかについての情報を得ることができる
  • 誤りを修正する機会があること
    • それを次の機会に活かすことができるような練習や仕事のやり方をする

経験から学ぶための三つの力

経験から学ぶためのベースとなる三つの力が以下。

  • ストレッチ
    • 高い目標に向かって挑戦する姿勢
  • リフレクション
    • なにかアクションを起こしている最中やアクション後に、何が良くて何が悪かったかについて振り返ること
  • エンジョイメント
    • やりがいや意義を見出して仕事を楽しむこと

またそれぞれの方略は以下であると述べられている。

ストレッチの方略

  • 挑戦するための土台を作る
  • 周囲の信頼を得てストレッチ経験を呼び込む
  • できることをテコにして挑戦を広げる

リフレクションの方略

  • 行為の中で内省する
  • 他者からフィードバックを求める
  • 批判にオープンになり未来につなげる

エンジョイメントの方略

  • 集中し、面白さの兆候を見逃さない
  • 仕事の背景を考え、意味を見出す
  • 達観して、後から来る喜びを待つ

その他、自分や他人への思いについてや啓発者とのつながりの大切さについても述べられていたが、ここでは割愛する。

また本題とは外れるのだが、紹介した書籍でOJTに関して言及している章があり、これは後輩や部下を持つ全ての人にとってとても参考になると思うのでぜひ読んでみてほしい。

YWTについて

YWTは、振り返りのために「日本能率協会コンサルティング」が提唱し日本で開発されたフレームワークです。Y（やったこと）、W（わかったこと）、T（つぎにやること）の日本語の頭文字をとって名付けられました。経験したことを思い出してから次の段階に進むので、問題点だけでなく良かった点も認識できる手法です

YWTの概要についてはこちらの記事を参考にさせてもらった。

経験学習の本からも感じられたが、成功したこともしっかり振り返ってそのエッセンスを言語化し、再現性を持たせられるようにするのが重要だと思う。

そのため個人的にはKPTよりも、「Y -> W」の過程で自分が具体的に経験したことから教訓やエッセンスを言語化し、次に活かせそうな雰囲気のあるYWTはしっくり来る。これは経験学習サイクルのプロセスとも合致する。

というか自分が無知なだけで、経験学習サイクルを回す目的でYWTが誕生した説あるな…

YWTはシンプルなのでシュッとできそうな予感はあるが、こちらの記事で言及されていた点に注意しなければならないと思った。

Y (やったこと)を挙げる際のポイント

  • 客観的に事実を記載していく
  • 自分の主観や感想は切り離す
  • 良いことだけでなく、悪いことも記載する

W (わかったこと)を挙げる際のポイント

  • やったことを通じて感じたこと、考えたことを書いていく
  • 「わかったこと」という言葉で勘違いしがちだが「考えたこと」を挙げる
    • 「xxという技術で開発をした」というYと、「xxという技術についてわかった」というWになるような浅い振り返りでは意味がない
    • その開発という仕事を通じて、自分は何を考えたのか、どのように次の行動が変わるのか、を考えるべき
  • 「どうしてそう考えたのか？」「経験を通じた変化は何か？」「他の人に伝えるには？」「今回の得られた学びは何か？」といった問いを立てることで、抽象化と言語化を促す

T (つぎにやること)を挙げる際のポイント

  • 「次にやること」を考える際に重要なのは論理性
    • せっかくの実績と考察をYとWとして出したにも関わらず、まったく関係のないことをTとして挙げてもうまく行かない

振り返りのやり方

経験学習サイクルとYWTの考え方、コツをざっくり学んだ上で「俺が考える最強の振り返り手法」を確立してみる。

ただ、ここまで色々言っておいて何なんだが、結局シンプルにTrelloで毎週YWTをやってみようというものになってしまった。Trelloに個人用YWTボードを用意し、workとprivateのラベルぐらい用意しておいて、毎週ひたすらYWTをするだけである。だがYWTする際はちゃんと経験学習サイクルや前で取り上げたYWTのポイントを意識するようにする。

Y

  • 仕事、プライベートでやったことを最低1つずつ出す
    • 頑張りすぎるとW以降がしんどくなり続かなくなるので、特に振り返っておきたいYに厳選して行う
  • もちろん悪かったことも含める
  • 仕事、プライベートそれぞれラベルぐらいはつけてカードを作成する

W

  • 「○○についてわかった」「○○完全に理解した」みたいな浅い振り返りは禁止
  • Yに対して、抽象化や経験学習を促す問いを立てる
    • ストレッチ、リフレクション、エンジョイメントの観点でアクションできていたか？
    • 「どうしてそう考えたのか？」
    • 「経験を通じて起こった変化は何か？」
    • 「他の人に伝えるには？」
    • 「得られた学びは何か？」
  • 上記問いを参考にカードを作成し、箇条書きでも良いのでdescriptionも必ず書くようにする

T

  • 最低1つ出す
    • 良かった点に対しては継続できるようなアクションを考える、もしくはよりストレッチなチャレンジを宣言する
    • 悪かった点に対しては改善案を考える

あとはGoogleカレンダーなどで週次のYWTイベントが通知されるようにしておけば準備完了。やっていくのみ。

まとめ

経験学習サイクルに関してざっくり学んだ結果、「これ要するにYWTでは？」という結論に至り、結果、個人でYWTを運用することになりました。効果があり、かつ頑張れば続けられそうなギリギリを攻めた感じです。

ただおそらく以前から課題に感じていた、具体的な振り返り方、振り返り時の問いの立て方の精度は上がったように思います。

またプライベートや仕事のラベルをつけるTrelloの運用が地味によいなと思っていて、プライベートでやったこと、わかったことが仕事に活きているのが見える化するともっとやろうという気持ちになれたりします。

やはり振り返りは難しいですね。皆さんが考える最強の個人振り返り手法、ぜひ教えてください。

参考

Dockerとplantuml-serverを使ってPlantUMLの実行環境を用意する

Docker plantuml

手軽に PlantUML をいじれる環境が欲しかったけど、軽く調べた結果、Mac での環境構築が悩ましかった。

色々検討した結果、ひとまず Docker で環境構築する方法をとった。

候補

  • ローカルでbrew install graphviz, brew install plantumlする
    • 変な依存ライブラリとかめっちゃ入れられそうなので、できればgraphvizをローカルに入れたくない w
  • PlantUML Viewerを使う
    • 悪くなさそうだったが、試しにいれてローカルのファイルを開いてみたが CORS っぽいエラーが出て面倒そうなのでやめた
    • Chrome ウェブストアのレビューでもDoesn't work at all.って言ってる人いたので最近の Chrome のアップデートで死んだのかな
  • plantuml-serverを使う
    • Docker の image があるので一番手軽に使えそうだし、軽く PlantUML を書いて UML を確認できれば十分だったのでこれを使うことにした

環境構築

Vim

Vim を使っているので PlantUML を書く用に plantuml-syntaxだけ入れておいた。他のエディタを使っている人も何かしらシンタックス用のプラグインはあるはず。

Docker

上記の plantuml-server 用の image が公開されているのでシンプルにそれを使う。こんな感じ。

# docker-compose.yml

version: '3.7'

services:
  plantuml-server:
    image: plantuml/plantuml-server
    ports:
      - 8080:8080

あとは docker-compose upして open http://localhost:8080すれば PlantUML の実行環境が手に入り、サクッと UML を確認できる。

まとめ

とりあえず Vim で PlantUML 書いて、ローカルで plantuml-server を立ち上げてコピペで UML 確認できるようになった。若干スマートさに欠けるけどまあいいかという感じ。

エンジニアの自分がインプットのためによく聴いているPodcastの番組まとめた

Podcast 英語 プログラミング 勉強法 ビジネス

最近はなにがし.fm みたいな番組がめっちゃ増えてきましたね。

普段、移動時間やジョギングする時とかに Podcast をよく聴いているけど、何をどういう目的で聴いているか自分で整理するためにもジャンル別に聴いている番組をまとめてみました。

Tech 系

Rebuild

  • 言わずもがなの番組、まだ番組が乱立してなかった頃からずっと聴いている
  • 話題になった Tech 系の話題や最新情報をキャッチアップできて良い
  • 最近はガジェットだったりコンテンツ系の話題が多い気がするけど、新しい言語とか新しい技術、マネジメント等について議論してる回は特に面白い
  • 英語回は英語の勉強も兼ねて死ぬほど繰り返し聴いた

fukabori.fm

  • マネジメントや開発組織、アジャイル系の話題など、個人的に好きなトピックを多く扱ってくれるので好き
    • これとかめっちゃ勉強になる
    • これも何回も聴いた

EM.FM

  • これもマネジメントとかキャリア考える上で参考にしている
    • 1on1 とか、プロダクト開発とか、エンジニア評価についてとかトピックがめっちゃ刺さる
    • この回とか好き

Misreading Chat

  • CS みが強すぎて完全に理解できない時もあったりするけど、面白いので結構聴いてる
    • 特に言語の歴史振り返る系
      • これめちゃめちゃ好き
    • 個人的に Rust 好きなので、Rust 関連の回とかも

The Changelog

  • Go とか Rust とか GraphQL とかイーサリアムとかトピックが個人的に刺さりまくることが多いのでチェックしてるけど、ガチの英語なので聴く頻度は少なめ
    • めちゃめちゃ集中しないと聴き取れないので元気な時だけ聴く
      • 集中しても全然聴き取れない
    • Go の Rob Pike がゲストで来てたりでアツい
  • 余談だけど、公式サイトは Elixir でできてる

hidek のエンジニアと長話

  • Podcast 枠に入れてよいかわからないが、stand.fm もたまに聴いていてその中でもこの番組が好き
  • 他の Podcast 番組にはあまり出られていないような著名な方がゲスト出演されていたりして面白い

y_matsuwitter 相談部屋

  • こちらも stand.fm から y_matsuwitter さんの相談部屋、トピックがエンジニアリングから経営、生産性、勉強法など自分が好きなものが多い
  • 1エピソードが5分程度なのでさくっと聴きやすい、特に良い回を何回も聴く

ビジネス系

前田ヒロ Startup Podcast

  • SaaS 界隈のスタートアップに投資されている前田ヒロさんの Podcast、SaaS 系のゲストや話題多め
  • 個人的にも創業期のスタートアップにいた期間がキャリアの中で圧倒的に長いので、トピックが刺さりまくる
    • ゲストの起業家の方々のマインド、考え方、失敗談などをインプットしまくれるので高まる、よい
  • 2021 年2月現在、もはや Tech 系の番組よりもよく聴いているかもしれない
  • この回とかめっちゃ面白い、URLからしてSUGOI

ゼロトピック

  • 10X Yamotty さんの Podcast
  • こちらも起業家の方やスタートアップみの強い方の経験談や考え方をインプットできて楽しいのでチェックしている
  • プロダクト開発みたいな観点でもめちゃめちゃ参考になる
    • 自分はスタートアップが長いエンジニアなので、こういう回は特によさを感じてしまう

その他

バイリンガルニュース

  • 上述の Rebuild でもたまに話題が上がっていて、英語学習のためにチェックするようになった
  • 話題もわりとテック系多めで英語と日本語が混ざっているので、フル英語の番組より気軽に聴けてよい
    • 英語の学習抜きにしても面白い内容
  • Mami さん、帰国子女とかではないのにあのレベルなのヤバすぎる(参照)

まとめ

今後も面白い番組を発見したら更新していきたい。

「初めてのGraphQL」を読んでサンプルアプリをTypeScript + React + typeorm + type-graphql + graphql-code-generatorで作ってみた

GraphQL TypeScript

最近、GraphQL を勉強するために「初めての GraphQL」という本を読んで、理解のために自分でも本の中で実装されているサンプルアプリを作ってみました。

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

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

Amazon

作ったのがこれ: https://github.com/danimal141/learning-graphql-ts

ただ写経するだけだとしっかり理解できない + 面白くないので本は雑に読みつつ、色々と魔改造しながら作ったのでそのメモを残しておきます。

全体

  • 本のサンプルアプリは JavaScript で書かれているが、全て TypeScript で書いた
    • GraphQL がせっかく型システムを持っているのだから実装側も型がほしい
  • ディレクトリ構成は Monorepo で yarn workspaceを使ってバックエンドとフロントエンドの package を良い感じに管理できるようにした
  • npm-run-allを導入してコマンドをパラレルでコマンド一発で実行するようにした
    • バックエンド、フロントエンド、GraphQL のスキーマを元に型を吐いてくれるやつとか色々立ち上げるやつがいたので
  • lint-stagedとhuskyを使って、コミット時に Prettier をかませるようにした
  • その他、ESLint などは適当に入れた
  • テストはだるかったので書いていません、すみませんすみません

Backend

  • 基本的には本の中で実装されているみたいに express や apollo-server-express を使い、playground 上で GraphQL のリクエストを確認できる感じにした
    • 途中で面倒になったので 本の中で実装されているが実装できていない Resolver とかあるかも
  • Mongo ではなく MySQL を Docker で立ち上げるようにした
  • 使ってみたかったのでtypeormとtype-graphqlを導入して DB と GraphQL のスキーマ定義するようにした
    • type-graphql が勝手にスキーマ吐いてくれるので良い
    • Spring Boot みたいになる
    • 後で気づいたが最近名前をちらほら聞くNest.jsとやらを使ってみても良かったのでは...？と思い始めている
  • あまりよく理解せずノリで使っていたが、途中で typeorm が Migration 機能持っていることに気づき導入してみた (最初は synchronize: trueで乗り切っていた)

Frontend

  • create-react-appを使って TypeScript のアプリのベースを作った
    • 途中で面倒になったので作ったのはユーザ一覧表示とユーザログイン部分機能だけ
    • 本の中の React はちょっと古い感じだったので Hooks を使いまくってモダンっぽくした
  • graphql-code-generatorを導入して、バックエンドで type-graphql が生成したスキーマを元に型ファイルを生成するようにした
  • クエリを投げまくるのを気にして、なるべくルートのコンポーネントがクエリを組み立ててリクエスト -> 子コンポーネントはフラグメントで欲しい情報を宣言し、レンダリングするみたいなのを意識した (Fragment Colocation と言う？ 参照）
    • 実際には Mutation でクエリの再フェッチがあったり、そもそも実装したコンポーネントがほぼ無いのであまりうまくできていない...
    • 仕事で Next.js + GraphQL を使った時にも意識したやり方だけど、pages でクエリを組み立て、pages を構成する各コンポーネントで必要な情報を Fragment で宣言するみたいにすると、リクエストも最低限になりまあまあキレイな設計になるのではないかと思っている (GraphQL 歴 2 ヶ月の意見です）
  • ログインする所は初めて Mutation をフロントエンドで実装したので若干悩んだ
    • 本の中ではMutationコンポーネントとか使ってたけど、Hooks で書き直した時にuseMutationが variables 空で呼ばれてしまってエラーになったりしてちょっとハマった

まとめ

  • GraphQL と TypeScript は良い感じに型システムを使えるので相性かなり良さそう
  • typeorm は悪くないけど、個人的には正直 ActiveRecord のほうが早く実装できる
    • Rails ヤメラレナイ...

参照