Hikaru Wada

くるくまカフェ#RailsはじめにRails で悲観的ロック（排他制御）を行った際に、それを Minitest のテストコードで確かめる機会があったので、簡単に紹介します。Rails で複数のリクエストが同時に処理される場合、データ競合が発生する可能性があります。悲観的ロックは、同時に1つのレコードに対して2つの更新リクエストが来た場合に、1つ目の処理が終わってから2つ目の処理が開始するようにして、競合を避けるようにする排他制御メカニズムです。Railsでは ModelName.with_lock do end などを用いて処理対象となるレコードをロックすることが可能です。きっかけは、とあるリクエストがエラーを吐いたことでした。そのリクエストでは、いくつかのモデルを作成するのですが、複合ユニーク制約が貼られています。エラーの内容を見てみると、ユニーク制約に違反するDBのデータ挿入エラーでした。原因を調査したところ、同一のエンドポイントに対して同一のリクエストが複数回連続で発生した場合に、後続のリクエストが失敗するという内容でした。その後の調べで、トランザクションは貼っていたものの、悲観的ロックがされておらず、ボタンにも連打対策がなされていなかったことが原因でした。テストを書くテストコードを書いてエラーが起こることを再現して、悲観的ロックをかけた上でテストがパスしたことを確認してみたいと思います。例えば以下のように Parallel gem を使うと簡単に非同期で複数回の処理を呼び出すことができます。code:parallel_test.rb require 'parallel'  test test_pesimistic_lock do   Parallel.each(1, 2, in_threads: 2) do     # 処理を実行するコードを書く   end endこのコードは、Parallel gem を使って、1 と 2 を要素とする配列の要素に対して、それぞれ別スレッドで処理を実行します（1と2そのものに意味はありません）。しかし、実際にこれでテストを回してみても、ブロック内部の処理のトランザクションが並列に実行されません。Minitestは各テスト実行時にトランザクションを張り、テストの終了時にロールバックを行うようになっており、これがテストが意図通りに動かない原因となっています。そこで、テストクラスに下記のコードを追加します。対象のテストクラス内で張られるトランザクションを無効にします。code:disable_transaction self.use_transactional_tests = falseその後、テストを実行します。この時、トランザクションを無効にしたテストは実行後、データベースが初期化されない（ロールバックされない）ため、DBのレコードを空にする必要があります。まとめてコマンド実行すると良いでしょう。code:run test rails db:migrate:reset RAILS_ENV=test & rails t path/to/test_file.rb:{テストメソッドの行番号}もし書いたテストコードを永続的に残しておきたい場合は、テストクラスを分けた上で、テストコードのセットアップでデータを空にする処理を書いておくと良いでしょう。参考 https://tech.hitomedia.jp/entry/2018/03/16/120249 https://zenn.dev/shuhei_takada/books/3ff66325f45adc/viewer/2bf43c#%E6%82%B2%E8%A6%B3%E7%9A%84%E3%83%AD%E3%83%83%E3%82%AF%E3%81%A8%E3%81%AF

Rails で Minitest を使って悲観的ロック（排他制御）をテストする方法

湯の山温泉 グリーンホテル#フルリモート #スクラム #モブプロ #モニクルはじめに2020年4月にモニクルに入社してから4年が経過しました。今回は、フルリモート環境、モブプロ、スクラムの3つの観点から、これまでの経験を振り返ります。フルリモート入社当初はコロナ禍の影響でフルリモートでの勤務が始まりました。当初はアフターコロナの時期が訪れたらある程度出社することも検討していました（とはいえ、たまに会いたいねくらいの温度感でした）が、半年後にはメンバーが各地域に散り散りになりました。かくゆう私は一番最初に東京から飛び出したメンバーの一人でした。当時の行動は勇足だったかもしれませんが、一ヶ月後にはCTOの塚田さんも北海道へ引っ越したことを考えると、おそらくあのタイミングで会社としてフルリモートでやっていくぞという覚悟が生まれた気もするので良かったのかなと思います。モニクルのフルリモート環境が成功している要因としては、経営陣のフルリモートに対する理解やプロダクトの迅速な改善やデリバリーを行い成果を示し続けていることもありますが、一番良いのは全員が毎日ビデオ通話アプリを立ち上げて顔が見える状態を基本としていることだと思います。常に顔を確認しているわけではありませんが、相手の表情ひとつで情報を読み取ることができたり、相手がそこにいる安心感があります。また、Gatherを使っていつでも誰でも同期的にやり取りができる状態を作っています。オンラインでも、雑談を含めたコミュニケーションが活発に行えるのはこのような文化があるからだと思います。今後はメンバーが増えていく中で、ある程度チームを横断して交流を深めたり、チーム間の良いところを共有して高めていく作業も必要になってくると思います。モニクルでは留学制度を導入したり、スクラムマスター同士の交流を経てその壁を乗り越えるための試みをしているところです。この辺りの試みについてはまた別の機会に。モブプロモブプロは、新メンバーがチームの一員としてすぐに活躍できるように、密度の高いコミュニケーションを促進します。リアルタイムで議論を行いながらコーディングを行うことで、すぐにドメイン知識を理解し、チームに溶け込むことができます。モブプロによるオンボーディングと最初の作業のことを「知の高速道路」と呼んでいます。入社当時はAndroidネイティブアプリ開発を得意とするソフトウェアエンジニアだった私ですが、モニクルではRailsやReactをベースとしたWeb開発が中心でした。不安を抱えていましたが、短期間でモブプロを通じて必要な知識を習得することができました。ドメイン知識についても同様です。今振り返ると、温かくサポートをしてくれた当時のチームメンバーには本当に感謝しています。現在も、新メンバーはモブプロから開発をスタートしています。しかし、モブプロ一辺倒で開発を進めるわけではなく、常にモブプロへの考え方に対するディスカッションを行いながら、柔軟に動いてより良い開発ができるよう努めています。スクラムを頑張った入社当初は、右も左もわからない状態の中で、とりあえずJiraやスクラムという開発スタイルを導入しました。当時は開発に必死で、正解もわからず、十分に機能させることはできていませんでした。それなりに開発は進むものの、初期の開発スタイルはCTOの塚田さんがリーダーシップを発揮して前に進めてくださったことが大きかったです。日々エンジニアとして仕事をする中で、次第にチームビルディングへの興味が湧いてきました。自分の力だけで生産性を50から100にするよりも、チームメンバー全員の生産性を引き上げることができれば、トータルとしてより大きな成果を生み出すことができると考えたのです。そこで、スクラムマスター研修に参加することにしました。研修を通して、スクラムの本質や、より効果的な運用方法について学ぶことができました。この時すでに入社初期と比べて組織も大きくなっていましたが、チームメンバーの安定化と複雑化を防ぐための仕組み作りが進められていき、取り組みやすい環境でした。現在、スクラムマスターとして以下の点に意識して取り組んでいます。 スプリントゴール達成へのサポート  チームメンバーが力を発揮し、スプリントゴールを達成できるよう、最大限のサポートを行います。 スクラム学習のための機会の創出  チーム全体でスクラムの考え方や手法を学び、より効果的に活用できるよう、読書会を開催しています。今は必ずしもスクラムに拘った選書をしているわけではありませんが、それ以外でも定期的に話し合うようにしています。 メンバーとの交流  各メンバーと1 on 1をしたり必要に応じてイベントを見直し、チーム内で改善が進むように小さな変更を取り入れながらふりかえりを進めています。まだまだ難しいなと思うことがたくさんありますが、今後も改善を進めていきたいです。終わりに最近、最近入社されたチームメンバーと話をする中で気づいたことがありました。それはモニクルにとって当たり前のことは、前職では当たり前ではなかった、ということです。思えば私自身も前職では当たり前でなかったことが山のようにあります。4年も経つと流石に慣れてしまい、忘れてしまった思いが、他のメンバーから思い起こされることがありました。4年間のふりかえりでは、そのような当たり前が他の会社やチームでは当たり前ではないかもしれないということを念頭におきながら、ぎゅっと凝縮して紹介させていただきました。今後も引き続き小さな改善を繰り返して組織にとって良い文化を作り上げていきたいと思います。ちなみに、このエントリは三重県の湯の山温泉グリーンホテルにて書いています。露天風呂が広く、とても気持ちよかったです。名湯百選にも選ばれています。では、また。

モニクルにジョインして4年が経ちました

大稻埕#台湾 #ワーケーション #モニクルはじめに弊社モニクルでは、全員が各地各国に居住し、フルリモートワークで働いています。（※内容は少し古いです）私自身は元々2020年10月より台湾の台北に居住していました。しかし、3年が経過したところで新たなライフスタイルを求め、日本へ帰国しました。3年ぶりに日本で生活を開始し、わずか3カ月ではありますが、再び台湾へ行ってみることにしました。とはいえ、今回の渡航は前回のように居住するわけではなく、わずか11日間の滞在です。モニクルではワーケーションをすることができます。特に補助がある訳ではありませんが、会社やメンバーに迷惑をかけしないよう事前に報告し、計画を立てれば問題ありません。休暇を取得することも可能でしたが、中国語を話せる私にとって、せっかくの機会なので台湾でのワーケーションに挑戦してみることにしました。どこで過ごすか島国である台湾とはいえ、台北と高雄の間には東京と名古屋間の距離ほどの距離があります。当然のことながら、事前に旅程を立てておく必要があります。私自身はすでに台北での居住経験がありますので、今回はなるべく台北以外の場所で時間を過ごしたいと考えていました。2023年に台湾鉄道で台湾一周を経験した時の記憶を思い返しましたが、台湾東部は都市規模が小さく、移動も便利とは言えません。また、せっかくの機会なので知り合いがいる地域を巡りたいと思い、今回は高雄から台北へ北上することにしました。コワーキングスペースをどう確保するかワーケーションをするには、作業場所の確保が不可欠です。また、宿泊先とコワーキングスペースの距離感（通勤時間）も意識しなければなりません。まずは、コワーキングスペースについて調べました。今回のコワーキングスペース選定地は、高雄、台南、台中、台北の4都市に絞りました。Google検索で「台南 工作空間」などのキーワードを入力すると、コワーキングスペースや比較記事などがヒットするので、それぞれ見ていきます。各都市ごとに時間・料金・場所を比較検討しました。日本と同様に、台湾にも数多くのコワーキングスペースが存在しますが、場所や料金は様々です。ドロップイン利用が不可な場所や、料金体系が不明瞭な場所も存在します。そのような場合は、Facebook MessengerやLINEで直接問い合わせると、詳細な情報を教えてくれる場合が多いです。当初は一つ一つ丁寧にメモを取ることも検討しましたが、早々に条件に合致するコワーキングスペースを発見しました。それがHour Jungleです。Hour Jungleの詳細については、別の記事で詳しくまとめる予定です。台南、台中、台北の主要都市に拠点を構えながら、低価格で快適な作業環境を提供している点が魅力です。各拠点には愛らしい猫が飼育されており、癒されること間違いなしです。スケジュールスケジュール（実績）は以下の通りです。 03月01日（金）  有給休暇を使い、飛行機で桃園国際空港へ  空港から台中へバスで移動  台中市内のホステルに宿泊 03月02日（土）  台中から高雄へバスで移動  高雄市内のホステルに宿泊 03月03日（日）  高雄から台南へ台鉄で移動  台南市内のホステルに宿泊 03月04日（月）  連泊のため、作業用の荷物だけを持って移動  HOUR JUNGLE TAINAN 台南中山館で作業 03月05日（火）  チェックアウトのため、すべての荷物を持って移動  HOUR JUNGLE TAINAN 台南中山館で作業  作業後、台中へ移動しホテルに宿泊    03月06日（水）、03月07日（木）  連泊、かつ独立した部屋を確保したため、自室で作業   WiFiは部屋ごとに用意されていて快適。しかし椅子が固かった 03月08日（金）  チェックアウトのため、すべての荷物を持って移動  ​HOUR JUNGLE TAICHUNG 台中館で作業  作業後、台北へ移動しホステルに宿泊 03月09日（土）  連泊 03月10日（日）  台北市内の別のホステルに宿泊 03月11日（月）  チェックアウトのため、すべての荷物を持って移動  HOUR JUNGLE TAIPEI 台北信義安和館で作業 03月12日（火）  深夜便で日本へ帰国私はいつも旅行の計画を立てるときにWanderlogを使ってまとめています。候補地や移動手段などを金額・URL・メモを残しながらまとめることができて非常に便利です。是非使ってみてください。まとめワーケーションにおいては、作業場所をよく検討する必要があります。ホテルの個室で連泊する場合、ホテルでの作業も可能ですが、場所によっては料金が高かったり、作業環境が整っていない場合もあります。いずれの場合も、代替案としてコワーキングスペースを調査しておくと良いでしょう。また、予期せぬ事態が発生する場合もあります。私の場合は中国語を話すことができ、Hour Jungleにも事前にLINEで連絡していたため問題なく利用できると考えていました。しかし、台中舘においては到着時にスタッフが不在だったため、手続きができず、朝の会議に間に合わないという事態が発生しました。このような想定外の事態が発生する可能性を常に念頭に置いておき、代替案や対応策を検討しておく必要があります。今回私が利用した各店舗とホテルの中には、快適にご利用いただける場所もあれば、そうでない場所もありました。経験を積み重ねることで、徐々に安定したワーケーション環境を構築できると考えています。今後も快適なワーケーション環境を追求していきます。

