読者です 読者をやめる 読者になる 読者になる

ぱいぱいにっき

Pythonが好きすぎるけれど、今からPerlを好きになりますにっき

YAPC::Kansai 2017 OSAKAに(行っ|喋っ)てきた #yapcjapan

ジャパーン!! 皆さんいかがお過ごしですか。

去る3月4日に行われたYAPC::Kansai 2017に行ってきたのでその感想です。雑多です。

yapcjapan.org

見たトークと感想

前夜祭: 突撃!隣の開発環境!

Vimmer(neovim)としてはVimmerの人が多くてほっこり。逆にEmacs勢が少ない。ひとでくんさんとかは昔はEmacsだったけれど、今はおもしろ拡張書きやすいから(という解釈でいいのか)Atomに移っていてナルホドなあと思いました。あとquartz composerスクリーンセーバーを作るのウケる。ああいうビジュアルプログラミング環境だったのか。

papixのalias設定し放題はウケる。僕もちょっとやってみたけれどこりゃ覚えられないなと思ったので、git statusgit checkout git push origin master すら全部手で打ちます。筋肉があればalias要らへんのや。とはいえ筋肉よりも記憶力のほうが強いひとはそっちを選ぶのは理にかなっていると思います。gcc とかと被らないの?という質問で「そんなにアホではないのでそれぐらいはわかります!」といってたのが面白かった。僕だったらミスって別のshellで立ち上げて直すことになると思う。

あと@ さんのWindowsのソフトの数々やテク(変数名が制限でややこいので変数を色で示す)などは、ううナルホド?と思いました。変数を色でやるのはなんかペアプロのときとかはいいかも。

同人作家としてはcharsbarさんの翻訳やるためにWZエディタの左手だけでやって右手を自由にして物理本めくったり鉛筆持つようにしていくのは関心でした。vimmerなら手を逆にするとできるぞと言われたけれど、僕は左手は利き腕ちゃうし難しそう。

songmuさんのは実は以前Yokohama.pmでライブコーディングやってもらった時があってその時に間近で見てたんですが、その時とはあまり変わらずの印象でした。tigとかもっと使っていったほうがいいかな?しかしfugitiveで結構やってたり。昔は使っていたのになー。

しかし

何を言っているんだ。

あとdankogaiさんがすぐ近くにいて以前のYAPCのときよりもdan the questionが飛び交っており、おおなるほど。。。となりました。

dan the interruptionなるほど。

メールフォームからメールを送る近代的な方法 azumakuniyuki さん

www.slideshare.net

幸か不幸か僕はメール技術に出くわしてなく、どうしてもというときは会社の諸先輩方に頼りっきりなわけですが、sendmailqmail など「ああ聞いたことあるー」ってやつを見て歴史を感じることができました。

そういえば今回のテーマは「温故知新」(トークしたのに会場来るまで知らなかったとはいえない)。こんな感じで歴史書みたいな発表が目白押しなのも目玉でした。

オープンデータを利用したWebアプリ開発 dokechinさん

www.slideshare.net

Mishina.pm(1回お邪魔しました!)の @ さんのトーク。オープンガバメント(古いか?)のデータを利用したウェブサービスについての発表でした。

行政のデータはいわゆる公式発表でこんなデータもあるのかと発見がある一方、情報の更新が遅いだとかそういう悩みにも言及されていてそりゃ大変だわみたいなのもありつつ、e-Statのデータは使いやすいとのこと。しかしe-Statのロゴが2000年台前後のホームページ感がある・・・。

YAPCでオープンデータといえばYAPC::Asia 2014でのperlbrewの作者である@氏の LT / Beyond Civic Hacking / gugod - YouTubeというLTが思い起こされます。データとデータを結合してビジュアライズするというグルー言語としてのPerlの使い方としても面白い発表でした。

2017年春のPerl charsbarさん

www.slideshare.net

Hokkaidoの発表は聞いてなかったので。

まあやっぱりキツイのは5.26.0で@INCから.(current directory)が消える件。セキュリティ問題になるのはたしかに分かるけれど、

