ふと突然、「不便さ」こそデザインされるべきだ、などという思考に頭が支配される。そんな今日の昼下がり。 紙の本は不便だ。検索できない。ハイパーリンクもない。でも、だからこそ目の前の文章に集中できる。活字の世界に入り込むことが出来る。小説に没頭することが出来る。 心をシングルタスクにすることができる。 電子書籍のデザインはどうあるべきか。問題は紙のような物理的な制約がないことだ。どこまでも機能が追加できてしまう。どこまでも便利を追求できてしまう。しかし、それは良いデザインといえるのか。 検索機能をつければ、その検索機能は画面の面積を占めるだけではない。読者の心にも入り込む。「検索する」という選択肢が入り込む。もちろんそれは便利だ。だが時として、集中の邪魔となる。読書体験の質を下げる。 温泉が好きだ。都会の喧騒を離れ、お金を使ってわざわざ不便な田舎の温泉宿まで足を運ぶ。不便だからこそ、いいのだ。

※３／９に後半大幅に加筆修正しました。 以前のエントリでコンテンツはクラウド型へ移行するべきだと書いた。その際に、クラウド側のコンテンツはユーザに所有感を与えられるとも付け加えたが、どうしてなのかは十分な説明をしなかった。 ブックマークについたコメントをみていても、そのあたりの解釈にいろいろ個人差があるようで、あらためて、僕が考えるクラウド型のコンテンツサービスのモデルについて説明をしたい。 まず、最初に誤解されていると思ういくつかの点について、僕の考えを述べさせて欲しい。 ・　クラウド型のコンテンツサービスは別に全部ストリームでやれといっているわけではない。 ・　ユーザに不便を強いるだけのDRMが無意味といっているだけで、DRM自体を否定しているわけではない。クラウド型のコンテンツサービスはむしろDRMと組み合わせたほうが相性がいい。 以下にまとめて説明する。 クラウド型のコンテンツサー

ブログ書いてないでさっさと原稿を書けよという気がするので、思ったことを忘れないように走りがきする感じで: 心配しなくても現在使われている大部分の言語はあと30〜40年で「昔そんな言語もあったね」レベルまで駆逐されるよ。 なぜ30〜40年って言ったかというと、それくらいあればプログラムの入力方法が変わる可能性が高いからだ。かつてパンチカードからキーボードに変わったように。 開発環境が変わった際に、いまの環境での「書きやすさ」を追求している言語はアピールポイントを失うことになるわけだな。だから、他の部分で40年後にも残る価値を持っていなければ駆逐されるのが当然だよ、と。 moriwaka: @nishio 割と同意するんですがFortranとCOBOLとCの長寿の秘密を解きあかしたい 僕の理解が正しければ、それは「新しい言語を学ぶことを厭わない人たちが好むような機能を持っていること」ではない。

ネットワークがつながらない状況での分散開発はどうやるのがいいかを考えてみる。 以前似たような経験したのは自分たちが複数の協力会社の１つという立場で、元請けのSVNリポジトリに直接コミットするというもの。ネットワークはつながっています。また元請けは基本的に開発はしておらず、協力会社も開発はほとんど終わっていて変更はバグ修正のみという状況です。 イメージはこんな感じ。 リリース（元請けのSVNリポジトリに直接コミット）する場合は、自分たちのSVNリポジトリにタグうってexportして、あらかじめチェックアウトしておいた元請けのSVNリポジトリのソースに上書きしてコミットします。この辺もHudsonで自動化してましたね。あとコミットするファイル一覧も出しました。元請けはそれと実際にコミットされたソースとを比較して漏れが無いか確認してたみたいです。 しかしこの方法だとファイルの削除やリネームに対応

