「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
デザインの「悪い方がよい」原則 The Rise of "Worse is Better"
デザインの「悪い方がよい」原則 The Rise of "Worse is Better" rpg@lucid.com 日本語訳: daiti-m@is.aist-nara.ac.jp 私や Common Lisp と CLOS のデザイナーのほとんどは、MIT/Stanford 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同
オブジェクト指向Rails - よりよいコントローラーを書く - 有頂天Ruby
Ruby 5で紹介されていたObject Oriented Rails - Writing better controllers - Pivotal Labsの訳です。(翻訳の質はうんこかもしれません、元記事読みましょう) 私は最近、Objective-Cを使ってiOS、Javaを使ってAndroid、たくさんのモバイル開発をしている。 私はRuby開発者でもあるので、それらの言語やフレームワークから学んだことを可能な限りRubyでも試し、適用してみようとするのは当然のことだろう。 今日はRailsアプリでよりよいコントローラを書くため、僕のベストを尽くそうと思う。 私はAndroidやiOS向けのアプリを書くとき、スタブやモックを使わないよう、自分自身に強制している。それは、オブジェクトの設計を向上させ、DI(依存性の注入)を使ってテストを書くことを意図している。 では、コードの例を見て
Apache Kafkaを使ったアプリ設計で反省している件を正直ベースで話す
Apache Kafka: Producer, Broker and Consumer2017年は生まれて始めてApache Kafkaを本格的に業務利用（PoCではなく本番運用）した年でした。Apache Kafka的なメッセージングミドルウェアそのもののは、社内的な事情でよく使っていたのでその使い勝手に対して困惑はほとんど無かったですし、ミドルウェアとして非常に安定しているため、Kafkaクラスタそのものでの不具合らしい不具合が発生したことは一度もありませんでした。 しかし、Kafkaのトピック設計などに関してのベストプラクティスは事例ベースでもあまり見かけたことがなく、チームメンバーと悩むことも多かったです。このストーリーでは、主にKafkaを利用したアプリ設計で考えたことや失敗したことを振り返りつつ共有します。なお、パーティション数や各種バッファサイズなどのチューニング要素は今回取
DBリファクタリングの勘所と所感 - そーだいなるらくがき帳
表題についてそーだいなる見解を書き残します。 今年の夏に id:koemu さんにbuilderconの懇親会で下記のような話をいただいていました。 懇親会で、DB側ばかりでなくプログラム側でも適切なドメインモデルの設計ができていれば、リファクタリング時の影響範囲がさらに小さくできるのでは？という話をしたところ、この辺りはアンサーブログを書いてくれるかもしれないってことなので期待しています！！！ www.koemu.com 忘れてないんですよ！しっかり覚えています。 結論 仰る通りだと思うし、適切なドメインモデルはRDBに限らずデータストア層のリファクタリングの負担を大きく減らすと思います。 ここから先は僕なりの考え方を書きます。 実は似たような話を PHPの現場 っていうポッドキャストでも触れています。 php-genba.shin1x1.com システムの柔軟性 勿論、コードの綺麗さや
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
Node.js + GraphQLでBFFを作った話 - Qiita
whoami @qsona (Twitter, GitHub, Qiita) Node.js developer FiNC 2016/2 〜 Ruby, Rails / MySQL love microservices! Microservices Meetup 主催 昨日3/30に開催: vol.5 (API Gateway & BFF) BFF とは? Backends for Frontends の略 クライアントとバックエンドの中間にサーバを置き、フロントエンド寄りの処理を行う Microservicesの文脈で語られることが多い 昨日の会長のスライド step by step BFF GraphQL とは? クエリー型 Web API RESTful API において問題になりがちな点をカバーしている 仕様として定められている (RESTfulはあくまでAPI設計の指針) Nod
form objectを使ってみよう - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。 Ruby化のプロジェクトが始まって1年が過ぎました。新しいメンバーも入り、Railsのコード量は日に日に多くなっています。可読性を保ちつつアプリケーションを大きくしていくために、使える知見をチームメンバーに効率よく伝えていくのが大事だと感じる今日このごろです。 普段メドピア内ではコードレビューや社内勉強会などで知識のシェアを行っています。そんなとき、ブログ記事や書籍などのまとまった文章があると「これ読んでおいて」と言うだけで良くなるので楽です。先日form objectを使ったほうがいいですよーという内容でレビューコメントをつけようとしたところ、日本語で詳しくまとまった文章が見当たりませんでした＞＜なければ自分で書くしかありません。そこで今回はRailsにおいて可読性を保つための知見である、form o
Essential RubyOnRails patterns — part 1: Service Objects
as seen by RubyOnRails Developers @ Selleo Service objects (sometimes referred to as services) is a holy grail in Ruby On Rails development that helps to decompose your fat ActiveRecord models and keep your controllers slim and readable. When to use Service Objects?The pattern is so simple and powerful that it may become a bit overused in time; it is particularly useful when we need a place to def
オーバーエンジニアリングの正体とその向き合い方 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) 問題は細部（あるいはその欠如）にあり。 議論とは、ソフトウェア開発の基本的な構成要素であり、スケーラビリティを向上させるためには避けられない摩擦であると言えます。議論を通して私たちは出来上がるものの品質に影響を与え得るような問題を早い段階で浮かび上がらせることができるのです。その1つがオーバーエンジニアリングの問題です。 ウィキペディアによると、オーバーエンジニアリングとは下記のとおりです。 十分な 安全率 や十分な機能の確保のためか、あるいはデザイン上の誤りのどちらかの理由から、アプリケーションが必要とする以上に強固で複雑なプロダクトがデザインされてしまうこと。 また、ウィキペディアには、オーバーエンジニアリングが好ましい場合として、さらに、このようなことも書いてあります。 ある特定の基準の下で安全
論理削除フラグという名の死亡フラグ - @ledsun blog
RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ
JJUG CCC 2017 Springで論理削除フラグをどうにかするための話をしてきました 【FOLIOスポンサー】 - itohiro73’s blog
JJUG CCC 2017 Springで、「データ履歴管理のためのテンポラルデータモデルとReladomoの紹介」という話をしてきました。 データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3 from Hiroshi Ito 今回の登壇は、株式会社FOLIOのスポンサーセッションです！FOLIOについてはこちらの入社エントリー記事もご参考ください。Toggetterは下のリンクから。 togetter.com 世の中のみなさんが「論理削除フラグ」を使いたくなるモチベーションとしては、実は「削除」ではなく別のビジネスロジックを実装したいだけであることがほとんどだと思います。 たとえば論理削除フラグという名の死亡フラグ - @ledsun blogというエントリを参考にさせていただくと、下記のような要件の例があります。 ・社員が退職（・転
Golangのエラー処理とpkg/errors
GoConでは毎回エラー処理について面白い知見が得られる．Go Conference 2014 autumn においては（実際のトークではないが）居酒屋にて@JxckさんがRob Pike氏から以下のようなテクニックを紹介してもらっていた． Errors are values - The Go Blog Golang Error Handling lesson by Rob Pike これはWrite（やRead）のエラー処理が複数続く場合にerrWriter を定義して複数のエラー処理を一箇所にまとめてコードをすっきりとさせるテクニックであった． そして今回の Go Conference 2016 spring のkeynoteにおいてもDave Cheney氏から（僕にとっては）新たなエラー処理テクニックが紹介された． Gocon Spring 2016 実際に使ってみて/コードを読ん
シリーズ判定最前線 - ✘╹◡╹✘
10 日ほど前から amakan books の再設計に着手しており、最近ようやく実装を終えた。いまデータ移行処理を実行している最中で、20時間ぐらい掛かるのでゆっくり待ちながらこの記事を書いている。変更理由についておさらいするという意味も含めて、変更内容と意思決定の背景について書き記しておく。 テーブルの変更 旧 DB スキーマ では以下のようなテーブル群を利用していた。 amazon_product_link amazon_product_responses author_product_list_memberships author_product_memberships authors evaluations product_links product_lists products 新 DB スキーマ では以下のようなテーブル群を利用するようになった。 book_authors b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Placehold.it - Quick and simple image placeholders
まだAPI定義管理で消耗してるの？〜Swaggerを用いた大規模アプリ時代のAPI定義管理とコードジェネレート〜
How to design a replay system
設計をする上で役にたった制約について
似非サービスクラスの殺し方 / #ginzarb
TechCrunch
