ぱいぱいにっき

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

WebSocketをいい感じに扱ってくれるミドルウェアkuiperbeltのDockerfileを作ってDockerHubに上げた

要約

  • WebSocketをいい感じに扱ってくれるミドルウェアkuiperbeltのDockerfileを作った
  • Docker対応のために幾つかの事柄をやった
    • オプションを環境変数で渡せるようにするとか
  • あとまあいろいろやった

経緯

  • YAPC::Okinawaで結構大々的に宣伝をした(つもり)なんだけれど、いろいろ残念なところを直しておきたいと思ったのでいろいろやっていた
  • README.md のインストール方法が腐っているとか
    • Goは基本go getでコマンドインストールできる。けれどkuiperbeltはdepで依存ライブラリのバージョン固定をしており、go getはそんなの無視して最新バージョン取ってきたりローカルにすでにあるバージョンを使おうとして、インターフェイスが変わるとコンパイルに失敗する
    • あと単体コマンドで動くやつはGoコンパイラは要らないので、release binaryを用いるのが吉。kuiperbeltは以前からこれを提供していた
  • ところでrelease binaryがあるツールはid:Songmuさん作のghgを用いると、OSやアーキテクチャを考慮してダウンロードしてくれるので便利ということが知られていますが、kuiperbeltはrelease binaryのパッケージングがghgに対応していなくて適用できてなかった
    • というのをYAPC::Okinawaのスライドを書いている時に気がついた
  • しかしパッケージングを変更すると会社の方で使われているアプリケーションで影響があるのでは?(chefレシピとか)と社内Slackで言ったら「それよりもDockerfileの変更がある」と言われて、たしかに今はDocker上で動かしているからそうか〜となった
  • というわけでパッケージング変更と公式Dockerfile/docker imageの配布をすすめることにした

やったこと

パッケージング変更

  • そういえばGoのツール作る時にビルドやらテストやらrelease binary上げるのとか毎回コピペやなって思った
    • コピペでやるよりは自分用テンプレがあるとええやろと思い、作った

github.com

  • 中身はdepとかクロスコンパイルツールgoxzGitHub releaseに生成物を上げるghrとかをインストールしたり、所定のディレクトリに生成物をはいたり、それをアップロードするMakefileの雛形みたいなやつ
  • これをkuiperbeltから使うようにした

github.com

Dockerfile作成

  • 課題として、Docker内で動作するkuiperbeltに対してオプションをどのように渡すかという問題がある
    • 現状、kuiperbeltは数多くのオプションをyml形式で設定ファイルを記述することで行っている
  • Docker containerで設定ファイルを必要とするアプリケーションは基本的にはボリュームマウントするか、イメージビルド時に含めてしまうか、はたまた起動時にS3からcurlスクリプトで引っ張ってくるとかそういうのが必要
    • 全部めんどくさい
    • 社内ではイメージビルド時に含めつつ、インスタンスによって変動しそうな要素は起動時に環境変数から設定ファイルに書き込むようにしている
  • あと、コンテナ起動時の引数で渡す方法と、環境変数で渡す方法がある
  • まあ環境変数でやるのが一番簡単
  • しかし、たくさんのオプションを環境変数で使えるようにするのめんどいなってなる
  • ところがkayac/go-configって言う便利なやつがあるっぽいのでそれを使うことにした。べんり
  • あとは最近入ったmulti stage buildなんか使ってscratchイメージベースなので結構軽い。4MBです。お試しあれ
$ docker pull mackee/kuiperbelt:latest
  • static buildしたGoバイナリってパフォーマンスにどれ位影響あるのだろうか。今度ベンチマークを取って試してみたい

サンプルアプリもdocker-composeで試せるようにする

  • 簡単なチャットアプリが_example以下に元々入っている
  • Perl/PSGI
  • PerlのPreforkサーバでも刺さらないWebSocketアプリケーションが書けるというのを示すためのもの
    • sinatraとかflaskでも作ろうかなとは思っているけれどまだやる気が出ない
  • ビルドするのに現代Perlの知識が必要だったので、これもDockerに押し込むことにした
  • 具体的にはdocker-composeでkuiperbeltとデータストアとして利用するRedisを立てつつ、ローカルのPerlアプリケーションが動作するコンテナもビルドする
    • 仕事で得た知識を使っていて、例えば依存が書かれたcpanfileだけをCOPYしておいてその上でcpmで依存入れた後に必要なapp.psgiとかindex.htmlをCOPYする戦法で行くと、依存の変更が無ければ全モジュールインストールし直しでビルド時間がなが~いにならない
    • 普段はこういう仕事を時々やってます
  • あと立ててみたら不審な動作をしていたので、チャットメッセージのブロードキャスト部分を大幅に直した
  • このコンテナも実は別タグでDockerHubから落とせます
$ docker pull mackee/kuiperbelt:webchat-example
  • 今はBootstrap + jQueryで貧相な感じの見た目だけれど、Vue.jsとUIツールキットライブラリ使ってもっとまともな感じにはしたいと思っております
  • 直している時に、そういえばXSSヤベーんじゃねと思ってネットでググって出てきたXSSロケーターなるものを入れてみたら案の定ポップアップして笑ったので、Perl側でHTML::Escape噛ました。あと、クライアントの生成したUUIDをそのまま使っているので、それを無視してPerl側でUUIDを生成するようにした。これでも大丈夫なんです
  • クライアント側にはリトライ機構とか入ってないし、アイドルタイムアウトの機能も使ってないので、そのへんも手を入れたいけれど、JSの知識がない。

