1 年以上前から、チームメンバーの提案で Container/Presentational パターンを現代的にアレンジした設計を導入し、徐々に改良を重ねてきました。 Hooks が普及して、関数コンポーネント内で状態管理や API 呼び出しができるようになって便利になった一方で、いくつかの困りごとがありました。 「見た目だけテストしたいのに、なんで API モックの準備が必要なんだろう...？」 「このコンポーネント、何の責務を持ってるんだっけ...？」 「新しいメンバーが入ったとき、どこを変更すればいいか分からない...」 確かにファイル数は Hooks だけの時より増えてしまいますが、責務分離により各ファイルが単純になり、特にチーム開発では「単純明快なルール」の方がうまく機能することが分かってきました。 そこで、一時期「もう古い」と言われがちだった Container/Presenta

バリデーション解体新書 2025/4/8に開催した #アーキ部 『バリデーション解体新書』の内容を編集したものです。 バリデーションとは何か? 広義には、 何らかの処理を実施するにあたって、入力データが想定する条件を満たすかを検証する行為 と言える。 この定義で、アプリケーションのどこでバリデーションをしているのかを考えると、以下のように各層にそれが見られる。 このように実装される場所が散らばるので、「バリデーション」や「入力チェック」を分類して開発ガイドラインを作ることが多い。 例えば、大規模Java開発向けのTERASOLUNA開発ガイドラインを見てみると、 ユーザーが入力した値が不正かどうかを検証することは必須である。 入力値の検証は大きく分けて、 1. 長さや形式など、文脈によらず入力値だけを見て、それが妥当かどうかを判定できる検証 2. システムの状態によって入力値が妥当かどうか

