第4回 テストダブル ～忠実性と決定性のトレードオフを理解する～ | gihyo.jp
自動テストを書く際に使いどころをマスターしたいテクニックがテストダブル（Test Double）です。テストダブルを効果的に使えばテストの網羅性、速度、再現性を向上させますが、使いどころを誤れば変更や改善の妨げになりかねません。今回は、テストダブルの利点と注意点をまとめます。 テストダブルとは何か テストダブルとは、自動テストに使用する偽物、代用品のことです。たとえば、データベースや外部サービスの動作を模倣した偽物（テストダブル）を作り、自動テストから使います。 自動テストで偽物を活用するテクニックを「モック」（Mock）と呼ぶ方も多いですが、より正確には、テストに偽物を使う技術を総称してテストダブルと呼びます。この場合の「ダブル」は身代わりや影武者のようなイメージでとらえてください。テストに使う身代わりなのでテストダブルです。テストダブルの種類として詳しくはスタブ（Stub）、スパ
【第1回・前編】 エンジニア和田卓人の今を形作る技術 | GeeklyMedia(ギークリーメディア) | Geekly（ギークリー） IT・Web・ゲーム業界専門の人材紹介会社
『テスト駆動開発』や『SQLアンチパターン』をはじめとする技術書の翻訳者、さまざまなIT企業をわたり歩く技術顧問、さらに最近ではエンジニアリング文化を伝える講演者としても活躍されている和田卓人さん(https://twitter.com/t_wada)。 そのソフトウェアエンジニアとしての素顔を株式会社一休CTOの伊藤直也さん(https://twitter.com/naoya_ito)が聞き出す対談の前編では、一線を画すエンジニアであり続けるために自らのプロジェクトで意識的にコードを書いているという和田さんの姿勢に始まり、ベテランとして「技術のらせん」を読み解くケーススタディとしてDDD（Domain-Driven Design）を題材に話を伺います。 ・伊藤 直也さん / 株式会社 一休 執行役員 CTO 新卒入社したニフティ株式会社でブログサービス「ココログ」を立ち上げ、CTOを務め
martinfowler.com
Software development is a young profession, and we are still learning the techniques and building the tools to do it effectively. I've been involved in this activity for over three decades and in the last two I've been writing on this website about patterns and practices that make it easier to build useful software. The site began as a place to put my own writing, but I also use it to publish arti
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
Popular React Folder Structures and Screaming Architecture
Screaming ArchitectureEvolution of a React folder structure and why to group by features right away React folder structures have been debated for years due to React's unopinionated approach, leading developers to ask, "Where should I put my files? How should I organize my code?" I've researched the most popular approaches to organizing React projects: Grouping by file type like components, context
正しいクラウドはある意味で遅い - Software Transactional Memo
TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは
Colocation
We all want to have codebases that are easy to maintain, so we start out with the best of intentions to make our codebase (or our corner of the codebase) maintainable and easy to understand. Over time, as a codebase grows, it can become more and more difficult to manage dependencies (JS, CSS, images, etc.). As projects grow, an increasing amount of your codebase becomes "tribal knowledge" (knowled
GraphQL の Fragment Colocation を導入したら依存関係がスッキリしてクエリもコンポーネントも書きやすくなった
この記事は Money Forward Engineering 1 Advent Calendar 2022 11 日目の投稿です 🎄 昨日 10 日目は cabossoldir さんによる 『コードレビューのとき、私は何をレビューしているのか？』 でした。 🙈 TL;DR Fragment Colocation とは、コンポーネントが必要とするデータを Fragment にまとめてコンポーネントと同じ場所に配置 (co-locate) すること Fragment Colocation を導入することで、「Query や Mutation を実行するコンポーネント」と、「それらの結果を必要とするコンポーネント」との関心の分離ができる Query, Mutation, Fragment はそれを実行するあるいは必要とするコンポーネントと同じファイル内に宣言すると依存関係が見やすく、変更が
「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
レイヤードアーキテクチャを振り返る - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
クリーンアーキテクチャ(The Clean Architecture翻訳)
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
再利用可能なコンポーネントはアンチパターン - ジンジャー研究室
言いたいこと Webフロントエンド界隈で「コンポーネント」という言葉が蔓延していて、「再利用可能になるように設計すべきだ」という論調があるが、実際には本当に再利用可能である必要性があるまで、極力考えないほうが良い。YAGNIとも言う。 以下、現時点での考え。 ビューの階層化自体はOK ここはReactの恩恵と言っても良い気がしていて、それまであんまり明言されて来なかった「ビューの階層化」について公式で説明している点がとても良くて、開発者全員がビューはツリーになってるよねというマインドで統一できた功績は大きいと思う。 再利用可能なコンポーネント ビューはツリーでいいんだけど、それをコンポーネントと呼んでいるのでなんとなくDatePickerとかTextEditorみたいな汎用的なものを想像して、「アプリケーションの事情を知っていてはいけない」という気持ちになって疎結合に作りたくなってしまう。
Webフロントエンドと アーキテクチャ事情の持論を喋る
PDF 版: https://s.aho.mu/220922-techfeed_expert_night_4.pdf TechFeed Experts Night#4 〜 フロントエンドアーキテクチャを語る https://techfeed.io/events/techfeed-experts-night-4 でフロントエンド設計をテーマとして使用したスライドです。本編5分。 ===== ▼ 元データで参考リンクとして張っていた URL たち SPA/MPA 議論の俯瞰と現代における設計のポイント（あほむ） — TechFeed Conference 2022講演より - TechFeed The "Developer Experience" Bait-and-Switch - Infrequently Noted The Cost of Javascript Frameworks - W
Domain Modeling Made Functional を読んだ - 詩と創作・思索のひろば
最近フロントエンドに限らず TypeScript を書くことが多くなって、これでそれなりの規模のサーバサイドアプリケーションを書くときどうなるんだろう、と気になって読んでみた。いわゆる普通のオブジェクト指向ではなく関数指向な書き方でいきたいとき、どうするのが好ましいのか、というような観点。 名前的にそのものずばり、という本があったので購入した。日本のウェブを検索してみてもいくらか言及があるので価値はありそうだという判断で、大人なので円安でも強行する。 Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F# (English Edition) 作者:Wlaschin, ScottPragmatic BookshelfAmazon 自分は PDF で読みたかったので
「50%の完成度でサービスを出す」という言葉を誤解してはいけない
はてなの近藤社長の、「５０％完成度でサービスを出す」という指摘は、まさに「ソフトウェアはサービス」の時代を反映する、ものすごく意味のある言葉だが、万が一勘違いする人がいると困るので、自戒も含めて補足しておく。 ここで言う「５０％の完成度」とは、「サービスとして『完成品』と呼ぶにはまだ機能が十分揃っていない」という意味の完成度を指し、決して「アーキテクチャーや不完全だったり、明らかなバグがあるのにサービスインしてかまわない」という意味ではないので注意が必要だ。 少し前に、私の会社で外部のエンジニアを使ってあるウェブ・サービスを作ったことがあるのだが、慣れていない人にプロジェクトのマネージメントをさせてしまったために（これは私のミス）、一応外見上は動いているものが出来てきたものの、スケーラビリティに明らかな問題があり、ユーザーの数が増えたときに破綻するようなものが出来てきてしまったのだ。 担当
プログラミングに必要なブレイクスルー
Yoyo Code (Matyáš Racek's blog)より。 ソフトウェアの開発方法を劇的に変えるには、いくつかのブレイクスルーが必要だと感じています。ブレイクスルーといった場合、それは大きなブレイクスルーを意味します。例えば、「構造化プログラミング」のブレイクスルーのようなもので、プログラミングに対する私たちの考え方を完全に変えてしまうようなものです。ここでは、それに関するいくつかの見解とアイデアを紹介します。 グルーコードや定型文を書くのは無駄だ 私が書くコードのほとんどは、面白いことはするわけではなく、定型文か、サブシステム同士を繋ぐための糊のようなものです。この種のコードは、すでに何度も書かれていて、これからも何度も書かれるような気がします。それなのに、なぜまた書かなければならないのでしょうか? 問題は、コードがかなり異なっていることで、通常は既存のコードをそのまま使うこと
営業日などの規則性と例外を扱うための設計
解決したい問題 例として、飲食店の予約サービスを考える。 予約を受け付けるためには各店舗の営業スケジュールを管理しておいて、営業日の営業時間内のみ予約を受け付けるようにする必要がある。 たとえば、ある店舗は各曜日の営業時間について、以下のように定めているとする。 平日：11:30-22:00 土曜日：11:00-22:00 日曜日：11:00-21:00 定休日：木曜日 これを素朴に設計すると、たとえば以下のような「営業日については営業時間を保持し、定休日についてはレコードがない」というテーブルになるかもしれない。 店舗 曜日 開店時刻 閉店時刻
Reactでロジックをhooksにまとめないという選択肢 - Hello Tech
javascripterです。ハローでは、プロダクトのローンチ前からAutoReserve の開発に関わっています。 突然ですが、Reactを使用する際、コンポネントのロジックや状態が増えてきたとき、みなさんはどうされてるでしょうか。 関数コンポネントでは、一般にcustom hooksとしてまとめて切り出すことが多く行われていると思います。 今回の記事では、useState/useRef + custom hooksという単位で切り出すのではなく、 クロージャを使いロジックや状態をコンポネントの外に持たせるようにリファクタリングすることで、コードの見通しが良くなる、という事例を紹介します。 JavaScriptにおけるクロージャとは、関数が外側のスコープの変数などへの参照を保持できる機能のことです。ここではクロージャとして実装しましたが、同等のことはclassを使っても実装できます。 A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cookpad TechConf 2022 - About PJ Takanawa (Hiromu Miyazaki)