先日、藤沢のヒトとかと酒飲んだ流れで、安全保障系のチャットとかに参加してみたけど、ちょっと面白かったよ。他にも人がいっぱいいたし、意訳もあるけど、再現するとほぼこんな具合。 私「軌道上に衛星上がってない以上、国威効用効果といっても限定的だろ」 甲「二段と三段ロケットは日本上空を通過して太平洋に落ちたと言うけど、データは取れたんだろうか」 乙「日本海に堕ちた一段目までは捕捉したはず。それ以上は知らん」 丙「韓国軍が東海に堕ちたのを確認した」 私「東海？ 日本の西に堕ちたはずだが」 丙「東海だ」 甲「まあ実践訓練がてら、政治的なデモンストレーションが組めて良かったんじゃないか、日本にとっては」 私「でも誤報もあったわけだし、課題は随分残った」 丙「日本は北朝鮮に事前通達されなかったのはどう考えるのか」 乙「北朝鮮は偽の発射予告もしていたわけだし、あまり関係ないだろ、それ」 甲「むしろさ、日本海
ふと気が付けば周囲のほとんどが「プププッ、プププッ…」という愉快呼び出し音が聞こえる我らがホークスの親会社の携帯電話会社に乗り換えやがって「俺も乗りかえっかなー」と思わないことも無い今日この頃。 しかし、iPhoneだけは大論外。だって、あんな携帯「おっさん確定アイテム」じゃ〜ん。 セカンドバッグにiPhone入れて、Bluetoothのヘッドセットで通話してるおっさんとか、ああっ！想像するだけでもう嫌っ！ 「そんなことないでしょー、Appleの生み出すイノベーションは時代の最先端を行く若者の支持を得てんじゃないの？」 なんて寝言をぶっこく奴は、今すぐiTunesを立ち上げて、画面左端のiTunesStoreをクリックして見やがれ！そして「App Store＞電子書籍＞有料トップアプリケーション」に進むとだな……！ ちばあきおの「プレイボール」がそりゃもう大人気さ！
こんな話題はいまさらかもしれない！ それはわかってます！ だけど書きたい！ なにって、[OK]ボタンの位置のことです！ これって右に置くのが自然だよ絶対！！ 理由は単純で、 [OK][キャンセル] は、画面によっては [保存] [取り消し] だとかに名前を変えるし、 さらに、入力が3ページあるようなウィザード形式の画面なんかだと、 [ここまでOKそして次の画面へ]、[間違ったかもしれないから前へ戻って修正] とかになっちゃう。 うん、このウィザード形式の時のことを考えるとわかりやすい！ ウェブは横書き！ 左から右に読む！ 左からやってきたんだから、[戻る] のは左！ 右に進んでいくんだから、[進む] のは右！ だから、[次へ] も [保存] も [OK] も右が自然！ ウィザードっぽい画面の時と他の画面の時とで 「OK的なもの」の位置がぶれていると、少し迷うよね。 だから[OK]は右に統一
2009年04月12日 全てのネットサービスを構成する「サービスの３原色」とは? 「光の３原色」という言葉を聞いたことがある人は多いと思います。全ての色は「赤」「青」「緑」から構成され、この３つの色を構成する比率を変えることで、どんな色でも作り出せる、という概念です。 ネットサービスのコンセプトを「そもそも論」で点検する12の質問をガイドラインに、池邉CTOと、私とで、ライブドアのメディア事業部の各サービスについて責任者を、個別に呼んで、「そもそも、どうよ」からの議論をやる中で、「光の３原色」に似たような、ネット上のサービスを構成する「ネットサービスの3原色」的な概念を思い付きました。 ネットサービスを構成する「サービスの３原色」 ほとんどのネット上のサービスは、「Media」なのか「Community」なのか、「Tool」なのか、の3者択一のうちのどれかを基本に置きながら、この3要素がカ
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
今日はふぁぼったーのフロントエンドのDB処理まわりをリファクタリングしました。この辺りも、もう1年半も開発・拡張を続けている部分なのでかなり汚くなっており、今後のためにできるだけソースを短くし、保守性の高いコードに書き直すなどの作業です。 そのなかで、以前から気になっていた点があったので、せっかくなので検証してみました。 前提 ふぁぼったーでは、発言をデータベースから取得する際、最初に発言とそのユーザーをSTATUSテーブルとUSERテーブルからSELECTして、そこで得た発言のIDを用いて、右下に出る各発言のふぁぼりユーザーをFAVORITEテーブルとUSERテーブルから別途SELECTしています。二つに分けたのはその方が速かったからですが、今回検証したのは、後半のふぁぼりユーザー取得部分の書き方です。 FAVORITEテーブルから複数の既知のステータスIDのレコードをSELECTしてき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く