タグ

ブックマーク / zigorou.hatenablog.com (5)

  • 速報、1500万人が使える mixi OpenID の技術面を解説するでござるの巻 - Yet Another Hackadelic

    と言う訳でついに来ましたね。 http://mixi.jp/openid.pl mixi OpenID << mixi Developer Center (ミクシィ デベロッパーセンター) 中の人、お疲れ様でした。 実はさっきまで mixi に行って技術的な意見交換などしてきました。mixi OpenID の技術的な側面なんかを簡単に紹介したいと思います。 ミクシィ認証 これは普通の OpenID Provider の挙動と同じです。僕のアカウントは http://mixi.jp/show_profile.pl?id=29704 なので僕の OP Local Identifier は、 https://id.mixi.jp/29704ここでお気づきの方も居るかと思いますが、OP Local Identifier 自体も https で提供されています。さて最初の html の内容を確認して

    速報、1500万人が使える mixi OpenID の技術面を解説するでござるの巻 - Yet Another Hackadelic
  • Catalyst Conference #1 まとめ - 日向夏特殊応援部隊

    昨日は直前にエロギークな人のトラブルもありましたが、何とか無事に終える事が出来ました。 参加者の皆さん、お疲れ様でした。 と言う訳でプレゼンのまとめと個人的な感想です。 プレゼン CatalystからModelを切り離せ (g:catalyst:id:dann) 資料 今回の基調講演の一つ。g:gatalyst:id:dannさんのプレゼン。エンタープライズアーキテクチャ的にCatalystを分析して、かくあるべきと言う事を言ってる方は少ないので非常に参考になりました。 WAFにおけるModelとは何ぞやと言う事から、Modelにはどのようなパターンが存在し、それらをWAFではなくAFに落とし込む方法論をModelの分類ごとに手法化って感じ。 素晴らしい、また後で資料読みたい。 Catalyst REST Practice #1 (g:catalyst:id:ikasam_a) 資料 RO

    Catalyst Conference #1 まとめ - 日向夏特殊応援部隊
    sbg3
    sbg3 2008/04/24
  • Yet Another Hackadelic - 直積の導出と考えうる全ての値を網羅したハッシュの生成

    昨日から激しく悩んでいた内容で、id:kazuhookuさんとnishioさんに色々教わったので、その内容のまとめ。 やりたい事 my $entries = { A => [0..5], B => ["A".."D"], C => ["a".."c"] }; みたいな集合A, B, Cってのがあるとして、A, B, Cから一個ずつ値を抽出してくる組合せを列挙すると言うお話。 ちなみに場合の数として、6 * 4 * 3 = 72 通り存在するハズです。 List::Utilのreduceを使う id:kazuhookuさん案を適当に整形。 #!/usr/bin/perl use strict; use warnings; use Data::Dump qw(dump); use List::Util qw(reduce); my $entries = { A => [0..5], B =>

    Yet Another Hackadelic - 直積の導出と考えうる全ての値を網羅したハッシュの生成
  • Re: MySQL最適化のミニtips - 日向夏特殊応援部隊

    元ネタ: http://labs.unoh.net/2007/07/mysqltips.html あまり具体的じゃないので、僕の考えとか。 正しいかどうかは各自の状況だとか実際試すべきなんだけど、参考になれば。 MyISAM、InnoDBなどテーブルタイプ 僕は断然InnoDB派です。 ただ仰るとおり、ログるだけのテーブルとかならMyISAMでもいいとは思うけど。 トランザクションやロック処理などが必要ない場合など、MyISAM形式にも良いところはあるので検討してみる価値はあるかもしれません。 これだけの指摘だとちょっと微妙な気がするです。 MyISAMの使いどころってのは、 ピンで他とリレーションが無い単純追記系のテーブル リレーションがあり、同一トランザクション内での更新系クエリが存在する場合は、トランザクションが期待通りに動かないので、基的にはInnoDBと混在させるべきではない

    Re: MySQL最適化のミニtips - 日向夏特殊応援部隊
  • 効率的なインデックスの生成と管理について - 日向夏特殊応援部隊

    不思議とアプリケーションチューニングに置いて、余り語られていないINDEX化ですが、 意外ときちんと調べて見ると色んな機能があるんだなと再認識させられます。 複合INDEX 例えば複合INDEXなんかですが、 多くのプログラマが勘違いしていたりとか、あるいは適切に張る努力を怠っていたりしませんかね。 テーブルに複合インデックスがある場合、オプティマイザではインデックスの左端の先頭部分のいずれかをレコードの検索に使用できます。 たとえば、(col1, col2, col3)に3カラムのインデックスがある場合、(col1)、(col1, col2)、および (col1, col2, col3) に対して、インデックスの検索機能を使用できます。 上記の引用でもあるように、(col1), (col1, col2), (col1, col2, col3)のいずれかの組み合わせがANDで指定されている

    効率的なインデックスの生成と管理について - 日向夏特殊応援部隊
  • 1