写真のような感じでRubyKaigi2018で登壇し、RubyKaigiを経て、ようやくngx_mrubyのv2をリリースしました。基本的にv1と互換性がありますので、今後はv2を開発していくことになります。 github.com ngx_mruby v2の目玉機能としては、Rubyスクリプトからノンブロッキングのsleepとhttp[s]クライアントを使えるようになったことです。実装的には、nginxのsub requestという機能をうまく使って、ノンブロッキングのhttp[s]クライアントを汎用的なsub_requestメソッドとして実現しています。 では、本エントリではそのノンブロッキングhttpクライアントがどの程度高速処理可能になったかを実験してみましょう。また最後には、RubyKaigi2018の感想も述べます。 実験 proxyサーバのblockingとnon-blocki

今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ

という話を新卒エンジニア研修座学の最終回で発表しました。 昨日ちょうど、ペパボ研究所の2017年の実績をまとめており、まだまだ国際化は足りていないものの、だいぶ論文を書いたりしているなぁと改めて思いました。 rand.pepabo.com 実績はサマリーは以下の通りになります。博士学位論文を書きながらも、所長を含めて研究員4名でできたばかりの研究所で、雑誌や書籍やエンジニアの技術カンファレンスもこなしながらよくここまで書けたなと振り返って思います。 博士学位論文 1本 ジャーナル論文集招待論文 1本 ジャーナル論文 1本（予定） 査読付き論文 1本 査読なしの研究報告 6本 口頭発表 20本（後2本追加予定） 学会誌・商業誌解説等 4本 助成金・研究費等 2本 論文を読んだり書いたりするペパボ研究所において、大企業が持つ研究所とは違い、なぜWebサービスに関わる企業がなぜ研究所を持ち、論文

エンジニアリングや研究開発について思うことをこれまで色々とツイートしたりしてきたが、それを改めて短編エッセイ集のようにまとめて整理し、自分の行動原理や思考を言語化して振り返っていた。以下目次。 基礎を学び古典を知る サーベイと評価の重要性 論文という学習と貢献を両立する手法 企業でのスペシャリストに求められるさらなるスキル 技術への深入りの効能 インフラエンジニアのキャリア再び 技術という真にフェアな領域 エンジニアへの動機付けと教育 知識をコードで表現する専門職としてのエンジニア 技術に対する思考 技術力の醸成による先行報酬 エンジニアのアウトプットと個人の実績 アカデミアか企業か家族か 楽しいことと貢献とその評価を重ねる 技術と自由 技術が目的 基礎を学び古典を知る 技術力を高めたい、成長したいという前提において、基礎を学ばずに発想で勝負などと、勉強もせずに過去の天才達とに渡り合うほど

7年前の僕はひとたび外に出ると何者でもないエンジニアでした。会社で周りよりも仕事を覚えてこなすのが少しだけ早い、会社の独自仕様に詳しい、それぐらいだったように思います。 ある日、自分が本屋に行ってふと一冊の技術雑誌を開いた時に、そこに書かれている技術はほとんどわからず、自分の得意分野の技術でさえ、社内でやっていることは当たり前のこととして書かれていた上で、さらにそれを高度に一般化し解決する技術が解説されていました。それを見た時に、自分の技術が単に社内独自の業務を経験的に知っているだけであったことになんとなく気付かされました。 ただ、この雑誌に書いている人は本当にプロフェッショナルな専門家なのだろうとしばらくは思っていたのですが、後に執筆陣も自分と同様に会社で働いているエンジニアであり、何も状況は変わらないことに気づき、その人達の経験に基づく一般化された知識とその応用力、それを可能とする視座

Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ

hb.matsumoto-r.jp 以下のエントリは一部誤認が含まれていたので、上記エントリにその旨をまとめましたので御覧ください。 とある事情でミドルウェア上から高速にリモートホストのポートのListenチェックをしたくなりました。ローカルホストのポートであれば、/procやnetlinkなどを使って素早くチェックする方法がありますが、今回は対象がリモートホストなのでソケットでなんとかする必要があります。 そこで、誰もがまず思いつくのは、connect()システムコールによってリモートホストのポートに接続しにいって、connectできればOK、できなければNGと判定する方法があり得るでしょう。（高負荷時に接続できないパターンはListenしていないと判定してよい） そこで一旦、最低限socket()システムコールとconnect()システムコールで接続する時のパケットをtcpdumpで眺

