タグ

2008年2月11日のブックマーク (8件)

  • ブログでリアル電報を募集したら結婚式当日にいくつ送られてくるかテスト - iGirl

    結婚式まであと3日。11/11入籍当日に友人とカフェでパーティをしましたが、チャペルでの式&披露宴は11日の月曜日(祝)です。そこで 親族ばかりの結婚式に電報とか送ってくれたら喜びます。飛んで喜びます。 史上初?ってか図々しい?お願いをしてみようと思います!!!だってねだってね、親族全員集めての結婚式って一生に一回じゃないですか。ちょっと愉快なことしてみたいなって。人にお願いすることが苦手な私ですが、勇気をふりしぼってブログに書いてみようかと。 何事においても、もしもマイナスに進んでもね、「あれやっとけばよかった!!」ってゆう後悔より「やっちゃったー><」ってゆう後悔の方がいいかなって。一生の思い出つくってみたいなって。まだ見ぬ人とブログ以外でもちょこっとつながってみたいなって。だから一回もお会いしたことない人も「しゃーないな。協力してやるか」という奇跡の人が地球上にいたら面白いなーって。

    ブログでリアル電報を募集したら結婚式当日にいくつ送られてくるかテスト - iGirl
    se-mi
    se-mi 2008/02/11
    makotokaga氏と連名で送りました。
  • tsukutter

    なにこれ? 作ったものを皆に見てもらうためのサービス 作った物を多くの人に見てもらいたい。そんなあなたのためのサービスです。 最近は小さいWebアプリなどであれば当に数時間で作れてしまうものもあるくらいです。そういうものを作ったときはぜひ「つくったー」で紹介してください。 つくったーで紹介が増えればつくったーを見る人が増える。良い循環が生まれるんじゃないかなー? と思っています。 つくったー例 見てる人が実際に使えるものが望ましいです 以下想定される/されない つくったー例 ウェブアプリ グリモンとかのスクリプト 普通のアプリケーション バージョンアップ告知 利用方法 ①Twitterで つくったー をフレンドに登録 ②何かを作ったらその内容をTwitterで @tsukutter というフレーズに続けて発言しよう ③その内容がつくったーに取り込まれます(反映には時間がかかります)

    se-mi
    se-mi 2008/02/11
    つくったー
  • social web rambling マイクロソフトのヤフー買収問題、泥沼化?

    どうやらYahooの取締役会はMSの提案を拒絶することにしたようだ。買収提案発表以来、すでに13%も下げていたMSの株価はさらに下がるかもしれない。Yahoo買収の代金はキャッシュとMSの株を充てることにしているから、MSの株が下落すると資金負担はさらに増える。さすがのMSにとっても80億ドルの損となると頭が痛いだろう。 しかしMSは負担が耐えられないとみたら提案を撤回すればすむ。多少時間がかかっても株価はおおむね元に戻るはずだ。一方Yahooにはどういう成算があるのか? このまま収益が改善しなければ数年後にはハゲタカ・ファンドの餌になって細切れにされて叩き売られてしまうだろう。 ではGoogleに広告部門を任せるか? 短期的には収益は改善するだろうが、実質的にはGoogleの子会社化への道だ。しかも独禁法による規制のためGoogleが正式にYahooを買収できる可能性は(MSのバルマー

    se-mi
    se-mi 2008/02/11
    収益が改善されなければハゲタカ・ファンドの餌食になって細切れにさる/どう転んでもGoogleの勝ちという説
  • InnoDB におけるカラムの格納 - kazuhoのメモ置き場

    カラムサイズが768バイトを超えると16KB単位になるってのは重要。 Question: How much space InnoDB allocates for each blob outside of the page? HT: For each column that InnoDB needs to store ‘externally’, it allocates whole 16 kB pages. That will cause a lot of waste of space if the fields are less that 16 kB. The ‘zip’ source code tree by Marko has removed most of the 768 byte local storage in the record. In that source code tr

    InnoDB におけるカラムの格納 - kazuhoのメモ置き場
    se-mi
    se-mi 2008/02/11
    なんと。
  • 3年前のはてなブックマーク (でぃべろっぱーず・さいど)

    se-mi
    se-mi 2008/02/11
    サービスに歴史あり
  • cl.pocari.org - オープンソースになった Fastladder の ER 図を描いてみた

    オープンソースになった Fastladder の ER 図を描いてみた 2008-02-10-1: [SQLite] Livedoor の Fastladder がオープンソースになったということで、勉強を兼ねて ER 図を描いてみました。 (クリックで大きくなります) 使ったツールは DBDesigner 4 (日語版) です。 DBDesigner 4 では、SQLite 3.x のデータが読めないようなので、SQLite ODBC Driver を使って、ODBC で読み込み、リバースエンジニアリングしました。 テーブルの定義はソースを見ながら作成中ですが、あまり Ruby が分かっていないので時間がかかりそうです。。。そのうち公開します。 - Fastladder Open Source http://fastladder.org/

  • 不満はモチベーションに昇華しなきゃ | おごちゃんの雑文

    会社の求人をいつも出している。 別に緊急に人が欲しいというわけではないが、かと言って人手が足りているわけでもないので、「人を取る用意があります」という意思表示をしているわけだ。「どんな人が欲しい」の類は過去のエントリにも出ているし、人についてどう考えているかも書いているので、気になった人は読んでもらうと嬉しい。 で、読んだ一人から応募があったのだが、落としてしまった。それはなぜか。 まぁ一番の理由というのは、今はそんなに「人手」が欲しい状態じゃないということ。 私よりも能力の高い人だったら、私の仕事のうち任せられるものは任せてしまえるから、いろいろ楽になる。仕事が過多状態にあれば「の手も欲しい」だろうから、「人手」で解決をつけて楽になれる。でも、現状では応募して来た人はすぐに任せられる程能力も高くはないし、その人が出来る仕事がそれ程過多状態でもない。まぁつまり「出会い」が悪かったというこ

    se-mi
    se-mi 2008/02/11
    意気込みの裏づけ。「業務経歴以外の実績」と「作品」が重要という話。要するにアウトプットだ。
  • MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場

    集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに1回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に

    MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場
    se-mi
    se-mi 2008/02/11
    行のサイズを小さく保つ