その辺の試行錯誤はこちら

https://github.com/mackee/kuiperbelt/pull/48github.com

試したい場合は、

$ git clone https://github.com/mackee/kuiperbelt
$ cd kuiperbelt/_example
$ make up
$ make open

で終わりです。お試しあれ

DockerHubに上げる

  • 当初、travisのdeployにあるのかなと思ってたけれど、そんなことはなくて、DockerHubからGitHubの連携やるとwebhookか何かで変更検知して自動ビルドしてくれるっぽい。便利
    • タダ枠だからなのかしらないけれど、ビルドキュー入ってからイメージできるまでは結構時間がかかる
  • というわけで公式イメージです

https://hub.docker.com/r/mackee/kuiperbelt/hub.docker.com

README.md更新

  • ちょっとだけ気合を入れて書き換えた
  • ところで英語はかなりできないです。トラウマがあるレベル
  • 今回はGrammerlyGoogle翻訳を併用しつつ書いたけれど、まだまだ意味不明な文があると思う。つらい
  • どんな機能があるか分からんという声があったので、APIとCallbackのsummaryみたいなものを作ってみた

github.com

  • 少しは見栄えが良くなったのではないのでしょうか

お知らせ

  • kuiperbeltではユーザを募集しております
    • 内需要を満たすだけだと多様性がないもので。。。
  • 使って作ってみたとかあれば教えてください
    • どうぶつタワーバトルのコピーを習作として作りたいと去年末から思っておりますが、なかなか取り掛かれておりません
  • あと見栄えのするロゴね……

YAPC::Okinawa 2018 ONNASONに(行っ|喋っ)てきました #yapcjapan

こんばんわ、みなさんのYAPCは終わりましたか? 俺はこれを書ききったら終わるからみんなも書いてくれ!!!

というわけでYAPC::Okinawa 2018 ONNASONに行ったりトークをしてきたりしました。

yapcjapan.org

前夜祭

P3020010.jpg

前夜祭は国際通りのバーのようなところで開催されました。モニタが壁の至る所にあり、結構奇妙な場所でした。

同僚の@さんがspacemacsの話をされました。おそらくneovimでめんどくさい人はワタクシだと思われます。

YAPC::Okinawa 2018 ONNASON に参加できて最高だった話 - 俺イケ!!!

あとAliCloudの話をされていた方は確かに知らない世界!!!という感じでした。中国リージョンだと強そう。というか最近中国の方がOSS界でも目立ってきたねという話を近くにいたしんぺいさんと話していました。Vue.js界隈とか。

LTでやられたきれいなコードの書き方という発表もかなり面白かったです。アプローチや雰囲気がいつかのYAPCの「草とPerl」に似ていました。

www.slideshare.net

このあとの二次会でも核戦争後の世界を想定して人里離れた今回の会場であるOISTからどのように帰るかなどの話で盛り上がりました。いや、その話をしていたのは僕だけかもしれません。

本編

朝8時に県民広場に集合して、そこからバスで向かうという感じでした。ところで周りを観察すると一般的にWebエンジニアは朝に弱いと思われますが、土砂降りの雨にも関わらず集合率が異様に高く、もしかすると遊園地に行くときだけ早起きする小学生かな?という感想を抱きました。とはいえ朝のトークも皆さん見てくれるので朝にトークする側にとってはとてもうれしいですね。

P3020014.jpg

これは集合場所の県民広場です。

OISTについたあとの写真はどうせあとから公開されるだろうから撮っていませんでした。

見たトークに感想を言っていきます。スピーカーの方々の名前は敬称略です。

Webサービスを監視するときに僕達が考えたこと id:papix

Webサービスを監視するときに僕達が考えたこと / YAPC::Okinawa 2018 // Speaker Deck

個人的にベストトークです。スピーカーチケットしかなかったので投票できませんでしたが。実際世間的にも2位だったようです。

普段は外に出されにくい監視とサービス運用に関するあれこれが濃く詰まったとても秀逸なトークだと思いました。とくに「何故監視を行うのか」「何故アラートの棚卸しを行うのか」など理由とやることがセットになった話というのは僕は大好物です。なので僕がトークをしてもそのようなふうになります。

監視というのはまさに職業Webエンジニアでないと直面しない問題であり、業務で体験しないとなかなか知ることの出来ない知識なので、サービス運用をしたての新人の方などにおすすめなスライドだと思います。

HTTP/2にまつわる事実と誤解 Kazuho Oku

視点と検証という感じでした。内容としてはHTTP/2とHTTP/1があるけれど、ぶっちゃけどっちが速い?というちょっと考えるだけだと「色んな要素があるよなあ」と思ってなかなか答えられないことを、様々な視点からベンチマークを行って「実際色んな要素が関わってこういうときはこっちが速くてこういうときはこっちが速いよ、あなたのお客さんはどれに当てはまるだろう?」というグレーをグレーと言い切るための手法を教えられたトークでした。僕、こういうトークも好きです。僕はモバイルがお客さんで、レイテンシも多ければパケロスも多い環境なわけですが、QUICとかだとどうなんだろうと思ったりしました。まだ真面目には調べていない。

