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

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

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

Offers を運営している株式会社 overflow の あほむ でございます。 10年越しのWebフロントエンド 最近更新していない 自分のブログ を遡ると「フロントエンド」という語の初出は 2010 年であり、転職のタイミングで自らを「Web フロントエンドエンジニア」と定義したのは 2012 年の頃でした。 それから 10 年、自分語りとして記憶をたぐることの老害仕草たるやですが、今回はそのノリのまま表題の通り Web フロントエンドという職種界隈についての考えを述べてみます。 Webフロントエンドとは一体... 先日、TechFeed Experts Night#4 〜 フロントエンドアーキテクチャを語る でお話しする機会をいただいたので改めて自分の中の Web フロントエンドを言語化してみました。 イベント資料 より抜粋 いくら抽象化しても原則としては全てが HTML で表現さ

Offers を運営している株式会社 overflow の あほむ でございます。 本記事は Chrome Platform Status からなんとなく Proposed なステータスのフィーチャーを取り上げて、そのプロポーザルを眺めてみるシリーズです。前回は prefers-reduced-data でした。 Web におけるテキスト入力をシンプルに統合する API 今回は EditContext API を眺めてみます。本当に眺めるだけで深入りしないので概要のみのライトな記事とご認識ください。 大昔お世話になった contenteditable 周辺の事情にも革命が起こらないものだろうかと思う今日この頃です。 CSS Custom Highlight API を取り上げたときこのように書きましたが、Chrome Platform Status を眺めていたらそれっぽい API があっ

Offers を運営している株式会社 overflow の あほむ でございます。 本記事は Chrome Platform Status からなんとなく Proposed なステータスのフィーチャーを取り上げて、そのプロポーザルを眺めてみるシリーズです。前回は CSS Anchored Positioning でした。 HTMLVideoElement 以外も Picture-in-Picture したい 今回は Document Picture-in-Picture を眺めてみます。本当に眺めるだけで深入りしないので概要のみのライトな記事とご認識ください。 専用の Window を丸ごと PiP すればいいじゃない！ Picture in Picture (以下 PiP) は動画コンテンツ等を画面隅などに置かれる小さな表示領域で独立して再生させる一種のマルチウィンドウ UI です。現在

概要 こんにちは、Offers を運営している株式会社 overflow のバックエンドエンジニアの shun です。今回は、GAS（Google Apps Script）のコードの書き方と、ゴリゴリに GAS を書きまくってきた知見から少しのテクニックを紹介できればと思います。 今の時代、エンジニアリングを利用した業務自動化を実装するのは必ずしもエンジニアだけではないと思っています。ちょっとしたデイリー業務, 対応漏れ確認 など、サクッと自分の業務のサポートをしてくれる相方を、職種問わずに自分自身で実装ができる世界になっています。その大きな協力者になるのが今回ご紹介する GAS（Google Apps Script）となります。 GAS（Google Apps Script） とは？ GAS（Google Apps Script） とは、Google が開発した JavaScript 記

概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々

Offers を運営している株式会社 overflow の あほむ でございます。今回は個人的に気になって調べてみた系のネタを散漫に書いたブログです。 ダークモードに対する疑問の発端 美観やバッテリーパフォーマンス[1]を理由とする話を念頭に置きつつ OS レイヤーにおける UI のスイッチングは自動で行われるとして、モバイルアプリや Web の個々の提供者が向き合う必然性はどこにあるのでしょうか？ Web で実装するときは prefers-color-scheme を使って CSS Custom Properties で宣言されたカラーパレットを切り替えることになります。モダンブラウザのサポートが充実しているので実装上の難関はありません。よって本記事では何のためにダークモード[2]を提供するのかという動機付けの理解を目的とします。 ダークモードの存在を肯定しうる理由たち よく目にする主要

まえがき こんにちは、Offers を運営している株式会社 overflow CTO の 大谷旅人 です。 小ネタです。 弊社では Ruby/Rails をバックエンドの開発言語として採用しており、その柔軟性は開発の大きな助けとなっている面がありつつも、コードベース全体の規模増加や保守効率を考えて環境自体の見直しや、段階的な新環境への移行も行っています。 その中で、今回は Ruby での開発体験を向上させるために行っていた、静的型解析の導入に関してのお話です。 型安全性な環境(TypeScript,Rust,etc..)から Ruby に戻ってくるとやはりあっちは機構が勝手にチェックしてくれていいぞいいぞと思うわけで、 C#が dynamic 型で静的型言語なのに動的型付していたり, Python が type hints で型検査してたりを見ると、どうにかこうにか導入したいと日々思ってい

