売上の9割が書き手に入るという新ソーシャルネットワーク tsū 登場
フェイスブック対抗、で出てくるソーシャルネットワークとしては、先月 Ello をご紹介しました。個人情報を売らず、プライバシーを大事にする代わりに、便利機能を有料で売るというモデルでした。 昨日21日火曜日に(時差がある […] フェイスブック対抗、で出てくるソーシャルネットワークとしては、先月 Ello をご紹介しました。個人情報を売らず、プライバシーを大事にする代わりに、便利機能を有料で売るというモデルでした。 昨日21日火曜日に(時差があるので実際には今日でしょうね)公開された tsū(ツー) は、それとは違う方向性でフェイスブックと差別化しようとしているソーシャルネットワークサービスのようです。 tsū ではフェイスブック同様に広告は表示され、そこからの収入が運営にも回されるのですが、広告収入の9割は利用者に還元されるのだということです。 サイトでは、「サイト上でコンテンツを作って
トイレは空いているか? Raspberry Pi でトイレの利用状況をネット表示
“Is the toilet free?”(トイレは空いているか?)という直球なドメインにアクセスすると、”yes”か”no”のどちらかの文字だけが […] “Is the toilet free?”(トイレは空いているか?)という直球なドメインにアクセスすると、”yes”か”no”のどちらかの文字だけが画面に大写しされます。 ソフトウェア企業Made by Manyが社内プロジェクトとして開発したのが、トイレの空き情報をRaspberry Piで監視する Is The Toilet Free 。トイレのドアの開閉を、Raspberry Piをベースとした機器で収集し、その結果を冒頭のwebサイトで公開したり、その他の方法で共有させています。 データ分析 3週間分のデータをSQLで引いてわかるようになったのは、以下のような項目です。 トイレが空いているか? 総ビジター数 ビジター間の最短時
Kazuho@Cybozu Labs: MySQL のクエリ最適化における、もうひとつの検証方法
« メッセージキュー事始め with Q4M | メイン | フレンド・タイムライン処理の原理と実践 » 2008年06月09日 MySQL のクエリ最適化における、もうひとつの検証方法 EXPLAIN を使用して MySQL の SQL を最適化するというのは、良く知られた手法だと思います。しかし、EXPLAIN の返す結果が、かならずしもアテになるわけではありません。たとえば、以下のような EXPLAIN を見て、このクエリが最適かどうか、判断ができるでしょうか。私には分かりません。 mysql> EXPLAIN SELECT message.id,message.user_id,message.body FROM message INNER JOIN mailbox ON message.id=mailbox.message_id WHERE mailbox.user_id=2 OR
JSRuby - Javascript による Ruby(っぽい)実装 (nakatani @ cybozu labs)
OreScript時代の幕開け - yukobaの日記 http://d.hatena.ne.jp/yukoba/20071108/p1 巷で OreScript ブームが巻き起こる中、某所ではさらに局地的に Javascript での言語実装ブーム。 ××さんが ******* を試作したり、西尾さんが python4js を試作したりして、うーむこんなおもしろそうなお祭りは看過できんでわないか。Ruby 成分の多い中谷としてはここはやっぱ Javascript で Ruby かっ！？ そういえばだれか Javascript でパーサ書いてはったよなあ。それを使わせてもらえば Ruby の構文木をさっくり得られて、ちょこちょこっとインタプリタ書いたら、FizzBuzz くらいなら動くんじゃないの？ という思いついてしまったからには、もう作ってみるしか。 というわけで言った者勝ち(笑)の
Kazuho@Cybozu Labs: MySQL のウォームアップ (InnoDB編)
« DBIx::Printf と LIKE 式 | メイン | メッセージキュー事始め in Perl - コマンドラインクライアントを作ってみた » 2007年10月11日 MySQL のウォームアップ (InnoDB編) サーバの起動直後はデータがメモリ上にないためデータベースの応答速度が遅い、というのは良く知られた話かと思います。MySQL の場合、使っているエンジンが MyISAM であれば、各データファイルをあらかじめ cat ... > /dev/null するなりしてバッファキャッシュに載せておけばいいのですが、InnoDB は独自のキャッシュを持っているのでそういうわけにもいかないように思います。 具体的には、パフォーマンスを最大限発揮するためには OS のキャッシュにではなく、InnoDB のバッファプールにデータをロードすべきであるという点。それに、たとえ OS のキャ
Javascriptでdiffる ( with 形態素解析 ) (nakatani @ cybozu labs)
Javascript で diff というのはいくつか試された例はあるようですが、まだこれといった決定打は出ていない様子です。 実は diff は見た目ほど軽い処理ではないので、Javascript にやらせるのはこれが結構大変…… diff の計算量は、おおざっぱに言うと比較対象の要素数の二乗に比例し（実際にはそれより小さくすることができるのですが、まあ話のイメージとして）、かつメモリを大量に消費するので、バッチ的な処理に最適化されていない Javascript にはどうしても荷が重いものとなってしまいます。 比較対象の要素数を減らせば当然計算量は減りますが、行単位で比較してもあまり嬉しくない（わざわざ Javascript で処理するということは自然文が対象と思って良いでしょう）。最小の文字単位だとギブアップ。 ということは形態素解析で分かち書きして、単語単位で diff するのが J
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
