ぱいぱいにっき

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

GitHubにメール書いて放置アカウントを消してもらってkuiperbelt organizationを作った

要約

  • そろそろ合ったほうがいいなと思ったので、kuiperbeltのGitHub Organizationを作ろうと思ったら、もう既にそういうユーザがいた
  • 見てみると最近活動していなさそうだったので、GitHubにメールを送って名前空間を開放してもらった
  • すぐにkuiperbelt organizationを取ってmackee/kuiperbeltをtransferしました

経緯

  • DockerHubのautomated buildでimageを作ってもらう関係上、kuiperbeltリポジトリに同居していたサンプルアプリを別リポジトリに追い出そうと思った
  • mackee/kuiperbelt-sample-appだとしまりがないので、kuiperbelt organaizationを取ろうと思った
  • でも https://github.com/kuiperbelt は誰かのアカウントとして取られていた
  • 最近使われている形跡がない……2013年に作られてリポジトリはなくどこかのリポジトリに何回かコミットした程度
  • ここで以下の記事を思い出した

lestrrat.ldblog.jp

efcl.info

  • 某Slackで上記ブログのlestrratさんに聞いてみたら「突撃あるのみ！」と背中を押してもらったのでメールすることにしてみた

GitHubにメール

  • 上記azuさんのブログに「問い合わせフォームよりはメールのほうが速い」とあり、まあそりゃそうだよなと思って直接メールした
  • 文面は自分で書いてみようと思ったが、だいたい参考にしたazuさんのものと同じような感じだった
  • で、送ったら20分で返ってきた
Hi Taniwaki,

You are in luck — we have classified the kuiperbelt account as inactive and released the username for you to claim, as per our Name Squatting Policy:

https://help.github.com/articles/name-squatting-policy

Be quick, as the username is now publicly available.

Have a great day!
  • このName Squatting Policyの存在は知っていたが（というか知ってたから問い合わせたんだけれど）、あまりにも早すぎてびっくりした
  • 返信来てからメールを確認するまで1時間ほどたっていたので急いでkuiperbelt organizationを取った

ogranaizationへの移管でやること

  • Goはcodeに自分へのインポートパスがgithubのフルパスで書かれていることが多く、置換が必要
  • また、ドキュメントにもコードへのリンクやインストール方法などで入っていることがあるので置換する必要がある
  • やった

github.com

  • 見落としていたのは.travis.ymlでタグ切った時にリリースバイナリを作るところでリポジトリ名を指定していたのでここもやらないといけなかった
  • DockerHubも同じようにOrganizationを作ってdocker pull kuiperbelt/kuiperbeltで利用できるようにした

まあいろいろやった。あとこのブログ書く時に確認したらhttpsに出来ててめでたい。

そろそろ正式サービスが始まる#arukas でkuiperbeltを動かしてみる

golang Perl Redis

arukas.io

これで

github.com

を動かす話

要約と言うか感想

  • Arukasは簡単だけれど、その裏返しで制限が厳しい
    • private registryにはまだ対応予定状態だとか
    • VPNっぽい仕組みがないとか
  • kuiperbeltが想定している環境ではない
    • 特定のコンテナに対する通信がしたい
      • コントロールパネルやAPIからはホスト名とポートを取れる
      • コンテナ自身が割り当てられている環境を知る方法はなさそう？
        • 環境変数とかで知れるようにしてほしいと要望メールした
        • 追記: Twitter眺めてたら取る方法を発見した。下の方に追記してます
  • データストアとArukasは非常に相性が悪い
    • と言うかストレージが無い
    • MySQLだとレプリ組んでなんとかするとかRedisでもそうするとかそういうレベル
    • そもそもDocker自体とも相性が悪いのだけれど
    • 海外のContainer as a Serviceであるhyper.shにはあるらしい
  • kuiperbelt instance 1台構成なら出来たのでやり方を晒してみる

何を構築した？

  • かんたんなWebSocketを使ったチャットアプリ
  • kuiperbeltを使えばWebSocketとか何も考えずに作った普通のWeb Applicationでも簡単にWebSocketを扱えるようになりますというのを示したい

構成