そろそろPerlでのHTTP/2について触れたい xaicron

そろそろPerlでのHTTP/2について触れたい // Speaker Deck

僕のトークでも言っていることなんですが、最近のプロトコルって非同期通信を多用して1本の通信路をフル活用するので、それはそれでLLにとっては厳しい環境といえるんですよね。なので出てきたAnyEventを使ったHTTP/2のコードはやはりキビシ〜ってなりました。とはいえプロトコルパーサーがあって、それが使えること自体はすごく意味があって、簡単に使えるラッパーを書いたりするのもこれで出来るんじゃないかなーと思いました。CoroとかPromisesとか使ったらもっと簡単にかけないかなとか。出来るってことで勇気がもらえたトークでした。

曖昧な文脈文法となんか論理的な話 @

ああ、はじめはパーサーとか書いたことあるでっていうノリだったんですが、だんだんわからなくなり、最後のテイラー展開でパツンとつながったという感じでした。とはいえ、パワーワードが連発してわからないけれど面白いタイプのトークで面白かったです。22の壁とか。研究者の方で話が面白いのは違反でしょうという話を後でしていました。

High (Availability|Performance) WebSocket for Perl Real-Time Application id:mackee

ワイのトークや。後述。

Inlineモジュールの世界 id:moznion

The World of Inline Module // Speaker Deck

「Inlineモジュールは人を脅かすときなどに使える」確かに驚きました。こういう悪魔合体系のモジュールはギリギリAcmeでギリギリ実用的みたいな世界観があり、僕も曖昧になりたいと思いました。というかnumpyが早すぎるんだよな、それが違反です。libnumpyみたいなのが出てきてみんな幸せになって欲しい。moznionさんのトークはいつもどおり大変楽しめてよかったです。

Perlコーディングテクニック2018 id:akiym

Perlコーディングテクニック2018 // Speaker Deck

このトークではPerlってやっぱり多様性があるなあと思いました。他の言語だとクラスの作り方が何種類もあるみたいなことはあんまりないと思うし、バリデータも選択肢がたくさんあることはあまりないかと思うんです。けれどPerlだとセンスのいい人が「これはどうだ?」と提案してそれが使われるみたいな世界観があり、人によってはどれを使えばいいんだよ!ってなるけれど、言語が提供するものではなくそれ以外の人が提案して幸せになっていくのもよいのではないかなと僕は思いました。

A bridge to my carrier by the Perl @

A bridge to my carrier by the Perl

YAPCのキーノートはこういう有名な方のルーツを追えるトークで、僕は大好きです。はじめのほうは写真が気になって仕方がなかったけれど、写真がどんどん話の本筋に絡んでいくのは面白かったです。あと僕は2000年前後のインターネットをギリギリ体験した人間だと自分では思っているんですが、そのときに思った掲示板とかWebサービスを作るかっこいい人が地続きで回りにいるんだなあと思うと感慨深くなりました。

LT

ベストトークの芹川くんは僕が連れてきて来ました。なんや!それぐらい言うてええやろ!!! とはいえうちの会社の人は新卒氏含め口がうまいのですごいな~と思います。つまり技術ができてトークが出来るだけでは目立てないので危機感を感じました。あとKindle Oasisうらやましい。内容は。。。ごめんな、、、、なんでも聞いてくれな。。。

PPRとKeyword::Simpleの話はちょっと興味がある話題で楽しかったです。ただ、動的解析になっているので静的解析したい!!! そのためにPPR使えんかなと思っている今日このごろです。どなたか知見を持っていませんか?

自分のトーク

speakerdeck.com

本番投入もしたし、満を持してkuiperbeltの紹介をしてやろうと意気込んでいたんですが、書いているうちに「ミドルウェアの作り方みたいな話のほうが刺さりそう」と思って方針転換してやったトークでした。皆さんいかがでしたか?

あと、WebSocketをLBに入れる入れないという議論があり、今までの前例ではLBに入れない方が多く、Twitterでも「LBに入れるのはつらそう」という意見がありました。で、僕はこのトークではWebApp側がWebSocketのサーバの管理をしたくないからという説明をしたのですが、それだと弱いのかなあと思い、会社Slackでこのトークにも出てこられたid:sfujiwaraさんに「LBなんで入れてるんでしたっけ」と質問したところ、

  • TLS Terminationをサーバでしたくない
    • 証明書の管理とかしんどい。AWSならALB挟めばACMが使える
  • 落ちたやつの切り離しを勝手にやってくれる
  • そもそもコンテナ化してポコポコ生まれはボコボコ生まれる環境ではそれぞれがインターネットにさらされるのはキツイ
    • 弊社ではkuiperbeltはECS上で運用しています

などなど、現在の弊社のアーキテクチャだと必然的にLBに入れざるを得ないと言われました。

これとは別に思ったのが、僕はアプリケーションを書く人間で、fujiwaraさんはインフラをやる人間なのですが、出自が違うと同じミドルウェアであっても視点が少し違うんだなーおもしろいなあ、と思いました。

そんな感じでこのトークを聞いたりスライドを見たりして「俺はこうやっているよ」というのを是非僕に教えてほしいです。そうやって皆さんの知見を吸うために僕はトークをしているので。

あと、できればkuiperbelt、使ってみてほしいなと思います。