2024年03月の台湾ワーケーション 記録

ライムリゾート箱根#ライムリゾート箱根はじめに先日、ライムリゾート箱根で認定スクラムマスター研修に参加してきました。研修で感じたことは先日書いた記事をご覧ください。今回は簡単にライムリゾート箱根の様子をシェアします。なお、会議室など一部の設備は未使用です。行き方ライムリゾート箱根に行くためには、小田原駅から箱根登山バスで約40分かけて南仙石原駅まで行きます。その他の手段として、自転車や車で山道、峠道を駆け抜けるという方法があります。私の場合は名古屋駅から新幹線ひかりで小田原駅まで向かい、バスで行きました。ちなみに、施設周辺には何もないので注意してください。コンビニはGoogleマップで徒歩10分のところにありますが山道で車通りも多いのでそこそこ危険です（車があれば問題ないでしょう）。外観ライムリゾート箱根の外観。スロープを抜けて入り口に入ることができます。施設の形は丸みがかった大きな三角形をイメージするとわかりやすいです。建物の中央部は抜けていて、中庭になっています。通常館内を歩く時は三角形の辺伝いに歩きます。1階・研修兼ダイニングフロア玄関を抜けると大きなフロアがあります。奥の長いテーブルはダイニングとして食事をとるときに使用します。さらに奥には研修用のスペースとバーカウンター。手前には暖炉があります。ダイニングから暖炉と玄関を写すとこんな感じ。玄関のすぐそばまでデスクや椅子があります。ちなみに暖炉は実際に薪を焚べて火をつけることができます。冬の箱根はとても寒いので、ここで温まりながらメラメラと動く炎を見るとアガります。研修用スペースです。すり鉢状になっていて、講師が一番下に降りて話をします。ここの長椅子がかなり座りにくく腰が痛くなります。食事食事はビュッフェスタイル。テーブルに並べられた食事を自分で好きなように取ります。ご飯の上に自分で自由に刺身をおける勝手丼が個人的に一番美味しかったです。甘エビ大好きなんですよね…！！お酒のバックログです。BLUE MOONというホワイトエールビールが美味しかったなぁ…。ダントツで減ってますねwこちらはワイン・日本酒です。コインを入れてボタンを押すと蛇口を捻ったかの如く、水ではなくお酒が出てきます。研修では夕食の時間帯に飲み放題になっていました。ちなみに、箱根街道という日本酒がありますが、名前は箱根でも箱根で醸造された日本酒ではないということを後から知りました。隣町の足柄上郡大井町にある、石井醸造さんのお酒です。でも美味しかったです。やや辛口って書いてある通り、ほんのり辛口なので飲みやすい日本酒かと思います。部屋宿泊施設を兼ねているこの施設では、1階と2階に宿泊用の部屋があります。扉は大きいですが、引き戸でオートロックのような設備は備わっていません。この施設では不要でしょう。部屋の手前に洗面・トイレ・休憩スペースがあります。靴を脱いで上がると座敷があります。独特なレイアウトで布団（マットレス）が敷いてあり、4人まで泊まることができそうです。他の部屋は確認できていないため、同じレイアウトなのかどうかはわかりません。研修ではこの部屋を独り占めできたので、中央の机でまとめを書いたりしていました。押し入れのようなベッドルームはやや圧迫感があるため、背の高い方や慣れていない方は落ち着かないかもしれません。私はドミトリーなどに慣れており、逆にめっちゃ落ち着けましたwちなみに、館内着が上下分かれていてとても着心地が良かったです。見た目もいい感じです。CISCOルータが配備されていました。スピードは特に不便を感じない速度で快適でした。スピードテストをするのを忘れました。温泉1階に温泉があります。脱衣所に行くのに中庭を通る必要があるのですが、1月の箱根は超寒くてきつかった…。温泉は、内湯と外湯があります。広くてめちゃくちゃ気持ちよかったです。今回の研修で貸切だったため、内湯も混雑することなくくつろげました。夜、露天風呂に入ると冬の星座「オリオン座」が見えてとても贅沢な空間でした。その他写真に収めるのを忘れてしまいましたが、ランドリー（洗濯機と乾燥機）が無料で使えます。最後に素晴らしい研修施設でした。研修をする際に、ワークショップをしたり、交流を深めるのに最適な場所だなと感じました。ライムリゾートは新潟県の妙高にもあるので行ってみたいなぁ…。それではまた！！ > Xでシェア

ライムリゾート箱根はいいぞ

