タグ

Perlに関するuokadaのブックマーク (10)

  • Hokkaido.pmでuWSGIについてLTした - 北海道苫小牧市出身の初老PGが書くブログ

    Hokkaido.pm でuWSGIについて話してきました。uWSGIは Nginx や Cherokee でも標準対応がされ初めており、今後の発展が期待されるアプリケーションサーバです。スライドは以下です。 ウヰスキーとPSGI View more presentations from hiratara デモがメインだったので、デモの手順についても書いておきます。 まず、uWSGI はデフォルトではhttpではなくuwsgiプロトコルを喋るので、uwsgiプロトコルを喋れるフロントエンドを立ち上げます。Plack::App::uWSGI は、いちいちnginxとかをセットアップするのが面倒だったので自分で書いたPSGIサーバで動かせるuwsgiのフロントエンドで、githubにだけ上げてます。uWSGIにpsgiプラグインを実行させるためのmodifier1である"5"は、現状ではfas

    Hokkaido.pmでuWSGIについてLTした - 北海道苫小牧市出身の初老PGが書くブログ
  • YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>

    はい、というわけで自分のトークです: 昨年12月頃から関わってるlivedoorBlogのコードを触っていた時の憤りをスライドにぶつけてみました。 追記:スライドに「ログにマーカーをつける」というのは、(コード読んでないけど)多分こちらのエントリにあるLog::Minimal::Indentとだいたい同じ感じのヤツです ところでWeb上で見かける感想の中でこんなのがありました: 今年個人的に一番衝撃的だったのはやっぱ、livedoor blogのPlack化です。技術的な側面もさることながら、ああいう近視眼的には何のメリットもないし、逆にデメリットの方が大きそうな案件にリソースを割くジャッジができる会社としての姿勢が当に凄いなと。 実はビジネス的にも意味はあるんだなー。 なかなか書くことができなかったんだけど、その内容というのがこちらと→ ブログのお引っ越し機能を大幅に強化しました! (

    YAPC::Asia Tokyo 2013: 「本当にあったレガシーな話」と最近のlivedoorBlogの改修 : D-7 <altijd in beweging>
  • Perlの書けない女子大生がはてなインターンに参加してきた - ぴよぴよ.py

    精神の時の部屋でお馴染みのはてなインターン(8/12 - 9/6)に、 Perlの書けない情弱女子大生が参加してきました。 photo by Norio.NAKAYAMA はてなインターンのいいところ *Webアプリ開発をひと通り体験できる 詳しくは インターン前半まとめに書きますが、 はてなインターンでは設計からサーバーサイド/クライアントサイドの実装までを2週間で体験することができます。 毎日午前中に講義を受け、午後にはその話題に関連する課題が出されます。 わからないこともたくさんありますが、 スーパーエンジニアさんが学生2人に対して1人メンターとして常についてくれるという最高に贅沢な環境でプログラミングをすることができます。 楽しすぎて定時には帰れませんでした。 *エンジニアになりたい学生にとって最高の環境 エンジニアになりたい学生にとって最高の環境とはなんでしょうか。 6万円以上す

    Perlの書けない女子大生がはてなインターンに参加してきた - ぴよぴよ.py
  • Crypt::CBC による Blowfish 暗号化 - naoyaのはてなダイアリー

    This module is a Perl-only implementation of the cryptographic cipher block chaining mode (CBC). In combination with a block cipher such as DES or IDEA, you can encrypt and decrypt messages of arbitrarily long length. The encrypted messages are compatible with the encryption format used by SSLeay, and can be made compatible with the newer OpenSSL package by specifying the -salt argument. 先の XML.co

    Crypt::CBC による Blowfish 暗号化 - naoyaのはてなダイアリー
  • (How to Write a (Lisp) Interpreter (in Perl)) - tokuhirom's blog

    lisp インタープリタを Perl でかいた。前から lis.pl をつかってみたかったのでちょうどよかった。 元ネタはこちら 日語: http://www.aoky.net/articles/peter_norvig/lispy.htm 英語: http://norvig.com/lispy.html perl の強力な機能をつかいこなすことで非常に簡単に lisp を実装できる。汎用性をたかめるためにちょいちょい細工してるので python のやつより長いけどね。質的にはあんま量かわらないです。 Parse は非常に手抜きなのはソースをみればわかるとおりです。元のやつがそうだからですが。 全ソースはこちら。 use strict; use warnings; use utf8; use 5.16.0; use autodie; package Lispl::Env { use L

  • Burrows Wheeler Transform と Suffix Array - naoyaのはてなダイアリー

    ,. -‐'''''""¨¨¨ヽ (.___,,,... -ァァフ|          あ…ありのまま 今日 起こった事を話すぜ! |i i|    }! }} //| |l、{   j} /,,ィ//|       『BWT について調べていたら Suffix Array のライブラリができていた』 i|:!ヾ、_ノ/ u {:}//ヘ |リ u' }  ,ノ _,!V,ハ | /´fト、_{ル{,ィ'eラ , タ人        な… 何を言ってるのか わからねーと思うが /'   ヾ|宀| {´,)⌒`/ |<ヽトiゝ        おれも何をされたのかわからなかった… ,゙  / )ヽ iLレ  u' | | ヾlトハ〉 |/_/  ハ !ニ⊇ '/:}  V:::::ヽ        頭がどうにかなりそうだった… // 二二二7'T'' /u' __ /:::::::/`ヽ /'

    Burrows Wheeler Transform と Suffix Array - naoyaのはてなダイアリー
  • Perlで圧縮

    SmartPhone development guide with CoffeeScript + Node + HTML5 Technology, for...Naoya Ito

    Perlで圧縮
  • Consistent Hashing を試す

    Consistent Hashing は、 複数のノードにレコードを分散させる方法として、 Amazon Dynamo や Cache::Memcached::Fast などで使われているアルゴリズムです。 この文章では、Perl で実際に Consistent Hashing を実装し、 その特徴を理解することを目的とします。 更新履歴 2008-06-01: 公開 サーバー台数で割った余り (mod) を使用する まず Consistent Hashing と比較するために、レコードに対して整数のハッシュ値を求め、 ハッシュ値をノード数で割った余り (mod) で、ノードを選択するという方法を書いてみます。 ここでは、ハッシュ値の算出に CRC (Cyclic Redundancy Check) を使用しています。 use strict; use String::CRC; use Pe

  • naoyaのはてなダイアリー - コネクションプーリングの話

    かなりながーいエントリになる予定なので,結論だけ最初に書くとこんな感じ. この話題については自分も あとで書く と言って書いてなかったので書いてみますよ。2006年の下期にもなってコネクションプーリングかよというツッコミもありそうですが、あとで書くといったら書くの。あとで読むといったら読む。 普通「コネクションプーリング」と言ったら、主に二つの役割があると思います。話を簡単にするためにウェブアプリケーションに限定して言及します。 ウェブアプリケーションから DB への接続を開けっ放しにして、接続に必要とされるオーバーヘッドをカットして双方の負荷を下げる。 ウェブアプリケーションと DB への接続を「使いまわす」ことで、同時接続数を節約する。 というもの。 mod_perlDB と接続維持するとコネクション数増えて云々という話は主に前者のみについての話になります。Apache::DB

    naoyaのはてなダイアリー - コネクションプーリングの話
  • 「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)

    前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとは はてなおやさんが考察しているように 普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので, このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで シ

    「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)
  • 1