2011年11月1日火曜日

Perl's Talk at nds #23

長岡開発者勉強会 #23 にプレNiigata.pm と YAPC::Asia Tokyo で得た勢いを借りて Niigata.pm メンバーでPerl話をしてきました。

トークテーマどうしよう?

今回はPerlユーザーの勉強会ではないので、どういった人達(層)がターゲットなのかと考えると
  • 今時Perl? ありえない! って技術者
  • 技術者じゃないけど、Perlって何?
  • Perl使ってるけど、CGI == Perl という認識
という層がターゲットになりそうなので、啓蒙的なセッショントークになるなと。(実際そうでしたし)
 僕の前に話す @neko_gata_s さんも同じようなことを考えてるだろうし、被るとまずいなー、、、でも @neko_gata_s さんが空気読んで二人とも変化球投げたら残念なことになりそう、、、

トークの有効性を上げたい

ということで、トークは2本用意した(それでも CPAN と TIMTOWTDI は被ったけど)。

ただ、スライドを見せて説明というだけで、Perlの良さを実感してもらえるようなトーク術は身につけていないので
  • 「動くものを実際に動かす」ところを見せる
  • 実際に動くコードを見せる
  • ライブコーディングする
のはやろうと。 @neko_gata_s さんも デモとライブコーディングやってたし、『Perlerはデモとライブコーディングをするんだな』という感じになるのは悪くないと思う。あと、ネット環境がない状況でできるデモである必要があるなーとも考えてた

NDSで使ったスライドツール

Perl話をするのでAmon2::Liteでスライドアプリを作るつもりでいたけどExpress/Node.js で作った(というか javascript で作った)。悩んだけど、結局全部 javascpript で作れるというのはやっぱりメリットだし、テンプレートルールに従ったテキストファイルをHTMLレンダリングして表示させる方法として
  1. XMLHttpRequestで、オリジナルのテキストブラウザ側でを受け取って、そこでレンダリングする
  2. サーバー側でHTMLレンダリングしたものをブラウザに送る
というサービスの両方提供するというポリシーで作ることにしたので、サーバーでHTMLレンダリングするための関数群とブラウザ上でHTMLレンダリングするための関数群は同じ物を提供すればいいので、Express/Node.jsを採用

ネタ本を見せた

興味を持ってもらおうとPerlのネタ本を幾つか持参した
  • CPANモジュールガイド
  • PERL HACKS
  • ミニマルPerl
持っていくのを忘れたもの
  • モダンPerl入門
  • まるごとPerl
  • BlogHacks

あと、長岡技術科学大学の学生の中に(アルバイトで)Perlを使っているという希望があったんだけど、彼らが卒業するとPerlではなくPythonユーザーしかいないという恐ろしい現実も味わってきた。 ので、長岡技術科学大学でPerlのイベントやらなくちゃいけない

Perl セッションのトーク

「Perlに対する誤解を解く」@neko_gata_s さん
- Niigata.pmを立ち上げました
- Perl == CGI じゃない
- psgiという規格(十分高速)
- plackupのデモ
- perlbrew: システムとは隔離したディレクトリに (好きなバージョンの) Perlをインストールする
- cpanm: perlbrewでインストールしたPerl (システムPerlも) にCPANモジュールをインストールする
- CPANモジュールを使ってのデモ その1 TwitterのStreamAPI を使って即座に反応するbot を動かす
- CPANモジュールを使ってのデモ その2 Twitter Follower のアイコンを集めてgifアニメーションにする
- TIMTOWTDI(やり方は一つじゃない)とPerlのベストプラクティス
- Perl書籍の宣伝(「モダンPerl入門」「PerlCPANモジュールガイド」etc)
- テストの文化。prove の話
- Question.「WindowsのPerlは何を使ったらいいんですか?」-> Answer. StrawberryPerlとか ActivePerl...

「裏・Perlに対する誤解を解く」@ishiduca
- すぐに始められる
- 話し言葉のように書くことができる(シンタックスシュガー)
- 割りとなんでもできるし、わりとどんな書き方ができて書いてて楽しい
- CPANを使って必要に応じた拡張する言語
- CPANテスターがモジュールをテストしてくれる
- Perlを使うハッカーが格好いいやり方でやってるので真似したい
- UNIXコマンドとパイプを駆使して単語出現頻度を調べる
- コマンドとパイプでやったことをPerlでやる
- Perlでも一行で書きたい: 関数を重ね着する -> コマンドと関数の並びが逆なので同じ並びにしたい -> λ式を使う -> なんかダサい -> CPANモジュール(Sub::Pipe)を使う -> 別の方法として関数リファレンスを扱う関数を使う
- TIMTOWTDI: 汚いコードだったら悪いやり方だし、綺麗なコードだったらいいやり方だと思うので、格好いいやり方ができるようになればいいだけじゃないの