#CSM #スクラムマスターはじめに2024年1月24日から26日の二泊三日、オンサイト型の認定スクラムマスター研修に参加してきました。私は、モニクルでソフトウェアエンジニアとして主に社内向けのプロダクトの開発をしています。私はスクラムマスターを担当していますが、進めていくにつれて何が正しいのかわからないことが増えていきました。 スクラムをしているつもりだが、ミニウォーターフォールになってしまっている感覚がする スプリントゴールが設定できない ベロシティだけで数ヶ月間の未来予測をしており、リファインメントができていない作業を見積もらなければならない スクラムマスターが何をすればいいのかわからない ふりかえりで良いアイデアが出てこない 作ったものがなかなかリリースできない ステークホルダにマイクロマネジメントされてしまう社内ではスクラムマスター同士の情報交換をする場があり、困った時にアトラクタの書籍やWebの資料を目にする機会が多くありました。その後、アトラクタのメンバーから直接教えていただける認定スクラムマスター研修に参加すると体系的に学ぶことができて良いのではないかということで、参加してみることにしました。印象に残ったこと私が研修に参加した上で印象に残ったことを紹介します。アジャイルな開発が向いている領域現代はソフトウェア・ハードウェアともに進化の速度が早く、世の中で受け入れられるプロダクトも次々に変わっていきます。このような状況下でのプロダクト開発は未来予測が難しいため、素早く仮説検証を行って必要なものを無駄なく作る必要があります。問題を分類して意思決定をモデル化したフレームワークとして「クネビンフレームワーク」と言うものがありますが、カオスな領域・複雑な領域に属するものは問題を解決する方法が理解できないので（複雑な領域の場合は）試行錯誤を行ったり、（カオスな領域の場合は）まず何か行動してみる必要があります。ウォーターフォールの場合は作ったものが役に立つものなのかを知るのに時間がかかり過ぎるため、作ったものがムダになるリスクが高まります。このような領域ではアジャイルな開発が適しています。つまり、顧客が抱えている問題をするために、それを解決する（と思われる）を提供し、顧客の反応を見ながらのがアジャイルの本質です。間違いがあればすぐに修正し、変化を見ながら役に立つものを作っていく。現代のプロダクト開発では、そのような領域の問題が数多くあるため、各業界・各社・各チームが問題解決のためにアジャイルな開発手法（=スクラム）を導入しています。未熟なチームこそスクラムを導入すべき研修を受ける前は、優秀なチームメンバーでなければ良いスクラムはできないと思っていました。しかし、実際には未熟なチームこそスクラムを導入すべきと言われています。なぜなら、チーム結成当初からいきなり成熟した優秀なメンバーを十分に揃えることは稀だからです。また、スクラムでは全体の時間の約20%をスクラムイベントに費やすため、開発時間だけ考えれば非効率と言えます。しかし、この非効率さこそスクラムをうまくやるための仕掛けなのです。 を重視し、を作り、を通じてニーズや状況のしていく。アジャイルマニフェストにも示されているような価値観を大事にするために必要なエッセンスが詰まっています。仮に、チームが本当に未熟で成果が出せないとすれば、それは最初のスプリントレビューですぐに気づくことができ、対処するために動くこともできます。スプリントレビューで価値あるフィードバックを得るためにスクラムで最も重要となるのは、スプリントレビューで顧客から価値あるフィードバックを得ることです。顧客に成果を見せることで、その価値を判断し、次のスプリントの方向性を決定します。そのため、スプリントレビューで良いフィードバックを得られるよう準備することが重要です。鍵となるのは、です。明確なスプリントゴールがあれば、メンバーは目標達成に必要な行動を考えることができ、POをサポートできます。そして、実装を行ってインクリメントを作ります。結果として、スプリントレビューで得られるフィードバックはスプリントゴールを達成したインクリメントに対する価値判断になります。私の開発チームでは、スプリントゴールをどう設定すればいいのかわからず、「」として省略してしまっていましたが、それは間違いだということがわかりました。「」を考えながらゴール設定をすると良いということを教わりました。また、スプリントレビューのメンバーは必ずしも固定である必要はなく、「」ということを念頭に置いて招待すると良いとのことでした。タイムボックスを意識するスクラムにおいて、タイムボックスを意識することは重要なルールの一つです。これは時間内に話を終わらせることを意味します。たとえ話が終わりそうになくても必ず一度タイムボックスで区切り、その後必要に応じて再検討する必要があります。毎回話がまとまらない場合は、その理由を分析し改善方法を検討する必要があります。実際に私のチームではデイリースクラムの時間が30分以上かかってしまう問題がありました。原因として、デイリースクラムに直接関係のない内容を話しているということがありました。この問題を解決するために、デイリースクラムの時間まで話すのを待つのではなく普段から相談したい相手とコミュニケーションを取るように促し、デイリースクラムでは必要な報告だけを行うように努めてもらい、時間内に終わるようにしました。スクラムイベントのタイムボックスを守ることがルールを守ることになり、スプリントゴールを達成する目標を果たすことにもつながります。「時間がもっとあれば…」と言いたくなる気持ちをグッと堪えて、小さなインクリメントを積み上げスプリントゴールを達成することが重要です。一方で、研修中はスプリントレビューに最も時間を割いて（各チーム時間制限なしで）全チームの発表を聞きました。最も重要な時間であることの表れなのかもしれません。また、チームの調子がよくなれば良いフィードバックが増えるので、続けていくにつれて時間が短くなっていくのかもしれないなと感じました。研修で体感したスクラムの力研修では、その場で集まったメンバーでチームを組み、実際にプロトタイプの開発を行います。スクラムイベントを除いた開発時間は、たったの20分程度です。まだ知り合って間もないメンバーで息を合わせて作業を行うのは困難でしたが、それでもスプリントレビューで成果を発表しなければなりません。実際、初回のスプリントレビューでは厳しい意見が数多く出ました。しかし、チームは次のスプリントで軌道修正を図り、次の発表では「使ってみたくなった」とフィードバックをいただくことができました。ふりかえってみると、もし最初の段階でフィードバックをもらえていなかったら…と思うとゾッとします。楽しく楽に仕事できるようにするためのふりかえりスプリントレトロスペクティブは、開発プロセスそのものを改善するための場です。つまり、プロダクトやバグではなく、開発方法の問題に焦点を当て、より楽しく楽に仕事ができるように改善していくことが目的です。これまで、私のチームでは何のふりかえりなのか明確にしておらず、プロダクト改善や技術的な試みがしばしば議論されていましたが、これは誤りでした。プロダクトに関するレトロスペクティブは、「リリースレトロスペクティブ」など別の機会を作って、それに合わせてメンバーも調整して行うといいようです。また、成熟したチームは、レトロスペクティブ前に問題を見つけて改善できるため、次のステップとして、例えば「Slackで朝の挨拶をする」というような簡単で実験的な取り組みを入れてみると良いことを学びました。一見意味がないように思えるような取り組みでも、予期せぬ良い改善につながる可能性があります。良いと思えば続ければいいし、意味がないならやめれば良いだけなので、確かにデメリットはなさそうです。現在読んでいる「アジャイルレトロスペクティブ」には様々なゲームが紹介されているので、ユーモアのある面白いゲームを取り入れて、楽しいレトロスペクティブを開催し、チーム全体で楽しく楽に仕事ができる環境を作っていきたいと思います。スクラムマスターはチームを自立へと導く存在研修最終日では、「偉大なスクラムマスター」について考えました。スクラムマスターは、チームやメンバー、組織を支援する縁の下の力持ち的な存在です。サーバントリーダーとして、メンバーに指示をするのではなく、チームを注意深く観察し、自走できるよう支援します。メンバーのマインドセットを変えるのは容易ではありません。状況によって求められることも異なるため、一概にこれをやれば良いといったタスクリストはありません。その点でスクラムマスターは大変な仕事ではありますが、一つ一つ確実に原則を守ってやっていけば良いんだという一定の安心感と自信を得られました。さらに、チームが自立し始めると、スクラムマスターの存在は必要なくなり、「見えなくなる」という興味深い考え方も学びました。最終的に自分の居場所がなくなるというのはちょっと寂しい気持ちもありますが、開発でいう「属人性を排除する」イメージに近い気もします。ここまで到達できるように努力したいです。最後にこのワークショップを通してわかったことは、スクラムをうまく回すための「銀の弾丸などない」ということでした。チームとステークホルダーが良いプロダクトを作れるようにするために支援をし、プロセスを改善することで、短時間で効果的なプロダクトを生み競争に勝つことができます。スクラムにおける本当に大切なことを守りながら、まずはを持って小さなことから少しずつ改善していきたいと思います。 < XでシェアSpecial Thanks今回認定スクラムマスター研修に参加する機会を与えてくれた /wadata/モニクル.icon モニクルとCTO塚田さんに感謝申し上げます。スクラムマスターの育成にも力を入れている弊社では新しいメンバーを大募集中です。記事を見てもし興味がある方がいたらこちらから誰とでもカジュアル面談できます。お気軽にご連絡ください。

認定スクラムマスター研修に参加して印象に残ったこと

台南 / 神農街#アドベントカレンダー #Jira #FigJam #Scrapboxはじめにこんにちは、@sugoi_wada sugoi wada.iconです。この記事は、モニクル Advent Calendar 2023 の22日目の記事です。昨日は/wadata/yohei.kuji.iconによるでした。今回は弊社初のアドベンドカレンダーとして、最近自分が仕事をする上で意識しているJira、Scrapbox、FigJamのそれぞれの役割と使い分けについて書いていきます。ツールの導入経緯現在モニクルではJira、FigJam、Scrapboxの各ツールが導入されている状況ですが、私た入社した2020年4月当時はどのツールも使っていませんでした。その後、随時ツールの導入が行われていき、今の状態になりましたが、改めて導入に至った経緯をまとめておきたいと思います。まずはJiraの導入に至った経緯です。実は、私が入社する前は1人エンジニアの出来立てほやほやスタートアップで、マネイロのサービスもまだ存在していませんでした。そんな中、私と/wadata/ka2n.iconの二人が同時に参画しエンジニアが三人になったところでチームでの開発体制に移行するということで、私がJiraの使用を提案し、導入に至りました。この時期は創世記でまだ何も整備されていない状態でしたので、エイヤで入れた記憶がありますが、以下の点を考慮に入れました。 使い慣れたツールを使いたい（前職で使った経験がありました） スクラムが可能なツールを使いたい（ただのカンバン系ツールは避けたい） なんならドキュメントも書く場所が欲しい（当時はConfluenceも同時に導入しました）次にScrapboxです。上記にもあるように導入前はConfluenceを使用していました。Confluenceには以下のような課題がありました。 ドキュメントをカジュアルに書き残せない  どこにページを置くべきか悩んでしまい、雑にページを作るのが憚られる ドキュメントの更新がしにくい（編集画面に遷移する手間がかかる） 他人のページを編集・整理しづらい 階層構造を管理しにくいその後、/wadata/nkzn.iconが弊社にジョインしてScrapboxの導入を進めてくれました。Scrapboxは常に編集モードでドキュメントの更新がしやすく、ページに階層構造という概念が存在しないため置き場所に迷うことがありません。また、ページを[]で囲っておけばリンクが紐づいてくれるため社内wikiのような役割も果たすことができて大変便利です。ちなみに、[]で囲うことをブラケティングと呼ぶそうです。最後にFigJam（Figma）の導入経緯ですが、元々デザイナーがおらず業務委託先でSketchなどを利用したデータの受け渡しが行われていましたが、後にデザイナーが入社してからオンラインコラボレーションデザインツールとしてFigmaが導入される運びとなりました。その後、FigJamがFigmaの新しいツールとして公開された流れで、FigJamを導入することになりました。ツールをどう使い分けるか？そもそも、これらのツールは本来の使用目的がそれぞれ異なります。table:何をするためのツールか？ Jira	課題やプロジェクト管理をするツール Scrapbox	チームでリアルタイムに情報を共有できるツール FigJam	オンラインホワイトボードしかし、それぞれに共通する特徴として情報を残したり整理することができるため、プロダクト開発を進める上での要求・要件・設計などの情報がこれらのツールに集約される傾向があるように感じます。仕事でこれらのツールを使っていくうちに、各ツールごとに得意なこと・不得意なことがあることがわかってきたので今回はそれをまとめます。みんなで多面的なアイデアを出しあうならFigJam一択私の所属するチームでは実行計画を行っています。実行計画では、スプリントバックログに積まれた（積んだ）アイテムを実際に実装するにあたり、どのような作業が必要かを書き出して整理する会です。実行計画にはチームのエンジニアが参加します。実行計画を通じてスプリントバックログアイテムで具体的にどのような作業を行うかのイメージを膨らませ、メンバー全員で共通認識を合わせることができます。実行計画の詳細についてはまた機会があれば別の記事で書こうと思いますが、実行計画ではFigJamを開いて議論をしています。なぜ実行計画の場でFigJamが良いのかをまとめてみました。 メンバー全員でコラボレーションができる セクションや図形、付箋を色別に貼って線で結ぶことができるなど表現力が高くヴィジュアライズしやすい  さらに画像やテキストも自由に配置できる ページをスプリントごとに分割せず、同じページに書くことでスプリントを跨いだ課題に対し、継続的に議論ができるようになる 付箋の記入者が自動的に記録される スタンプやステッカーなどが豊富で遊び心が多く、テンションが上がる特に大きめのアイテムになるとどこから手をつければいいのかと悩むことがありますが、FigJam上であればまずみんなで付箋に情報を書いた上で整理していくことができるので、自然とアウトプットが進んで議論が捗るようになりました。みんなで同時に書いたとしても、コンフリクトしたりどこに書けばいいのかわからないという困り事が発生しないため、全ての意見や参考資料のリンクが残ります。みんなでアイデアを出し、頭の中を整理して情報を共有するツールとしてはFigJamが適しています。いつも同僚の/wadata/yohei.kuji.iconがステッカーをたくさん貼ってくれるので、ドキュメントをみた時のつまらなさもありません。ちなみに、Miroなどの類似ツールでも大丈夫だと思います。超お手軽な社内情報共有wikiとして最強のScrapboxFigJamがみんなで情報をアウトプットし整理するのに役に立つことを紹介しましたが、一方で検索機能は使いにくい、見辛いなと感じることがあります。そんな時はScrapboxが役に立ちます。FigJamで議論を交わして決めた設計に関する記録（Architecture Decision Record: ADR）や意思決定をScrapboxにサクッと1ページにまとめることができます。また、プロダクト固有の表現や単語にはブラケティングすることで、それらの解説は他のページに説明を委ねることができます。モニクルでは、社内共有目的で作成されたScrapboxのプロジェクトが一つ存在していて、そこを見れば他のチームメンバーにもADRを共有することができ、プロダクトを横断したナレッジのシェアができています。Scrapboxでは検索機能の他、ブラケティングによる検索性がとても高い割にメンテナンスコストが低いので、FigJamの内容をScrapboxでまとめる用途としては最適だと感じています。チケットとして課題をまとめて管理するJira最後はJiraです。Jiraはこれまでのツールとは性質が異なりプロダクトの課題を管理するツールですが、課題をチケットとして管理することができ、各課題に詳細を書くことができるため上記のツールに書くような内容をJiraにも書くことができます。ただ、Jiraを使ったコミュニケーションには以下のような問題があります。 チケットの順番を様々な尺度・粒度で並び替えてみることができない 詳細を書く時にコラボレーションできない 詳細やコメントを見る場合、一つ一つ開かないと中身が確認できない チケットの紐付けが面倒（紐付けるチケットの番号を選ぶ部分のUXが悪い）一方で、チケットのアトリビュートに値を付与することによって検索性が向上したり、スプリントに特化しているためやりやすい面があるのも事実です。なので、Jiraのチケットに対して細かな情報は記載せず、適宜URLを貼り付けたりコピーした内容を貼り付けることによって、Jira上で内容に関して細かな議論をしなくても良いようにしています。最後にツールにはそれぞれの特徴があります。目的に応じてうまくツールを導入し社内に広めることによって徐々に浸透していき、当たり前にそのツールを使ってくれるようになります。社内でみんながツールを活用して情報を残したり、オープンにしてくれることは嬉しい反面、使い方を間違えてしまっているんじゃないかと思うケースもよく見かけます。そんな時、ふと立ち返ってみて、今使っている様々なツールや世の中にある新しいツールを使ってみることで思わぬ新発見があるかもしれません。明日は、モニクルの神デザイナー大谷和宏さんの23日目の記事です。お楽しみに 👋 > X でシェア宣伝/wadata/モニクル.icon モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。もし私とお話したい方はこちらからどうぞ 🤝

