Offers を運営している株式会社 overflow の あほむ でございます。 今回はプロジェクトで Web フロントエンド領域のテストを書くにあたって方針を決めた際の ADR をブログ向けに再整理したものをお届けします。 テストコードを書くべきか書かざるべきか 逃げ切りが確約された作り捨ての納品プロジェクトでもなければ、継続的なメンテナンスを前提にテストコードは書くべきが現代のソフトウェアエンジニアにおける共通了解でしょう。 急がば廻れ、ほとんどの場合においてテストコードを書くメリットがデメリットを上回るものと捉えられています。ここでは書かなくても良いケースをあえて論じることをしませんが、個別具体でテストが不要と断定できるときはそうすればよいでしょう。 テストを整える工数をどう捉える TDD (Test Driven Development テスト駆動開発) に代表される、テストコー

概要 こんにちは、Offers を運営している株式会社 overflow でフロントエンドのテックリードをしている Kazuya です。 久々にGraphQLについて書かせて頂きます。今回はapollo-server-expressを使用したGraphQLのモックサーバーの構築方法についてご紹介します。こちらは自身が担当している新規プロダクト（Offers MGR）でもリプレイス後から現在まで約2年間使用し続けています。 初心者の方でも理解しやすいよう、できるだけ詳しく解説していきますので、ぜひ参考にしてもらえればと思います。 [AD] GraphQLが向いている現場とは？運用実践LT 弊社（株式会社overflow）が主催で開催予定のGraphQLに関するイベントになります。 なぜ導入したのかや、実運用の方法、運用してみてのメリットデメリット、どんな現場なら向いているのか？といった組織面

はじめに おはこんばんちは。 Offers と、Offers MGR を運営している株式会社 overflow のバックエンドエンジニアばばです。 Web サービスを開発している皆様であれば、高度なデータ処理の大変さ・つらさを味わったことはあるかと思います。 たとえば グラフ用データを作成するには、API からデータ取得が終わった後に、DWH で集計して、その後バッチ処理かけてごにょごにょ 想定してたよりデータ量が多くて、許容時間内に処理が終わらないー あの API 、 Rate Limit 厳しいからから並列数制御しないといつまでたっても取得がおわらない・・・ など、悩みはつきません[1]。 上記の悩みが、開発効率性を落とし、技術的負債となってきていることから、Workflow Engine (タスクの実行順序など業務プロセスを自動で管理するソフトウエア) を導入しようという話がチーム内

Offers を運営している株式会社 overflow の あほむ でございます。 本記事は Chrome Platform Status からなんとなく Proposed/In Development etc なステータスのフィーチャーを取り上げて、そのプロポーザルを眺めてみるシリーズです。前回は form-sizing field-sizing CSS property でした。 SPA 的な画面遷移を性能計測したい 今回は Soft Navigations Performance Entry を眺めてみます。本当に眺めるだけで深入りしないので概要のみのライトな記事とご認識ください。 SPA 的な画面遷移とはつまり History.pushState や History.replaceState を用いた JavaScript 駆動なナビゲーションを指します。このような遷移を指してここ

フィーチャーフラグ（Feature Flag）でアジリティあげ - 導入時の技術選定と運用観点 | Offers Tech Blog こんにちは、プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow CTO の大谷旅人です。 今回は「Offers MGR(オファーズマネージャー) 」にフィーチャーフラグ（Feature Flag）機構を導入した際の選定視点含むアレコレについてお話していきます。 フィーチャーフラグ（Feature Flag）とは この記事で紹介する Feature flag とは、機能のオンオフをコード変更やデプロイ不要で変更するための仕組みのことです。 より詳しくは、以下の URL を参照下さい。 導入の背景、目的 背景: As-Is から To-Be への転換 フィーチャーフラグ（Feature Flag）導入前の状態（As-

