謎の地雷を踏み抜いたのでメモ。
Next.jsで静的HTMLを出力する next export がありますが、これをローカルで実行すると何故かエラーが吐かれ失敗するという事象がありました。
Error occurred prerendering page "/hoge". Read more: https://nextjs.org/docs/messages/prerender-error Error: Cannot find module for page: /hoge
CIだと通るのに不思議だな〜と思っていましたが、以下に解決法が載っておりました。
私の場合、別のターミナルでyarn dev (next)コマンドを実行させていました。そのプロセスを停止して、yarn build && yarn exportを実行したら、問題は解決しました。
あっ・・・ next dev やりながらだとダメなのね・・・
ということで next dev を止めて next export したら無事通りました。めでたしめでたし。
Cypress入門１日目だけどやってみてハマったので書く。
ネットワークリクエスト・レスポンスのSpyとStubが出来るよって機能らしい。
今回のやりたいことはGAと通信しているかどうかなので、GAへのリクエストをSpyしてレスポンスを見るなりすれば疎通確認が取れる。
そんなこんなでこういうコードが出来た。
「こんな短いコードのどこにハマんねん」って感じでしょうが、 cy.intercept する際にどうやって別ドメインを指定すればいいのかサッパリわからず、変に cy.origin 使ってみたり右往左往してました。
で、結局optionに hostname があるのを発見してこれ使えばよかったんかいとなりました。
めでたしめでたし。
GitHubから2022/10/01よりプロジェクト情報を取得する ProjectNext が廃止となり、代わりに ProjectV2 を使おうというお達しがありました。
ProjectNext で使っていたNode IDを ProjectV2 でも使えるのかなとやってみたらダメだったので、新たに取得してみた。
仕事上でAPIを使っているということもあり、今回は会社のorganizationから取得してみました。
クエリはこんな感じ。
プロジェクト番号は各プロジェクト上に割り振られている番号でURL見るとわかると思います。
それかクエリ実行するのめんどくせーって人は単純に PN_XXXXXXX ってなってるIDを PVT_XXXXXXX って置換すれば良さそう。
やってみたのでメモとして書く。
対応しないといけないことは以下になります。
今回対応したCIはCircleCIなので、こんな感じで組み込んでみました。
設定している ROLLBAR_CODE_VERSION はdocker build時にARGで渡して、アプリケーションでClientに組み込むようにします。
こうしないとcode_versionをClientとSourceMapで同期できないので、Rollbarからしたらエラーは報告されたけど、どのSourceMapを突き合わせたらいいのか分からなくなるわけです。
あとは、公式でも紹介されているWebpack Pluginがあるのですが（ https://github.com/thredup/rollbar-sourcemap-webpack-plugin ）、正直活発だとは言い難い状況なので今回は使いませんでした。もし気になさらない方は使ってもいいのかも？
Next.jsでは本番環境でのbuild時にSourceMapを出力しないようになっているのですが、 next.config.js で productionBrowserSourceMaps: true とすることで出力するようになりますのでやっておきましょう。
TypeScriptもやってる人は tsconfig.json にて "sourceMap": true をしておきましょう。 inlineSourceMap ってのもあるのですが、こっちを有効化した場合はNext.jsがどういう認識をするのかは未検証・・・
最後にクライアントでのRollbarへのエラー送信のためのスニペットを組み込みます。これはRollbarがNext.jsのサンプルを用意してくれているので参考にしてこんな感じで書きました。
これで上手く行っていたらエラー時にRollbarに報告されるはずです。
設定できているかの確認方法としては、ブラウザの開発ツールにあるコンソールで window.onerror("TestRollbarError: testing window.onerror", window.location.href) を実行してみたり、スタックトレースがきちんとできているかを確認する方法としてボタンを押したら throw new Error("TestRollbarError"); を実行するようにしたらいいと思います。
あとSourceMapが上手くいっていない時はこんな感じの警告が出るかもです。
私の場合はうまくcode_versionの同期ができておらず、SourceMapをminified_urlからダウンロードしようとしていたため起こっていました。
何かSourceMap周りでうまく行っていないときは、RollbarのProjects -> Source Mapsも確認してみるとそちらでエラーが出ていたりするので確認してみるといいかもしれません。
※この時はcode_versionがクライアントでundefinedを設定していたので上手くいかなかった・・・
正直Sentry使ってたらあんまりハマることなく、スッといけたんだろうな〜と思いつつもRollbarでの対応を書いておきました。
特に選定に制限がない方はSentry使いましょう。
所属しているチームで遊撃部隊の立ち上げをしてから上期・下期を経て、色々とまとめていきたくなったのでまとめる。
前段として弊チームではバックエンド・フロントエンド・アプリ・インフラの垣根なく、皆で全領域をこなせるようになろうをモットーで普段の仕事をこなしていますが、それでも個々人の得手不得手がありタスクを持つ人が偏るという現状があります。
その中でも特にインフラを触れる人が少なく、インフラ系統のタスクが拾いきれずに埋もれてしまっていました。私が手の空いた時にインフラタスクをこなしてはいたのですが、それでも片手間では処理しきれないサイズのタスクがチラホラとあり手に余っている状況が続いていました。
こういった事象は他の会社でも起きているだろうと調べてみると、Misocaさんのテックブログで参考になる良い記事がありました。
イメージはMisocaさんのこれhttps://t.co/2NzxEhidJe
— しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) October 29, 2021
「重要度: 非常に高いわけではないが、無視できるほどは低くない」「大きさ: プロジェクト化するほどは大きくないが、一人がプロジェクトの片手間でやるには手に余るボリューム」といったこぼれタスクを片手間でやるのではなく、しっかりとチームを組んで対応しましょうというのがMisocaさんがやってらっしゃる遊軍チームでした。
「なるほど、遊軍という概念があるのか」と感銘を受け、マネージャーに掛け合い"遊撃部隊"という名で立ち上げ許可を頂き、たった一人ですが遊撃部隊が誕生するに至りました。
まずは対応が必要なタスクの棚卸しから開始しました。弊チームではスクラムを導入しているのですが、そこで利用しているGitHub Projectのボードとは別のボードを作成し、スクラムからは独立して管理するようにしました。
この背景としては、遊撃部隊のタスクとしてDX（開発体験の方）に繋がるツールの調査・検証などストーリーポイントが付けづらいタスクが多いということと、実際にサービスに形作られていくものがあるタスクではないのでタスクの性質が別なものは分けた方がいいだろうという思惑からでした。
ただし、タスク状況が私しか分からないというのは非常に不健全ですので、「今何をやっていてどのようなメリットがあるのか？どのような進捗なのか？」を毎日のミーティングの中で個別に報告するという形式を取っています。
タスクの棚卸しの後は、優先度の高いものから順にこなしながらも「（SRE文脈での）トイルを洗い出す」「アラート類の整理」「開発チームからの不便だと思っている点・アイデアの吸い出し」「DX向上に繋がるツールの調査・検証・導入」を並行しながら行いました。
主に埋没タスクの掘り出しと生産性向上という未来への投資タスクの２軸ですね。独立部隊で活動する意味合いをより強固にするためにも、今あるタスクをこなすことだけに注力した近視眼的な活動だけはやめようと決めていたので、それらの２軸も活動の芯として据えた次第です。
これ以外にも遊撃の名に沿うよう、開発チームで負いきれないバグの調査やQAチームなど部署の離れた他チームへの技術フォローも散発的にやっておりました。（こう書くと何でも屋さんですね😇）
アレコレと書きましたが、この10ヶ月では主にやったことをまとめます。
ザッと羅列してみましたが、一人でやっているとこのくらいが限界でした・・・
ここに列挙した以外にも社内関連で採用活動や、社内イベントに向けたアレコレなどをやっていましたが、まだまだやりたいことが多いです🤔
特に最近は色々な会社さんがやられているプレビュー環境自動作成の構築とかはとてもやってみたいですが、なかなか時間が取れず。
ここまで遊撃部隊をやった感想としては、自分にはこういう裏方作業というか縁の下の力持ちな役割が向いていたんだなと気付かされました。こういう発見があるので新しいことに挑戦してみることは良いですね。
あとは遊撃部隊という取り組みを通じて、Googleさんが提唱しているSREという職種についての造形が深くなりました。特にGoogleさんが主催でやってらっしゃるSRE研修に参加させていただたいのですが、何故SREという新しい職種が必要なのか？組織にどういったメリットがあるのかがよりクリアになる良い研修でした。もう少し今やっている様々なタスク群が落ち着けばSLA/SLOの設定などなどSRE活動へ着手していきたいです。
という遊撃部隊を立ち上げてみたまとめでした。