f:id:mackee_w:20180321145828p:plain

  • Perl/PSGI Application x N
    • 素Plackで書いたPrefork Server
    • 別にここはRailsでもSinatraでもLaravelでもSlimでもDjangoでもFlaskでもExpressでもなんでも、Webサーバーであればなんでも良い。僕がPerlならサクッと書けるからそうしただけ
    • ここはスケール可能で、詰まったら何台でも並べられる
  • Redis x 1
    • 高可用性取るならレプリケーションしたほうが良い
    • というかコンテナでデータストア運用するのが（ｒｙ
    • ここもRedisじゃなくてもKVS的な機能を持っていれば良くて、pub/subとかは使ってない。SET型使ってるけれどmemcachedであれば、カンマ区切りで複数個入れるのでも良くて、と思ったけれどアトミックに要素を出し入れするのは考えないといけ無さそう
    • ぶっちゃけRDBMSでも良い
    • というか認証も暗号化もかかってない。ノーガード戦法で平文をインターネットが漂っている
      • ホストとポートを推測しにくいものを使って、パケットがArukas内部で収まっていることを祈りながら使っているけれど、みなさんは真似しないように
      • ローカルのredis-cliから繋げられてデバッグに便利
  • kuiperbelt x 1
    • アイコンはWebSocketのロゴらしいです
    • ここが現状1台なんだなぁ
    • いや、今回はAppのほうでkuiperbeltのエンドポイントを返すようにしたのでそこを複数個にしてクライアントがランダムで何処かに繋げば複数台が可能
    • ここには課題があります

kuiperbeltがのびのびと動くための条件

  • のびのび=クライアントからのWebSocketを扱うkuiperbeltが複数台でロードバランサー配下に収まって機能する
  • Web Application側がメッセージをクライアントに送る時に対象のクライアントがどのkuiperbeltにつながっているかを知る必要がある
    • この情報は接続時コールバックで渡ってきてWeb Application側がKVSとかに保存する
  • 接続時コールバックでWeb Applicationに通知するための「外からつながる自分のホスト名/IPアドレスとポート」をコンテナ自身が知る必要がある

Arukasでは

  • アプリケーションは単一のエンドポイントを持つ
    • これが曲者でアプリケーション起動時に設定したポートに飛んでいくが、httpsしか対応していないっぽい？
  • コンテナ一個一個にホスト名とポートが割り当てられる
    • これらはガチャ
  • コンテナごとに割り当てられるホスト名とポートをコンテナ自身が知ることができれば勝つる
    • 現在は敗北してます
  • しょうがないので1アプリケーション1コンテナ、増やしたいならアプリケーションを増やす、この辺のリストはWeb Application側に環境変数で渡せるようにした
    • このやり方でも無停止でkuiperbelt側を増やすことが出来る
  • 1コンテナでも512MBもメモリがあれば2500接続ぐらいは余裕で持つ事ができるわけで、全然問題無さそう。メッセージ数はちょっとあれだけれど
    • 今のやつはつながっている全員にブロードキャストしているので危ない

設定例

kuiperbelt

f:id:mackee_w:20180321152806p:plain

webapp

f:id:mackee_w:20180321153037p:plain

redis

  • redis:latest指定して立ててるだけ

展望

  • 前述のhyper.shでも試してみる
    • つながるIPをコンテナにアタッチできるみたい
    • ドキュメント見る限りはそれでもやはりよしなスケールは出来無さそう？
  • GKEもといkubernetes...
  • もっとちゃんとしたアプリケーションを作る
    • このサンプルアプリだと見た目で夢が広がりにくいかなあ
  • あとコンテナで監視ってどうやるんだろう。。。

追記:2018-03-22

Twitter眺めてたら、 pottavaというイメージをArukasで立てている人がいて、そのコンテナのURLを叩いてみると、渡ってきた環境変数やらがババっとJSON APIで取得できるという代物だった。

その中にMARATHON_HOST と MARATHON_PORT という環境変数があり、値の方はコントロールパネルで見たことのあるようなものが。。。。

早速自分も同じイメージで立ててみて検証してみた。

である。つまりこれは望んでいたものではーーー？？？？？

今のkuiperbeltの公式イメージにそのまま適用することは出来ないが、arukas用の設定ファイルを作ればいけるのでそういうDockerfileを書いてみようと思う。

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

golang Perl

要約

  • 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とかクロスコンパイルツールgoxz、GitHub 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更新

  • ちょっとだけ気合を入れて書き換えた
  • ところで英語はかなりできないです。トラウマがあるレベル
  • 今回はGrammerlyとGoogle翻訳を併用しつつ書いたけれど、まだまだ意味不明な文があると思う。つらい
  • どんな機能があるか分からんという声があったので、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.102のPerl 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とか全然書いていないんですけれど、屋号が詐欺にになっている？　さて、良いお年を〜。