タグ

2010年1月13日のブックマーク (16件)

  • InnoDB, InnoDB-plugin vs XtraDB on fast storage

    To continue fun with FusionIO cards, I wanted to check how MySQL / InnoDB performs here. For benchmark I took MySQL 5.1.42 with built-in InnoDB, InnoDB-plugin 1.0.6, and XtraDB 1.0.6-9 ( InnoDB with Percona patches). As benchmark engine I used tpcc-mysql with 1000 warehouses ( which gives around 90GB of data + indexes) on my workhourse Dell PowerEdge R900 ( details about box ). On storage configur

    InnoDB, InnoDB-plugin vs XtraDB on fast storage
    kamipo
    kamipo 2010/01/13
  • 4章:XPCOM活用術 - Firefox拡張機能開発チュートリアル (XHTML)

    株式会社クリアコード/下田 洋志 SHIMODA Hiroshi http://www.clear-code.com/ 章では,JavaScriptだけでは行えない高度な処理を実現するため,XPCOMの活用方法を解説します. はじめに JavaScriptには,ファイルの読み書きや文字コードの変換などの処理をする機能はありません.こういった高度な処理を行うには,それ以外の技術を併用する必要があります.Internet ExplorerではそのためのしくみとしてActiveX がありますが,Firefox ではXPCOM(Cross Platform Component Object Model)というしくみを使います. XPCOMとは XPCOMは,プラットフォームに依存しないコンポーネント(プログラムの部品)を開発するためのフレームワークです.また,そのフレームワークに則って開発された

  • prototype.js vs jquery vs mootools vs YUI vs Dojo

    prototype.js、jquery 、mootools、YUI 、DojoAdobeSpry、Dojo、 MicrosoftAjax、YUI、Rico、MochiKit、Ext、Alfax、script.aclo.us… 実際使ってるのから名前は聞いたことある程度のものまで、色々と出てきて便利なのはいいんだけど、 正直どれ使えばいいのか分からない…(´д`)という時もある。自分は大抵mootoolsだけどw 選ぶ時の参考になるかもしれないAjaxフレームワークのベンチマーク記事の紹介。 まずPeter Velichkov’s Blogの MooTools vs JQuery vs Prototype vs YUI vs Dojo Comparison Revisedでは タイトルに挙げたprototype.js、jquery、mootools、YUI、Dojoのベンチマークをグラフにし

    prototype.js vs jquery vs mootools vs YUI vs Dojo
  • プログラミング言語 Misa

    #! /usr/bin/misa ごっ、ごぉおっ、ご〜きげんよおぉおおぉおほっ。ほおぉおぉおっ。 「ごきげん☆みゃぁああ”あ”ぁ”ぁああ〜っ」 さわやかな朝の☆ご挨拶! お挨拶がっ。 澄みきった青空にこだましちゃうぉ〜ああぉおおおぉん。 「は、はひっ、はろおぉっ☆わぁるどおおぉっぉ〜っ」 こ、この文章は☆おサンプル! おおぉおぉおおサンプルプログラム!! どんなおプログラム言語でも基のご挨拶させていただくのぉぉおッ! 「ぽうっ」 長々と書くのがこ、ここでの〜、ここでのぉおおぉおぉぉおたしなみぃぃいぃ。 「長いぃ。長すぎましゅう。ご挨拶にこんなプログラム長すぎまひゅぅうぅ☆ んおおぉぉ、ばかになる、おばかになっちゃいましゅ〜ッ」 長いのがっ、バッファの奥まで入ってきましゅたぁあぁあっ! ばっふぁ☆溢れちゃいまひゅぅ〜。あみゃぁあ”あ”ぁ”ぁああ”あ”ぁぁ。 「で

    kamipo
    kamipo 2010/01/13
  • CPAN::Mini で CPAN のミラーをローカルに: blog.bulknews.net

    CPAN::Mini で CPAN のミラーをローカルに DECON で話してきたネタですがちょっと詳しく。 飛行機やら電車の中やらでオフラインハックするときに(たまに)問題になるのが CPAN モジュールの不足です。「あぁ、このマシンにはあのモジュール入ってねぇ~」とかでハックが滞るのは萎えます。というわけで minicpan。CPAN::Mini というモジュールで、CPAN モジュールの最新版だけを持ってきてミラーをつくることができます。 導入は簡単で、CPAN から install CPAN::Mini すると minicpan というコマンドが付属してきます。コマンドラインから使うには、 > minicpan -r http://ftp.funet.fi/pub/languages/perl/CPAN/ -l ~/minicpan とかすれば finet から HTTP で同期で

  • JavaScriptライブラリ「mootools」をマスターするためのサイト14

    twitter facebook hatena google pocket 軽量なJavaScriptライブラリとして一定の地位を得ているmootools。 今回はmootoolsをマスターするためのサイトを紹介します。 追記: 2008/2/15 1サイト sponsors Reference ・mootools 1.11 リファレンス ・moo.fxリファレンス ・mootoolsの機能まとめ HowTo / Review ・ドキュメントも充実「mootools 1.0」 - 軽量なAjax/JavaScriptライブラリ ・Ajaxライブラリ MooTools の紹介 ・あのmoo.fxがバージョン2に - 滑らかで超軽量のエフェクトはこれ! ・軽量 javascript effect library - moo.fx PLUGIN ・mootools Plugins ・Mootoo

  • 京都収納棚:DBMの率直な壱実装 - mixi engineer blog

    飲み屋に行くとかなりの確率で荷物を忘れて帰るmikioです。さて、今回はここ2ヶ月ほどで急ピッチで開発した軽量データベースライブラリ「Kyoto Cabinet」について紹介します。 開発の動機 以前から軽量データベースライブラリとしてご好評いただいているTokyo Cabinetですが、DBMとして必要十分な機能と性能を備えていてなかなか良いものだと自負しております。ただ、開発を進める中でいくつか不満な点があったのも事実です。端的に言えば、全てC言語で記述して、標準ライブラリ(とzlib/bzip2)以外の機能は全て自作しているので、最適化がしやすい反面、メンテナンスの難易度が高くなってしまっているというのが不満です。 そこで、多少性能が悪くなってもいいから、私自身としてお気楽に開発およびメンテナンスができて、移植性も高いような実装を作ってみようと思い立ったのが昨年10月頃。様々な検討を

    京都収納棚:DBMの率直な壱実装 - mixi engineer blog
  • ネットワーク性能のチューニング (TCP編)

    前回はsun4vアーキテクチャのSolarisでネットワーク性能を改善する方法について説明しました。今回はSolaris一般についてTCPの性能を改善する方法を説明します。 TCPの性能のチューニングといえば、まずはウィンドウサイズです。必要なウィンドウサイズは、通信相手とのRTT(ms)÷1000×帯域(bps)÷8で求められます。今どきはRTTが300msくらいあるヨーロッパ相手でも50Mbpsとか出ることがあるので、2MBはほしいです。国内については、石川県から東京を経由して行くので場所によってはRTTがいくらか大きくなりますが、悪くても50ms程度なので2MBもあれば320Mbpsまで対応できます。 受信ウィンドウの最大値を決めるカーネルパラメータはtcp_recv_hiwatで、デフォルトは48KiBです。ミラーサーバは受信のスループットをあまり必要としませんが、これはあまりにも

  • ロードアベレージが1000を超えた

    最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 12月17日の未明にftp.jaist.ac.jpのロードアベレージが1000を超えました。気がついたときには峠を過ぎていて、15分平均がちょうど1000くらいで、1分平均は120くらいまで下がっていました。忙しい間はMRTGがsnmpdからロードアベレージを正しく取れていなかったため、残念ながら証拠が残りませんでした。UltraSPARC T1は32スレッド同時に処理出来るので、1000といってもシングルコア・シングルスレッドのCPUの31くらいですけどね。 12月16日の朝にFirefox 3.5.6がリリースされました。翌午前1時くらいにアメリカのからのアクセ

    ロードアベレージが1000を超えた
  • 新しいストレージを構築してみた(ハード編)

    最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 先日壊れたSATAのディスクアレイの筐体ですが、これは寄贈してもらった試作機なので(こんなんばっかり)、修理については営業と相談してくれとサポートに言われてしまいました。お金を出して修理してまで使いたい筐体でもないので、お財布と相談して新しいストレージを調達することにしました。 今回はSSDを4つ外付けしたときと同じ方法を使いました。Supermicroのシャーシに、マザーボードなしで電源が入るようにするボードを付けてSASエンクロージャを作って、2TBのSATAのHDDを12個突っ込みました。 今回のシャーシは、3.5インチのスロットが24個にLSIのSASエクス

    新しいストレージを構築してみた(ハード編)
  • Ameba PACO [アメーバパコ]  みんなでお絵かきブログに貼り付け

    AmebaPACO(アメーバパコ)は、みんなが描いたパーツを組み合わせて絵(=パコ)が作れるお絵かきサービスです。パコってなに? 「パコ」はみんなが描いたパーツを組み合わせて作った絵のこと。作ったパコはブログにカンタンに貼りつけられるよ!1度に作れるパコは最大4コマまでだから、1コマだけ作ってデコメ風にしてみたり、4コマ作って4コマ漫画風にしてみたり、あなたの好きなようにパコを作ってみてね♪誰かが作ったパコをアレンジして、パコを作ることもできるよ♪ パーツを組み合わせてパコを作ろう! 作ったパコをブログに貼りつけよう! 好きなようにパコを作ってみてね♪ さっそくパコで遊ぶ!

    kamipo
    kamipo 2010/01/13
  • Chrome Extentions by os0x

  • RSS等のXMLファイルを見やすくするGoogle Chrome拡張 : しげふみメモ

    2010年01月12日23:23 カテゴリGoogle Chrome RSS等のXMLファイルを見やすくするGoogle Chrome拡張 Google ChromeRSS等のXMLファイルを開くと、改行のない残念な表示になってしまいます。 (この記事投稿時点で私が使っている 4.0.288.1 dev での表示) これを見やすく表示してくれる拡張機能があります。 Google Chrome Extensions: XML Tree 以前のバージョンでは日語が文字化けしていましたが、今は問題なく表示されます。 対応するタグが分かりやすくなっています。 また、タグをダブルクリックすると、折りたたんだり、展開できます。 あと、RSSだけでなく、XMLで書かれている設定ファイル等をちょっと確認したい時にも重宝します。 例えば、以下はSUSE Linuxの自動インストールの設定ファイル。 情報

    RSS等のXMLファイルを見やすくするGoogle Chrome拡張 : しげふみメモ
  • いやなブログ: Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか

    Linux の共有ライブラリを作るとき PIC でコンパイルするのはなぜか 通常、Linux の共有ライブラリを作るときは各 .c ファイルを PIC (Position Independent Code) となるようコンパイルします。しかし、実は PIC でコンパイルしなくても共有ライブラリは作れます。それでは PIC にする意味はあるのでしょうか。 さっそく実験してみます。 int func () { printf(""); printf(""); printf(""); } PIC でコンパイルするには gcc に -fpic または -fPIC を渡します。-fpic の方が小さく高速なコードを生成する可能性がありますが、プロセッサによっては -fpic で生成できる GOT (Global Offset Table) のサイズに制限があります。一方、-fPIC はどのプロセッサで

  • ダイクストラ法(最短経路問題)

    ダイクストラ法 (Dijkstra's Algorithm) は最短経路問題を効率的に解くグラフ理論におけるアルゴリズムです。 スタートノードからゴールノードまでの最短距離とその経路を求めることができます。 アルゴリズム 以下のグラフを例にダイクストラのアルゴリズムを解説します。 円がノード,線がエッジで,sがスタートノード,gがゴールノードを表しています。 エッジの近くに書かれている数字はそのエッジを通るのに必要なコスト(たいてい距離または時間)です。 ここではエッジに向きが存在しない(=どちらからでも通れる)無向グラフだとして扱っていますが, ダイクストラ法の場合はそれほど無向グラフと有向グラフを区別して考える必要はありません。 ダイクストラ法はDP(動的計画法)的なアルゴリズムです。 つまり,「手近で明らかなことから順次確定していき,その確定した情報をもとにさらに遠くまで確定していく

  • A* - Wikipedia

    A*探索アルゴリズム A*(A-star、エースター)探索アルゴリズム(エースターたんさくアルゴリズム)は、グラフ探索アルゴリズムの一つ。 最良優先探索を拡張したZ*に、さらにf値として「現時点までの距離」g と「ゴールまでの推定値」h の和を採用したもの[1]。h は ヒューリスティック関数と呼ばれる。 A* アルゴリズムは、「グラフ上でスタートからゴールまでの道を見つける」というグラフ探索問題において、 ヒューリスティック関数 h(n) という探索の道標となる関数を用いて探索を行うアルゴリズムである。h は各頂点 n からゴールまでの距離のある妥当な推定値を返す関数で、解くグラフ探索問題の種類に応じてさまざまな h を設計することが出来る。 例えば、カーナビなどで用いられる単純な二次元の地図での探索では、h としてユークリッド距離 を使うことができ、この値は道に沿った実際の距離のおおま

    A* - Wikipedia