JiraとScrapboxとFigJamの使い分けTips

鹿港 / 摸乳巷#GraphQL #Fragment_Colocation #Fragment_MaskingFragment ColocationとはReactのアプリケーションでGraphQLを使うときに使われるテクニックの一つです。Fragment Colocationによって、データのフェッチ処理と、データをコンポーネントに描画する処理を分離できることなどがメリットです。詳しくはこちらも参考にしてください。実装例を見てみます。なお、本記事のコードは関係の深い部分のみを抜粋したものになりますので、importや足りない部分を調整してください。code:Pokemon.tsx gql(`   fragment Pokemon on Pokemon {     number     name     image   } `);  export const Pokemon = ({ pokemon }: { pokemon: PokemonFragment }) => {   return (     <div>       <a href={/pokemon/${pokemon.number}}>         <h3>{pokemon.name}</h3>         <img width={100} height={100} src={pokemon.image} />       </a>     </div>   ); };実装時のポイントは、Fragmentの定義の側にそのFragmentをPropsとして受け取るコンポーネントを配置（colocate）することです。PokemonFragmentのような型を自動生成するのにGraphQL Code Generatorを使っています。PokemonコンポーネントはPokemonFragmentをPropsで受け取りJSX.Elementを返しますが、データの取得方法に関する詳細が書かれていません。このようにデータの取得と描画を分離することで、このコンポーネントの保守性が上がります。ただし、この書き方ではFragment Colocationを強制することができません。具体的には以下のようにデータの取得する場所でもFragmentのフィールドにアクセスすることができてしまいます。code:index.tsx const PokemonsQuery = gql(`   query pokemons($first: Int!){     pokemons(first: $first){       id       ...Pokemon     }   } `);  const Index = () => {   const data, fetching, error } = useQuery({     query: PokemonsQuery,     variables: {       first: 151,     },   });      return (     <ul>       {data?.pokemons?.map(         (pokemon) =>           pokemon && (             <li>               {/* Pokemonコンポーネントの外でPokemonFragmentのフィールドにアクセスできてしまう */}               <h2>{pokemon.number}</h2>               <Pokemon pokemon={pokemon} />             </li>           )       )}     </ul>   ); };Colocationされたコンポーネント以外でFragmentの値にアクセスしてしまうと、もしFragmentのフィールドを変更した場合に呼び出し側のコンポーネントが壊れる可能性があります。また、見かけ上Fragmentのフィールドを使用していることに気づきにくいという問題があります。これはFragment Colocationの実装が不十分で保守性を下げることに繋がります。この問題を解決するアイデアの一つがFragment Maskingです。Fragment MaskingとはRelayが提唱している、Fragment Colocationをカプセル化するための方法です。Relay のチュートリアルでは標準でFragment Maskingを使った流れが示されています。なお、Relayの文脈ではData Maskingと表現しているようです。GraphQL Code GeneratorにRelayスタイルのFragment Colocationが実装されているので、今すぐ使うことができます。ということで、今回はgql-tag-operations-presetプラグインを用いて実際に使ってみます。gql-tag-operations-presetでFragment Maskingを使ってみるgql-tag-operations-presetやGraphQLクライアントの導入自体は済んでいる前提で進めます。まずは、codegen.tsの設定で有効にします。といっても簡単で、presetConfig: { fragmentMasking: true } を入れてあげるだけです。code:codegen.ts const config: CodegenConfig = {   ...   generates: {     'graphql/__generated__/': {       preset: 'gql-tag-operations-preset',       presetConfig: {         fragmentMasking: true,       },       plugins: [],       config: {         ...       },     },   }, };Fragment Maskingを有効にしてコードを再生成すると、カプセル化が効いてフラグメントのフィールドにアクセスできなくなります。さらに、FragmentのオブジェクトをPropsに渡す部分でもエラーが出ています。生成したコードを読むとわかりますが、$fragmentRefsというキーをもつ型に変換されていて、直接PokemonFragmentへ参照できなくなりました。code:1. graphql/__generated__/graphql.ts // fragmentMasking: false（またはデフォルト）の場合 export type PokemonsQuery = { __typename?: 'Query', pokemons: Array<{ __typename?: 'Pokemon', id: string, number: string | null, name: string | null, image: string | null } | null> | null };code:2. graphql/__generated__/graphql.ts // fragmentMasking: true の場合 export type PokemonsQuery = { __typename?: 'Query', pokemons: Array<(     { __typename?: 'Pokemon', id: string }     & { ' $fragmentRefs'?: { 'PokemonFragment': PokemonFragment } }   ) | null> | null };これをカプセル化されたコンポーネントの中だけで参照できるように変えていきます。code:Pokemon.tsx import { FragmentType, gql, useFragment } from '../graphql/__generated__';  export const PokemonFragment = gql(`   fragment Pokemon on Pokemon {     number     name     image   } `);  export const Pokemon = ({   pokemon, }: {   pokemon: FragmentType<typeof PokemonFragment>; }) => {   const pokemonFragment = useFragment(PokemonFragment, pokemon);      return (     <div>       <a href={/pokemon/${pokemonFragment.number}}>         <h3>{pokemonFragment.name}</h3>         <img width={100} height={100} src={pokemonFragment.image!} />       </a>     </div>   ); };ポイントは、Propsの型をFragmentから、FragmentType<typeof Fragment>に変更していることです。この型のオブジェクトはそのままで使うことができないので、useFragment(Fragment, fragment)を使って使えるようにします。このuseFragmentはいわゆるReactのHooksではなく、ただの関数です。どのような関数かは生成されたコードを読むとわかります。非常に単純で、as any で戻り値の型を明示してキャストしているだけですね。code:graphql/__generated__/fragment-masking.ts // return non-nullable if fragmentType is non-nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> ): TType; // return nullable if fragmentType is nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> | null | undefined ): TType | null | undefined; // return array of non-nullable if fragmentType is array of non-nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: ReadonlyArray<FragmentType<DocumentNode<TType, any>>> ): ReadonlyArray<TType>; // return array of nullable if fragmentType is array of nullable export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: ReadonlyArray<FragmentType<DocumentNode<TType, any>>> | null | undefined ): ReadonlyArray<TType> | null | undefined; export function useFragment<TType>(   _documentNode: DocumentNode<TType, any>,   fragmentType: FragmentType<DocumentNode<TType, any>> | ReadonlyArray<FragmentType<DocumentNode<TType, any>>> | null | undefined ): TType | ReadonlyArray<TType> | null | undefined {   return fragmentType as any; }つまり、オブジェクトにデータはあるものの、TypeScriptの型の上でFragmentのデータを隠蔽（Masking）することでアクセスできないようにしています。そしてColocationしたコンポーネント内部でキャストして使えるようにします。テストやStorybookでモックのFragmentオブジェクトを入れたい場合makeFragmentDataメソッドを作りPropsでFragmentオブジェクトを渡してあげましょう。code:makeFragmentData.ts import type {   ResultOf,   TypedDocumentNode as DocumentNode, } from '@graphql-typed-document-node/core'; import type { FragmentType } from '~/generated';  export function makeFragmentData<   F extends DocumentNode,   FT extends ResultOf<F>, (data: FT, _fragment: F): FragmentType<F> {   return data as FragmentType<F>; }code:component.ts import { Pokemon, PokemonFragment } from '../components';  <Pokemon   pokemon={makeFragmentData(     {       number: '1',       name: 'ピカチュウ',       image: 'https://dummyimage.com/100x100',     },     PokemonFragment   )} />こちらもキャストしているだけですね。※ ちなみに、本題とはそれますが client preset を使う場合はmakeFragmentData(data, fragment)が生成されるコードに含まれているため、メソッドを作る必要はありません。Fragmentの中でも外でも使いたいフィールドはどうするかFragment Colocationされたコンポーネントの中でも、クエリの呼び出し側でも使いたいフィールドがある場合は、クエリ（ミューテーション）に直接フィールドを定義した上で、参照するFragmentにもフィールドを定義してあげましょう。まとめFragment MaskingはFragment Colocationを強制するためにとても便利な機能です。自動生成されたコードを読めばわかるように、実際に行っていることは型によるFragmentデータのカプセル化だけなのでGraphQLのクエリやミューテーションに影響を及ぼすことはありません。また、現在GraphQL Code Generatorではv3のロードマップが敷かれていて、client preset という便利なプリセットが作成されています。このプリセットは既にurqlのドキュメントで使われていたりして、今後のデファクトプリセットになる可能性があります。client presetでは今回紹介したFragment Maskingがデフォルトで有効になっていることからも、積極的に使っていくことは悪くない選択肢だと思います。参考 https://zenn.dev/mh4gf/articles/graphql-codegen-client-preset https://zenn.dev/takashima/articles/4c284439135a0c < Twitterでシェア宣伝/wadata/モニクル.icon モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちらから！

Fragment Masking で Fragment Colocation を強制する

