Rails: モジュール化強制ツール"Packwerk"の導入を振り返る（翻訳）｜TechRacho by BPS株式会社
概要 原著者Chris Salzbergさんの許諾を得て翻訳・公開いたします。 英語記事: A Packwerk Retrospective | Rails at Scale 原文公開日: 2024/01/26 原著者: Gannon McGibbon、Chris Salzberg 日本語タイトルは内容に即したものにしました。また、一部のパラグラフを分割しています。 CC BY-NC-SA 4.0 Deed | 表示 - 非営利 - 継承 4.0 国際 | Creative Commons Rails: モジュール化強制ツールPackwerkの導入を振り返る（翻訳） 2020年、ShopifyのチームはPackwerkという名前のRuby gemをリリースしました（関連記事）。Packwerkは、Railsアプリケーション内で境界を強制的に定めてモジュール化するツールです。Packwerk
イベント設計のシンプルなヒューリスティック「誰が誰を呼ぶべきか？」（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Who calls who? — a simple events heuristic | Arkency Blog 原文公開日: 2023/11/20 原著者: Tomasz Stolarczyk 日本語タイトルは内容に即したものにしました。 2つのコンポーネントを統合するとき、両者間の通信に使いたいコマンドやイベントをどちらのコンポーネントが所有すべきかで悩んだことはありませんか？今回は、そうした決定を下すときに役立つ手軽なヒューリスティック（発見的方法）を紹介します。 このヒューリスティックは、コンポーネント内でどの程度頻繁に変更が発生するかに依存します。実践する前に、これらのコンポーネント同士の関係を視覚化する必要があります。 コンテキストマッピング（Context Mapping）は、1個の境界付きコンテキスト（Boun
簡単そうで難しい要件定義：サービスメンテナンス機能編｜TechRacho by BPS株式会社
morimorihogeです。今年もTechRachoアドベントカレンダーを実施します。TechRachoを運営している弊社（BPS株式会社）及び弊社にご縁のある会社・個人の記事を公開していきますので、皆様お楽しみに！ さて、僕は職位としてはマネージャ職に当たりますが、良くある開発チームの例に漏れずちょいちょいチームの手が足りない所ではプロジェクト管理や設計、実装に入ったりすることもあります。上流から実装・運用までやるいわゆるなんでも屋ですね。 そんな中で上流設計・要件定義を詰めていく役割もよくやることがあるので、今回はその辺りの内容がテーマです。 開発現場のエンジニアはもちろんですが、ビジネスサイドでエンジニアチームに機能要望を出したりする人にもぜひ読んで欲しいと思いながらまとめていこうと思います。 今も昔も割とふわっとした要望をもらうことが多いのが「サービスメンテナンス機能」です。 い
Railsで学ぶSOLID（2）オープン/クローズの原則（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: SOLID Principles #2: Open/Closed Principle | Netguru Blog on Ruby/Ruby on Rails 原文公開日: 2018/03/09 著者: Marcin Jakubowski サイト: netguru 訳注: 「オープン/クローズド」とされることもありますが、本シリーズでは「オープン/クローズ」で統一しました。 「SOLIDの原則シリーズ」へようこそ。このシリーズ記事では、SOLIDの原則をひとつずつ詳しく説明し、分析します。シリーズの最後にはいくつかのヒントや考察を含む総括記事をお送りしますのでどうぞご期待ください。 それでは始めましょう。「SOLIDの原則」とはそもそも何なのでしょうか？SOLIDとは、オブジェクト指向プログラミング設計における一般的な原則であり、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