概要 あけましておめでとうございます、Offers を運営している株式会社 overflow でフロントエンドのテックリードをしている Kazuya です。 新年一発目なので、少し軽めの内容でお送りします。今回は冬休みの宿題（勝手に自分で宿題化させているだけ）として取り組んだ、Github Actionsのneedsを活用して静的テストの並列化させた方法を紹介します。Github Actionsをあまり触れたことないという方でも理解できるよう内容だと思いますので、ぜひ最後まで読んでいただけると幸いです。 [AD] Offers MGR(オファーズマネージャー) 本記事で紹介する方法は、筆者が担当しているプロダクトである「Offers MGR(オファーズマネージャー) 」で活用されています。「Four Keys分析」や「サイクルタイム分析」など開発組織の生産性を最大化するために必要となる指標

まずは長いものに巻かれたいときもある Offers を運営している株式会社 overflow の あほむ でございます。 先日 コードベースのディレクトリ構成にフォーカスした記事 を公開した関連記事として、Next.js App Router をどのように取り扱っているかについてご紹介します。 【AD?】今回の記事の内容を含んだり含まなかったりすると思いますが、来週 2024/01/17(水) 19:20 〜 オンライン開催の PWA Night vol.59 で発表予定なので興味のある方はぜひ。（終了済み） 下記は本記事の内容を含むイベント発表資料です。ご参考までに。 今回の前提 前回記事 の引用ですが今回も同様です。 最終目標は単体事業でありつつ実質マルチプロダクトな画面群のリプレース クライアントサイドでヘビーなビジネスロジックを持つ必要がない アプリケーション特性としては SaaS

概要 こんにちは、Offers を運営している株式会社 overflow でフロントエンドのテックリードをしている Kazuya です。今回は、筆者が担当しているプロダクト「Offers MGR(オファーズマネージャー) 」で採用しているディレクトリ構成の一部について書かせていただきます。 後述しますが、「Offers MGR」では求められる要件が複雑且つ通信で取得する情報量が膨大であることからAPI関連のディレクトリ構成もやや特殊なものになっています。ベースは以前こちらの記事で紹介した「Viewsレイヤー」を拡張させる形になっています。 専用構成になっている感があるため、参考になるかは分かりませんが、ぜひ最後まで読んでいただけると幸いです。 Offersのディレクトリ構成はこちら 弊社フロントエンドのボスであるAhomu先生が担当されているOffers側のディレクトリ構成は以下の記事をご

こんにちは！ Offers, Offers MGR を運営している株式会社 overflow 所属、エンジニアの藤井です。 最近、既存機能のリプレースのため頻繁にデプロイ作業を繰り返していたのですが、Docker ビルドの時間が長くてイライラしていました。 Docker イメージのサイズは可能なかぎり最小を保つべきですが、それでも追加開発を繰り返せばギガバイト単位になってしまうことも珍しくはありません。 そうなると、Docker ビルドにかかる時間も長くなり、開発効率が落ちてしまいます。 そこで今回は、git-log を上手に使って無駄な Docker ビルドを回避する方法をご紹介します。 その前に、まずは Docker タグの戦略について考えていきます。 Dockerタグの戦略について Microsoft のドキュメント "Recommendations for tagging and

Offers を運営している株式会社 overflow の あほむ でございます。暖冬と言われつつもすっかり寒い季節ですね。おかげさまで割と走っているほうの師です。（師走） n 年ぶり n 回目の Web フロントエンド 最後にメイン開発者の立場でコードをスクラッチしたのいつだったっけ？と遡ると 2018年ごろのブログ記事 がでてきました💀 実際には 2017 年から 2018 年にかけての作品ですかね。当時の構想から読み取れる重厚かつ自己表現の感に内心苦笑いしつつ久々の新規建立です。 今回はディレクトリ構造の面から紹介していきます。 推しディレクトリの先達たち 推しディレクトリという言葉に乗っかってみたものの、ゴメンそこまでの熱感は持っていないかもしれない🥺 とはいえ先達の記事もご紹介しておきます。 今回の前提 本稿において、これらの前提に依存した論はほとんど含まれない認識ですが一応

