Shibuya.pm のレポートではないレポート
残念ながら、レポートになっていないレポートです。
「読むヒマがあるなら、ニコニコ動画にアップされている動画でも見た方がいい」
というのが正論すぎて何も言えません。
Shibuya.pm Technical Talk #10 ‐ ニコニコ動画:Q
にアップロードされているようです。
他にも良質なレポート&感想がいろいろなところでアップされているようなので、本当に自分用のメモ程度に。
TPF-J(仮)について (lestrrat)
- TPF-J 改め JPA
Perl 業界全体を盛り上げるための法人を立ち上げちゃいます!
目的は Perl 文化の啓蒙や技術者育成。
なぜ必要かって?
それはね Perl といえば
- 死んでる言語だよね
- 知ってる!知ってる!CGIでしょ!
- 遅いよね
- システム作れないよね
- 習得コスト高すぎだよね
- 覚えても仕事にならないよね
こんなイメージが先行しているよね。
つまり
- 彼氏が Perl やっていた。別れたい
こうですか><
Ruby には matz さん + 「Rubyいいよ!」って言う人たちがいる。
Perlにも dankogai 氏もいるけれど そういう「人々」が必要だよね。
そこから Perl にはまだ将来性があるんだ!仕事になるんだ!という「文化」をアピールしたい。
ところで具体的には何アピールするのさ?
他の LL に流れそうな人をどうやって魅了するのさ?
初心者向け Perl OO 講習 - LL温泉報告 (tokuhirom)
- tokuhirom がぴょんぴょん飛んでた。結婚したい。
こうですか?><
おわり。
というわけには行かないので
Perl といえば
だがそれがいい。
Perl OO は見えすぎる。だがそれがいい。
それがイヤならば隠蔽するためのモジュールがたくさん CPAN にある。
それを使いこなすのが楽しいよね!
Shika.pm もよろしく。
Benchmark of Perl Web Application Frameworks (hidek)
Perl の代表的な WAF (Web Application Framework)
- CGI::Application
- Catalyst
- Mojo
- Sledge
- Soozy
- Jifty
全部おそいよね。
Catalyst なんて CGI で動かすと 1 秒で 2 件のリクエストしか処理できないよ!
2リクエストとかバカなの死ぬの?
(そもそも mod_perl 配下で動くことを想定しているし、仕方ない)
なんでこのご時世に CGI なの?バカなの死ぬの?
でも、そもそも CGI は Perl のお家芸だよね?
Perl は多様性を認めてきた。イロイロなカタチで用いられて当然。
お問い合わせフォームを Catalyst で作るだなんてナンセンスだよね。
そんな中、軽量ウェブアプリケーションフレームワークが登場してきた。
レンタルサーバとかで簡単に動かせるよ。しかも、めっちゃはやいよ!
こーゆー多様性をもって、お家芸を、Perl を復興させてこうよ!
修造乙。
Yacafi と見せかけて Module::Setup の話 (Yappo)
と見せかけて Yacafi のお話し。ってゆーか情報リーク。
(「これはひどい」のコメントが印象的でしたw)
Yacafi って?
- CGI のアプリケーションフレームワーク
- 超軽量
- コンパイルすると1ファイルになっちゃう手軽さ
- しなくても 2 ファイル
- (M)VC
- 初心者。。。中級者くらいが使いやすい
とにかく「軽量ということにたいしてこだわり」がある。
今は Model のフレームワークのようなモノを作っている。
MENTA (tokuhirom)
これからは CGI の時代!
- CGI 使ったら身長が 3cm 伸びました
- CGI 使ったら彼女ができました
- ロリポップで動くよ!
MENTA って?
- 一番最初に登場した Lightweight WAF
- すごい!
- Pure Perl
- はやい、かるい
- なんでもついてくる
- 充実の extlib
- erb like の View
- 旧来の Perl スタイル(関数ベース)で書ける
- 初心者にやさしい
初心者には敷いたレールの上をいってもらったほうが、正しい Style などが身につきやすい。
奥深いところはその後から、Perl の楽しさが分かってからでいい。
俺の後ろをついてきな!的フレームワーク。
NanoA (kazuho)
「なのえー」って呼んでたけれど「なのあ」が正式名称?
かわいい!
NanoA って?
- 今の WAF ってプロ向けすぎて意味わかんないよね
- Dispatch テーブルとかいらないよね
- エスケープなんて自動でやってよ
- コントローラとテンプレートの分離なんて必要?
- mod_perl、fastcgi とか CPAN とかばかばかしいよね
- 簡単インストール
- コンポーネント指向
- シンプルだけれどパワフル
1 つのファイルをアップロードして実行すると、自動で展開されてセットアップが終了する。
これはすごかった。
少しのコードで十分なアプリケーションつくれるよ!
NanoA つかってみようと思います。
Catalyst の次は Mojo ? (charsbar)
CGI のテストってめんどくさい。
環境変数がひつようだったりテスト環境必要だったり。。。
Mojoで書いたアプリなら簡単だよ!
テストが必要なら追加すればいい。
ちょっと Mojo はあんまり勉強してなかったのでサッパリでした。
勉強しなくちゃ。
remedie" pluggable media center application (miyagawa)
これはすごい。Plagger のマルチメディア版?
実演を見るのが一番いいと思うんだけれども、ニコニコにはアップされていないかもしれない。
"kamaitachi" perl flash media server (typester)
Perl で FMS (Flash Media Server) を作るためのフレームワーク?
FMS ってゆーのは
- Remoting
- Server と Client のやりとり
- Shared Object
- Client 間での Object 共有
- Media Streaming
- メインの機能
Kamaitach は Remoting と LiveStreaming に対応
Moose つかってまーす。
パケットをブロードキャストするロールがあるらしいけれど、これはどのレイヤでのことだったんだろう。
簡単にサーバーを立ち上げることができる。
録画機能や静的動画ファイルを配信する機能もつきます。
パケットをキャプチャリングしてそれを録画できる。
ウェブサービスにおける SSD の使い方 (kazuho)
HDD は遅いからみんな努力している。
たとえば書き込みバッファを使うとか。
読み込み (ランダムリード) はバッファ不可能なのでIOトランザクション減らすしかないよね。
だから、いろんなレベルでキャッシュしている。
一方で、参照局所性が低い全文検索のようなサービスではキャッシュさせにくいためアクセススピードの速い SSD が向いていそう。
アクセス単位を調べてみたら、平均的に小さいことが判明したので、検討の価値ありと判断し SSD 化。
SSD 化したら読み込みで10倍のパフォーマンスアップ。書き込みでもバッファありでもなしでもパフォーマンスアップ。
ある種の検索が遅すぎる問題。これについてはよく分かりませんでした><
SSD はシーケンシャルライトが遅いことは覚えておこう。
SSD と HDD を混在させると管理大変。
メモリ 64G で買うと、50〜100万必要になり、もれなくハイパワーなCPUがついてくる。
SSD なら 64G でも10万円くらい。でも安すぎるとだめだよ。
どんなケースなら SSD 化の価値がある?
- アクセス単位が小さい場合は高速化が期待できる
- SSD を増設すればサイズも大きくなる
- キャッシュのためのメモリ減らせたりする
- どうせ HDD だって壊れるんだしスレーブとしてなら十分でしょ
まとめると、SSD は HDD に比べ、ランダムアクセス性能が高いので、ランダムアクセスがメインとなるようなサービスでは、従来のメモリにキャッシュさせる方法をとらなくても、十分なサービスを低コストで提供できますよ。
ってゆーお話しかな?
Moxy at Dwango(仮) (acotie)
Moxyって?
- ケータイブラウザを PC 上でエミュレートできる
- 各種キャリア対応
- べんり!
- UA の変更がカンタン
- プラグイン形式で機能が増やせ、とにかく多種多様のプラグインがある
- 開発者にとってもべんり!
- シンプル
- インストールもカンタンだ。。。よ?
Plugin でいろいろできるから Plugin を開発して便利にしましょう。
Moxy もあとで勉強しよう。
EC2 と S3 で Hadoop する (lopnor)
Perl で Hadoop しましょう。
ログ解析には時間がすっごくかかる。
解析のためのフレームワーク的なものとして Hachero というものを作った。
Plagger のように、やりたいことを Plugin でどんどん追加できるよ!
ちょっと、Hadoop についての知識が足らなかったので勉強します><
Acme::Acme::Don't 2.0 (gfx)
心理学の勉強をする、Perl 本体のソースコードを読むのが趣味な大学生。
don't の中の don't が実行されないのは Acme::Don't のバグである。
実行されるようにしました。
ポイントは
use B; # Perl の内部構造にアクセスできるモジュール # SV 構造体、OP構文木にアクセスする機能を持つ
B モジュールを使えば Perl を内部からいじれるよ!
EBCDIC 2.0 Binary Hacks (takesako)
学生さんを援助したい方がいらっしゃいましたら、ゲンナマでお願いします。
- 11/11 Happy Binary の日
Level1 で死亡した。
EBCDIC という遠い国のお話し
実演がすごくて面白かった。
EBCDIC は昔々の文字コード?
このマッピングと ASCII とのマッピングの違いを利用してイロイロごにょごにょしているらしい。
Yokohama.pm 活動報告 (clouder)
日本で7つ目の Perl Mongers
設立の目的は
- 横浜中心で活動している人ってたくさんいるよね!
- Shibuya.pm だと遅くまで飲めないじゃん!
やってみたら Shibuya.pm とあまり変わらないメンバー。
それでも徐々に参加メンバーが増えています。
Tech Talk だけじゃなくて勉強会もやりたい。
100 人規模の運営をする Shibuya.pm は改めてすごい。
うん、すごい。
京都観光を終えて (mala)
- 最速転職研究会主任研究員
最近京都に7ヶ月ほど観光にいってきた。
その間にイロイロなウワサがあったが
- 無かったことにしよう
帰ってきたら、Livedoor Reader が遅くなってた。
fork して子プロセスが終わるのを待つような処理で、遅い子がいると全体が待ちになっていた。
タスクを細かく分解して、個別ワーカにし、ワーカは可能な限り永続的にすることで、この問題を解決しようとした。
ジョブサーバ、メッセージキューの導入で複数台のサーバで処理。
使ったのは、隣のビルに開発者がいたので Q4M を使ってみた。
ボトルネックの部分を調べるのに Devel::NYTProf を利用した。
いろいろな原因があったけれど RSS0.91 の DTD が 404 になっていたことが判明。
しかも DTD をとりあえず必ず Parse するのが libxml の仕様になっているため、ロスが大きかった。
つまり、libxml でベンチすると DTD 取得のため w3c に DoS アタックしちゃうから気をつけてね。
キャッシュの問題もあった。メモリには全部乗らないので、トップページを表示してから、未読記事を表示するまでのタイムラグを用いてバックグラウンドでキャッシュを作ることで対応。
未読記事のキャッシュヒット率が 45% から 86% まであがった。
ここでも、バックグラウンドでキャッシュするジョブを Q4M を用いて作っている。
ユーザの移動先を先読みしてキャッシュするっていうのは、ユーザの行動を予想できるサービスでは使えるかもしれない。
これは、真面目に聞いたら本当に観光していたのかと、、、思わないか。
感想
Perl の将来が不安。
とか
お家芸なのに奪われている。
とかいろいろあったけれど、初心者からしてみると Perl のコミュニティの大きさは本当に素晴らしいと思い、まだまだ将来性は十分にあるなぁと感じています。
ただ、Perl の玄関先にいる人にとってみれば過去の言語というイメージがあるのも事実だと思います。
現に職場では、自分が Perl を読めるので「古い言語である Perl のソースコードを、新しい言語である Ruby に書き換え、メンテナンス性を向上させる」という、言われてあまり納得できないような作業をしています。*1
とにかくPerl は可能な限り撲滅する方向で進んでいます。*2
使っている自分は Perl は全然現役の言語だと思っているのですが、そうでない人から見れば、やはり古くて、ダサくて、終わってる言語というイメージが強いんだなぁと実感しました。
でも、今は新入社員なのでとりあえずモリモリ力をつけて、そのうち逆に全部 Perl にしてやる!くらいの気持ちでいたいと思っています。
また、Perl の玄関から少し中に進んだ人にとっては、コミュニティのレベルが半端なく高くて、せっかくの大きく有用なコミュニティであっても、逆に馴染めないという部分があるようにも思います*3。
初心者向けなのは mixi の CGIコミュとかくらいじゃない?とか思えるくらい。
ま、この点に関しては、かなり主観なので自分だけかもしれませんが。
今回の Shibuya.pm も初心者の自分が本当に行って大丈夫か?くらいに思っていました。
TAKESAKO さんの後押しがなかったら、その場には行かずに後日公開されるニコニコを見て満足していたと思います。
(TAKESAKO++ です。ありがとうございます。)
そんなわけで JPA には啓蒙活動を通じて、より初心者がどっぷりと Perl にハマれるような展開を期待しています。
今回、こうやって Shibuya.pm に参加できたことは非常に良い経験でしたし、次回以降も継続的に参加できればいいなぁと思っています。
また、出張の予定を作るしかないね!
(終電さえ気にしなければ、もう少しいろいろとお話しができたのに!とゆーのが唯一の後悔)
お話しの中で「開発者が隣のビルにいる」とかそーゆーお話しがあったけれど、地方の会社ではそーゆー技術者の交流がなかなかないので、すっごくうらやましかったです。
あ、忘れていたけれども「初心者でも全然へーき!どんどんおいでよ!全然話しがわからなくても、自己啓発やモチベーションアップになるし、なによりさらに Perl が好きになるよ!」ってゆーのは自分自身の感想として書いておきます。
最後に。
- 自分の隣に座っていたのが mala さんだった。転職したい。