Hachioji.pm #21に参加しました
3度目の参加。しいたけの石づきをコリコリコリコリやってました。
話題の中心は月末に迫ったYAPC::ASIA。
HOME | YAPC::Asia Tokyo 2012
そしてHachioji.pm主催のLTソン。
http://ltthon-yapc2012.hachiojipm.org/
やろう！LTソン！
LT
テーマは「typo」。
- ytnobodyさん
- ハンドルネームの変遷を初めて知りましたが内緒にします。
- そんな発表だっけ？
- moznionさん
- ichigotakeさん
- twitterでキーワードを拾ってyanchaに投稿するプラグイン(?)
- #hachiojipmを拾ってyanchaに投稿するデモ
- が、動かず、ライブデバッグ
- maka2_donzokoさん
- Hachimoji.pm
そのあとは
YAPCのチケットが売り切れたとか、LTソン企画メンバー用のチケットが買えてないとか、そんなでした。
Perl Beginners #4 で、読めなかったコードを読んでもらった
これは私が実際に体験した話なんですがね、勉強会に行ったんです。Perl Beginnersって言って、隔月でやってて、もう4回目になる。私全部出てるんです。この勉強会の面白いのが、区民館とかそういうところを使うんですね。この日も銀座の区民館でやった。
受付に着きまして、今日の催しのボードを見たら、Perl Beginnersがない。変だなーと思ってたら受付の方が声かけてきて、「1号室の方ね？英語の」えっ……
まあ区民館の方だし、英語の名前の集まりだってことを言いたかったんだろうなと理解したんですが、どうもひっかかる。
嫌だなー、嫌だなーと思いながらも会議室の方に進んでいくと、いきなりフッと目に入った。
私が迷い込んだのは、Perl Beginnersじゃなくて、
PRL BEGINNERS だ っ た ん で す 。
ということで、Perl Beginners #4 に参加して、ビギナーズセッションもやらせてもらいました。
Beginners Session
その1 papixさん
- 自己紹介
- Perl入学式代表取り締まられ役
- 質問:オブジェクトを学ぶ上で、参考資料となるモジュールはないか？
- 勉強するときは、読む・写す・書く
- 読む: はじパー、続はじパー
- 書く: CPANモジュールガイド、Acme大全
- 写す: ？
- 勉強するときは、読む・写す・書く
- CPANモジュールは？
- たくさんありすぎ
- 規模が大きいのは不適切
- 玉石混交
- 回答:ytnobodyさん
- 回答:toku_bussさん
- Hokkaido.pm Casualで聞いたときの答え
- cpanm, Amon2, Mojolicious などが挙がった
- 感想
- papixさん初めて見たけどトークの冴えがすごい
- プロの方々がどうやって勉強したかを追うのはためになる
その2 hsksyusk
わたくしでございます。
スライドはこちら。
Beginners Session at Perl Beginners #4
怪談風に話しましたがあまりウケませんでした。
簡単にまとめると、
- Web::ScraperでHTML内のURLを取ろうとしたんだけど、Data::Dumperで出力したら以下のような意味のわからないコードが出てきた
$VAR1=bless(do{\(my$o='http://www.perl-beginners.org/2012/08/perl-beginners-4.html')},'URI::http');
- これは何？
- 読み方がわかんないんだけど。
- なんで warn $res->{link}; で文字列が出力されたの？
- 回答:ytnobodyさん、maka2_donzokoさん
オーバーロードについては、toku_bassさんが分かりやすいサンプルコードを書いて下さいました。
Perl Beginners #4 · GitHub
- 感想
- これに遭遇してから、blessとかで検索して件のピンクのページを読んでもいまいち理解できなかったので、すっきり。
- 勉強になりました。
LT
ライブコーディングで学ぶPerlオブジェクト指向(ytnobodyさん)
ということで、それを踏まえて、Animalクラスのライブコーディングを見せていただきました。
コードはgithubに。
GitHub - ytnobody/PerlBeginners4-LT
作るAnimalたち*1と、そこで使ったオブジェクト指向の概念と合わせて読むとよろしいんじゃないかと。
- Animalクラス
- 声という変数を持ってる
- newでcry変数を持たせる
- 持っている声で鳴く能力がある
- barkメソッド
- 声という変数を持ってる
- 動物だけど鳴き声がニャーに決まってるCatクラス
- 動物で飛ぶ能力を持つBirdクラス
- Animalクラスを継承
- subで飛ぶメソッドを追加
- 猫と鳥を合成したキメラクラス
- 鳴き声はニャー、飛ぶ能力を持つ
- parent で二つ親を指定する
- 同じく飛ぶ能力を持つBatクラス
- 飛ぶ能力だけを独自に作る
- そういうクラスをMixinという
- Animal::Mixin::Flyクラスを作る
- 中でExporterを使う
- Batクラス
- Animalクラスを継承
- Animal::Mixin::Flyを使って、飛ぶ能力を使えるようにする。
- 飛ぶ能力だけを独自に作る
その他、オブジェクト指向のコードを書くのに便利なモジュールも紹介
- Class::Accessor::Fast
- Mouse
- 独自の書き方
- 感想
- 概念説明してもらいながらコード読むのは大変分かり易い。
- オブジェクト指向を学ぶのに最適なサンプルな気がする
- papixさんの「写す」向け？
名前空間とかの話(toku_bassさん)
- 名前空間は連想配列で実装されている
- use Hoge::Foo; は、Hoge::Fooパッケージとは関係ない
- ファイル名を指定しているから
- eval, do, require, use どれもファイル名を指定しているだけで、パッケージ名ではない
- モジュールでパッケージ名をtypoしたら(ファイル名はあってる)
- ファイルは正常に読み込まれる
- typoしたパッケージ名でパッケージが作られる
- 実行時には正常なパッケージ名で呼ばれることになるので、名前の不一致でエラー
- パッケージはグローバル
- 完全な名前を指定すればどこからでも参照できる
- 一度useで読み込めば、他でuseの必要はない
- でも、パッケージ毎に use を書かないと管理できないので、書くべき。
- use Data::Dumper; するだけで、 Dumperメソッドが直接使えるのはなぜか？
- Data::Dumper->Dumper が、完全な名前で指定した形
- Data::Dumperの中でExporterを使っていて、mainパッケージにメソッドがMixinされたので、Dumperだけで使えた。
- 感想
- Dumperが使えた理由を教えてもらえてありがたかった
- いままで何の気なしに使ってました。
- use も、cpanモジュールを使うためのもの、程度の理解だったので、理解が深まった。
- Dumperが使えた理由を教えてもらえてありがたかった
渾身会
ハワイアンのお店でしたが、フロアが完全に女性で占められており、ガチホモ合コンと判断された我々はガラスで区切られた別室に隔離されました。トイレに液体ハミガキがあったので、あれを口に含んだら爆発すればいいと思います。
ytnobodyさんからオブジェクトの使いどころ的な話が聞けた。
- 自分でモジュールを書くときは、継承とかはあまり使わないで書いてる
- 継承は使いやすいけど可読性は悪くなる
- なるべくサブルーチンだけで済ませてる
- グローバル変数が必要になるような状況なら使う
最後は発表で出し損ねたスライドで締めます。
*1:パペットズーピロミィみたいですね
『[24時間365日]サーバ/インフラを支える技術』とSIのインフラを比べる
僕はSIerで、インフラやることが多いのだが、ふとWeb系のインフラとの違いが気になって、『24時間365日 サーバ/インフラを支える技術』を読んだ。そこで見えた違いや共通点をまとめてみる。
ただ、僕がSI側として見えているのは、自分の関わったプロジェクトが主で、たぶん全然毛色の違うシステムもあるとは思うので、その辺はご注意下さい。
前提
まずは、システムの差異の前提となる、web系とSI系の差異に触れておきたい。簡単にまとめると、こうだ。
| web | SI |
|---|---|
| 自分たちで面倒を見る | 引き渡して終わり |
| ブラックボックスを嫌う | 作り込みを嫌う |
| OSSを好む | OSSを嫌う |
| 負荷が予測できない | 負荷はほぼ予測できる |
| 状況に合わせて変化する | リプレースまで手を入れない |
本書で触れられているweb系のシステムは、基本的に構築も運用も自社で行っている。一方SIerは、要件に従ってシステムを構築したあと、顧客に引き渡して完了。もちろん保守も一貫して行うこともあるが、その場合も構築した要員が運用者として残るとは限らない。システムに関する知識がほとんどない運用者に引き継ぐこともある。
SIにおいて、このような引き継ぎが可能なのは、納入した後にシステムに変更が入ることがほぼ無いためだ。このため、運用マニュアルさえしっかり作っておけば、運用者はそれに従うだけでよい。
一方Web系は、システムが本番を迎えた後も、システム自身に変更が入ること、システムへの負荷が変化することが前提としてある。このため、運用者は状況に応じてシステムを変更し続けなければならない。そのため技術力や対象のシステムについての知識が必要となる。
Web系では、システムで何か問題があった場合も、自分たちで作ったものだから自分たちで解決するのが基本だ。そのためにはブラックボックスはなるべく少ない方がよい。
一方SIでは、ブラックボックスであれ保守契約が結べるものであれば導入を厭わない。問題があっても問い合わせて解決してもらえればよいのだ。逆に、なにか作り込んだものに問題があると、構築した要員でなければ対応できない場合もあるため、なるべく作り込みをしないようにする。同じく保守契約がないという理由で、OSSも導入したがらない。
以下、本の各章ごとに、web系とSI系との差異に触れてゆくが、こういった前提が、システムの差異に現れてくる。
1章 サーバ/インフラ構築入門 ……冗長化/負荷分散の基本
1.1 冗長化の基本
本書では冗長化の基本を「予備機を用意する」としている。これをベースに、以降の章で様々な冗長化の方法を紹介していく。
一方SIでは、同じように冗長化の構成を取ることもあれば、予備機の用意だけで済ませることもあり、予備機すら用意しないこともある。どのくらいの時間で復旧できればよいかという要件によって、冗長化の構成を決める。サーバが故障しても、保守契約があるから修理・交換してくれるしね。
冗長化する際のポイント「SPOFを作らない」というのは、webもSIもいっしょ。
ただ、SI側がSPOFを考える範囲が広いような気がする。サーバの電源ユニットとかファンとかも対象にする。可能な限り1台のサーバが落ちない構成を考えて、冗長化できるところは全て冗長化する。クラスタも用意しないシングル構成や、Active/Standbyのクラスタに限らず、どんなに規模が大きいインフラでも、各サーバはこういったHW構成にしているので、慣習的なものかもしれない。もちろんこれをやる分、1台あたりのサーバの値段は高くなる。
1.2 Webサーバを冗長化する ……DNSラウンドロビン
1.3 Webサーバを冗長化する ……IPVSでロードバランサ
1.4 ルータやロードバランサの冗長化
クライアントからのリクエストを複数のサーバに振り分けることで、負荷分散と冗長化を兼ねる。順番にリクエストを振り分けるのが、もっとも単純な負荷分散か。本書ではこういった機能を、Linuxでサーバを立てて、その上で実現している。
一方SIでは、たいていロードバランサの専用機を入れます。単純なラウンドロビンなら、サーバ構築するSIerがマニュアル見ながら設定することもある。けど、たいていの場合はネットワーク専門の人が入るか、ネットワークチームがあればそこの担当になるので、私のようなサーバインフラ担当にとってはほぼブラックボックスです。
2章 ワンランク上のサーバ/インフラの構築 ……冗長化、負荷分散、高性能の追求
2.1 リバースプロキシの導入 ……Apacheモジュール
これも負荷分散の一つで、URLを解析して、内部の各サーバにリクエストを振り分ける。本書ではこの機能は、Apacheモジュールのmod_proxyで実現している。
SIだと、これも専用機の守備範囲にするところだけど、あんまりリバースプロキシとして動かしているという話は聞かない。
DBの負荷を減らすための仕組み。DBへの問い合わせ結果を一時的にキャッシュする。本書では、memcachedを使ってキャッシュサーバを立てている。
SIだと、キャッシュサーバが入る構成は見たことがない。その代わり、DBサーバにメモリを積んで、それをキャッシュに充てることが多い。なので、性能を見るときは、DBのキャッシュヒット率を結構気にする。
2.3 MySQLのレプリケーション ……障害から短時間で復旧する
2.4 MySQLのスレーブ+内部ロードバランサの活用例
DBサーバの冗長化は、DB内のデータをどう冗長化するかが問題になる。DBのデータが複数あり、常に同期した状態でなければ、随時更新されるDBの冗長化にはならない。
本書では、DBの冗長化に、MySQLのレプリケーション機能を利用している。マスターとなるDBサーバが1台あり、そのDBに対する変更をスレーブに伝えて同じ変更を加え、同期を取るという仕組みだ。
スレーブは複数台持てるので、シングルマスタ・マルチスレーブという構成を取る。更新系の処理はマスタに対して行わなければDBの同期が取れなくなるが、読み取りだけならスレーブからも可能だ。従って、読み取り処理はスレーブの方に分散することができる。
ではSIはどうかというと、そもそもDBサーバのハードウェア構成に違いがある。Web系システムのDBサーバは、他のサーバと同様に内蔵ディスクを持ち、そこにDB領域を持つ。DBサーバが死ぬとその領域のデータは見えなくなる。
SIの場合は、DB領域を外部のストレージに持つ。接続形式はFCが多く、複数のサーバに接続される。DB領域には基本的に1台のサーバからしかアクセスできないが、マウントし直せば別なサーバからもアクセスできる。こんな感じです。
で、肝心のDBの冗長化、負荷分散というと、OracleRACの一択だ。先ほどDB領域には1台のサーバしかアクセスできないと書いたが、この機能を使うと複数のサーバからDB領域にアクセスできる。なので、DBサーバを増やせば、それだけ処理を分散させることができるし、サーバが1台が死んでも残りが生きてサービスが継続する冗長化構成になる。
それでもストレージ自身はSPOFだし、負荷分散もできてない。これにどこまで可用性を持たせるかはわりとシステムによって異なる。Oracle Data Guardによって、MySQLのレプリケーションのような構成もできるが、あまり使うという話は聞かない。ストレージ自身の機能として、あるディスク領域を常時別な領域に同期するというものもある。これだとマスタ側のディスク領域が死んでも、ディスクを切り替えればすぐに復旧できる。ストレージ自身に可用性を持たせる場合は、RAID10構成にして、ホットスペアディスクを何本も積んでおく。
OracleRACやData Guardを導入する場合は、だいたい経験のある人をプロジェクトに入れて、その人に一任することが多い。僕はよくわかりません。
2.5 高速で軽量なストレージサーバの選択
各サーバで共有して使うファイルなどを格納しておくため、ストレージサーバを使用する。本書では普通のサーバのディスク領域をnfsで共有して使っている。
SIだと、ストレージサーバというのはあまり出てこない。各サーバで共有するデータは、たいてい外部ストレージに入れて、read onlyでアクセスさせる。
3章 止まらないインフラを目指すさらなる工夫 ……DNSサーバ、ストレージサーバ、ネットワーク
DNSについては自分の理解が追いついてないので割愛。
本書ではストレージサーバの冗長化を、DRBDによって、2台のサーバのディスクの同期を実現している。プライマリ側が死んだら、セカンダリ側に切り替える。
SIでは先ほど書いたように外部ストレージを使うので、そのストレージの冗長化をおこなう。方法は、RAIDとスペアディスクで可用性を高めるか、それに加えてストレージ自身の機能でバックアップ用ディスクと同期させておくといったところだ。
3.3 ネットワークの冗長化 ……Bondingドライバ、RSTP
3.4 VLANの導入 ……ネットワークを柔軟にする
ネットワークの冗長化は、WebもSIもあまり変わらない。サーバ側ではBonding機能を使って、サーバ-スイッチ間の冗長化を行う。スイッチ間のネットワークの冗長化は、RSTPによっておこなう。
WebとSIの差異は、冗長化構成より、NICの構成・ネットワーク構成にある。これもそもそもというところだが、web系ではサーバを汎用的に使用できるようにするため、HW構成をなるべく統一しようとする。サーバの役割を柔軟に変更できるし、故障した際に他のサーバを代替に使用しやすい。
接続するセグメントの多いサーバは余計にNICが必要になるため、他のサーバと構成が変わってしまう。本書では、それを避けるための構成を紹介していた。一方SIだと、そもそもサーバの構成を統一するという発想がない。そのためNICは必要な分だけ積む。さらに役割ごとに複数のネットワークセグメントを持つことも多い。例えばAP-DB間のセグメント、監視用のセグメント、バックアップ用のセグメントなど。
4章 性能向上、チューニング ……Linux単一ホスト、Apache、MySQL
4.1 Linux単一ホストの負荷を見極める
4.2 Apacheのチューニング
4.3 MySQLのチューニングのツボ
この章では、トップダウンで負荷を分析して、ボトルネックを発見し、それに対処する流れが解説されている。
ここでもWebとSIの前提の際が出てくる。Webでは、負荷が予測できないことが前提になっているから、稼働後の日々の負荷分析と、それに対するチューニングが必要になる。
一方SIだと、負荷は導入前に想定し、それを処理できる構成として納入する。納入前には性能テストをおこない、定められた時間内・ハードウェアの負荷以内で処理をこなせるかを検証する。性能監視の閾値もその時点で決められ、基本的には運用中に変更することはない。
本書には、性能テストに関する記載はなかった。
5章 省力運用 ……安定したサービスへ向けて
5.1 サービスの稼働監視 ……Nagios
5.2 サーバリソースのモニタリング ……Ganglia
5.4 デーモンの稼働管理 ……daemontools
このあたりは監視について。監視サーバを立てて、そこで各サーバを集中監視する。監視対象としては、死活監視、リソース監視、プロセス監視。
WebでもSIでも監視についての考え方は変わらない。違いは利用するソフトウェアで、Web系はOSSで、SI系はサーバと同じメーカー製品を使う。メーカー製品は前述の監視項目をまとめて監視できるものが多いが、カスタマイズは難しい。
5.3 サーバ管理の効率化 ……Puppet
サーバ管理を自動化するツールとして、Puppetが紹介されている。Puppetは、ファイルのパーミッションや、ソフトウェアパッケージ、ユーザ・グループなどのあるべき状態を定義し、自動的にその定義に適した状態にする。構築時から運用中も使えるツールだろう。
SIだと、このあたりの作業はほぼ手作業でやる。運用中の設定変更は、めったにおこなわれない前提だ。
5.5 ネットワークブートの活用 ……PXE、initramfs
ネットワーク経由でブートイメージを転送して、そのイメージでサーバを起動する。このネットワークブートによって、ディスクレスでサーバを動かし、故障率を下げるという手法が紹介されていた。また、サーバの役割を変更するにも、ネットワークブートを使えば別のブートイメージで起動し直すだけなので、容易に構成変更が可能と。
このへんはSIには縁のないところです。
5.6 リモートメンテナンス ……メンテナンス回線、シリアルコンソール、IPMI
5.7 Webサーバのログの扱い ……syslog、syslog-ng、cron、rotatelogs
サーバに障害が発生した場合に、リモートから対応するための手段として、メンテナンス用の外部回線の用意、シリアルコンソールを別のサーバにつないでおく、といった手法が紹介されていた。
SIだと外部からアクセスするなんてもってのほかで、メンテナンス用のネットワークを組んでも、それは外部に抜けられない閉じたものとする。
ログに関しては、ログの集約やローテーションについて触れられていた。syslogサーバを立てて、そこにログを集約するという手法も紹介されていた。
SIでは、ログの集約を行うところは少ない。監視に使用しているソフトがログ監視も兼ねているため、監視段階では集約しているが、ログ自体は各サーバが個別に持っていることが多い。
本書で触れていないこと
バックアップ
バックアップの目的としては、二つ考えられる。随時更新されるデータの保全と、システム復旧時間の短縮だ。
データ保全という意味では、バックアップ対象は更新データとなる。ファイルの場合もあるが、ここではDBのバックアップについて触れる。
SIでDBのバックアップを取得する際は、データの完全性が求められる。DB稼働中にバックアップを取得しようとすると、取得中にデータが更新されてしまうことがあり、データの整合性がとれなくなってしまう。そのため、DBを止めてオフラインバックアップを取得する必要がある。DBを止められるタイミングが限られている場合にも、日次でオンライン、週次でオフラインといったように、必ずバックアップ計画にオフラインバックアップを組み込む。バックアップの際にDBを止める時間を如何に短くするかという課題があり、その課題を解決するため、たとえばレプリケーションしているDBを切り離して、そこからバックアップを取得するという方法もある。
どの段階までデータを戻せればよいかという要件も重要だ。データをもらって処理するようなシステムでは、その入力データさえあればDBのデータを復元できる場合もあり、そういう場合は1週間前までとか、1ヶ月まえに戻ればよいという要件もある。障害時の直近まで戻す必要がある場合は、バックアップから戻したあと、さらに多重化したDBのログを使って戻す。
バックアップの取得先には、LTOを使うことが多い。LTO5なら1巻に圧縮3TB格納できる。バックアップデータが大きい場合はLTOが多数格納できるテープライブラリを導入する。他に、外部ストレージをバックアップ先とする場合も、最近増えてきている。
バックアップデータについて、外部に持つ必要があるかどうか、という点を考慮する必要がある。サーバがある施設が全損した場合、外部にバックアップデータがないと復旧が難しい場合もある。LTOなら外部に搬送する場合もあるし、ネットワーク経由でバックアップセンターにバックアップを取得する場合もある。
まとめ
Web系もSI系も、互いのやり方を知って、よいところは取り入れればよいんじゃないのと思いながら書き進めてきた。SI側としては、高価な専用機やソフトウェアがOSSで置き換えられることに危機感を覚えると共に、大規模なストレージなど金をかけることで実現できている強みなども知ることができたのが収穫だった。だが、Web系の人がこの記事を読んでSIのやり方を知ったところで、参考になる部分があるかというと、ちょっと疑問だ。
繰り返しになるが、ここで取り上げたWeb系というのは以下の本で読んだ内容でしかないし、SI系は僕がこれまで携わったり耳に挟んだプロジェクトでしかないので、全然違うよこんな現場もあるよという指摘があればぜひ。
![[24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)](http://ecx.images-amazon.com/images/I/51uK4ACymiL._SL160_.jpg)
[24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)
posted with amazlet at 12.05.28
Perl Beginners #2 参加してきた
主催者の方のレポート、他の参加者のレポートは、こちらから。
http://www.perl-beginners.org/2012/04/perl-beginners-2.html
以下レポートと感想など。各セッションのタイトルは曖昧ですすみません。
Beginners Session
Perlでの動的ページの作り方(@ctyoさん)
Q.Ajaxでjsonを返すようなCGIを作ってみたけど、リクエスト毎のif文でいっぱいになっちゃう
A.
- WAF使うと簡便な書き方ができるので楽だよ(@irmrさん)
- json出力は、CPANにそれ用のモジュールがあるので使うといいよ。(@ytnobodyさん)
- リクエストに対して処理を割り当てることを、URLのマッピングというよ。(@ytnobodyさん)
- それをやるためのCPANモジュールもあるよ。
- ディスパッチャという言葉もあるよ。
感想
僕ははじめからWAFを使っていたので、ディスパッチャの実装なんて考えたこともなく、結構新鮮だった。
ディスパッチャのCAPNモジュールがWAFの中でも使われてるっていうのは、考えたら当たり前だけど、どんなモジュール使ってるか意識したことなかったなあ。amon2だとAmon2::Web::Dispatcher::Liteという独自のを使ってるのね。
Amon2::Web::Dispatcher::Lite - Sinatra like dispatcher for Amon2 - metacpan.org
サーバにもモジュールを入れたい(@i4djunichiさん)
Q.サーバにもモジュールを入れたい。cpanmとlocal::libを使えばできるっぽい。
- でもplackupできない……
A.
- やりたいことはperlbrewとDarkPANでできると思う。(@ZIGOROuさん)
- 自社ではOrePANを使ってやってる(@ytnobodyさん)
- local::libでやりたいことはperlbrewでできると思う。(@ZIGOROuさん)
感想
内容あんまり理解できてないので、上で的外れなこと書いてるかもしれない……
というか、最初はさくらのレンタルサーバーみたいな非root環境でCPAN使ってモジュール入れたいみたいな話かと思って聞いてた。それならあたしもlocal::libで苦労して環境整えたこともあるし、そのあとperlbrew入れてその手軽さに驚いたこともある。
OrePANは使ったことないけど、自作のモジュールを登録できるのは勉強になりそう。
休憩
休憩中は、隣の席になった@ctyoさんとお話しさせてもらった。
mod_perlなどメモリに常駐するものだとリソースを食うので、ちょっとしたものだったらCGIで動かした方がいいのではと思い、CGIで実装したのだとか。この辺のリソースの消費量というのも、意識したことがなかった。比較とかあるのでしょうかね。
あと、CGIとかhttpdとかplackとかの役割が二人ともよくわかっておらず、話しながら「？」「？」となった。この辺は後ろで。
LT
PSGIへの誘い(@ytnobodyさん)
- 最近のperl製webアプリケーションではよく使われてる。
- ナウい。
- 普通のCGI, CGI.pm, PSGIでの書き方を比較
- PSGIはシンプルな書き方ができるよ。
- デプロイ*1比較
- PSGIライブコーディング
- 質問:受けられるplackでリクエストは？
- 理想的環境だと数千。実際はそれより低くなる。ベンチマークとるのが一番。(@ZIGOROuさん)
- QPSの肌感覚はある程度知っておくべき。DBとAPだとオーダーが一桁違う(@ZIGOROuさん)
感想
「PSGIは仕様、Plackは実装」というのを何度も聞いているんだけれども、PSGIの仕様に沿ったコーディングというのを見て、その辺の区別がようやく実感として得られた。
そしてCGI。これも仕様なんですね。PSGIと並べるとわかりやすい。
ストーカー力(@poohtarouさん)
- @kazeburoさんを追っかけてたらストーカー認定された
- ストーキング力
- Kossy(WAF)初心者向けの題材として最適
- 質問:導入されてるサービスは？
- 回答:NHNさんの内部システムで使われてる
- 質問:ポート番号を表に出したくないけど、どうやってる？
感想
ストーカー名乗るならブログ二年分読んでからにしろということだと思います。
JPAセッション(@ZIGOROuさん)
- 人生初の技術系じゃない発表
- JPAの今年の活動
- ジョブボード作ります
- 企業の採用サイトのリンク集
- 将来的にはperlを使ってる企業に開放したい
- perldoc.jpを移管してJPAで運営します。
- デザイン公募してます。
- ゆくゆくはPerlに関する情報を発信するメディアにできれば
- 著名pmを地域に派遣。移動宿泊費を出してます。
- HOME | YAPC::Asia Tokyo 2012決まりました。
- ボランティアさん募集中
- irc.freenode.org で連絡とってます。
- ボランティアさん募集中
- ジョブボード作ります
- 質問:perldoc jpの翻訳ボランティアはできますか？
- 回答:CVSとgithubでやってる。githubの方が緩く参加できる。
- 詳しくはperldoc.jpまで。
- 回答:CVSとgithubでやってる。githubの方が緩く参加できる。
感想
地域pmや、今回のPerlBeginnersなど、Perlコミュニティが盛況である影には、JPAさんがいると思うのです。JPA++
懇親会
には参加せず。お金用意するの忘れた。
本編参加者に女性がおられたのでガチホモ合コン回避かと思われましたが、懇親会は無事ガチホモ合コンになったようでなによりです。
おまけ
休憩中の会話で、perlがwebサーバ上で動く仕組みがわかってなかったことがわかった。ビギナーズセッションで聞けばよかったです。で、その辺のことを調べてみた。
- CGI, mod_perl, FastCGIというのは、Perl*3とwebサーバが連携するための仕様。インタフェースの決めごと。
- Apache, lighttpd, nginxなどのwebサーバにはこれらのインタフェースでperlを動かすための機能が実装されていたりいなかったりする。
そしてPSGIについても。
まとめ
自分がちゃんと理解できてないところが、いくつか明確になったのが、今回の収穫だった。前回もそうだった気がする。
ビギナーズセッションを聞いたり、それに対しての答えを考えたりしていると、自分の中でスルーしてた疑問が掘り起こされる。
結構いい経験だと思う。
Objective-Cの正規表現でメタ文字をエスケープするには\\を使う。
NSRegularExpressionSearchで正規表現検索をする場合、(とか+とかのメタ文字自体を引っかけるためには、\\を前に付けてエスケープする。[option]+[\]で出るバックスラッシュ2回ね。
[@"ab(c)" rangeOfString:@"(" options:NSRegularExpressionSearch]; //not match
[@"ab(c)" rangeOfString:@"\(" options:NSRegularExpressionSearch]; //not match
[@"ab(c)" rangeOfString:@"\\(" options:NSRegularExpressionSearch]; //match
[@"ab(c)" rangeOfString:@"[(]" options:NSRegularExpressionSearch]; //match4番目もマッチするけど、「Objective-Cの正規表現でカッコ()にマッチさせるには、文字セット[]の中に書く」のはよろしくないです。
近代プログラマの夕とカレー
昔、月刊アスキーの中に、近代プログラマの夕(ゆうべ)という連載があった。編集長の遠藤諭が、ホーテンス・S・エンドウ名義で書いていたコラムだ。内容は、「本物のプログラマはPascalを使わない」ネタや、「この醤油はユーザーインタフェースが悪いね」とか「支払いは3k円」、「ロクゴーゴンザブロ」みたいな独特の発言ネタ、カレーやドクターペッパーとプログラマの関係など、プログラマの生態的なものが多かった。
僕は中学まで北海道の田舎に住んでいて、地元で売ってるコンピュータ雑誌は月アスだけで、毎月買ってはいたものの、分厚い本の内容はほとんどわからなかった。わからないながらも、カオス理論ってすごいなーとか、ベンチマークのグラフかっこいいなーとか、98じゃなくてDOS-V欲しいなーとか思って読んでた。そんな僕にとって、このコラムは、月アスの中でも理解することができる貴重な記事だった。これを読んでいるうちにプログラマに憧れ、いまはSIerになり、人生を激しく後悔している。それはともかく、このコラムのファンになった僕は、連載を追いかける他、アスキーに単行本を注文して読みふけっていた。
旭川高専5年生になり、大学編入の受験のためはじめて上京した時、このコラムで取り上げられていたカレーを食べようと、アジャンタに行った。当時はジャワカレーの中辛くらいの辛さにしか免疫のなかった僕には、アジャンタのカレーは辛すぎた。はじめはすごい量の汗をかき、そのうちに寒くなって震えがきて、半分以上残してしまった。苦い(辛い)思い出だ。
その後、プーさんのカレーに鍛えられ、札幌でスープカレー屋を訪ね歩き、結構辛いカレーも食べられるようになった。今、そのカレーをもう一度食べたい。そう思って、お店の名前を確認しようとググったら、近代プログラマの夕のブログ版が引っかかった。
http://blogmag.ascii.jp/tokyocurrydiary/cat30/
読んでみたら、当時と変わらないテンションで、つい読みふけってしまった。さらに遠藤さんが、東京カレーニュースなるFBページを運営していることもわかった。そして件のアジャンタが、カレーランキングのトップを争っていた。
東京カレーニュース
僕も「いいね！」を押すとともに、キングオブフードであるところのプーさんのカレーに一票を投じた後、懐かしさに突き動かされてこのブログを書くに至った。
月アスはもう無くなって、ググってもバックナンバーの目次も出てこない。近代プログラマの夕の古本はまだ買えるようだ。実家には残っていたはずなので、今度帰省したら読み返してみよう。
近代プログラマの夕(ゆうべ)
posted with amazlet at 12.03.25
近代プログラマの夕(ゆうべ)〈2〉
posted with amazlet at 12.03.25