do "hogehoge.pl";

とかやるのにも影響を受けると聞いてまじかーとなる。configとかではよくやっている。一時的にcurrentを入れるみたいなのも出来るようだけれど、どうなるかはどうなるかですかねー。

Webアプリケーションのキャッシュ戦略とそのパターン moznionさん

speakerdeck.com

沖縄で噂の彼です。「キャッシュの話をするんですよ。なので50万円を下ろしてきました」「無利息キャッシング」などと言っていて本当に大丈夫なのかなと思いましたが、キャッシュのパターンに名前をつけるという体系的な説明でおもしろうまいトークでした。

キャッシュは麻薬なんですよ、そうなんです、彼が言いたいことを言ってくれた。むやみにね、レスポンスキャッシュとか透過的キャッシュとかするとサービスは死ぬ!!!!!!!!!!!!! 人間も死ぬ!!!!!!!!!!!!!!!!!!! おい聞いているか!!!!!!!!!!!!!!!!! 消し込みとかどうするんや!!!!!!!!!!!! キャッシュとか根本的に難しい技術なんですよ、まともにやっていくにHAHAHAAHAHAHAAHAHAHAH!!!!!!!!!!!!

キャッシュはベンチでは安易に上がるんで人間成功体験を得ると(ISUCONなどで)やっちまいをしますが、それは真の成功体験ではない。僕は見に行ってないけれど、そーだいさんのトークでもRDBの技術は長いこと使えるので、RDBでまともにテーブル設計とインデックス貼ってクエリを書いてがんばってがんばって、それでもだめでマットウならキャッシュを使うように僕はしたい!!!!!!! し、僕のチームのレビューではそんなことを時々書いたりします。

話が脱線しましたが、moznionがやっている規模のサービスはなかなか無いんで、そういういざという時に使える技術を把握しておきつつ、とりあえずRDBでがんばる方向にしたほうがみんないいんじゃないかなと思いました。MySQLはクソ速いし正確だしトランザクションがある。こちらからは以上です。

Perl to Go codehexさん

Perl to Go

Go slideはogp出ないのね。。。残念。

さて様々なPerl MongerがGoをやっているわけですが、私もその例にはもれないので興味深い発表でした。

Perlで並列(Parallel)をやるにはforkがよく使われるテクニックであり、つまり他方のプロセスの変数の値を直接見聞きすることは出来ないわけです。一方Goはgoroutineという仕組みで軽量スレッドを立ち上げてやっていくわけで、スレッドなので共有メモリ環境です。CLIプログラミングに向いているという共通した特徴を備えるものの、並列のやり方は全く違うわけでした。

なのでProcletをGoに移植するのめんどくさそうだなーと思ったんですけれど、goletはそのあたりをPlan9アセンブラのコードまで追いかけつつシステムコールがこのように発行されているからスレッドのプロセスからも起動できるみたいなことを言っていてナルホドなあと思いました。

ところで界隈ではgenericsだのなんだの言ってますが僕は「genericsあったら使うけれど別にみんなが必要ではないやろ。実際に使うのはマッチョだけだしマッチョなら筋肉で解決しろ」派なので、皆さんコード生成していこうな。

利用しているBaaSが終了するときにすべきこと または Parse.com の終了と私たちの取り組み side_tanaさん

speakerdeck.com

普通、自分がやっているサービスがどっぷり浸かっているBaaSとかSaaSとかが終了したら絶望なわけですよ。しかしやらんとアカン、アカンのやという精神のもと、ちゃんとエクソダスしたのは偉い。僕とかMySQL for RDSが終わりますとか言われたら誰かに泣きつく。

じわじわ自分のところのデータベースに持っていくのに、BaaS側のサービスからもダブルライトしてもらうのは出来ないけれど、手前にプロキシ挟んでてよかったわ〜〜事案とかマジでこえーーーって思ったので気をつけよっと思いました。こえーっ。

PerlのWebアプリケーションをデプロイする時に僕達が考えたこと papixさん