大稻埕碼頭#GraphQL #Next.js #Apollo #Persisted_Queriesこちら（GraphQL の Persisted Queries について）の続きです。はじめに私が所属するモニクルのサービス「マネイロ」では、REST APIからGraphQLへの移行を進めています。フロントエンドはNext.jsを採用しており、REST APIのデータ取得にはSWRを使っています。これをApollo Clientで置き換えています。バックエンドではRailsにGraphQL Rubyを使ってクエリやミューテーションを作成しています。なお、Apollo Serverは使っていません。さて、マネイロは資産運用に関する悩みを解決するお手伝いをするために無料でオンライン相談ができるサービスを提供しています。そのために相談予約可能な日時や時間帯を取得するAPIがありますが、このAPIレスポンスはCDNにキャッシュしています。GraphQLに移行しても同じようにCDNにキャッシュしたいのですが、GraphQLはデフォルトでPOSTリクエストするためVercelのCDNでキャッシュすることができません。また、そもそもGraphQLクエリをブラウザに露出してしまうのも避けたいところです。そこで、Persisted Queriesを使ってこの問題を解決することにしました。Persisted Queries を使う方法として二種類のパターンを考えてみました。 Next.js（フロントエンド）からNext.js（API Routes）へのリクエストにのみハッシュ値を使う Next.js（フロントエンド）からRails（バックエンド）に至るまで全てハッシュ値でやりとりする今回は前者の実装だけで目的を達成することができるため、前者の実装を行うことにしました。クエリとハッシュ値を相互に変換するテーブルを用意するまず、今回の実装に必要となる変換テーブルを用意します。前回の記事でも紹介したgraphql-codegen-persisted-query-idsを使います。READMEを読みつつインストールした後、codegen.ymlに設定を記述します。名前やファイルパスは適宜読み替えてください。code:codegen.yml overwrite: true ... generates:   generated/server.graphql.gen.json:     plugins:       - graphql-codegen-persisted-query-ids:           output: server           algorithm: sha256   generated/client.graphql.gen.json:     plugins:       - graphql-codegen-persisted-query-ids:           output: client           algorithm: sha256その後、コード生成コマンドを実行します。code:console ./node_modules/.bin/graphql-codegen --config codegen.ymlこれで、generated/server.graphql.gen.jsonとgenerated/client.graphql.gen.jsonのファイルがそれぞれ出来上がります。どのような形式になっているかは、前回の記事が参考になります。Apollo Linkの設定Http Linkを使います。以下のように設定していきます。 url  BFFへのエンドポイントを指定する useGETForQueries  クエリにはGETリクエストを利用するためtrueにする fetch  GETリクエストの場合は query をハッシュ値に置き換えるcode:apolloClient.ts import { ApolloClient, from, HttpLink } from "@apollo/client" import queryHash from "generated/client.graphql.gen.json"  const endPointLink = new HttpLink({   uri: "/api/graphql",   useGETForQueries: true,   fetch: (uri, options: RequestInit) => {     if (options.method === "GET") {       // クエリをハッシュ値に変換します       const path, queryString = uri.toString().split("?")       const params = new URLSearchParams(queryString)       // params の中身についてはこちらが参考になります       // https://www.apollographql.com/docs/react/api/link/introduction/#the-operation-object       const { query, operationName, ...others } = Object.fromEntries(params)       const hashedParams = new URLSearchParams({         q: queryHashoperationName,         operationName,         ...others,       })       return fetch(${path}?${hashedParams}, options)     }      return fetch(uri, options)   }, })  export const apolloClient = (() =>   new ApolloClient({ link: from(endPointLink) }))() 上記の例ではfetchを独自にオーバーライドしていますが、graphql-codegen-persisted-query-idsはApollo Link用のアダプタも用意されていて、こちらを使うことでApolloの仕様に沿ったリクエストを書くこともできます。API Routesでの処理最後にAPI Routesの処理を書いていきます。主な観点は以下の部分です。 next-http-proxy-middlewareを使用すると、簡単にProxyするBFFが書けて楽 ハッシュ値をクエリに戻した上で、GraphQLバックエンドにPOSTリクエストする HTTP キャッシュヘッダーをセットするcode:pages/api/grpahql.ts import type opnameHash from "generated/client.graphql.gen.json" import hashQuery from "generated/server.graphql.gen.json" import type httpProxy from "http-proxy" import { NextApiHandler, NextApiRequest, NextApiResponse, PageConfig } from "next" import httpProxyMiddleware from "next-http-proxy-middleware"  export const config: PageConfig = {   api: {     bodyParser: false,     externalResolver: true,   }, }  const handleProxyInit = (proxy: httpProxy) => {   proxy.on("proxyReq", (proxyReq, req, res) => {     if (proxyReq.method !== "GET") return     const path, queryString = proxyReq.path.split("?")     const params = new URLSearchParams(queryString)      // クエリのハッシュ値からクエリを復元する     const { q, operationName, ...others } = Object.fromEntries(params)     const query: string | undefined = hashQueryq      if (!query) throw new Error(クエリが見つかりませんでした。 ${q})      // GETリクエストをPOSTリクエストとして送信する     proxyReq.method = "POST"     proxyReq.path = ${path}?operationName=${operationName}     const bodyData = JSON.stringify({       query,       operationName,       ...others,     })     proxyReq.setHeader("Content-Length", Buffer.byteLength(bodyData))     proxyReq.write(bodyData)   })   proxy.on("proxyRes", (proxyRes, req, res) => {    // ※ req オブジェクトからリクエスト情報が取得できるので、クエリに応じたキャッシュの設定などをすると良いでしょう     proxyRes.headers"Cache-Control" = "s-maxage=60, stale-while-revalidate"   }) }  const h: NextApiHandler = (req: NextApiRequest, res: NextApiResponse): Promise<void> =>   httpProxyMiddleware(req, res, {     ..., // ※ RailsバックエンドへのProxyの設定を書く     onProxyInit: handleProxyInit,   })  export default h これで完了です。Apollo Linkを使っているため、フロント側のuseQueryフックは変更する必要がありません。これでCDNでのキャッシュと、クエリをブラウザに露出させることを防ぐことができるようになりました。まとめPersisted QueriesはApolloが提唱する仕様通りに作ることもできますが、今回の例のように自分で変換処理を書くことで、最低限の仕組みだけで実装することが可能です。一方でApolloの仕様に則ったライブラリも豊富なので、そちらに実装に合わせておくと良い場合もありそうです。いずれにしても仕組み自体は難しくないので、覚えておくと何かと便利な仕組みだと思いました。 < Twitterでシェア宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

GraphQLクエリをCDNキャッシュに載せたい

林家花園#GraphQL #Persisted_QueriesGraphQL クエリの特徴GraphQLではクライアントとサーバ間のやりとりにGraphQLクエリを使うことで、一回のリクエストで必要な要素だけを取得することができます。code:sample_query  query GetCustomerQuery {    customer(id: "Customer001") {      id      email      profile {        id        name      }    }  }通常はこのようなクエリをPOSTリクエストのペイロードに含めて、{ "query": "query GetCustomerQuery {...}" }のような形でサーバサイドにリクエストします。サーバサイドではこのクエリを解釈し、必要なオブジェクトや要素だけをクライアントに返却します。このようにして、クライアントはクエリを記述することによって一度に複数のネストしたオブジェクトを最低限必要な要素だけ取得することが可能になります。なお、上記の"Customer001"のような値は引数（variables）として渡すことが一般的ですがPersisted Queriesではvariablesを取り扱わないため省略します。Persisted Queries とはPersisted Queiesは、リクエストのペイロードにGraphQLクエリの文字列を直接含めるのではなく、ハッシュ化した文字列（ハッシュ値）を使ってリクエストする方法です。クライアントはハッシュ値をペイロードに入れてリクエストした上で、サーバサイドではハッシュ値をクエリに戻し、必要なデータを返します。Persisted QueriesはGraphQLの機能を拡張したプロトコルです。そのため、Persisted Queriesに対応したクライアントでは以下のようなペイロードを送ります。code:extensions.json {   "extensions":{     "persistedQuery":{       "version":1,       "sha256Hash":"ハッシュ値"     }   } }クライアントはクエリをハッシュ化する必要があります。上記の例ではSHA256のハッシュアルゴリズムを使ってハッシュ値を生成しています。また、サーバサイドでは受け取ったハッシュ値をクエリに戻す必要があります。ここで、クエリとハッシュ値を変換する方法を2種類紹介します。クエリとハッシュ値を相互に変換するテーブルを用意するクエリとハッシュ値が相互に変換できればそれで良いので、クライアントとサーバ側でそれぞれ変換テーブルを事前に用意しておくことで対応させることが可能になります。変換テーブルはビルドステップで事前に準備したり、スクリプトを走らせて生成したりします。以下はJS環境で使うためにgraphql-codegen-persisted-query-idsという自動生成ツールを用いて作った json ファイルの例です。code:client.json {  "getCustomerQuery": "ハッシュ値" }code:server.json {  "ハッシュ値": "query GetCustomerQuery {...}" }client.jsonをクライアントで、server.jsonをサーバサイドでそれぞれ使用します。クライアントではハッシュ値をそのまま取り扱うことはしたくないですが、このツールを使えばgetCustomerQueryというクエリの名前を使ってハッシュ値を取り出すことができます。便利ですね。Automatic Persisted Queries で自動変換を行う前述したような変換テーブルを用意することなく自動的に変換を行ってくれるようにする方法としてAutomatic Persisted Queriesがあります。Automatic Persisted Queriesを使う場合は、Apollo のようなそれに対応したサーバとクライアントを使います。仕組みとしては、クエリと対応するハッシュ値をクライアントで動的に生成し、クエリの代わりにハッシュ値をサーバサイドに送ります。もしサーバサイドでハッシュ値に対応するクエリがわからない場合はエラーを返します。そこで、クライアントは再度同じクエリをリクエストするのですが、その時にクエリ文字列とハッシュ値を両方ともペイロードに含めます。サーバサイドではハッシュ値とクエリを登録した上で結果を返します。それ以降登録されたクエリはハッシュ値だけ送ればよくなります。これを自動的に行ってくれる仕組みがAutomatic Persisted Queriesです。Persisted Queries はどのような問題を解決するのかデータ通信量の削減GraphQLで複雑なクエリを使用するとクエリ文字列が長くなるため、ペイロードサイズが大きくなりネットワークのパフォーマンスが低下します。Persisted Queriesを使用すると長いクエリであっても文字列長が同じハッシュ値を送るため、ペイロードサイズが削減できます。さらに、サイズが小さくなることでGraphQLクエリをGETリクエストで送信できます。GETリクエストにできれば一般的なCDNで結果をキャッシュできるようになるため、パフォーマンスがさらに向上します。セキュアな通信の実現GraphQLのクエリはスキーマさえ正しければどんなクエリでも受け付けることができます。複雑なクエリの中には処理の重いロジックや、深いネスト、無駄なプロパティが含まれる場合があります。また、場合によってはクライアントから悪意のあるクエリや想定外のクエリ（ただしスキーマ上は正しいクエリ）を含めたリクエストがくる場合もあるかもしれません。通常のクエリであれば、このようなクエリでもあってもスキーマ上正しければ値を返すしかありません（※クエリの複雑度を計算して閾値を超える場合にはエラーを返す方法は存在しますが、閾値を超えなければ正しいレスポンスを返すでしょう）。しかしPersisted Queriesを使うことによって事前に決められたクエリのハッシュ値のみを受け付けることができるようになるため、想定していない複雑なクエリや悪意のあるクエリをクライアントから送られても破棄することができます。まとめPersisted Queriesそのものは非常にシンプルなんですが、GraphQLの拡張機能であるがゆえに体系だった解説記事が少ないなと思い今回まとめてみました。次回は、実際にやってみた例を紹介しようと思います。 < Twitterでシェア参考 https://relay.dev/docs/guides/persisted-queries/ https://blog.codecentric.de/en/2020/05/how-to-secure-a-graphql-service-using-persisted-queries/ https://developers.gnavi.co.jp/entry/frontend_improvement/ https://qiita.com/Quramy/items/b3943a0c27f3ade2c57d宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