この記事は、Pepabo Managers Advent Calendar 2016の3日目の記事です。2日目は、弊社チーフエンジニアhsbtさんの「マネージャが仕事の仕組みを作る」でした。 僕自身は、エンジニア専門職の主席研究員兼シニア・プリンシパルエンジニアではありますが、特にペパボ福岡のエンジニア組織を現場でまとめる人間として、エンジニア組織を成長させる中で個々のエンジニアの成長をサポートしているという意味では、マネージメントに関する活動も兼ねております。 しばしば、インターネットサービスの高度化と複雑化の速度が早過ぎるため、グランドデザインができない、人が多過ぎても成立しない、少な過ぎても難しい、とういうような類のサービスを作り上げないといけない状況があります。その際に、厳密過ぎない役割を持たせ、それぞれが横断的にそれぞれのスタイルで、まるで、攻殻機動隊の世界におけるスタンドプレー

Pmilterというサーバソフトウェアを作りました。 github.com PmilterはProgrammable Mail Filterの略で、SMTPサーバ（送信や受信）とmilterプロトコルで通信し、SMTPサーバの送受信の振る舞いをRubyでコントロールできるサーバソフトウェアです。 これまでにも、milter managerやRubyのgemを使ってmilterサーバを作るといった素晴らしいソフトウェアがありました。ですが、今回僕がフルスクラッチで作りたかった理由としては、 とにかくインストールや設定がシンプルで運用しやすいサーバソフトウェアにしたい ミドルウェアとして振る舞いを設定する感覚でRubyで制御する事に専念したい 依存ライブラリを減らしワンバイナリでサーバに配置できるようにしたい 設定変更に再起動することなくRubyを変更するだけで振る舞いを変えられるようにしたい

この話については、僕が専門としているWebサービス関連の業界におけるお話だと思って下さい。ただ個人的には、もう少し広範囲でも適用できる話なのではないかなとも思っています。 ということで、早速アウトプットすることのメリットから簡単に今の現状をまとめて今後エンジニアはどういう心構えで取り組んでいけば良いか、その中で、社外発表することのメリット、その社外発表の頻度を高める事の副次的効果についてまとめていきます。 アウトプットすることのメリット アウトプットする事やOSS化する事のメリットは、自分も含めて最近随分と語られるようになってきております。ここではそれについてあまり詳細に語る事は省略して、メリットを箇条書きでまとめると、 自分の技術が整理され、振り返りも容易になる フィードバックが得られる 自分の技術とその他社外のエンジニアと技術を足しあわせての技術検討（開発）が可能になる 自社だけでなく

福岡の博多で開催されたHacker Tackleという技術イベントで、「HTTP/1.xとHTTP/2が混在する時代のウェブサイト設計とmruby in HTTP serverの可能性」というタイトルでお話をしてきました。 hackertackle.github.io HTTP/2に関しては既に素晴らしい発表が幾つかされており、特に今年のYAPC::Asia 2015で id:kazuhooku さんと id:Jxck さんが発表されたHTTP/2の内容は素晴らしいです。今回の僕の発表で同じような所を喋ってもどうしても二番煎じになってしまうため、よりサーバ実装についてや実際に使う時にHTTP/2のどういう特徴がチューニングに関わってくるかという話を、mruby組込みをまじえてお話しました。特に、サーバプッシュや優先度制御、それを制御するための方法について言及しています。また、現在公開できる

コードレビューにおいて、レビューする側の人間がレビューされる側の人間に対してどう接していくかという議論はいくつもされてきています。 特にコードレビューにおける怒りや強い指摘という話題に関しては、以下の記事に丁寧に言及されており、概ねこの内容に僕も賛成です。 クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々 コードレビューという状況においてこういった「する側」「される側」の立場があるため、怒りや強い指摘において一定の説得力を持たす事ができると思うのですが、一方で、これがもし、コードレビューの状況からよりプライベートな人間関係においても波及していくと、それは問題だと言えるでしょう。 スタンフォード監獄実験という非常に興味深い、というか非常に恐ろしい実験があるのですが、その中で以下のような実験結果が得られています。 スタンフォード監獄実験 - W