出来なかった話

- 日本語の扱い: input && decode -> hogehoge -> encode && output
- OOPプログラミングの学習スタイル(落下傘式勉強法がいいんじゃないの?)

NDS #23 全体の話

- コンスタントに続けて今回23回目というのが素晴らしい!
「Titanium勉強会を新潟でやってみた」 @Nkzn
- アンドロイドモバイルの勉強会を新潟でやろうとしても、個人の呼びかけだどなかなか人は集まらない
- NICO (財)にいがた産業創造機構 に勉強会をやるので協力してくれと直談判したら、やってくれた
- 二週間で60名の申し込みがあった(最終的には70人程度)。うれしい誤算
- 会場インフラの話(略)
「Googleマップあれこれ(仮)」@yu_hori
- 日本地図センター http://www.jmc.or.jp/
- 地形図(だったか?)を紙からwebへシフトしようという計画
- これまでの地形図にあった情報(ex: 記念碑や送電線や護岸など)が省略されている
- 踏切の印が入るようになった(のは嬉しいが、場所によって記載されない場所があったりでよくない)
- Wordを使ったプレゼン。アイディア賞
「動画推薦サイト作りました(になる予定)」@ooooooo_q
- 動画に寄せられる評価に対して評価する(メタ評価)、更にメタ評価に対するメタメタ評価を用いて動画を推薦するサイト
- まだできてない
- 乞うご期待
- 「みっちり学ぶGoogle Chrome拡張~FixHootSuite作成のウラの裏」@civic
- バックグランドページについて(起動したらwindow閉じても立ち上がってる, etc)
- もともとあるサービスを使ってエクステンションを作る際に注意すること -> サービス提供者の意図を組まないものは作らない
- Google Chrome がOSになった時のことを視野に
- 「Perlに対する誤解と解く」 @neko_gata_s -> ※ 上記参照
- 「裏・Perlに対する誤解を解く」@ishiduca -> ※ 上記参照
「Node.jsでWWW::Mechanizeぽいの作って画像をダウンロードするまで」 @ishiduca (突発セッション)
- 目的のコンテンツに移動するまでに5度URLを移動しなくちゃいけないけど、イベント駆動のJSだとコールバック地獄!
- コールバック地獄な書き方がいやなので、ちょっと工夫しよう
- 関数の実行タイミングを管理する JobQueue を用意する
- 関数の実行を止めておく "関数の部分適用" を実装する
- ダウンロードデモ
- 突発で話したら、何を話してるか分からんなー(シミュレーション大事)
- スライドの文字もっと大きくしないと駄目でした
- 長岡技術科学大学でPerl使う学生は今年の卒業する学生で絶滅するらしい
- Perl書く学生は、アルバイトでPerl書いてる! → Perl使う事業者がいる
- 「CPANモジュールガイド」持っていった。学生受け悪くなかった気がする
- CSSディスったけど、CSSでドラえもん書いてる学生がいた
「TDDのすゝめ」@masaru_b_cl
- == 開発手法
- == スキル
- (開発者、プロダクトの)健康を保つため
- Red -> Green -> Refactorng -> Red ... 3ステップのサイクル
- Red: 失敗するテストを書く
- Green: テストを通すようにコードを書く
- Refactoring: テストが通る状態を維持しながら、コードを管理する
- 3つのステップを「小さく」「すばやく」繰り返し行う
- 「すぐに動くけど汚い」コードと「すぐに動かないけど綺麗な」コードの手順。
- 自分が最初のユーザ。客観的な視点でコードを見直す
- TDDを身につける: テスト駆動開発入門のコードを写経!
- TDDを身につける: レガシーコード改善ガイド
- 実装コストは多少増加するけど、運用時の修正コストが減少する
- デモは DART での TDD
- この手の勉強会で会場のインフラがうまく動作しないケースに録画を使うというのも手だな、と
- ペアプログラミングもやりたい at TDDBC長岡(@t_wada さん呼びたい)
- (質問)絶対に失敗すると分かるような簡単なテストもやる必要があるのか? -> TDD手法が身につくまではやったほうがいい。慣れてきたらやらなくてもいい

0 件のコメント:

コメントを投稿