GraphQL の Persisted Queries について

林家花園#Deno #Fresh 前回の記事で使ってみたFreshについての特徴と所感をまとめてみようと思います。もし前回の記事を読んだことがない場合は、先に読むことをお勧めします。Denoを初めて触ろうと考えている人やFreshを使ってみたい人に参考になればと思います。Fresh は Preact 依存のフレームワークFreshは内部実装でPreactが使われています。そのため、後ほど紹介するパッケージ管理システムの中にデフォルトで組み込まれているPreactを外すことはできません。前回はRSSフィードを作るだけだったので、特にPreactやJSXを使うシーンというのは無かったのですが、Preactを外してしまうとFreshサーバの内部実装でエラーになってしまいました。そういう意味では、今回はよりシンプルなHttpフレームワークを使うだけでも良かったのかもしれません。ゼロコンフィグでTypeScriptが使える私は普段から専らTypeScriptを使っていますが、Denoは何の設定をせずともTypeScriptを使うことができます。つまり、Node.jsでTypeScriptを書く際には必須となるtsconfig.jsonが必要ありません。この辺りの仕組みとしては、まずDenoを使うときに必須となるdeno-cliにTypeScriptが内包されています。そのため、下記のコマンドでどのバージョンが使われているのかを知ることができます。code:console deno --version  # deno 1.24.3 (release, aarch64-apple-darwin) # v8 10.4.132.20 # typescript 4.7.4tsconfig.jsonをカスタマイズすることもできます。カスタマイズする場合は、deno.jsonまたはdeno.jsoncというファイルを作成します。ただし、カスタマイズできるのはcompilerOptionsのセクションのみに限定され、そのほかは無視されるようです（Denoには無関係の機能や不完全な動きをするものが含まれるため）。Freshの新規プロジェクトにはdeno.jsonが含まれるため、そのままcompilerOptionsセクションを作成すれば良いですね。ちなみに、デフォルト値については公式ページにまとまっているため、目を通しておくと良いかもしれません。デフォルトでstrict: trueなのは最高ですね。ビルドステップがない昨今のNode開発環境ではほぼ確実に必要となるWebpackやesbuildなどのビルドツールも不要です。僕自身はビルドツールの設定に拘ったり全ての設定の意味を調べて必要なものを吟味することが好きなんですが、サクッとアプリを作りたいときにはそれが時間泥棒になってしまう場合があるので、何も設定が必要ないのはプロダクト作成に時間とエネルギーを割くことができて良いですね。Freshで作成したアプリをDeno DeployにデプロイするようにGitHub連携しておくと、mainブランチをプッシュした直後にアプリケーションがデプロイされReady状態になります。よくみてみると、Deno Deployのプロジェクトページにビルドの画面はありません。これがゼロビルドステップの力か〜と感動しました。Next.js風のファイルシステムルーティングFreshはNext.jsと同じようなファイルシステムをベースとしてルーティングを採用しています（Fresh公式でもそのように謳っています）。例えばroutes/hoge.tsxを作成したら、/hogeにアクセスできるようになります。Next.jsであればpages/配下ですが、Freshではroutes/配下であれば、APIリクエストをハンドリングしたり（一般的にはrouters/api/配下に定義しますが任意です）、JSXを返してHTMLのページをレンダリングするすることができます。公式ドキュメントの表がわかりやすいので参考にしてみると良いでしょう。import map を使ったパッケージ管理システムDenoではimport時に直接URLを書いてしまう方法の他、パッケージ管理を行う手法としてdeps.tsを使う方法とimport mapを使う方法の二種類があるようですが、Freshの新規プロジェクトではデフォルトでimport mapを使った方法が採用されています。これはプロジェクト内にimport_map.jsonファイルを置いて依存を解決する仕組みです。code:import_map.json {   "imports": {     "$fresh/": "https://deno.land/x/fresh@1.0.2/",     "preact": "https://esm.sh/preact@10.10.0",     "preact/": "https://esm.sh/preact@10.10.0/",     "preact-render-to-string": "https://esm.sh/preact-render-to-string@5.2.1?external=preact",     "rss-parser": "https://esm.sh/rss-parser@3.12.0"   } }インポートしたいESモジュールのURLに対して、任意の名前をキーとしたJsonを定義します。このようなファイルをプロジェクトルートに配置したのち、deno.jsonにファイルパスを明記してあげると、このファイルを使って依存を解決してくれます（実行コマンドの引数に--import-map ./import_map.jsonと指定する方法もあります）。code:deno.json {   ...   "importMap": "./import_map.json" }実際のコードでは以下のようにインポートして使います。code:main.ts import { HandlerContext, Handlers } from "$fresh/server.ts"; // https://deno.land/x/fresh@1.0.2/ import Parser from "rss-parser"; // https://esm.sh/rss-parser@3.12.0DenoはNodeとの互換性がないため、現状はNode用に作成されたnpmのパッケージをそのまま使うことはできません（3ヶ月以内には80%〜90%のnpmパッケージを簡単に使えるようにする計画がブログで公表されました）。そこで、npmパッケージを使いたい場合は以下の順番で試してみると良いです。1. https://deno.land/x にホスティングされていないか調べるdeno.land/x はDeno用モジュールのホスティングサービスです。lodashやdayjsなどの人気なパッケージはすでに公開されているようです。今回使ってみたFresh自身もここにホスティングされています。import_map.jsonのURLにhttps://deno.land/x/{パッケージ名}@{バージョン}と書いて使います。2. ESM形式で、Deno用にビルドされたパッケージを配布してくれるCDNを使う前回のRSSフィードを作成するときは、rss-parserというnpmパッケージを使うために https://esm.sh というCDNを利用しました。ブラウザでhttps://esm.sh/{パッケージ名}にアクセスすると、https://esm.sh/{パッケージ名}@{バージョン}にリダイレクトされるので、それをURLとしてimport_map.jsonに書いてあげましょう。実は、DenoにはNode互換のパッケージが存在しており、Node専用のモジュールをNode互換のモジュール呼び出しに置き換えることにより使える場合があり、その仕組みを使ってDeno用モジュールを配布できるCDNのうちの一つがesm.shです。ちなみに、依存パッケージの更新管理はdependabotやrenovateがよく使われますが、Denoではuddというツールがよく使われているようです。しかし、現状はesm.shのURL形式を完全にサポートできていないため、今回は使いませんでした。今後のアップデートが待たれるところです。クライアントサイドJSを動かすための仕組みFreshはインタラクティブなページを実装するための仕組みとしてアイランドアーキテクチャを採用しています。基本的に全てのコンポーネントはサーバサイドでレンダリングされますが、islands/配下に定義したコンポーネントだけはクライアントサイドで埋め込まれレンダリングされる仕組みです。動的なコンポーネントだけはファイルシステムで孤立・分離させることでクライアントサイドJSの量を最小限に抑えられますし、影響がそのコンポーネントに閉じるように工夫されています。まとめ一部の内容はFreshというよりDenoの良いところを語ってしまいましたが、Freshは軽量で薄いフレームワークのため、初めてDenoを触ってみたい方には最適なフレームワークのうちの一つではないかと思いました。次はislands/をゴリゴリ使ったアプリやPreactをガッツリ使うもの、ある程度大きめのページも作ってみたいです。Freshに関してより詳細な情報を知りたい方は、https://fresh.deno.dev/docs/concepts を眺めてみてください。Freshの考え方が簡潔にまとまっています。 < Twitter でシェア参考 Fresh - Deno の 次世代 Web フレームワーク Effective Deno Deno v1.15で導入されたNode.js互換モードについて宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

Fresh - DenoのWebフレームワークを触ってみた特徴と所感

大稻埕/迪化街#Deno #Fresh #RSS #Deno_Deployはじめに私が所属するモニクルでは、開発チームの各メンバーが書いた技術ブログをまとめたサイトがあります。https://developers.monicle.co.jp/まとめサイトを作るに至った経緯や、作成の流れについては同僚の/wadata/nkzn.iconnkznさんが書いたこちらの記事が参考になります。さて、私はScrapboxのまさにこのプロジェクトに記事を書いているのですが、オーナー（つまり自分自身）のアカウントでログインしていると、一般的に他のブログページにある、いわゆる「閲覧モード」が存在せず、記事の閲覧と編集を常に行うことができます。それがScrapboxのいいところの一つではあるのですが、カジュアルに記事を修正して行った時に起きてしまった悲劇と、それをDeno Freshで解決してみた話を紹介します。wada-blog が上位を独占？！ある日、ふと技術ブログまとめサイトをみたところ、自分が過去に書いた記事がすべて新着記事として上位に上がってきてしまう事態が起きていました。なぜこんなことになってしまったのかと考えてみたのですが、一つ心当たりがありました。それは「過去に書いた記事を一気に編集してしまった」ことでした。ちょうどこの時Scrapboxでカスタムのスタイルを当てて見た目を変更していたため、古い記事のタグの配置を変えたりしてレイアウトを整えていました。それが仇となり、過去記事が上位を独占してしまいメンバーに申し訳ない気持ちになりました。そこで、まずは根本的な原因を調査することにしてみました。Scrapbox の RSSフィード は RSS 2.0 ベース技術ブログまとめサイトでは、各個人のブログページのフィードを登録して新着記事を取り込むようになっています。RSS 1.0/2.0, ATOMの仕様が存在しますが、どの仕様に準拠したRSSでもパース可能なrss-parserを使ってJS Objectに変換した上で記事の発行日時にソートしています。また、ScrapboxのRSSはRSS 2.0を使っているようです（wada-blogのRSS）。RSS 2.0 の仕様を読んでみると、各記事を表現するitem要素の中にある日時はpubDate(発行日時）しかありません（ちなみに、ATOMの仕様には作成日時と更新日時という項目があります）。また、Scrapboxの記事を更新した場合はpubDateが更新されるということも判明しました。これを根拠にしてデータを定期的に都度作成している技術ブログまとめサイトでは、Scrapboxで編集した記事の発行日時が更新されて新着記事に上がってしまうということがわかりました。pubDate だけを上書きしたRSSフィードが欲しいここで、まずはこの問題を解決する方法を考えてみました。ScrapboxのRSS自体は、自分ですぐに触れるものではないのでどうしようもありません。また、技術ブログまとめサイトのロジックを変えることも検討しましたが、まとめサイト側で作成日時がわかるデータを保持していないため、すぐにはできそうになく諦めました。そこで、ScrapboxのRSSのうち、pubDateだけ作成日時に差し替えたRSSサーバを別途立ち上げることを検討しました。Scrapboxには、RSSとは別にAPIも存在していてページの一覧をGETで取得することができます（wada-blogのAPI）。このAPIレスポンスには各記事の情報の中に作成日時が含まれるため、発行日時だけ差し替えたRSSアプリを構築することができそうです。Deno の Fresh を使って爆速でRSSフィードを実装するそこで、今回はDeno用のWebフレームワークであるFreshを使ってRSSフィードを実装してみることにしました。Freshは2022/07/28 に1.0がリリースされたばかりの新しいフレームワークで非常に軽量です。クライアントに送信するJSはデフォルトで0KBで、リクエストに応じて edge サーバでレンダリングをして返すのが特徴です。まだ安定版がリリースされたばかりのため、プロダクションで使われているケースはあまり多く知りませんが、フレームワークの特徴からしても静的なLPや動きの小さなWebページには適していて、実際にDeno公式ブログでは使われているようです。今回作成するアプリは1ページのみで xml を返すだけなので、フレームワークとしてはなるべく小さくて開発体験が高速なツールがいいなと思っていました。その点でFreshはWebpack等のプレビルドを行う必要がないためアドバンテージがありました。また、ファイルベースルーティングを使用している点も気に入りました。私は普段Next.jsベースのアプリケーションを開発しているため、同じシステムを採用しているのは馴染みやすいです。もちろん、ただ単純にDenoやDeno Deployを使ってみたかったという理由もかなり大きいです。そして、です。https://rss-proxy.deno.dev/api/scrapbox/wada-blogソースコードはこちらにアップしています。https://github.com/sugoi-wada/fresh-rss-proxy作り始めてから数時間で無事に最低限の実装が出来上がりました。本当にpubDateを差し替えただけのミニマムな実装です。デプロイ先にはDeno Deployを利用しています。プッシュした後にビルドステップを踏まずにデプロイが終わるのは凄くいい体験ですね。RSSを切り替えてまとめサイトを再度確認してみると、wada-blogが元々あった場所に収まってくれていました。これで一安心。まとめ今回は、意外なところからRSSフィードを作ることになった経緯とその結果を中心にまとめてみました。次回は、Freshを使う上で調べたことについてまとめていきたいと思います。それでは！宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