YAPC::Okinawa全体の感想

やっぱりこういうリゾート地でカンファレンスやるのはいいですね! 知らない人とも出会えるし、知らない文化に触れることが出来るし、カンファレンスってのは知らないことへの扉になるべきと思っている人間なので、知らない土地でやるっていうのはそれに合っているなあと思いました。地方開催最高!!!

そんなわけで次は東京なわけですが、ホームなのでやっていくぞ!!!!

その他観光

沖縄初上陸で、本編翌日の日曜日は晴れたので観光に行きました。

P3040026.jpg

ジョブキューのスライドに使えそうな信号機があるステーキ屋に行ったり、

P3040072.jpg

首里城で石製だったりタンパク質製の猫にあったり、

P3040210.jpg

泡盛コーヒーで破滅している人間を眺めたり、

P3040221.jpg

P3040223.jpg

コンクリート製のクジラに会いに行ったり、

P3040224.jpg

P3040226.jpg

クジラに取り込まれた魚介類の表情を眺めて死後の世界での気分を想像したりしてました。

あと、ルートビア大好きっ子なのにエンダーに入ったことなかったのですが、念願のエンダーにも行けました。

沖縄最後の飯はやっぱり

そんな感じで沖縄は体験が最高という話でした。皆様ありがとうございました。

P3040312.jpg

YAPC::Okinawa 2018でWebSocketを喋るミドルウェアを作って本番投入した話をします & 予告編 #yapcokinawa

ハイサ〜イ! 最近また入院したマコピーです。

今沖縄に行く飛行機に乗り込んだところなんですけれど、明日のYAPC::Okinawaの予告です。

High (Availability|Performance) WebSocket for Perl Real-Time Application

どういうことやねんって感じですけれど、kuiperbeltの話です。やっと本番投入しているっていうのを胸はって言えるようになったので、本番投入するまでの話をします。

で、なんで作ったかとか経緯の話を盛り込んだらスライド枚数が爆発してしまいとてもじゃないけれど収まらないので、経緯やHTTPに関する前提知識を入れた第1章を公開します。これで「ああ、なんか興味ある話ししてる」って思ったら沖縄まで来てトークを聞いてくれ!!!!

speakerdeck.com

この内容の再演は可能です。

2017年の個人的なまとめ

観測されなければ、存在していると認められない。というのは自分に対する戒めであり、軸であると考えていて、というわけで自分が何であるかを表現するために、今年のアウトプットをまとめようと思ったのでした。

過去のまとめ

2016年 2016年個人的振り返り - ぱいぱいにっき

2012年 2012年、泣いたこと、笑ったこと、学んだこと - ぱいぱいにっき

去年は書いてなかったけれど、それ以前は書いていたよなーって思ったけれど、なんか逆でした。

年末に精神的に不安定になる傾向にあるらしい感じはするので、まあ書く暇もなく社会にキレている場面が多かったなあとか思いました。あと暇かどうかもありそう。同人誌とか。

ギジュツ的なこと

新しく学んだ知識

  • Docker

結構人任せだったけれど、今年はその場限りのDockerfileをサクッと書けるぐらいには理解できてきたと思う。コンテナ周りの特性はだいぶわかってきたし、何をやっちゃうとうまくコンテナにはまらないかは経験したので、あとは本番に乗っける経験かなあとか思った

趣味でPWAを書いた後に、仕事でLambda@Edge使ってNode.jsのコード書いたりしてみたので、ある程度近ごろのJavaScriptのツールチェイン周りはわかった気がしないでもない。始めた当初は謎だったwebpackの立ち位置もわかった。Vue.jsもある程度は……。けれどメインストリームであるReact周りはさわれてないので、何かしら触ってみたい気がする

  • Test2

振り返ってみると、自分の中でテストコードを書くための技術というのは毎年積極的に更新していて、テストコードを書くことがライフワークになりつつある。その中でも今年はPerl5の新しいテストフレームワークであるところのTest2を触ったり読んだり書いてみたりした。YAPCでもトークがありました。で、Test2を使って書いてみたテストコードが、実はWEB+DB Press vol.102Perl Hackers Hubのサポートページのコードにあります。是非見て欲しい。

それを踏まえて、書いたのがTest::MasterData::Declareで、Qiitaにこんな記事を書きました。

qiita.com

これを使ってできることを言ったらGoを使っているチームからも導入したいと言われたので、来年あたりにはコンテナに押し込んでPerl環境がないプロジェクトからも使えるようにしてみます。

行ったイベント

YAPC::Kansai 2017 Osaka

yapcjapan.org

mackee.hatenablog.com

一週間前に鎖骨折ったので骨が粉々の状態で行った地方開催になった初めてのYAPCです。喋ったやつはこちら。

speakerdeck.com

まあやっていることを話しただけです。裏テーマとして運用やっているプロジェクトでもこうやって積み重ねれば外に言えるぐらいの話になるんだぞ!!! ってチームメンバーに伝えたかったのもあります。

Y8 Spring

y8-2017-spring.hachiojipm.org

懇親会でやったやつ。

speakerdeck.com

懇親会で僕の前に行われた@さんのクイズの余興の話でめっちゃ盛り上がっていて、これのあとでやるのかよって思いながら行った感じがします。とはいえお酒の力にも助けられて非常に盛り上がった。僕のトークであんなにワッとなったことないです。