プロダクト開発組織・人材を対象に、開発パフォーマンス・生産性の最大化インフラ Offers MGR と副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニアの shun です。今回は弊社でローンチしている Offers MGR を活用し、半年間開発チームの運営をしてきて取り組んできたことと、その成果について話せればと考えています。書き出すとかなりの量となったため、今回は一旦「変更障害率」の数値を見つつ改善した話をしたいと考えています。 モチベーション 2023年4月から、主にtoC側のプロダクト開発をするチームのリードとして振る舞うこととなりました。正直何もわからなかったので、一旦チームとしてのアウトプットは如何なる時でも重要であろうと考え、ちょうどリリースされたばかりの Offers MGR の FourKeys を用いて眺め、改善してみようと考えたの

こんにちは! 副業転職プラットフォーム Offers を運営している 株式会社overflow で主にフロントエンドエンジニアをしております、さわ(@hacksaw_a_)です! 私は自称 Notion 芸人マスターなのですが、アジャイル開発でのタスク管理を Notion でやるのがけっこう苦になってきた今日このごろです。 今回は Notion からタスク管理の移行を考えて Linear を使ってみたのでその感想を共有します! 公式の "Get Started" 進めてみる ※気になった点以外は割愛します ※最後に Pros/Cons ポイントをまとめてます🏃‍♂️💨 Github連携 目玉でしょうからもちろん連携しておきます コードの読み込み権限は不要(だから安心してね! ってことですね) 個人・組織(Organization)共に連携可能 どのリポジトリを連携するかの設定可能(全リ

概要 こんにちは、Offers を運営している株式会社 overflow でフロントエンドのテックリードをしている Kazuya です。今回は、筆者が担当しているプロダクト「Offers MGR(オファーズマネージャー) 」で前回の記事に掲載していた辞書ファイルを管理するSaaS「Localazy」について紹介させていただきます。 多言語対応で必要になる辞書ファイル（文字列リソース）の管理ですが、JSONにベタ書きして管理する方法やスプレッドシートなどを活用してミニマムに管理する方法などあると思います。ただ、中長期の運用や翻訳作業のコストなど課題をクリアできる手法を検討するのは難しいと思います。 そこで今回は、新規プロダクト開発で導入してみた「Localazy」について実際の利用方法や設定などを紹介していければと思いますので、ぜひ参考にしてもらえればと思います。 [AD] Offers M

実はOffersMGRでもDatadog Synthetic Test を用いてテストを行っていました。 しかし、シナリオが2つしか無くカバー範囲も狭く、デグレが起こっても検知出来ない状況でした。 今回のPlaywrightを使ったE2Eテストの導入では既存シナリオの移行とOffersMGRの全ページが健全に動作しているかのチェックを目的としました。 今後を見据えた設計と運用 BtoCももちろんですが、BtoBのプロダクトは特に成長していくとともに安定したサービス提供が求められるのでテストの重要度は高くなります。 そのため、E2Eテストや結合テストの拡充は必然的に実施していくことになります。 一応、特定のComponentに対象を絞る事によってE2Eテストでも結合テストが出来ます。 しかし、E2Eテストは結合テストと比べ実行速度が遅く、最終的なテスト量はE2Eテスト < 結合テストが理想で

概要 こんにちは、Offers を運営している株式会社 overflow でフロントエンドのテックリードをしている Kazuya です。今回は、筆者が担当しているプロダクト「Offers MGR(オファーズマネージャー) 」で先日実装した多言語対応について書かせていただきます。 近年はプロダクトがグローバル化していくケースが増加しており、それに伴い、WEBアプリケーションも英語や中国語をはじめとした複数言語のサポートをする必要がでてきていると思います。ただ、多言語化は実装する現場からするとやることが漠然としており、どのように進めればよいのか、構成はどのようにすればいいのかなど、多言語化をする際に考慮すべきことが多くあり、なかなか実行に移すのは難しいです。（筆者も右往左往していました） そこで今回は、新規プロダクト開発で実際に実装してみて得た知見をベースに多言語化の構成やポイントなどを紹介し

月$12を払うか、1700分を浮かすか - テストを実行時間ベースで分割し並列実行する話 | Offers Tech Blog こんにちは、プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow CTO の大谷旅人です。 今回は、CI(GitHub Actions)上のテストにかかる時間が長く、リリース時にテスト完了待ちで無駄な時間が発生しているというありがちな問題に対して、ワークフローだけ弄って 3 分でテスト時間半分にした結果改善されたのでそんなお話を。 リリースまでのフローと課題 参考までにその PJT でのリリースまでのフローは以下のような流れでした。 feature ブランチでのチェック完了後、develop ブランチ(メインライン) にマージ develop ブランチ(メインライン) にマージ後、以下が実行 2.2. SmokeTest

Offers を運営している株式会社 overflow の あほむ でございます。 本記事は Chrome Platform Status からなんとなく Proposed/In Development なステータスのフィーチャーを取り上げて、そのプロポーザルを眺めてみるシリーズです。前回は Media Queries Level 5 nav-controls でした。 追記 2023.10.10 form-sizing: fixed | content 紹介したそばから normal → fixed 、 auto → content に変更されていました。(IRCログ) 次項のサンプルコードは normal | auto のままですが使い方自体は変更されていないようです。 form-sizing ではなく field-sizing というプロパティ名への変更も提案されていてポジティブな流

Velocity（ベロシティ）とは、スプリントの期間内で完了できたタスクのストーリーポイントの合計値です。ストーリーポイントとは、タスクの規模感を示す数値になります。（この概念に筆者はだいぶ苦労しました。後半でどう突破したか説明します。） 極端に示すと、Velocity の最小・最大幅で見たときに 2.7 倍(約 3 倍とさせてください w)の Velocity 向上となりました。[1] スクラムを実施しているチーム構成 まず、上記の実績を出したチーム構成は以下です。本来のスクラムではマーケ人員はあまり登場しないイメージがありますが、弊社の場合はプロダクト開発の進捗によって日々のマーケターの動きに影響するケースがあるため、参加してもらっています。 スクラムマスター(1 人) ※筆者がエンジニアと兼業している PdM(1 人) デザイナー(1 人) エンジニア(2 人) マーケ(1 人) 私

はじめに こんにちは。 プロダクト開発組織・人材を対象に、開発パフォーマンス・生産性の最大化インフラ Offers MGR と副業転職プラットフォーム Offersを運営する株式会社 overflow のエンジニアの藤井です。 みなさま、実装の前にきちんと設計のドキュメントを作成していますでしょうか？ 昔、私が働いていた大手 SIer の現場では、 ・・・といったように、じつに事細かな設計工程が組まれておりました。 しかし事業会社の開発組織で、このような工程を採用している現場は稀でしょう。 特にスタートアップの、ごく少人数でビルド＆スクラップを繰り返す製品のローンチ段階では、"<b>実装こそ仕様！　ドキュメントなどない！</b>"というストロングスタイルが必要だったりします。 そのため、その後もドキュメントを残す文化が根付きづらい、という話もよく聞きます。 (その点、弊社はドキュメンテーシ

こんにちは、プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow CTO の大谷旅人です。 昨今は登壇やらモデレーターやら、サービス開発やら、次男の中学受験やら、猫ちゃん飼育やらで何かとせわしなく時が過ぎる毎日です。 というわけで、2023 年 2 月 9 日に開催された Developers Summit 2023 で登壇してきましたので、その様子をご紹介します。 Developers Summit 2023 発表内容 弊社 overflow は、副業転職プラットフォーム Offers の開発、運用をしています。 サービス開始してから 3 年、その前も含めると 6 年の組織運用の中で起きたことをベースに 定量評価は、組織が疲弊する (用法、用量をまもらないと) というテーマで開発生産性についてお話をしました。 組織の成長に伴い、どのように定量評