はじめに こんにちは、普段 Ubie で症状検索エンジンユビー(https://ubie.app/)の開発をしている江崎です。 最近、Cursor エディタや GitHub Copilot などのコーディングアシスタントツールが進化し続けていますが、社内固有のデザインシステムとの連携はまだまだ課題が残っていました。そこで社内エンジニアである sosuke とともに、Ubie Vitals というデザインシステムを MCP サーバー化することで、UI 開発の速度と精度が劇的に向上した体験を共有します。 目次 デザインシステムと開発の現状課題 MCP サーバーの登場 Ubie UI MCP の構築 デモ テキストだけで UI 実装が可能に デザイナーの壁打ち相手としての可能性 今後の展望 デザインシステムと開発の現状課題 Ubie では「Ubie Vitals」というデザインシステムに則って

はじめに GitHub Actions (GHA)、便利ですよね。 便利なんですが、たまに「え、そんな仕様だっけ？」みたいなワナに遭遇します。そして毎回忘れてワナにハマってしまいます。 今後そんなワナにハマって時間を無駄にしないよう、ワナ仕様について網羅していきます。 対象読者 GitHub Actions を使い倒したい方 割と大きめな規模の GitHub Actions を構成している方 初級編 run を複数行で書くときの記法 GHA というか YAML の記法です。いきなり GHA から外れてすみません 💦 が、よく忘れるので覚えておくと助かります。以下の 2 種類を覚えておけば、ほとんどの場合事足りると思います。 | は改行を改行として実行する

本スライドはオブジェクト指向プログラミング（OOP）を理解しているバックエンドエンジニアの方向けに、フロントエンドのコンポーネント指向を解説することで、フロントエンドを開発するための足がかりを作ることが狙いです。OOPとの違いを意識することで、フロントエンド特有の設計思考を身につけましょう。Reactと…

“見積り” を作成した開発チームと、それを確認したビジネス担当者や経営者が、その内容を巡って対立することがあります。「見積りが大き過ぎる」「いや、これぐらいはかかりますよ」といったあのやり取りです。 これはおそらく、両者がともに “見積り” と “計画” を区別せず、混同しているから発生しています。見積り依頼を受けた時、開発チームが提出するものは、おそらく “見積り” です。しかし、ビジネス担当者や経営者が期待するアウトプットは “計画” なのです。 こうして “見積り依頼” という名のもとに、ソフトウェア組織に対立が日々生じているのではないでしょうか。 “見積り” と “計画” は別物見積り結果の「30人月」という数字（①）は、計画ではなく見積り工数です。そんなことは当たり前ですよね。 工数が明らかになれば計画なのか？それでは、30人月の開発を5人でこなすから「6か月」かかる（②）、とい

GitHub Advent Calendar 2024の14日目の記事です。昨日はwa-chan222さんの未経験から始めたGitHub活用の基本と学びでした。 はじめにフューチャー社内の有志メンバーでGitブランチフローの規約を作成しました。 ひとまずは形になったので紹介します。 Gitブランチフロー規約 | Future Enterprise Coding Standards ※GitHub/GitLabを利用し、トランクベース開発を採用しないアプリケーション開発を想定しています。 内容へのフィードバックは、Issueかツイッター宛にメンションを入れてコメントを貰えると幸いです。 なぜ今更Git？Gitは2005年に公開され、2007年のGitHub登場以降、バージョン管理ツールとして爆発的に普及しました。現在では、業界のデファクトスタンダードと呼べるほどの地位を確立しています。 公開

以下の公開計測会でやったものを個別に解説してみる。 細かいテクニックが多いのだが、それを可能な限りテキストとスクショで解説したい。使い方の解説が中心で、どういう意味があるかは解説しない。 Chrome131時点のスクリーンショットで、後で読む場合は頻繁にUIが変わっている点に注意。大事なのは意図。 宣伝: これを御社のサイトで解説する仕事をやっています。 デモのURL これに意味はなく、今日偶然見ていただけで意図はない。関係ないがエッジランナーズは最高のアニメ。 DevTools を開く F12 or 右クリックから「検証」 DevTools > Lighthouse この状態で計測 このとき、新しいプロファイルを作ったりして、可能な限り Chrome拡張が入ってない状態にすること。Chrome拡張による処理も計測に含まれてしまう。 Lighthouse レポートの読み方 点数部分にマウス

「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な

（まだ書いてる途中）僕がシニアエンジニアとしてどのようにアジャイル開発を実践しているかの現在地を紹介します。アジャイルな開発に取り組んでいるみなさんにとって何かしら、ヒントや刺激になるようなものがあると嬉しいです。

このYouTubeライブはフロントエンドの最適化を専門にするmizchiさんがCloudflare Meet-up Tokyoで行った同タイトルのプレゼンを、RustやRDBの実装に詳しいkoba789さんを話し相手に語っていくというものだ。背景としては2人ともチーム開発の現場でのRailsが活発に利用されていた時期にウェブ開発を経験し、現在はNode.jsのサーバーサイドも実践している。 ライブは3時間半という長時間におよび、スライド外の周辺情報や持論や余談など多岐に渡るので、すでにこのプレゼンに触れた人でもさらに深掘りできるようなコンテンツになっている。 全体を大まかに1時間ごとの3パートに区切って視聴するとわかりやすい。前半はRailsからNext.jsに辿り着くまでのウェブ開発の変遷。ORMの話は主に後半戦で。最後の1時間はアフタートークになっている。 内容としてはRailsアプリ

builderscon 2024 で発表した資料です。以下、トーク概要です。 Webアプリケーションを開発・運用していく中で、1つのテーブルに日時カラムが増えていったり、巨大なテーブルが爆誕した、という経験はありませんか。また、これがプログラムの複雑さに繋がることもあると思います。このような事態を…

tl;dr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビュ

前からずっと言いたかったことがある。同じ過ちを犯すゲーム開発者に。あるいは、「ゲームを完成させた体験が無い人」に。 あなたのゲーム開発に対する予測は、ほとんどの場合正しくない。それも、20%や40%などの振れ幅ではない。200%とか400%のスケールで大きく間違っている。 私はその感覚を確かめるべく一つのアンケートを実施した。結果は火を見るより明らかな傾向を示した。 個人ゲーム開発者に質問です。「１年で完成させる」と思って作り始めたプロジェクト、実際に完成したのは？ — じーくどらむす/岩本翔 (@geekdrums) June 4, 2024 Twitterアンケートの統計的な正しさは保証しない。そもそも母集団が偏っているし、最後の選択肢が「未完成」を含めていることに対して「４年以内に諦めて未完成」の人も含めているかもしれない。が、エターナったという意味では４年以上完成しないもの、に含め

昨日うるう日にしか発生しないバグに遭遇した。Javascriptを書く人には有名な話だとは思うので大して面白くはないかもしれないが一応メモ。 詳しくは書けないがバグが発生した関数の仕様としてはざっくりと下記のような感じ。 対象の年月日が基準日の1年前から1年後の間に含まれる場合はtrueを返しそうでない場合はfalseを返す 引数として2020-12-24というフォーマットの文字列が渡される(判定対象の日) 引数として2021-01-01というフォーマットの文字列が渡される(+-1年の基準日) Javascriptで書く (例) 対象の日: 2024/10/10 基準日: 2024/01/28 この時、trueになる範囲は2023/01/28 ~ 2025/01/28。なので2024/10/10はtrue。2023/01/28も2025/01/28もtrueになる。閉区間。 とあるコードの

保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発⁠⁠、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ

Badプラクティスを選んで失敗しながら進めた新規プロダクト開発/Develop a new product with bad practices

アジャイルチームが変化し続けるための組織文化とマネジメント・アプローチ / Agile management that enables ever-changing teams