技術ブログまとめサイトに wada-blog が上位独占してしまったので Deno Fresh で直した話

七海: https://ccklibrary.org.tw/w/zh_tw/index#Homebrew #Brewfileはじめに今まで利用していたPCはIntelのMacBookPro16インチでしたが、今回新たにM2のMacBookProを入手したので、セットアップについての備忘録を残したいと思いました。最近では多くの方が、タイムマシーン等を使ってSSDの中身を丸ごと移動するような方式をとっているかもしれませんが、私は綺麗な環境からスタートしたい気持ちが強く、そのような方法はとっていません。また、Intel版とApple Sillicon版の違いにより、別々に配布されているバイナリは丸ごと移行して欲しくない場合もあるでしょう。ということで、今回は Homebrew の Brewfile を使ったアプリの管理方法について紹介します。なお、初回の執筆時の環境はこちら。 旧: Intel MacBookPro 新: M2 MacBookPro Homebrew 3.5.9Homebrewのインストールはこちらから済ませておいてください。旧Macで準備することBrewbundleを使って新Macを使うためにはその元となるBrewfileが必要なので、それを準備します。Homebrew でアプリをインストールするまずは今使っているMacでインストールしているアプリをなるべくHomebrewでインストールしておくと良いでしょう。また、Macアプリの場合は--caskオプションをつけることでHomebrewにアプリを管理させることができます。code:zsh brew install app_name brew install --cask mac_app_nameちなみに、Macアプリの場合はUIからアップデートしないようにしておくと良いでしょう。Homebrewの管理が外れます。アップデートしたい場合は--greedyオプションを使います。code:zsh brew update && brew upgrade --greedyMac App Store のアプリについてmasというツールを使うことで、Mac App Store のアプリもBrewfileで管理できるようになりますが、認証面の問題で少し使いにくく、コツがいるため今回の説明からは省きますが、興味がある人はやってみてください。Brewfile の作成使っているアプリをHomebrewで管理することができたら、あとはbrew bundle dumpコマンドを使ってダンプファイルを書き出します。code:zsh brew bundle dump --global --forceホームディレクトリに .BrewfileができていればOK。中にはテキストでbrew installされているファイルが書かれています。ちなみに、masを使った人はMac App Storeのファイルも書かれています。GitHubのリポジトリ等に保存.Brewfileの保存先はどこでもいいですし、ファイル共有ソフトで管理するだけでもいいですが、今後も定期的にダンプして差分を更新していくことを考えるとGitでどこかのリモートリポジトリにプッシュしておくのがおすすめです。また、本題からはそれますが.zshrcや.gitconfigなども入れておくと良いでしょう。私はこれらのファイルを.dotfilesディレクトリに置いて、シンボリックリンクを使ってホームディレクトリに配置しています。Gitを使う場合は~/.dotfilesをコミットしてリモートリポジトリにプッシュすればOK。code:zsh mkdir ~/.dotfiles mv ~/.Brewfile ~/.dotfiles/.Brewfile ln -s ~/.dotfiles/.Brewfile ~/.Brewfile  # .zshrc 等を含む複数の隠しファイル（.から始まるファイル）をシンボリックリンクする場合は以下 ls ~/.dotfiles/.* | xargs -I{} basename "{}" | xargs -I{} ln -s ~/.dotfiles/{} ~/{}新Macで準備することさて、ここから新しいMacでのセットアップを始めます。Homebrewのインストールは済ませておいてください。Brewfile の取得と配置まずは保存した.Brewfileを新しいMacで取得します。git cloneをしたり、zipでダウンロードしたものを解凍したり、どんな方法でも構いません。その後、旧Macと同じ状態を作るため、ホームディレクトリ直下に.dotfilesを置いて、その中に.Brewfileを配置するのが良いでしょう。その後、同じようにシンボリックリンクを貼ります。Brewfile を元にアプリをインストールこれで準備は完了です。あとはbrew bundle dumpコマンドを使ってインストールしていきましょう。code:zsh brew bundle --file=~/.Brewfileネットワーク状況にもよりますが、相当な時間がかかる場合があります。またたまにパスワード入力を求められて止まるので気にしてあげてください。以上！宣伝株式会社モニクルでは、はたらく世代・子育て世代が抱えるお金や資産運用に関する不安や悩みを解決するお手伝いをさせていただき、現在から老後に至るまでの資金計画や最適なポートフォリオの提案を行っております。会社の紹介スライドはこちら → https://speakerdeck.com/monicle/about

新しい Mac を手に入れたらまずやること [Brewfile編]

#ベロシティ #スクラム #見積もり #アジャイル #ストーリーポイントはじめに私が所属するチームではスクラム型のソフトウェア開発（アジャイル開発と呼ぶかもしれません）を行っています。具体的には、各スプリントを始める前に、作業チケットにストーリーポイントで見積もりをしてスプリント内で終わらせることができそうな範囲を見極めます。見極めのためには過去のベロシティが参考になります。なぜなら、チームがこれまでのスプリントでどの程度のストーリーポイントを消化できたのかを確認できるからです。さて、今回はそんな指標として用いられるベロシティや見積もりについての考え方や、チーム内で実践していること・工夫していることをまとめます。この話は私が所属するチームにおける内容であり、一つの考え方・事例として参考にしてください。ベロシティは実績であるそもそもベロシティとは何か？というと、スクラムチームが1回のスプリントでDone（完了）にしたストーリーポイントの合計値です。言い換えると、1回のスプリントで見積もりした作業がどのくらいできたかの実績をあらわします。そして、各スプリントごとのベロシティを見てみるとある程度の傾向が見えてきます。安定・上昇・下降・乱高下くらいのパターンに分かれるでしょうか。この数値や傾向を見ると何がわかるのでしょうか？ベロシティを計測するワケは、不確実性の削減にあるベロシティの見方を考える前に、ベロシティを測る意味について考えてみます。その答えはズバリ「未来の予測可能性を高めること」にあります。ある機能を追加するとき、それが1週間で終わるのか、1ヶ月で終わるのか、3ヶ月で終わるのかは誰もが知りたいことです。アジャイル開発では、ベロシティがその役割を担っています。例えば、過去のベロシティ平均が15だったチームでは、各スプリントで15ポイントのタスクを消化できるので、ある作業を見積もった時に30だったのであれば、おそらく2スプリントかかるだろうと予測できます。私のチームでは1スプリントが1週間なので、2週間かかることが推測できます。このようにして過去の経験から未来の不確実性を少しでも削減するためにベロシティを計測します。この内容から以下のことがわかります。 ベロシティを計測するためには、見積もりが不可欠である ベロシティ（平均）が安定していなければ意味がない  ベロシティが乱高下している場合、次のスプリントでどのくらいのポイントが消化できるかがわからないベロシティは価値提供の速度である日々の業務をこなす中で、緊急対応を迫られる場合があります。クリティカルなバグが発見されて調査や修正が必要になったり、データの修正や集計が必要になった場合です。また、緊急ではないけれどリファクタリングをしたり簡単なバグ修正をすることもあるでしょう。このような作業チケット（ストーリー以外のチケット）にはストーリーポイントをつけないようにしています。この背景には、ベロシティは（顧客への）価値提供の速度であるという考えに由来しています。前提としてアジャイル開発ではバグの発生やリファクタリングの必要性を最小限に抑えるようなコーディングを心がけるように考えられているため、バグ修正やリファクタリングの作業は負債であると考えます。もしも、ベロシティが毎週のように下がっていた場合はストーリーチケットが消化できていないことになります。その理由をチームメンバーで考えます。例えば以下のような原因が考えられます。 バグが多く、バグの調査や修正に時間がかかっている  → アプリケーションの品質が下がっているなら、上げる工夫ができないか考える  → 設計に問題があるなら、改善案について話し合う  → 調査に必要なログ基盤が不完全なら、ログ基盤の強化について考える リファクタリングや設計の見直しをするのに時間がかかっている  → ベロシティを下げてもやることに理解が得られるように話し合う  → スプリントにどのくらいの割合で、直接価値提供をするわけではないが、後の業務が楽になるなどの利益があるチケットをやるべきかを話し合い合意する 見積もり以上に時間がかかっている  → 実際にやってみないと（調査してみないと）わからない作業チケットについては調査自体を別チケットにして、解像度を上げてから再度チケット分割する  → 影響範囲が見積もり時より広く時間がかかりそうな場合は、メンバーと共有した上でチケットの分割や再見積もりについて検討する スプリント中に作業の差し込みが多すぎる  → 作業の優先度に変更がないか確認する  → 差し込み作業をやることでスプリントの目標が達成できない可能性が上がることについて確認する  → スプリントを閉じて仕切り直しを検討する  → スプリントの期間を短くしてみるベロシティからこのような問題点を発見し原因を追求して改善していくことによってベロシティの安定化（障害が取り除かれ、自然と緩やかに上昇することも良いでしょう）に繋がります。終わりに元々は社内向けにまとめていた記事を改めて整理して大幅に加筆しました。ベロシティを考える上では見積もりも重要なトピックなのですが、また機会があれば書いてみようと思います。まだまだ手探りな点もありますが、一つの考え方として参考にしていただければ幸いです。

