PHPerKaigi 2020 にスピーカー＆当日スタッフで参加してきた
PHPerKaigi 2020にスピーカー兼当日スタッフで参加してきました、エントリーです。
スピーカー
二日目に、PHPシステムをコンテナで動かすための取り組みのすべて by きくもと | トーク | PHPerKaigi 2020 #phperkaigi - fortee.jp として30分枠で話してきました。
資料は↓です。
地味なネタだけに通ると思っていませんでしたが、久しぶりに外で話す機会が持てたことに感謝です。
また聞きにきていただいたかたにも感謝です。ありがとうございました。
何か新しい技術とかはないのですけど、実際にやったことであるので、何かの参考になれば幸いです。
やはり話すのは楽しいですね。また良いネタができたときには話したいです。
当日スタッフ
また、今年もですが、当日スタッフでの参加でした。で、例年通り受付してました。
今年は幸い人が集中することもなく、また慣れている参加者もそれなりにいるのか、受付はほぼスムーズに流れていたように思います。
が、今年の最大のポイントはやはり、これですよ、これ
トレカ！
全員にあったわけではないのですがそれでも物量がすごくて、スマートにお渡しできず、ちょっとバタバタしながらのお渡しになってしまったかなぁと思っており、また次回があるなら良い方法を考えてリベンジしたいところです。
お渡しする時の皆さんのリアクションがよくて、受付的にも楽しかったです。
皆さん、ご来場ありがとうございました！
最後に
毎年こうやっていろんな人と交流できるPHPerKaigiに感謝です。また、来年もなんらかの形でかかわっていきたいなぁという気持ちになった 2020 でした。
ありがとうござました！！！
Dygma Raiseがやってきた
７月に申し込んだキーボード Dygma Raise
がついに届きました！
ついにDygmaがやってきた！まずは開封の儀。これで年末年始は楽しめるぞ。 #dygma #dygmaraise pic.twitter.com/RqLd5rfIsz
— kikumoto (@takakiku) 2019年12月28日
申し込んだ時はまだ絶賛開発中だったので、夏の終わりにくれば良いかなと思ってましたが、結局ほぼ半年待った形に。 まぁ、待つことは覚悟してたので、そこはあんまり気にはしてない。
そもそもなぜ Dygma Raise を買ったかですが
- 分割キーボードにしたかった
- Mistel Barocco を持っている人のをみて、１体にもできるのは何となく良さそうだった
- 親指部分に機能を集中させたかった
という感じで調べてたら Dygma Raise を見つけて、これだ！と思いポチりました。
繋いだ状態はこんな感じ（まだまだこれから整えていく）
ファーストインプレッション
キースイッチは Kailh Speed Silver というやつにしました。
まぁ、特に嫌いという感じではなかった打感なので、これで良かったかな。
Macのキーボードに慣れすぎていたから、キーキャップが発する音（と言えばいいのかな）がまぁまぁするなぁという感じ。
親指部分に、Returnとかバックスペースを使えるのはやはり快適。（あくまで個人的感想ですw）
パームパッドもついてくるのだけど、これは私は使わないかなぁ。
本体については基本大満足ですね。本当は、パームレストが取り外せるともっと最高なんだけど。（なお、一体型というのは理解して買っています）
一方問題なのはキーの設定をするソフトウェア。
Bazecor というアプリをダウンロードして使うのだけど、まだまだ不安定な感じですね。
もっとも、不安定なのはソフトなのかキーボード側のファームなのかは定かではないですが。
レイヤーを任意に一発で切り替えたいのだけど、現状は１つのキーに特定のレイヤーの変更を割当る感じになってしまう。
実質２、３レイヤーしか使わないから、レイヤーのために２つのキーを割り当てる程度でまだ棲むけど。
このあたりは、ソフトウエアのアップデートに期待したい。
それにまだまだよく落ちる。。。
ソフトウェアが落ちても別にキーボードそのものはちゃんと動くから、まぁ早く安定版を作ってくれ、という感じ。
キーの設定をテキストでエキスポート、インポートできるのは良いですね。git 管理することにしました。
まだまだ年末・年始休暇は始まったばかりなので、まずはキー設定を自分好みにしていくぞ！！
ファイルが作成されたら自動追尾するfluent-agent-chimeraを作りました
特定のディレクトリ配下に、任意のタイミングでディレクトリが新規作成されて、その配下にログが出力されているような状況下で、そのログをin_tailで取り込みたいという必要性から、fluent-agent-chimera
を作りました。
目次
例えば というディレクトリ、ファイルがあるとします。 これに対して、設定ファイルとして以下のようなものを用意します。 この設定でfluent-agent-chimeraを起動すると、まず のファイルが監視対象となり、ログが出力されると指定のfluentサーバにログがforwardされます。 ここで というファイルが作成されると、dir1/hoge_20180202.log は監視対象からはずれ、dir1/hoge_20180203.log が監視対象となります。 さらに が作成されれば、このファイルも新たに監視対象となります。 このように、監視対象のディレクトリと、正規表現にマッチするファイル（ただし、ファイル名に日付を含むファイル）を新規に作成されるものも含めて自動追尾して、fluentサーバにログをforwardしてくれるのが、fluent-agent-chimeraです。 まぁ、アプリとかバッチのログ出力をちゃんと最初から設計して、普通にfluentやfluent-agent-hydraなどで追えるようにしおけばこんなものは不要なのですが、いろいろ事情もあるわけで（つらい）、こんな GitHubのリポジトリにも書いていますが、fluent-agent-chimeraは、@fujiwara さんの です。基本的な構成は同じで、inotifyでの処理部分を作り込みつつ、in_forwardを削ったり、ファイルの中身を処理するところ削ったりしています。 fluent-agent-chimeraは、基本的に新規作成ファイルの検知がメインで、あとはなるべくローカルのfluentに処理を移譲する、という想定でいます。 あとは、fluentのclientとして、@lestrrat さんの に変更しまいた。fluent-agent-hydraを大きく書き換えているので、fluentのclient部分をfluent-agent-hydraに組み込まれているfluent clientに依存させると、それに追随するのも手間かなと思ったのと、単にいじってみたかったので、変えました。そのおかげで、unix domain socketでfluentサーバと通信も可能です。 今回、初めてGoのソースを公開するってのをしたのですが、一連の公開の手順については、@songmu さんの を多いに参考にさせてもらいました。 goxz 含めて、gobump, ghr, ghch などが見事に連携されていて、このやり方が標準になれば良いのでは、と個人的には思ったほどです。多分、今後もこれにならう感じになりそうです。 個人的には、やっぱりGoは肌にあっているなぁという感じです。もっとGoを書いていきたい。 で、もし感想とかありましたら、@takakiku までいただけると嬉しいかもです。どういうものか
/path/to/batchdir
- dir1
- hoge_20180201.log
- hoge_20180202.log
- xxxx_20180201
- yyyy.log
- dir2
- hoge_20180201.log
[Server]
Network = "tcp"
Address = "127.0.0.1:24224"
[[Logs]]
Tag = "batch"
Basedir = "/path/to/batchdir"
Recursive = true
TargetFileRegexp = "^.+/batchdir/.*(\\d{8})(?:.*\\.log)?$"
FileTimeFormat = "20060102"
/path/to/batchdir
- dir1
- hoge_20180202.log
- xxxx_20180201
- dir2
- hoge_20180201.log
/path/to/batchdir/dir1/hoge_20180203.log
/path/to/batchdir/dir3/hoge_20180202.log
闇のようなツールを生み出しました。実装について
そのほか
最後に
Nginx+SiteGuard LiteのRPM作成Docker - ngx_mruby を添えて -
さくらインターネットの環境でSiteGuard Liteが無償で使えますが、特に今年の６月にはNginx版も提供されるようになっていますね。
それまではApacheのみの対応であったので、Nginxを使っている身としてはちょっと縁がないかなぁと思っていたわけですが、Nginxが出たので利用し始めています。
ただ、仕方ないのですが、Nginxをソースからビルドしてインストールする、という手順となるのでそこが複数台のサーバにインストールするときに面倒だったり、一応バージョン管理もしたいので、イマイチでした。
なので、CentOS7限定（自分が必要だったので）ですが、SiteGuard Lite付きNginx RPMをビルドするためのDockerfileを作ったので公開します。RPM作成となるベースのNginxは、CentOS7向けに公開されているSRPMを使っています。
ついでに、ngx_mrubyも必要であったので ngx_mruby 付きです。公開リポジトリには、ngx_mruby なしも公開しています。
ngx_mruby あり github.com
ngx_mruby なし（同一リポジトリの別ブランチ） https://github.com/kikumoto/nginx-siteguard_lite-rpm/tree/without_nxg_mruby
上記リポジトリのREADMEの通りですが、そもそもさくらインターネットの環境でSiteGuard Liteを利用できる条件を満たしていることが前提です。
その上でリポジトリをcloneして
make
すれば build ディレクトリ配下にRPMが作成されます。
このRPMを使えば、SiteGuard Lite公式のドキュメントにてNginxをビルドする箇所を、RPMインストールに読み替えればOKです。
誰かの参考になれば幸いです。
感動で始まり、（良い意味で）悲しみで終わった三日間
悲しみで終わった、ってタイトルに書くと、なにかよくない印象かもしれないけれどそうではないです。
iOSDC JAPAN 2017
に、昨年に続いて今年も当日スタッフとして参加させてもらいました。
いろんな方のブログやTweetを見る限りは、大成功といって良いと思っています。
スポンサーの皆様、スピーカーの皆様、来場者の皆様、当日スタッフの皆様、ネットワークチームの皆様、コアスタッフの皆様本当にありがとうございました。
特に、コアスタッフの方々には大きな感謝しかないです。大変な準備をしていただいたおかげで当日は大きなトラブルもなく色々なことが無事に進みました。ありがとうございました！
以下は完全に個人的なポエムですね。興味あればどうぞ。あとは、カンファレンススタッフやってみたいなぁと思うかたに、何か感じてもらえれば。
で、何が感動の始まりだったかというと、こちらの Tweet の通り。
王座を争う戦いに破れて、棺桶に封印される主催者。
— kikumoto (@takakiku) 2017年8月30日
ではなくて、iosdcの当日スタッフMTGの様子です。１年ぶりの再会となった人もいて、なんかこうスタッフMTGから感動が始まっている気がした。 #iosdc pic.twitter.com/oVIHGW6IUa
昨年も当日スタッフだったので、この事前MTGで１年ぶりにあう人が結構いました。スタッフの中には時折他の勉強会などで会う人も多少はいたのですが、１年ぶりのひとも結構いました。
なんでしょうね、昨年同じ時間をわずかながら共有しただけなのに、いろんな記憶が呼び起こされるし、あーこの人たちいたからとてもうまくいったなぁとかあって、この人たちとまた一緒だから今年も安心だぁ、などなど、今年もスタッフやってよかったぁ、と感動してしまったわけですね。これは２年目じゃないと味わえない感覚なんだろうなと。
さて、三日間はほぼ受付に張り付いてました。たいていの個人スポンサー・スピーカーの方の対応はさせていただいたんじゃないかなと思います。
まぁ今年のスタッフの方々も大変すごくて、総勢800人の方々を無事に迎え入れることができたんじゃないかと思います。本当に感謝です。
そんなこんなで前夜祭の準備から含めて３日間、このようなすばらしい仲間たちとずっと仕事ができると楽しいだろうなぁ（カンファレンスのような日々が毎日あるのはさすが体が持たないけどw）と思いつつ、有意義な時間を過ごせました。
「夜の」は私は参加しなかったので、スタッフ打ち上げも終わって帰路についたのですが、なんと電車に乗って座ったところで、こみ上げて来るものがあって、涙がでてきたんですよねぇ。
またあと１年はスタッフとして同じ時間を過ごした多くの人たちとは合わないのだろうなぁ、と思ったらなにかこう悲しくなってしまって。
ただ、これも２年目だからだと思います。再会の感動を知ってしまったので、また１年会えないんだなぁと思うことで、涙になったんだろうと。
スタッフとして充実し、普段味わうことのない三日間を過ごせたからこそですね。
とにかく、こういう感情ってのはそうそう日常にあることではなく、本当にカンファレンススタッフというのはいろんな意味で良い経験ができるので、スピーカー登壇とは別な意味でオススメしたいです。
iOSDC以外にもカンファレンス・勉強会はたくさんあるので、ぜひやってみると良いと思います。
そこから新しい感動が始まるはずです。
以上駄文でした。
はやく１年すぎないかぁ〜。その前に振り返り会があえれば、多少の人は会えるか。
知らなかったを知った - BBQ::builderscon 2017 #1
builderscon といえば肉ですね（違う
ということで、
に参加してきました。
これは builderscon のテーマ「「知らなかった、を聞く」にある意味沿っているイベントでした。 今まで知らなかった「肉」の世界を知ってしまった感じです。
「肉」はあの塊でもって「肉」なわけですね。一つレベルがあがりましたw
ちょっと下の写真では肉の塊感が足りてないので、不十分ですね。手持ちがなかった。
l
冗談のように書いてますが、本当に肉はどの肉も素晴らしかったです。
元来雨男なので当初の天気予報（曇り時々雨）を見たときは、やってしまった、と思ってましたが当日は快晴で、いろんな方ともお会いできて最高の１日となりました。
次回もタイミングあえば是非参加したいですね。
では、最後に本編もよろしくお願いいたします。
Y8 2017 spring in Shibuyaに参加してきました
Y8 2017 spring in Shibuyaに参加してきました y8-2017-spring.hachiojipm.org
資料は connpass の方に上がってきているようですね。 connpass.com
諸々あって今年最初のコミュニティ型のカンファレンス参加。しかも久しぶりにスタッフではなく純粋に一参加者として行ってきました。
それなりのまとめはだれか書いてくれるだろうからそこは書かないですが、個人的には朝一の @oza_shu さんいよる speakerdeck.com
がよかったですね。
自分はデスクトップアプリ・Webサービスのプログラミング業をしてからインフラに移っていった勢ですが、@oza_shu さんが気になったようところはやはり同じように気になってそこからいろいろ学べたので、@oza_shu さんのあげているポイントは特にこれから学ぼうとする人は参考にすると良いんじゃないかなと思った。
その他のトークもどれもためになりました。全てを理解できるほどのスキルはないですが、それなりに参考・得るものがあり Y8 のトーク選定がすばらしいと感じました。スタッフのみなさまありがとうございます！
今回コンパクト開催ということでしたが、これは結構良いですね。トラックが複数あって選ぶのも良いですが、厳選されたもののみの１トラックだと、自分のとりあえずの興味分野外でも聞くことになって、結局はそこからも得るものがあることになり、これまでより興味・知識の幅が広がるように思いました。 Y8 はこのスタイルが良いのかもしれない（あくまで個人の感想です）。
また、次回があるだろう、ということで楽しみにしています。（あ、状況許せば当日スタッフはしたいかな。嫌じゃないですよw）