speakerdeck.com

伯!方!の!塩! じゃなかった、餃!子!の!王!将!

デプロイのビジョンという話があり、サービスの中でデプロイっていうのは結構大立ち回りをやるやつです。しかしミニマムデプロイでいいやつもあるわけです。そういうわけで我々はボタンポチで一発デプロイしたいのか、それともどのフェーズでも人間が戻せるように慎重にやっていきたいのか、そういうのを見極めていく必要がありますねという話があります。

無理やりロケットに例えると

  • 低コストで運用したい日本のイプシロンロケットでは実質パソコン一発で後は全自動で上がっていくようになっている
  • 人間載せているので安全にやりたいロシアのソユーズロケットではどのタイミングでも人間が脱出できるような手段を用意している

そんな感じで載せるもの(=サービス)によりますね。僕のトークのときの質問でもありましたが、ソーシャルゲームでデプロイミスると損失やばいので完全な全自動はやっていません。けれど、出来るだけ状況に応じてコマンドを打ち分けるみたいなのは人間がミスると終わるので(終わったことがある)できるだけデプロイのコマンドは単純化しつつエラーメッセージが出たら人間が対処できるようにしています。

一方去年作った僕の会社のサイトはmasterブランチにマージしたらそのフックを受けてwalterのジョブを実行してcapistrano-stretcherによるデプロイが成されます。ウェッブサービスはマスタデータの類が少なくポンとデプロイするだけであれば切り戻しも簡単だしパツイチデプロイを高頻度に刻んでいくようにやっていくのがいいのでは、というのがわたくしの見解です。

Perl ウェブ開発の中世 〜CGIPlack の間〜 xtetsujiさん

www.slideshare.net

ガチ歴史でした。まずは「会社」という概念の成り立ちから……。YAPC東インド会社の話を聞くとは思わなかった。

僕は中高で箱庭諸島などのCGI世代であり、社会人になったときにはいきなりPlackアプリを書いています。なのでその中間を知るという上で非常に興味深い話でした。

mod_perlというのはあくまでもApacheの拡張なんですよね。今で言うOpenrestyみたいな(nginx-luaでアプリを書く)。今となっては言語自体のWebサーバがあるのが当たり前ですが、ああいう風にプロセス分離してCGI的な世界観を維持しつつ毎度forkしない仕組みを考えた人は素晴らしいなと。preforkモデルだいしゅき。

はてなシステムの考古学 motemenさん

speakerdeck.com

はてなというインターネットのサービスとしては長寿なシステムの塊の歴史書。

考古学っていうのは地面を掘って人の骨とかくった貝殻のあととか見てどういう暮らしをしていたのかというのを見ていく学問なわけですが、コードというものはすでにそれ自体が文字なので推察しなくとも直接読み取れる情報は残っている、と。

しかし古代の章で壁画が現れ「テキストによる記録は希少、口承による調査を行った」という時点で「口承文学だ!」と笑ってしまったわけで。何事も歴史が重なるとそうなるのかなと思うと感慨深い。いや、今はgitとかの歴史があるから、後代になっても残るのではないかというのもありますが。ミニスカ宇宙海賊っていう小説があるんですが、千年前の建国の映像が残っているみたいな話があり、テクノロジーが進むと記録が残るという側面はありそうです。

さてその後時代が進み、はてなブックマークリニューアルの話も出たんですが、動いているもんをシュッと差し替えるのは実装力以上に実行力が試されるものだと僕は思います。端的に言えば覚悟と説得力。これはクソいから捨てようっていう人はいくらでもいいますが、実際捨てて作り直せる人はほとんどいないと思います。

さてそのおかげか、社内にうまくいく構成を作れたのでそれに則ったサービスが続々と出ていくというのはストーリー性もあり良いなあと思いました。言語の選択やらフレームワークの選択やらモジュールっていうのは文化なので文化の伝搬にリニューアルの成功が絡んでいるのはと思います。

しかし文化というのはいずれどこかで閉塞するわけで、そこでルネサンスるわけだなあと思いました。温故知新ですね。