はじめに こんにちは！Offers を運営している株式会社 overflow の バックエンドエンジニアの takkun7171 です。 前回に引き続き、個人的に大事だと思ってる、 ノウハウ・心構えを書いていこうと思います。 前回の記事 前回はハードスキル中心だったのですが、 今回はソフトスキル中心でまとめてみました。 かなり主観が混じってるので、賛否両論あると思いますが、 エンジニアのいち意見として緩く見てもらうと幸いです。 【エンジニアの勉強について】 若い人から学ぶ姿勢を持つ 当たり前ですけど長く働いていると、 同じ業界で働く人が自分より若い人だらけということになります。 当然ながら、若くて優秀な人から学ぶ、謙虚な姿勢を持つのは必要になってきます。 その時代のモダンな作り方、技術にキャッチアップできれば、 それまでの歴史や経緯について深く知らなくても、仕事出来てしまいます。 ぶっちゃ

はじめに こんにちは！Offers を運営している株式会社 overflow の バックエンドエンジニアの takkun7171 です。 エルデンリングをクリアして、Apex のランクを再開したところ、 初のソロダイヤを達成しますた。齢 40 過ぎのオッサンでも、やればできるんだから！！w さて、技術ブログなんですが、今回は技術というよりも Web エンジニアとして個人的に大事だと思ってる、ノウハウ・心構えについて 書いてみようかなと考えてます。 初心者向けというわけではないのですが、 4 月ですし、新人エンジニアの方も増えるということで 初心者の方にも読んで頂きたいです。 そこそこ分量があるので、前後編に分けて、 前編はハードスキル中心、後編はソフトスキル中心で書いてみます。 後編の記事 自分はマネージャーでも CTO でもなく一介のエンジニアでしかありませんが、 Web エンジニア歴は

概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。2022 年 2 月入社でそこまで日が経っていないので、今回は社内の技術スタックではなく、今後社内でも検討されるかもしれない「BFF」について触れていきたいと思います。BFF（Backend For Frontend）導入することで得られるメリット/デメリット、GraphQL を用いた技術スタック事例など紹介していますので、ぜひ参考にしてもらえればと思います。 BFF とは？ BFF とは、Backend For Frontendの略称で、「フロントエンドとバックエンドの中間に配置され双方の複雑な処理を緩和させる責務を持つアーキテクチャ設計パターン」のことです。これだけだと分かりづらいので簡単にまとめると、「バックエンドの API

プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow VPoE の あほむ でございます。 今回は Offers エンジニアリングチーム[1]においてリーダーやマネージャーといった職務をどのように捉えているかについて紹介させてください。なにかのご縁があって弊社にご興味をもってくださった方のご参考になれば幸いです！ エンジニアリング組織のリーダー、マネージャーの扱い 所属する組織の中で「リーダーシップを発揮してほしい」とか「リーダー経験がないとこれ以上評価できない」とかのコミュニケーションをとった/とられたことがある方も少なくないのではないでしょうか。 こういったコミュニケーションの背景には 「組織としてリーダーシップを発揮できる人材を欲している」 という意図や 「評価上の分かりやすい材料を欲している」 などの事情があると考えられます。 そんなこと

プロダクト開発人材の副業転職プラットフォーム Offers を開発している、株式会社 overflow にて EM をやっております磯崎と申します。 日々プロダクトを開発している中で、様々な格闘があるかと思いますが、その中でも大分格闘してきた Open API を用いたスキーマ駆動開発について今回は書いてます。 この構成で運用してよかったと今のところは思ってますが、色々面倒な事や落とし穴にも直面してきました。自分たちの中に溜まっている知識を書き記していくのでどこかでお役に立てればハッピーです ☺️ 最初に API を定義、その後開発を進めていくスキーマ駆動開発 そもそもスキーマ駆動開発とは、はじめに API を定義し、それを元にフロントエンド・バックエンドと開発を同時に進めていく開発フローです。 フロント実装においては通信部分で、「何を送信すべきか」、「何が返ってくるのか」を予め決まった状