Railsは技術的負債である
Railsを使うと、初速は早くなる。それは間違いないと思う。一方で、RailsはVierwからDBまで密結合したフレームワークなので、「段階的なアップグレード」とかがむずかしい。ヴァージョンをあげるときには一気にエイヤであげる必要が出てきがちである。さらに、プロダクトが巨大になってくると結局様々な工夫を凝らしてViewからDBまでの間を疎結合にしていくことになる。そうなってくると、「これRailsである意味あるんだっけ」となって、段階的なアップグレードのしにくさや気をぬくと密結合な設計になるという欠点が目立ってくる。 これは、まさに技術的負債そのものである。ここでわたしが「技術的負債」を「単なる悪いもの」として扱っているわけではないことに注意してほしい。Railsを使うというのは、そういう将来の負債を借り入れて、その借金を使って早くプロダクトを世の中に届けるという判断をしている、ということ
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD
この記事を書き上げるには、相当長い時間がかかりました。本来は今年の年明け、 Rubyの死 やデイヴィッド・ハイネマイヤー・ハンソンの TDDは死んだ がアップされて騒ぎになる前に投稿するつもりだったのです。昨年末に書いたツイートを見てください。 > Rubyにはもう飽き飽きした。理由はいろいろあるが、特にその副作用と、ステータスが可変なせいで大量のユニットテストを書かされるのにはウンザリだ。 @abevoelker Rubyの開発に関しては、大勢の人が心のどこかで何かおかしい、何かが欠けていると思っているようですが、たいていの人は責める対象を間違っています。Rubyで書いたアプリがとんでもない代物になったって？ それはあなたがきちんとテストコードを書かなかったか、テスト駆動開発（TDD）の指針に則って開発しなかったからです。もしくは、正しいデザインパターンに切り分けるための知識が不足してい
グローバルサービスでのタイムゾーンとの向き合い方 - Quipper Product Team Blog
Web developer の大庭 (@ohbarye) です。 今回はタイムゾーンにまつわるお話をしたいと思います。 タイムゾーンは私が Quipper に入社したばかりの頃に最も頭を悩ませたことの一つです。入社以前にはタイムゾーンを跨ぐようなグローバルなアプリケーションの開発を全くしてこなかったので、まさにゼロから学び、考え、そしてハマりました。今でも気を抜くとハマりそうです。 入社からおよそ1年。この間に得た経験と知識を活かし、タイムゾーンと向き合うテクニックをまとめてみたいと思います。 目次 はじめに 前提 - Quipper のご紹介 難しさ 現在時刻を扱う問題 言語、フレームワークの実装 認知の問題 タイムゾーンを考慮した設計の問題 解法 基本的な考え方 デフォルトタイムゾーンを設定する PostgreSQL Rails タイムゾーンを意識した設計 タイムゾーンを意識したプログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
