builderscon Tokyo 2017で圧倒的な敗北をもらって来た

8/4〜8/6にかけてbuilderscon Tokyo 2017にスピーカーとして参加させていただきました。当日話した資料については下記の通りです。 今回はmrubyの言語そのものの魅力と、僕たちが実装し、運用している内容について紹介させていただきました。 発表後、いくつかの質問や、Twitterでも質問をいただきすごく嬉しかったです。 一方で、今回の登壇は自分の現実をいい意味でフィードバックもらえる機会だったなと感じています。 具体的には当日全く集客ができませんでした。 会場としてはメインホールをいただいており、この上ない状況だったのですが、自身の実力がたりず、会場の10分の1も埋められていなかったのではないかなと思います。 こればっかりは当日にはどうすることもできない話ではあるのですが、つまるところ、その前段で、日常的にいかにアウトプットして、世界にインパクトを与え続けられているということが実践できてないのだなと感じました。 これまで積んで来たもので、それなりのステージに立てるようにはなって来たものの、まだまだ広く認められるというレベルには全く至っていないので、胡座をかくことなく、コードでも文章でもアウトプットし続けなければならいと身が引き締まりました。 僕はベストスピーカーの土俵にすら立てなかったので、また来年、強くなって帰ってこようと思います。 ここまでがスピーカーとしての話で、参加者としては、海外からのゲストスピーカーを始め、非常に幅広いテーマでこのカンファレンスでしか聞けない!!!という話しが多くあり非常に楽しく過ごすことができました。 個人的な話にはなるのですが、ペパボの縁がありつつも、会えそうで会えなかったmizzyさんとお会いし、さらには晩御飯をご馳走になったり、現在進行形で執筆を進めさせていただいている技術評論社の@inaoさんにダイレクトに原稿の催促をいただくなど、東京のカンファレンスだからこそ味わえる体験をさせていただきました。 ついに会ってしまった2人…! pic.twitter.com/y3Lzjyh3Wr — Shinya Tsunematsu (@tnmt) August 3,

More

YAPC::Fukuoka 2017 HAKATAでロリポップのAPIについてトークしてきた

僕にとって、YAPC::Fukuoka 2017 HAKATAは非常にロングランで濃いものだった。まずは前日に自社のオフィスで開催された、全然野菜に始まる。 これは元々同僚である @hsbt さんが社のSlackで下記の投稿をしたことから全てが始まった。 現在ペパボ@福岡はオフィス改装中で、ペパステというステージを設けて、登壇イベントをパッケージングしているのでほとんど準備することなく飲み物の準備をするくらいで、当日 #全然野菜 がバズるくらいには盛り上がって大変良かった。 YAPC::Fukuoka 前々夜祭(非公式) きた、ペパステという空間がおしゃれ #全然野菜 #yapchttps://t.co/lrA4cM89lL pic.twitter.com/vk1nglSPiE — うずら (@uzulla) 2017年6月30日 その後は公式の前夜祭に移動し、 @udzura が酔って変なテンションになりながらも、Perlと称してClangのライブコーディングをやり遂げるさまを眺めたりしていた。 こんにちは〜 pic.twitter.com/zpXDzk926t — SHIBATA Hiroshi (@hsbt) 2017年6月30日 そんなこんなでLTソンも終わり、 @hsbt と談笑していると、後ろから肩を誰かにぐわっと捕まれ、 「魚っ!おすすめ!」のような検索ワードか!!という勢いで @songmuさんに声をかけられたので、前夜祭のあとは次の日のトップバッターが両方存在するというチキンレースのような面子で鯖郎へ。 これが管理職ですよ — songmu (@songmu) 2017年6月30日 今年もとても良い YAPC だった! #yapcjapan pic.twitter.com/Mw27xOHh4s — 大沢和宏

More

スレッドセーフなmruby-signal-threadを書いた

最近仕事でmrubyを触り始めて、だいぶC言語に触れ合う時間が増えてきたので、@matsumotoryのススメもあって、mgemを書きました。 なぜ作ったのか mrubyには既にmruby-signalというCRubyのクローン実装のmgemも存在するのですが、マルチスレッドでの動作を考えた場合に、グローバル変数にmrb_stateを持つことから、意図しない動作となるケースがあるため再実装しました。シングルプロセス、シングルスレッドで使うにはmruby-signalで十分なので、今回はコントリビュートではなく別実装とした意図があります。 使い方 シンプルにこのような実装にしました。mruby-threadにシグナルを指定可能にしたようなイメージが近いと思います。 工夫 実装するにあたり工夫が必要だったのは、下記のコードです。 今回の実装はSignalThread#trapが実行されるごとに、mruby-threadを利用して、そのシグナルを処理する専用のスレッドを起動し、スレッドでsigwaitするような実装としています。しかし、その場合、複数のスレッドを起動した場合に、先に起動したスレッドに後続のスレッドが処理するはずのシグナルが配送されてしまう事が起こりえます。 HUPを処理するスレッド1を起動 USR1を処理するスレッド2を起動 USR1シグナルを送る この場合に、スレッド1にUSR1が配送されてしまうケースに該当します。スレッド1のsigwaitはHUPのみを待ち受けているのですが、そこにUSR1が配送されても意図したハンドラ処理を行うことが出来ません。この辺のシグナルの流れは同僚の@harasouが書いたLinux

More

SSHのログイン先でも最適化されたvimが使いたい

サーバでオペレーションするときに、ちょっとトラブルシュートしたりするくらいならよいのですが、定期的にログインして作業するサーバがそれなりにあって、その生産性があまり無視できなくなったのでSTNSにstns-setupという機能を設けました。 STNS導入済みのクライアントでstns-setupコマンドを実行すると、事前に定義しておいたコマンドを実行することが出来ます。 $ stns-setup アトリビュートはこんな感じです。 [users.example] id = 1000 name = "example" setup_commands = [ "git clone https://github.com/pyama86/dotfiles.git /home/example/dotfiles", "/bin/sh

More

STNSが単体でのTLS暗号化&クライアント認証に対応しました

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-22-22-54-23

先日STNS,libnss-stnsともに0.2.2をリリースしました。主な変更内容は下記のとおりです。 TLS暗号化に対応 TLSを利用したクライアント認証に対応 retry_requestパラメーターでクライントのリトライ回数を指定可能にした ubuntu14.04における再起動が完了しない不具合を修正 TLS関連 これまではnginxなどと組み合わせてTLS/SSL暗号化を提供していましたが、@naoto_gohkoさんからissueを頂いたのと、昨今みんな出来るだけサーバ立てたくないんだろうなぁというフォースを感じたので、単体でTLS暗号化に対応し、サーバ、クライアント共にパラメータを追加しています。 STNS.jp Configuration tls_ca = "keys/ca.pem" # using only client authentication tls_cert = "keys/server.crt" tls_key = "keys/server.key" クライアント、サーバいずれもパラメーターの内容は一緒ですが、サーバのtls_ca及び、クライアントのTLS関連のパラメーターについてはクライアント認証を行うときだけ指定してください。 TLS暗号化だけを利用する場合 stns.conf tls_cert = "keys/server.crt" tls_key = "keys/server.key" libnss_stns.conf api_end_point = ["https://example.jp:1104/v2"] TLSクライアント認証を利用する場合 stns.conf tls_ca = "keys/ca.pem" tls_cert = "keys/server.crt" tls_key

More