太古はみんな薄かった。それが積み重なって厚くなって身動きが取れなくなって、最終的には太古の薄いのを現代的にする形で復活させる。良い。

そんな感じではてなさんの歴史を追いかけながら文化の発展を知る良いトークでした。

LT

  • YAPCらしい多様性のある発表ばかりだった。。。
  • 最近まかまかさんの発表がちゃんと(?)PerlPerlしつつあるのははちぴーでも思っていて、そのたびに「オオッ」ってなるんですけれど、今回はまさかのコマアニメということで度肝を抜かされた

温故知新 takesakoさん

SECCON実行委員長のイメージが強いtakesakoさん。しかし以前のYAPCのLTでPerlクイズをやっていたような。

あとバイナリかるたとかアセンブラ俳句とか本当に変態で、「機械語だとほら575になっているんですよ、ニーモニックでもpushpushpoppushpushpushという感じでリズムがあって」とか言っていてほんとうにもう・・・と度肝を抜かれました。

そう、この話はパンチカードの時代の話から始まったんです。僕が物心つく頃にはコンピュータは買うもので、すでにインターネットが存在する世の中があって、それが常識だったわけだけれど、それをイチから作った人たちがいて、イチから作る過程に大事なものが詰まっていると。だから若手に伝えたいと言うのはナルホドなと思いつつやり方が斜め上を行っている感じでしたw

しかしSECCONはNirvana改とか最近のSAOコラボなんかも見せ方がすごくて、見せ方を工夫するというのは間口を広げる意味ですごく大事なことだなと、ゲームを作っていて僕も思います。音ゲーなんかも僕はやるんですが、他人がやっているのを「すげー」だとか「俺にもできそう」と思わせるエフェクトとか筐体にするっていうのが参入するために必要な要素だと思っていて、SECCONってやっていることはhackなんだけれど文字で起こすとよくわかんないから、ビジュアライズするというのはすげえなあと思ってました。

あとキーボードとマウス乗っ取ってマインスイーパーをクリアするスクリプトデバッグでAutorun仕込んだUSB指すのは良い……。

自分のトーク

speakerdeck.com

主に運用の話をしました。サーバエンジニアと言ってもコードを書くだけじゃなくてうまいことチームが回っていい感じに運用できるように手をつくしていくんだぞ!ということを伝えたくでやりました。

手応えは結構あって、懇親会などでも「聞きました、良かったです」という声がけをされる率が以前のトークに比べて多いなと感じているのでこういう系もやっていくぞ!!!と思いました。YAPCは仕事の話してビルコンとかは沼の話をするかな、今後は。

まとめ

  • そうよ、これがYAPCだよという感想
  • Fukuokaもやっていくぞ!! トーク応募するぞ!!!!
  • Okinawaも行きたい
  • 次の日に鴨川ビールという京都の会社での儀式に参加しましたが謎でした。謎だし、京都の会社の人は「いいじゃん〜明日帰ればいいじゃん〜」と引き止めにかかることがわかりました。危険です。今度は暖かい時期に行きたいですね。

しかし左手吊ってたけれど

そのうちトーク時の写真とか出そうだけれど、僕トークしているときは左手を三角巾のカッコイイやつで吊っていてその説明をトーク時に全くしていなかったので今説明すると、トークの一週間前にスノーボードで転倒して鎖骨がバラバラになっていてだいたい片手で生活していました。あとクラビクルバンドっていう方を引っ張って骨が刺さらないようにするやつもしてました。両手でコードとかは打てるんですけれどね。スライドもその状態で作りました。

バラバラなんで「これは手術した方がいいよ〜」と言われてたんですが「週末にイベントが〜」と言ったら「一週間後なら間に合うからまた来てよ」って言われていたのでした。トーク時とかは痛みとかはあんまりなかったです。

で、今病院にいて、全身麻酔の手術をした後なのでその話は退院してからまたブログに書こうと思います。今は吊ってないです。棒を入れたので。

では!