Shibuya Perl Mongersテクニカルトーク#14 に参加してくるつもりです。なんでこんな流れになっているのか全然理解してないですが、頑張って本を読まずに空気を読んできます。
Perl 6 Language Update / @dankogaiさん
- Perl6(Rakudo*) で FizzBuzz
- 三項演算子は??と!!
- 2.67秒。Perl5より1,000倍くらい遅い。ただし、夏の版より改善されている。
- Rukudoのビルドは、Perlとあまり変わらず、楽
- sub の中に sub を書ける
- スコープも正しく扱われる（外から見えない）
- $^n プレースホルダ → 引数であることを宣言
- 他の言語と違い、CATCH節はtryの中にある
- 無名関数.exception で直接例外を得られる
- 0..* → 無限リスト
- 無限リストへの map の適用は、現状ではまだできない
- ~~ any(<Fizz Buzz FizzBuzz>) → スマートマッチ
- multi sub → マルチディスパッチ。オーバーロード？
- infix:<!> → 演算子の定義
- Perl6のオブジェクト指向は、後付けではないのできれい
- Grammer → 正規表現をさらに強力にしたもの
- Perl6だと、 Combinatory Logic(組合せ論理) を楽に書ける
- 質疑応答
- Q. 後何分？
- A. もうオーバーしてます。
ぼくのかんがえたさいきょうのYAPC::Asia / @941さん
- 会場がすごい
- スピーカーがすごい
- スピーカーがすごい2
- 協賛がすごい
- 景品がすごい
- MacBook Pro, Mac mini, iPad, ipod nano など
- チケットがすごい！
- 完売していたが、再販決定！！ (18時より再販中)
- 数量限定なのでお早めに。「チケット買ってね」
JPA活動報告 / @lestrrat さん
memcached injection / 佐名木さん
memcachedの運用監視ノウハウ / @kazeburoさん
- mixiの障害 → memcachedが落ちた → Twitter で色んなエンジニアが原因究明
- 障害によってわかったこと → memcachedの重要性
- 安定稼働が焦点 → PDCA サイクル
- 「監視は継続的なテスト」 by 奥一穂さん
- 自動化し、それを可視化
- memcachedの監視
- プロセスの確認 → pgrepコマンドとその終了ステータス($?) + cronlog
- 死活監視 → nc -z にて11211を確認 (-wでタイムアウト指定可能)
- コマンドに対するレスポンス → Perlで "version\r\n" コマンドを投げて、結果が戻ってくるか
- NagiosPlugin 形式にする → 終了ステータス 0, 1, 2, 3 を割り当てる。(標準出力は補足情報)
- 接続ができない場合は、UNKNOWNとして扱う(コマンドのテストなので)
- コネクション数 → "status"コマンドを使い、最大接続数に対する接続数の割合を監視
- uptimeを監視する → 5分に1度確認、uptimeが310秒以下ならアラート
- daemontools で memcached を立ち上げると、死んだ後すぐ立ち上がるために死活監視が失敗する可能性
- まとめ
- 安定運用のためには、PDCAサイクル・自動化・可視化
IPA特別企画「身につけておきたい、今そこにあるシステムの救命措置」
IPA(独立行政法人情報処理推進機構)特別企画の、パネルディスカッションです。司会は園田さんです。
- 長期にわたって直してもらえない件がある
- エスケープのミス・忘れなのに、直せないのは何故
- 危険サイトとして公開すべき？ → デスマの原因、業務妨害
- 安全なウェブサイトの作り方
- 仕分けの影響で有料に？
- 新規案件向け。稼働中案件に適用しにくい
- 「稼働中のシステムにセキュリティ対策をしたい」
- どういうプロセスが現実的か
- ネックはなんなのか (技術、予算、体制、顧客の理解)
- Twitter のボットに呟かせるのはどうか (by dankogaiさん)
- 公開するとすぐ攻撃の対象となる。IPAが情報を保護している
- 1000日ルールはどうか？ 1000日経つと公開するとか。
- 脆弱性のあるサイトのうち、IPAが把握しているのは何割か
- 割合が低いとすれば、IPAに発見されるのが不運と捉えられる
- クローラ等で広範囲にスキャンをかけていくといい？
- →サンプリングは合法なのか。難しい。
- 「町を歩いて強盗に襲われた」ではなく「戸締まりをしようね」と思われるような対策がよい
- 現状は報告を受けているだけなので、サンプリングはしていいのか？
- はまちちゃんにチクる(by dankogaiさん)
- 昔のコードはひどい。5,000行程度あったり。「メンテして下さい」と頼まれるのは辛過ぎる。
- @kazuhoさんでもどうしようもないなら、しょうがないｗ
- 一定以上の基準をパスすれば入れる保険、とかはあるのか？
- 一時期はあった。今は聞かない。
- そういう保健等があると、モチベーションとなる。リスクヘッジとして使えるので。
- 社会調整的な動きしか方法がないのか。エスケープミスとかの防止方法は？
- Xslateなどは、エスケープ処理が初めから入っている。互換性は高いが、完璧ではない
- WEBブラウザ・HTMLの構造の問題。データとコードが混在しているために発生する
- アプリ開発者だけでなく、ブラウザ開発者を交えた方がやりやすい
- コードが受け渡しできなくなるのではないか？
- 受け渡したとしても、実行できなければよい
- 今までのブラウザは「なんでもあり」「なんでも実行」 → mozilla と MS に制限をかけるよう交渉？
- 開発側ではなく、プラットホーム側でなんとかするとよいのか
- IPAの報告がめんどくさい。報告が適切に来なかったりする。直接やり取りした方が早い方が多い。なんとかならないか
- IPAを経由すると報告者の保護ともなる。報告によって報告者が不利になる事例を知りたい
- IPAに報告したらIPAが代理で説明をしていると思うが、それは大変なのか？
- 技術的な説明では大変なことはないか？
- 相手による。理解できる・メンテできる人・会社が居ないパターンもある。
- ブログパーツのようなクロスサイトだと、切り分けはどうしているのか？
- クロスサイトスクリプティングの説明自体が難しい。ハードルが高い
- 新しく出てくる用語が多過ぎて、追いつけない部分もある。啓蒙も必要か
- WEBアプリケーションのセキュリティには、色んな要素がある。アプリだけでなくブラウザも関連する
- ブラウザを作っている人に言わせれば、HTMLをきちんと作っていないのが悪い。
- 責任の所在が不明確だが、被害を被るのはユーザ
- ブラウザのプラグインは、変なものは作りにくくなって来ている。よくなってきている。
- 萌えキャラはどうか？ → 人形で失敗したことがあるｗ
Perl 1,2,3,4 の歴史 / @mad_pさん
- 1,2 は知らないので、3くらいから
- 元ネタ → perldoc perlhist、history.perl.com、モダンPerlの世界へようこそ、など
- 黎明期（インタネット前）、普及期（CGI爆発）、発展期（WEBサービス、構造化）
- Perl1 1987年 基本的な機能
- Perl2 1988年 subの再帰、local, \d, \s
- Perl3 pack, unpack, foreach, GPL, ユーザ定義サブルーチン(XSの前身)
- Perl4 1991年 Camel Book の発売に合わせただけ。エンディアンの解説が有名！
- 1995年 CGIインタフェースの登場 → KENT・・・
- Perl5 1994 オブジェクト指向、use, my, perldoc
- 1995年 CPAN解説。anonymous FTP
- Perl本が大量に登場
- コミュニティが盛んに。1999年、YAPC。
- 1998年 Perl Conference Japan, 2000年 Perl/Ruby Conference, YARPC19010
- miyagawaさんにShibuya.pmを作らせたのはTokyo.pmの大きな業績ｗ
- これからのPerlは皆さんが作って下さい！
