「悪い方が良い」原則と僕の体験談｜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 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同
Real world es201x and future
現場のES201x と未来のアーキテクチャ - インサイドフロントエンド2
MVC と MVC2 について改めて考えてみる - スタジオ・アルカナ技術ブログ
はいどうも～。季節の変わり目のせいかゲホゲホが止まらないエンジニアの吉田です。 今回は、「MVC」と「MVC2」について改めて考えてみたいと思います。 Webアプリケーション開発では、よく「MVC」という言葉を耳にしますね。 「モデル」「ビュー」「コントローラ」の頭文字3文字をとって「MVC」です。 でも、「MVC」の話をしているのに、なんだか話が噛み合わないことがあるんです。 よくよく話を聞いていると、多くの場合、それは「MVC」と「MVC2」の混同です。 というわけで、「MVC」と「MVC2」の違いについて改めて考えてみたいと思います。 「MVC」とは何か そもそも「MVC」という言葉は30年ほど前（1979年頃）からあり、最初はSmalltalkの ウィンドウプログラム開発の設計指針として生まれたものです[※1]。 なので、「MVC」はもともとGUIのソフトウェアに適用するためのアー
Webフロントエンドハイパフォーマンスチューニングを読んだ - hitode909の日記
Webフロントエンドハイパフォーマンスチューニングを読んだ．最近フロントエンドでがんばるアプリケーションを作ってるので参考になった．ネットワークまわりからブラウザの細かい実装の話まで書かれていて良かった． link rel=prerenderで次のページをプリレンダリングできる 次のエピソードに飛ぶとか，コメントページからメインページに飛ぶとか，次に遷移するページが明確なときは有効そう あとからJSで足してもよい CSSのマッチ方法，div>div>span とか書くと右から左に順にマッチしていく なので入れ子をやめると速くなる．BEMでCSSを書くとネストせず書くので速い デベロッパツールでレンダリングの様子をこまごま見れる ペイントが発生した様子 レイヤの様子 ためしに，このブログのaboutページをプリレンダリングしておいたので，下のリンクから遷移するとすばやく遷移できるはず． <l
本当は恐ろしい分散システムの話
2. 2Copyright©2017 NTT corp. All Rights Reserved. 諸説あるが、ここでの定義は「部分的な故障を許容するシステム」の事 複数台のコンピュータを接続して信頼性を高めたり データが途中で化けても再送したり訂正したり 一部のコンピュータが突然故障しても引き継いだり 故障を設計の一部に組み込む事が必須となる 分散システムとは 3. 3Copyright©2017 NTT corp. All Rights Reserved. • 世はまさに分散システム戦国時代 • Hadoopを皮切りに次々出てくる巨大分散OSS • シリコンバレーでも分散ミドルウェアベンチャーが多数出現 • 高信頼なシステムを作ろうと思った場合には複数台のマシンによる高可用構成 が前提になる • Google、Facebook、Amazon等はもちろん • 金融、流通などのエンタープラ
時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ
サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDB、Amazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇
「現在時刻」を外部入力とする設計と、その実装のこと - クックパッド開発者ブログ
こんにちは。技術部 開発基盤グループの諸橋です。 クックパッドでは昨今の多くのWeb企業と同じように、GitHub EnterpriseのPull Requestを使ったコードレビューを広範に実施しています。わたしたちのコードレビューでは、ソースコードの字面にとどまらず、サービスの機能として魅力的かどうかや、保守性を含めた設計が適切かといった議論に発展することも良くあります。 きょうはそんななかで話題に上がった「現在時刻」の扱いかたに関する設計の話を書きます。 背景 サービスを開発・運営している我々には、時間帯によって出し分けたり、特定の期間のみに表示したいコンテンツがたくさんあります。 そのたびにデプロイし直すというのはつらいので(特に24:00に出なくなるコンテンツなど)なんとかしたくなりますが、一方で時限式のコンテンツはその時になるまでちゃんと動いているか確証が取れないので怖いです。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Webフロントエンドハイパフォーマンスチューニングを読んだ - hitode909の日記』へのコメント