話は変わって： とはいえ、HDDとSSDそのもののアクセス性能を比較した場合は10倍から20倍性能が違うのに対し、実際の業務を想定したOLTP処理性能の比較ではそれが2倍〜3倍程度に収まりそうであるのにはやや肩すかしを食らった感じもします。 HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験 － Publickey これはそんなもんじゃないかなあ。データベースではディスクアクセスがボトルネックとはいえ、性能の 90% を占めているわけじゃないからね。 たとえば処理にかかる時間全体のうち、ディスクアクセスにかかる時間が 60% を占めていたとする。ここで SSD によってディスクアクセスが 10 倍高速化したとすると、全体の処理時間は： 40% + 60% * 1/10 = 46% もとの処理時間の 46% になる。SSD でディスクアクセスが 10 倍高速化し

ちょっと思いついたんですが、砂漠にデータセンターを作るのはどうだろう。 通常データセンターで問題になりそうなのは ・土地代の問題 ・電力確保の問題 ・冷却対策 ・安定したネットワーク回線の問題 などがありそうなんですが、砂漠だったらこれらを全て解消できるのではないかとちょっと思いました。個別に見てみます。 【土地代の問題】 土地がいくらでもある砂漠なので、まずはこの問題はクリアですね。 【電力確保の問題】 太陽エネルギーをいくらでも活用できる砂漠であれば電力問題もクリアできそうです。 【冷却対策】 太陽エネルギーをいくらでも活用できるので、強力な冷却装置を設置することで冷却対策もなんとかなりそうな気がします。通常冷却を強くすれば排熱がすごくなりますが、砂漠なのでいくら排熱を出そうが大きな問題にはならない気がします。 【ネットワーク回線の問題】 砂漠にネットワークを引き回すのは大変かもしれな

先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの

タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、

Googleを始めとした巨大データセンターでは、消費電力が問題になっていて、どんどん電力の奪い合いが起き始めると思う。今後の電力はデータセンターにほとんど食われていくんじゃないかと。 ところで、サハラ砂漠でサハラの砂からシリコンをとって太陽発電をすると、砂漠だから常にお日様は照りまくってるのですごく効率がいいという話がある。 サハラ砂漠を太陽発電基地に このとき問題になるのが送電で、超伝導ケーブルを使うということになってる。 でも、そんなことせずに、太陽発電センターの横にデータセンターを作ってコンピューティング能力を世界に提供するようにしたら、普通の光ケーブルでつなぐだけでよくなる。 サハラだけではなく、世界の砂漠に太陽発電基地とデータセンターをセットで作るわけだ。 そうすると、増えるデータセンターとその消費電力という問題が解決できる。 Googleは涼しいところじゃなく砂漠にデータセンタ

「CPS（継続渡し方式）変換をJavaScriptで説明してみるべ、ナーニ、たいしたことねーべよ」で、説明用の疑似構文として、JavaScriptに“型パラメータと総称”を入れたものを使ったのですが、型パラメータと総称の構文って、けっこうむずかしいですね。必ずしもJavaScriptに限らず、既存言語にもこだわらず、型パラメータと総称の構文について考えてみます。 いくつかの言葉 String, Integerなど型の名前（型定数）、X, Yのような不定な型を表す名前（型変数）、List, Pairなどの型構成子を含む記号表現をtype expressionというのだけど、直訳すると型式＜かた・しき＞。「型式」じゃ、みんな「けいしき」って読んじゃうだろうから、型表現にします。 型構成子と総称型とパラメータ付き型は、（区別する人もいるかもしれませんが）同義語です。与えられた型構成子（プリミティ

CatalystCon の二次会でもちょっと話したことだけど、RDBMS のサーバクライアントモデルがウェブサービスにあっていないんだろうなと思っている。 現状の、SQL とパラメータを RDBMS サーバに投げて、RDBMS サーバ内でパース、認可、バインド、をやるってモデルはスケールアウトしない (Oracle とかどうなってるのか把握してないけど) 。実際、たとえば memcached なんかは、パース、認可、バインド、読み書きのうち、読み書き以外はすべてアプリケーションサーバで実行する構成になっている。RDBMS もそういう方向になっていけば、いいのかな、と思っている。 古典的な読み書きは１台で行うとしても、パース、認可、バインドといった機能の下に、スケールアウト可能な形でキャッシュを配置することはできるだろうし。そうするとパフォーマンスの限界がぐっと上がるはず。