YAPC::Fukuoka 2017 HAKATA

yapcjapan.org

やったやつ。

speakerdeck.com

相変わらずテストの話。Fukuokaは半年前だからもう記憶も曖昧ですが、なんかラーソメーン食べたりうどん食べたりなんか充実した感じでした。食い物のことしか記憶に無いのはどうかと思うが……。

吉祥寺.pm 11

kichijojipm.connpass.com

やったやつ。

speakerdeck.com

7月に鎌倉にチームごと職場が移ったので鎌倉飯テロ画像が多めです。

実際今年はkuiperbeltのコードを触る機会が多くて、っていうのはなんでかというと実際に現場で使われ始めているからなんですが、今年作られたPull Requestは19件もあるわけで、

Pull Requests · mackee/kuiperbelt · GitHub

レースコンディションなくすために内部構造変えてもらったり、通信アイドル時間で切断するのを実装するためにWebSocketライブラリを変えてみたりなどいろいろでかいやつがありました。

kuiperbeltの実際に運用していってどうかみたいな話はYAPC::Okinawaで是非話したいというかプロポーザル応募したので受かるといいな〜。次は強力なゲストがホールで喋る裏ではなくてでかいホール的なところでやりたい〜〜!

builderscon tokyo 2017

builderscon.io

感想ブログ。

mackee.hatenablog.com

やったやつ。

speakerdeck.com

僕の中でYAPCで仕事の話して、buildersconで工作的な話をするみたいな感じになってますが、別にbuildersconで仕事の話のプロポーザルをやってもいいとは思っています。ただ、受かるかな〜という感じですね。

その他書いたライブラリ

github.com

GitHub探して上に出てこないやつ見たらこれぐらいだった。

詳細は以下です。

qiita.com

仕事のこと

2017年は、ずーっと同じサービスの同じチームに同じ役割で1年間通して過ごしました。まともにリーダー的なことを意識してやるの始めてだったので、前半は苦手だなあとかうまくいかないなあとかあったけれど、後半はわりかし自然体で行けた気がする。

あと、後半に安定してきて他の人に仕事を回しつつ時間を作ってライブラリ書いてプロジェクトに突っ込んでみたりとか出来てよかった。あのあたりが一番今年で充実していた気がしないでもない。

来年も臨機応変に。

生活

今年のトピックとしては、

  • 骨を折った
  • 旅行しまくった
  • バイク修理してわりかし乗るようになった

ぐらいかなあ。

骨はYAPC::Osakaの1週間前にスノーボード行ったら一発目で前に吹っ飛んで鎖骨折ったんですが、「あーこれ離れすぎてるし、粉々部分もあるんで手術ですね」と言われて、トークあるんで一週間待ってくれ(迷惑な患者だ)と言って、YAPC::Osakaから帰ってきた翌々日に入院して次の日にすぐ手術でした。生まれて初めて骨折して、生まれて初めて全身麻酔です。入院は保育園の時に一回やって以来の2回目。うちの母にも飛んできてもらって大変ご迷惑をおかけしました。人生において転機として刻まれると思います。とはいえ、体験を得た事自体は悪くないです。次に活かしましょう。例えば小説とか。

旅行は上の話でも大阪やら福岡言ってるんですが、それ以外も

  • 北海道(ニセコ) バックカントリー体験として良かったが、自分の体力の無さに辟易したので今エアロバイクとか乗ってる……
  • 大阪 骨折った状態で新幹線乗って資料書いていた
  • 奄美大島 なんかいきなり同期旅行とか行くぞってなって行った。スキューバは体験としてよかった
  • 博多 おいしいものを食べた
  • あとバイクで相模湖行ったぐらいかなあ

などなどです。飛行機乗った回数はこれまでで一番多い気がする。来年も沖縄に行くし、そもそも年明けにニセコ行くので乗るわって感じです。修行は別にいいかなあ。

ゲーム

ゲームを作っている人間なのでいくらかゲームはする。とはいえ人並み以下ぐらいしかやっていない。

  • FF15 とりあえず全クリした移行やってない。最近はマルチがあるらしい?
  • 人食い大鷲のトリコ 最後まで行ったが、だいぶ疲れるゲームだった。
  • ゼルダ BoW まだ途中。長い〜〜。まあそれがいいんですけれどね……
  • スプラトゥーン2 会社とかでもまだまだずっとやっている。Wii Uのときも間欠的に2年近くやってたしこれもそうなりそう
  • PUBG 最近一番やっているゲームかも。とはいえ精神力を持ってかれる

去年末にHTC Viveを買ったのでいろいろやったがセットアップがめんどくさくて、最近はできていない。PSVRも買っちゃったけれど一回しか使っていない。。。使いたいですねえ。

映画