ベロシティを測ることの意味と見方の考察

#Ruby #Rails #トランザクションはじめに説明の内容や開発環境は Rails 7、PostgreSQL を前提としています。with_lock についてRailsには、モデルに行ロックをかける（クエリレベルで言うとSELECT ~ FOR UPDATEをする）方法として、model_name.with_lock(&block)というメソッドが用意されています。これを使うことによって、ブロックの内部では行ロックがかかり排他制御された状態で処理を記述することができます。code:with_lock_sample.rb book = Book.first book.with_lock do   # このブロックはトランザクション内で呼び出される   # bookはロック済み   book.increment!(:views) end引用: Rails ガイド - 悲観的ロックただし、引用した上記のサンプルコードにもコメントで書かれている通り、ブロック内部はトランザクション内で実行されることに注意してください。code:with_lock_sample2.rb book = Book.create!(title: "Book 1") pp "start" book.with_lock do   pp "with_lock start"   book.update!(title: "Book 1 Updated")   Paper.create!(title: "Paper 1")   pp "with_lock end" end pp "end"上記のサンプルコードを見ると、bookオブジェクトに対してwith_lockブロックを囲っているため、ブロック内部ではbookレコードに行ロックがかかり、それとは関係のないPaperモデルに関してはPaper.create!の直後にコミットされるように見えますが、実際にはそうではありません。実行結果は以下のようになります。code:with_lock_sample2_result.rb TRANSACTION (0.1ms)  BEGIN  Book Load (0.4ms)  SELECT "books".* FROM "books" WHERE "books"."id" = $1 LIMIT $2 FOR UPDATE    "with_lock start"  Book Update (0.2ms)  UPDATE "books" SET "title" = $1, "updated_at" = $2 WHERE "books"."id" = $3    Paper Create (0.5ms)  INSERT INTO "papers" ("title", "created_at", "updated_at") VALUES ($1, $2, $3) RETURNING "id"    "with_lock end"  TRANSACTION (0.3ms)  COMMITRailsのソースコードを読んでもトランザクションが作られていることがわかります。https://github.com/rails/rails/blob/04972d9b9ef60796dc8f0917817b5392d61fcf09/activerecord/lib/active_record/locking/pessimistic.rb#L92-L95試しに、with_lockのブロックが終わる前に別のスレッドからPaperレコードをクエリで呼び出してみると、コミットされていないのでエラーになることがわかります。code:with_lock_sample3.rb book = Book.create!(title: "Book 1") book.with_lock do   book.update!(title: "Book 1 Updated")   paper = Paper.create!(title: "Paper 1")   Thread.start {     pp Paper.find(paper.id)   }   sleep 1 endcode:with_lock_sample3_result.rb TRANSACTION (0.1ms)  BEGIN Book Load (0.5ms)  SELECT "books".* FROM "books" WHERE "books"."id" = $1 LIMIT $2 FOR UPDATE   Book Update (0.4ms)  UPDATE "books" SET "title" = $1, "updated_at" = $2 WHERE "books"."id" = $3   Paper Create (0.5ms)  INSERT INTO "papers" ("title", "created_at", "updated_at") VALUES ($1, $2, $3) RETURNING "id"   Paper Load (0.4ms)  SELECT "papers".* FROM "papers" WHERE "papers"."id" = $1 LIMIT $2   #<Thread:0x000000010a917480 (irb):5 run> terminated with exception (report_on_exception is true): /Users/username/.anyenv/envs/rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/activerecord-7.0.3.1/lib/active_record/core.rb:284:in `find': Couldn't find Paper with 'id'=6 (ActiveRecord::RecordNotFound)         from (irb):6:in `block (2 levels) in <main>' TRANSACTION (0.8ms)  COMMIT => 1 まとめ行ロックはトランザクションがコミットされるまでの間維持されるため、トランザクションを作ることを知っていれば当たり前のことですが、Railsのコードを読む時にはついついモデル単位でそのオブジェクトを捉えてしまい、思わぬ勘違いをしてしまうことがあります。今回はその一例を紹介しました。それでは楽しいRailsライフを！

Rails: with_lock のブロックはトランザクション内で呼ばれる

#Ruby いきなりですが、TypeScript で以下のような関数を書いてみました。実行結果はどうなるでしょうか。code:sample1.ts function sample1(array: number[]): { result: string[] } {   const result = array.map((num) => {     if (num % 2 === 0) return ${num} は偶数     if (num % 2 === 1) return ${num} は奇数      return ${num} は偶数でも奇数でもない   })      return { result } }  console.log(sample1(Array.from({length: 10}, (v, i) => i)))実行結果は以下のようになります。resultをキーとした、文字列配列（10件分）のオブジェクトが入っていますね。{  "result": [    "0 は偶数",    "1 は奇数",    "2 は偶数",    "3 は奇数",    "4 は偶数",    "5 は奇数",    "6 は偶数",    "7 は奇数",    "8 は偶数",    "9 は奇数"  ]} さて、これをそのまま Ruby に置き換えて書いてみました。しかし、一つ大きなミスを犯しています。どこが間違いかわかるでしょうか。また、実行結果はどうなるでしょうか。ちなみに、本記事の Ruby バージョンは3.1.2を使用しています。code:sample1.rb def sample1(array)   result = array.map do |num|     return "#{num} は偶数" if num % 2 == 0     return "#{num} は奇数" if num % 2 == 1      "#{num} は偶数でも奇数でもない"   end      { result: } end  p sample1(10.times)実行結果は以下のようになります。"0 は偶数"この実行結果を見るとわかることとして、10件分の文字列配列が出力されておらず、引数に渡した文字列配列の1件目のデータである 0 が map ブロックの引数に渡され、 return "#{num} は偶数" が呼ばれたところで処理が終わっています。つまりreturn句を関数内・ブロック内で呼び出した場合は、その時点でブロックと関数を中断してreturnに渡された値を返します。Ruby のreturn句はブロックも関数も抜けてしまうので、breakで書き直してみます。以下の実行結果はどうなるでしょうか。code:sample2.rb  def sample2(array)    result = array.map do |num|      break "#{num} は偶数" if num % 2 == 0      break "#{num} は奇数" if num % 2 == 1        "#{num} は偶数でも奇数でもない"    end        { result: }  end  p sample2(10.times)実行結果は以下のようになります。{:result=>"0 は偶数"}先ほどとは違い、resultをキーとしたハッシュオブジェクトが出力されるようになりました。ただ、値は相変わらず0は偶数という文字列のみです。つまり、break句を関数内・ブロック内で呼び出した場合は、ブロックを中断してbreakに渡された値を返しますが、関数は引き続き実行されます。中断する範囲がreturn句とは異なることに加えてbreak句が値を返すことができるというのも特徴的なポイントと言えます。break句で一歩前進したものの、依然としてresultの値が文字列配列になっていないのでnextで書き直してみました。code:sample3.rb  def sample3(array)    result = array.map do |num|      next "#{num} は偶数" if num % 2 == 0      next "#{num} は奇数" if num % 2 == 1        "#{num} は偶数でも奇数でもない"    end        { result: }  end  p sample3(10.times)実行結果は以下の通りです。{:result=>["0 は偶数", "1 は奇数", "2 は偶数", "3 は奇数", "4 は偶数", "5 は奇数", "6 は偶数", "7 は奇数", "8 は偶数", "9 は奇数"]}ようやくresultの値が10個の文字列配列をもつハッシュオブジェクトになりました。この実行結果を見るとわかることとしてnext句はブロックのループ処理は中断せず、呼ばれた際にブロック内部の後続処理をスキップします。また、breakと同様にnextも値を返すことができます。ここでわかったことをまとめます。 return: ブロックのループ処理も関数も中断して値を返す break: ブロックのループ処理を中断して値を返す next: ブロック内のループ処理結果として値を返し、次のループを開始する（ループ処理は中断されない）さまざまな言語に触れていると、このような微妙な条件の違いに混乱し時に思わぬ結果をもたらします。このようなミスを犯さないように、実務ではテストコードを書いていくことが大切です。冒頭のTypeScriptの例で言えば、breakやcontinueに渡せるものとしてラベルがあります。ラベルを使うことで、どの範囲のブロックを中断するかを明示的に指定することができます。TypeScriptのラベルについてはこちらを参照してください。Rubyには、breakやnext句にラベルを使って中断先を明示的に指定することはできませんが、代わりにcatchとthrowを組み合わせて似たようなことができます。code:label.rb catch (:done) do   5.times { |i|     5.times { |j|       puts "#{i} #{j}"       throw :done if i + j > 5     }   } endhttps://stackoverflow.com/a/1352143 より引用あまりこのようなコードを目にする機会は多くないかもしれませんが、覚えておくと良いかもしれません。

Hikaru Wada

Rails で Minitest を使って悲観的ロック（排他制御）をテストする方法

モニクルにジョインして4年が経ちました

2024年03月の台湾ワーケーション記録

ライムリゾート箱根はいいぞ

認定スクラムマスター研修に参加して印象に残ったこと

JiraとScrapboxとFigJamの使い分けTips

Fragment Masking で Fragment Colocation を強制する

GraphQLクエリをCDNキャッシュに載せたい

GraphQL の Persisted Queries について

Fresh - DenoのWebフレームワークを触ってみた特徴と所感

技術ブログまとめサイトに wada-blog が上位独占してしまったので Deno Fresh で直した話

新しい Mac を手に入れたらまずやること [Brewfile編]

ベロシティを測ることの意味と見方の考察

Rails: with_lock のブロックはトランザクション内で呼ばれる

Ruby の return に注意しながら next と break をうまく使い分ける

Rails で Minitest を使って悲観的ロック（排他制御）をテストする方法

モニクルにジョインして4年が経ちました

2024年03月の台湾ワーケーション 記録

ライムリゾート箱根はいいぞ

認定スクラムマスター研修に参加して印象に残ったこと

JiraとScrapboxとFigJamの使い分けTips

Fragment Masking で Fragment Colocation を強制する

GraphQLクエリをCDNキャッシュに載せたい

GraphQL の Persisted Queries について

Fresh - DenoのWebフレームワークを触ってみた特徴と所感

技術ブログまとめサイトに wada-blog が上位独占してしまったので Deno Fresh で直した話

新しい Mac を手に入れたらまずやること [Brewfile編]

ベロシティを測ることの意味と見方の考察

Rails: with_lock のブロックはトランザクション内で呼ばれる

Ruby の return に注意しながら next と break をうまく使い分ける

2024年03月の台湾ワーケーション記録