見たやつ

  • Dr.ストレンジ ハリウッドのバリバリVFX欠乏症になってしまったため、見に行った。その点は解消されたが、やっぱり自分に合うのはSciFiだなってなった
  • Ghost in the Shell うーん、うーん。いやわかる、わかるけれど。いや、イノセンスよりは遥かに理解ができる映画といえばいいのかもしれないし、わかりやすい。SACシリーズよりはわかりにくいかも。ARISEは見ていないので見たほうが良さそう。この映画はまあ良かったです
  • メッセージ 思ったんとちゃうとなったので。原作読んでないのが悪いんだけれど、もう少し言語学周りを掘り下げてもらったら燃えたんですが、まあそんな感じかとなりました。
  • ブレードランナー2049 今年一です。しかしブレードランナー原作は見てません。しかし良かった。ああ、良かった。
  • Fate/stay night [Heaven's Feel] 実はこれが今年一で、しかしアニメだったりするので別腹であると主張しています。SAOオーディナルスケールは見ていたらどうなっていたか、まだ見ていない。

同人誌小説とか

今年は春の文フリに色々書いて、冬は何も出来ずに1ページ分だけフリーペーパー書きました。もう少し定常的に書かないと、書き方自体を忘れて思い出すのに駄作を生み出すという状態になるので、それはよくないですね。

あとこっちの人格とあっちの人格を少しずつ一致させていこうと思った。

来年やりたいこと

  • 銃夢の映画見る
  • スノーボードがやり続けられる体力を作る 骨を折らない
  • たまには実家に帰る
  • 階差機関の完成
  • キーボード自作沼に片足だけ入る
  • Viveとかをちゃんと活用する
  • OSS書く仕事がしたい

そんな感じです。あと最近Pythonとか全然書いていないんですけれど、屋号が詐欺にになっている? さて、良いお年を〜。

#builderscon tokyo 2017に行ってきました, 階差機関と3Dプリンタの話をしてきました

書こう書こうと思っていたのですが遅れました。ちなみに2016の記事も眠っております。今更出す訳にはいかないやろ……。そんな感じで自分の中のワナビー属性を再確認しました。

さて去る8/3〜8/5にかけてbuilderscon tokyo 2017というものが行われたのでそれに行ってきたり、トークをしてきたりしていたのでその感想ブログというわけです。

builderscon.io

印象に残ったトークの感想

複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ

builderscon.io

ベストトーク投票3位のトークです。内容としてはGUIアプリケーションでいい感じにレイヤーを分けつつきれいに設計するには? みたいな話です。

僕は仕事ではまさにアーキテクト的な立ち回りをする事が多いのですが、設計に関しては他人のコードを読んで実践するという感じであんまり本に当たったことはありませんでした。そんなわけで去年とかもこのトークのスピーカーであるしんぺいさんがヤッパチーでやったトークを聞くまで「CQRSって何?」状態でした。聞いて「ああそれに名前ついているんだ」という感じです。こういう概念の話というのは自分でググるのは難しいです。何故かと言うとそれをなんと呼ぶのか難しいからです。というわけで人に聞くという手段を取るわけですが、周りにそういう人がいないと難しい。というわけでカンファレンスという場で体系的な知識をかいつまんで聞くというのは正統派なカンファレンスの利用方法ではないのでしょうか。

しんぺいさんはとっつきにくい概念を具体例に落とし込んで聴衆に理解できるように話すという点でとても優れたスピーカーであると思います。僕も投票しました。スピーカーとしても見習いたい。

Factory Class

builderscon.io

Jesse VincentさんといえばCPAN Authorという感じだったのがキーボード作って売っていたという話で、これは去年のbuilderscon tokyo 2016にも動け!Golang 〜圧倒的IoTツール開発へようこそ〜 - builderscon tokyo 2016というトークがあり、こちらも工場の話がありましたが、今回の話も工場関連。

僕は物理的な物を作るというのはやっていますが、それを製品として数百個数千個単位で売るというのはやったことがありません。ソフトウェアの世界でもProof of ConceptレベルのものもあればProduction Readyなものもあります。僕のはPoCレベルでこのトークで語られたキーボードはまさにProductionと呼べるものです。このような複雑な製品を個人で数千個作るのは出来ないので当然工場に頼むわけですが……トークを聞いているとkickstarterやindigogoでリリースできないガジェットがたくさんあるのがわかってきます(当然それだけが原因ではないのですが)。

マチュアがプロに頼むとカネがかかる、つまりぼったくられるという話はよく聞きますが、まさかやってくれないみたいなこともあるのかと思いました。途中「あなたが製造工場にとって取るに足らないほど小さな規模の製品を依頼しているのであれば、約束を反故にされる」みたいな話があったと思いますが、万全を期すために実力のある相手と組むことが逆に悪い方向に働くことがあるんだなあという新たな知見が得られました。今後の人生に活かしていきたいです。

The Evolution of PHP at Slack HQ

builderscon.io

みんな大好きSlack、みんな大好きPHP、そんな大好き同士は実は関連が深かったみたいな話、というかSlackはPHPで主に作られていますという話です。

会社でもSlackは使っていますが、概ね問題なく使っており、ボットおじさんとしてはAPIが豊富なのが良いという感じです。絵文字もカオスになっております。

Slackは他にもGoを組み合わせているようでそのあたりの組み合わせの話も聞けるかなと思ったのですがそうではなく、結構レガシーをモダンにするという話です。というかPHP5系をHHVMにするという「オッやっておりますなー」という話でした。でも実際に動いているからすごい。こういうこと言う人はいっぱいいますが、ちゃんとやりきっている人は貴重です。大変参考になります。話を聞いているとHHVMがやはりそういう既に動いている5系のアプリの移行をガッツリ想定しているからか、言語デザインやエコシステムとしてスムーズに行っている印象があります。またCanaryサーバ的な構成でデプロイしつつ比率をどんどん上げていくみたいな話も面白かったです。今回やっていきたいイチの話でした。

さてキーボード作る話もそうでしたが、今回も同時通訳がバリバリ活躍しておりまして、このトークの「びっくりタイプ変換」という訳は大好きです。スライドでもSuprise Type Conversionみたいな記述があったので直訳っちゃあ直訳。。。

自分のトーク

builderscon.io

3Dプリンタで作る1次元セル・オートマトン、階差機関、アナログコンピュータ」という題ですが、階差機関しかやってないです。世間の声としては概ね好評という話を聞いております。

僕がやりたかったのは、というかトークをする時のいつもの心構えなんですが「こういうのもあるよ」と提示することです。カンファレンスというのはある意味スピーカーの喋りたい話を参加者に半ば強制的に吹き込む事ができるので、自分の知ってほしい話を喋って新しい発想を促すぞみたいな感じです。その代わり時間を奪うわけですから責任も伴うわけです。いつもは自分が知って驚いたことや面白かったことを体系的にやっていく感じでやっておりうまくいっているのでしばらくはスタイルで行くと思います。階差機関の歯車の動きで加算とリセットを繰り返すのを理解したときは電撃が走った。

参考にした動画はこちら。

www.youtube.com

動いているのが見れます。

www.youtube.com

歯車動くのきれいみたいな動画です。

www.youtube.com

仕組みの動画シリーズの加算の仕組みのところです。これで仕組みを理解しました。このシリーズのあとの方にデジタル計算機である肝のインターロック機構や桁上り機構、コントロールセクションなどがあります。コントロールセクションの平板カムとリンク機構を組み合わせて回転を間欠的な往復運動に変えているのが見どころ。

そんな感じで機械計算機仲間を増やしていきたいですね。

というか裏がMaker Faire Tokyoだったんですよねー。来年は階差機関で出たいぞ。

以下はチラ裏ポエム。

ポエム

そういえばこのブログを書いている週末にはコミックマーケット92、つまり夏コミというやつが行われていて、奇しくもbuildersconの前身であるYAPC::Asiaの最後の年とおなじ東京ビッグサイトで行われているわけです。あのときは確かコミケの一週間後だったような。

さてこのコミケとbuildersconの共通点はなんだろうと考えた時に、僕が思ったのは「オールジャンル」という言葉です。

コミックマーケット同人誌即売会と呼ばれる催しに属しますが、僕が出展したことのある他の同人誌即売会に文フリというのがあります。これはオンリーと呼ばれていて、僕は創作文芸というジャンルなので創作文芸と評論周りのオンリーというやつです。他にも東方だったら例大祭、艦これであれば砲雷撃戦、同人音楽であればM3などとそこそこのジャンルであればオンリーというものはあるわけです。

では何故それに行かずコミケに行くかというと、それは人によって様々な理由があるからだと思うんですが、僕の中では知らないものを見つけたいからという話があります。これは逆の立場からもそうで、創作文芸というジャンルは一次創作つまりオリジナルなので二次創作にあるような公式からのルートのようなものはないわけです。じゃあどうするかというとなろうみたいな小説サイトとかで興味を持った人が実際の即売会に来てくれる。しかしそんな偶然ばかりに頼ってられないので、会場でうろついていたらなんか面白そうなやつがあったみたいなのを求めているわけです。

一度、コミケで隣の人が笏(しゃく)を売っていたことがありました。笏とは平安貴族とかが手に持っている平べったい木簡みたいなやつです。

Kamogawa ceremony 01.jpg
By Chris Gladis, Flickr user MShades - http://flickr.com/photos/mshades/153003004/, CC 表示 2.0, Link

で、面白いから買ったんですけれど、そこで笏は中世のカンペだった話とか、神社のホンモノから型紙を作ってそれを元に手で切り出す話とか面白い話が売っている人から聞けたんです。僕、笏なんてそれまで全く興味がなかったのに。コミケってそういう出会いがあるわけです。

buildersconもそういう「全然知らないジャンル、話、人に興味を持つきっかけになる場」になってほしい。トークだけじゃなくてHUBで飲んでそういう話が聞けたらいいと思うし。

そんな感じで大変満足し、大変承認欲求が満たされた会でした。いい話も聞けたし、いい話もできた。

ところで今回個人スポンサー及びスピーカーでいただいたしゃもじですが、笏に似てますよね? 笏には正しい持ち方があって……

(これは正しい持ち方ではありません)

起きたらしゃもじスタンド出来てたんだけど、高速印刷したらスカスカになってた #builderscon

写真を撮る練習

はい、ひょんなことから会社の人と旅行にいくことになり、「じゃあ写真はよろしく。いいカメラ持ってきてね」とか言われたので、久しく放置していた我が家のミラーレスを引っ張り出したのでした。

しかしまあ手持ちのレンズはキットのパンケーキズームという代物と、追加で買った標準単焦点という具合で。旅のポートレートをやるには少々力不足といった点があります。とくに望遠側が弱い。

単焦点はこれなんですけれど。あ、マイクロフォーサーズです。

photo.yodobashi.com

で、買ったのがこれで。

photo.yodobashi.com

もちろんオリンパスのやつとかでF4通しのレンズとかあるんですけれど、PROレンズなのでクソ高い。あとミラーレスは完全に放置していたのでまた放置しかねないので撒き餌レンズを買うのが適当だろうという具合ですね。

で、動物園行こうとしたんですけれどあとに予定が入っていたので目黒の植物園的なところに行って練習してきました。

www.ins.kahaku.go.jp

言ってみたんですけれど思ったより森です。僕はど田舎の森育ちなので森に来ると日常の風景を思い出す感がありそれはそれでよいのですがおもったより森でした。

P6170600.jpg

入り口からこれです。周りビルとか高速道路の高架とかあるんですけれど、なんで一歩入ったら森やねんって感じです。東京ってこういうの多くないですか? 皇居とか代々木公園とか……。

P6170623.jpg

P6170821.jpg

P6170867.jpg

こういうアップダウンある感じいいですよね。道的な伸びていくものに対しては魅力がある。構図とか学がなくてわかんないんですけれどとりあえず入れとけばいいかなって感じになってお手軽なのかも。

P6170644.jpg

3つに分けるといいってどっかのサイトに書いてあったけれどよく分からん。

P6170682.jpg

P6170710.jpg

緑ばっかじゃあれなんで、道端のものとか撮ってみる。しかし撮ったあとに俺は緑を撮りに来たのではないか? という謎の囁きによって少し後悔する。

P6170609.jpg

P6170699.jpg

まあどっちにしろ木ばっかなんで木を撮るんですけれど。ていうか異常に茂っていてコンクリートジャングルに寝泊まりしている身としては少し身構えますよね。

P6170621.jpg

あともともとなんか武家屋敷というか山城的なところだったらしくこういう看板があります。これは土塁と書いてあります。

P6170638.jpg

でかい。

P6170611.jpg

やたらでかい。

P6170634.jpg

高倍率ズームを買っているわけなので、まあこういう写真が撮りたくなるわけですね。

P6170684.jpg

若いので逆光でも構わず撮る。

P6170675.jpg

ワイド端は14mmなので歪むわけですが、そういうレンズは持っていなかったので広がりがありますね。

P6170826.jpg

適当に上に向けてみるとカッコイイ。金田パースに通じるものがありますね。

P6170869.jpg

これとか飛んでるんですけれど、撮っているときはよくわからない……。調べたらヒストグラムを出す機能があるっぽいので今度からそれ見ます。人間の目ってすごいなあって思いました。白飛びしない。

P6170717.jpg

葉っぱばっかなのもなんなんで花にしましょう。

P6170723.jpg

P6170727.jpg

花はなんかテレ端で寄ったほうがうまく決まるのはなんでなんですかね。うまく決まっていると思い込んでいるだけで実は別が良い? まあこれも飛んでますけれど。

P6170742.jpg

題名は「処遇」という感じです。

P6170852.jpg

P6170842.jpg

あじさいがいました。母が好きなんで送っときます。

P6170774.jpg

P6170777.jpg

とりあえず真ん中で撮ってみたけれどこっちのほうがいいかな? ってなったので寄せてみたらナルホドってなりました。このあたりの理論を身につけるのが難しい。何がいい写真なのか。何がいい構図なのか、何がいい色味なのか。解像度とは……。わからん……。

鳥とか蝶とかいたんですけれど、

P6170720.jpg

なんかこういう水を撮ってたら横でカップルが「めっちゃ黒い蝶いるじゃん、花の蜜吸ってるのかな」とか言ってマジかよってそっちに向けたら飛んでいきました。注意力が必要ですね。

で、スズメがバチバチ歩いていたんで撮ろうとしたんですけれど、

P6170665.jpg

P6170664.jpg

ダメですね。テレ端やし、シャッタースピードも上げられず。

で、カラスが木に止まっていたんですけれど、

P6170801.jpg

前の枝とかにAF当たって全然ダメで何度も撮り直して、そしたら「もう写真いっぱいです」とかカメラに言われて消してたんですけれど「あーもうどっかいっちゃったかなー」って思ってたらまだいて、どんだけこいつ休んでいるんだよって思いながら撮りました。

P6170811.jpg

角度を変えて撮れるぐらいじっとしていたなこいつ。カラスなんだけれどこうやって撮るとカッコイイな。

まとめ

  • 140mm楽しい。圧縮効果っていうんですか? そういうのもやっていきたい
    • しかし手ブレクソ辛い。ボディにもレンズにも手ぶれ補正ついているんだけれど、それでよくなっている気はせず呼吸を止める術が必要。今回はハンドストラップも導入し備えた感じ。
  • 今回は動かない物を撮っているわけで、旅行とか行くと人も撮るわけでそういうときは今回みたいに同じ構図を何枚も何枚も撮るみたいなことは出来ないわけである。平均して3枚から5枚ぐらい撮っている気がする。なので動物とかそういうのでやっぱり練習しないとなとは思った。
  • 単焦点は楽
  • カメラバッグ的なメッセンジャーバッグ買ったけれどそこそこ便利。重いけれど丈夫感ある。

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も行きたい
  • 次の日に鴨川ビールという京都の会社での儀式に参加しましたが謎でした。謎だし、京都の会社の人は「いいじゃん〜明日帰ればいいじゃん〜」と引き止めにかかることがわかりました。危険です。今度は暖かい時期に行きたいですね。

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

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

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

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

では!