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

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

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

RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン（コンテナ環境構築の基盤ツール）があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。 haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、 haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける ということができるからです。その特性から、CentOS6のよ

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

インターネットを作り上げることができる、そんなコミュニティを作りたいとずっと思っている。 インターネットの創成期において、産学両方向の技術と知見を同時に兼ね備え、両方向からのアプローチができるとにかくすごい人達によってインターネットは作り上げられ整備されてきた。それらを新しい世代で引き継ぎ、あの時のように、インターネットの未来に必要な価値を圧倒的速度で作り上げていく若い世代に僕はなりたいと思っているし、そういうコミュニティを作りたいと思っている。 社会活動的観点では、僕が企業だけでなくアカデミアにおいても活動を行い、産学両方向から得られる知識や考え方を学んでいるのはそのためであるし、新規性が重要視される世界での研究開発のアプローチ、実効性が重要視され自らが提供する価値を最大化するためのアプローチ、などなど、各領域における考え方や取り組み方はとても勉強になる。また、昨今では、企業はアカデミア

僕が博士課程で研究していた「Webサーバの高集積マルチテナントアーキテクチャに関する研究」という内容で、僕が通っている京都大学大学院情報学研究科博士課程の予備審査にいってきました。研究室は岡部研究室になります。 予備審査は、僕が所属する大学院の場合、基本的には博士課程の研究で3本以上ジャーナルを通す事を条件に、内容的にも指導教員の許可が受けられれば予備審査へと進むことができます。 博士課程においては、博士課程の入学資格審査の面接で情報学研究科のほぼ教員全員（数十人）の前でプレゼンし、博士課程が半分経過した際に受ける中間審査のプレゼン（これまた同様に教員数十人）に続く、大変厳しい審査のうちの一つです。プレゼン時間は1時間、質疑応答は30分です。また、そこに参加される先生方は、各専門分野でも世界トップクラスの研究者であるため、そのような方々の前で学術研究の発表をするのは、とにかくプレッシャーと

とあるサーバで妙にシステムCPUの使用率が高い現象が置きておりました。 そこで、まずはざっくりとperf topでプロファイルをとってみると、以下のようになっていました。 22.38% [kernel] [k] copy_pte_range 18.44% [kernel] [k] zap_pte_range 11.13% [kernel] [k] change_pte_range 3.58% [kernel] [k] page_fault 3.32% [kernel] [k] page_remove_rmap また、各プロセスのstraceを眺めていると、cloneで0.05秒とかなり時間がかかっているようです。これだと単純計算で1コアで秒間20回のcloneでコア100%占有してしまう程度の非常に低速な処理しかできないことになります。 sudo strace -T -o/dev/stdo

この記事はmruby adevent calendar 24日目の記事です。 mrubyでRedisを操作するmruby-redisは以前から開発していたのですが、最近Pipelining対応のPRを頂きPipelining対応したのでそれの性能を確認してみました。また、その結果簡単に作れるようになった分散型インメモリジョブキューであるDisqueのmrubyクライアントであるmruby-disqueの紹介をします。 github.com github.com RedisとhiredisのPipelining mruby-redisはhiredisというCライブラリを利用しており、hiredisでは効率的にRedisとIOできるようにPipelining機能をサポートしています。RedisとhiredisにおけるPipeliningを簡単に説明すると、 通常のRedisアクセスはクライアン

といっても、既存のmruby-mrbgem-templateをもう少し使いやすくしただけですが。 以下の記事を受けて、もう少し簡単にしたいなぁと。 inokara.hateblo.jp ksss9.hatenablog.com 使い方 まずはいつもどおりmgemをcloneして、 git clone https://github.com/matsumoto-r/mruby-mrbgem-template.git && cd mruby-mrbgem-template/ その中にある template_config.rb を自分の作りたいmgemの設定にします。この場合、作りたいmgemはmruby-exampleで、カレントディレクトリ（mrbgem_prefix）にディレクトリを掘りたいとします。 params = { :mrbgem_name => 'mruby-example', :

一度大学・大学院を修了した後に、研究職以外に就職した技術者は論文を書かなくなる事がほとんどだと思います。 僕は、一度インターネットのウェブサービスに関する企業で技術者をした後に、大学院に入りなおして同様の分野で論文を書き、現在再度技術者をやっているわけですが、技術者でも論文を書くメリットが ある と思っています。 以降でメリットについて述べますが、これらのメリットをまとめて手軽に享受できるツールって他にあんまりないんじゃないか（僕が思いつかないだけかも）と思ったので、この記事を書くに至りました。 というわけで、それを簡単にまとめます。 技術者が論文を書くメリット まずはざっと箇条書きします。 自分の考えた技術や既存の技術の調査、比較の試行錯誤を丁度良い分量でまとめられる 良い文章構成になるような書き方の知見が溜まってるので書きやすい 書き方の知見にのっとって文章にまとめることで、頭の中や提

社内での新卒研修を中心になってやってくれている okkunの提案で、キャリア・キーノートという取り組みを行っており、その中でWebオペレーション研修の記念講演ということで、恐縮にも自身のキャリアキーノートについて発表する機会を頂けたのでお話してきました。 研究の内容については、 okkun の以下の記事が参考になるかと思います。 blog.hifumi.info 技術者・研究者という立場から自分の人生を振り返ったような内容になり、これまでの自身の苦悩や絶望、そこからのブレイクスルーなどを振り返り話す事ができる良い機会となりました。 僕が技術者・研究者としてこれまでやってきて得た教訓を、教訓が得られたエピソードと共にまとめました。 話している中で色々な事を思い出し、あの時の葛藤や苦悩、さらには絶望した時の感情が沢山沸き上がってきましたが、それでも今自分はこうやって楽しく技術を学べている事に本

ブログ書くまでがペパボテックカンファレンス！ということで、昨日無事福岡支社で第二回ペパボテックカンファレンスが開催されました。参加して下さった皆さん、弊社までお越し頂きありがとうございました。 pepabo.connpass.com 「何か発表しません？」とあんちぽさんから言われた時に、各技術についての話については皆さんほんとうに高いレベルでお見せできるエンジニアばかりなので、僕はそれらをもう少し俯瞰して、 なぜペパボのようなWebサービス会社で研究・開発が必要になってきているのか 自分たちにメリットがあるような研究・開発の取り組み方についてどう考えているか 企業としてOSSで公開したりアウトプットする意義とその効果について 特に最近研究・開発として注力している部分はどこか 等についてお話しました。 所謂大企業の研究所以外の規模のWebサービス会社にとって、なかなか研究・開発というのはメリ

ど忘れしていたのでメモです。 LinuxでApacheのログローテート時に、プロセスをgracefulしたつもりが何らかの原因によりできていなくて、その後古いログファイルを圧縮して、いらなくなったその生ログファイルをrmしたつもりが、プロセスはそのログファイルのinodeを掴みっぱなしになっていて、古いログファイルにログを吐き続けていて困ったみたいな事があると思います。 その場合に、そのまま古いログファイルに吐き出さされているログをもう一度参照したいこともあります。差分がでてしまいますからね。 これinodeは掴みっぱなしだし、ディレクトリエントリからファイル名は消えているけど、fdもわかるから簡単にファイル内容取得できるはずだけどどうやるんだったかなーと思って試していたら、非常に簡単に取得できましたというメモです。 対象のプロセスからPIDを取得して、 ls -l /proc/PID/f

4月からペパボで働いているわけですが、前々から噂できいていたメモリリークの問題について、ペパボではわりと大規模かつ高負荷な環境でngx_mrubyを使ってくれているのでその環境を見ながらメモリリークを改善してみました。 状況的には、16時間動かしていると導入している環境のngx_mrubyを組み込んだnginxが1GBぐらいメタボっていました。 実装や幾つかの調査情報をみつつ、以下の2点においてメモリリークが発生していました。 mrubyが例外をあげて5xx系のエラーコードを返す時 mruby_set系のディレクティブを使っている時 上記のそれぞれにおいて、C側で生成したオブジェクトをarenaに登録したまま、不要になったにも関わらずarenaからオブジェクトを除外してGCさせるように処理できていなかった事が問題でした。 これらを、ほぼ同等の改修によってmrb_gc_arena_save(

3月26日で子供が生まれてちょうど1年になるわけですが、この1年間学生とフリーランスエンジニアをやりながら子育てをしてきました。保育園に預ける事はせず、本当に朝から晩までつきっきりの生活です。超寝不足でした。 で、4月からは福岡にあるGMOペパボという会社で働く事になっています。もう明後日ですね。もちろんそれで子育てが終わりというわけではなく、これからもずっと続いていきますが、生活が大きく変わる事は間違いありません。 そこでこの1年、世界中の誰よりも我が息子といる時間が長かったと自負しているわけですが、その中で思った事、そして4月から働くにしても家庭内で積極的に手伝った方が良いと思う事を書こうかと思います。 とはいえ、まだ1歳になった子供についてしか書く事はできないので、これから子供が生まれて最初の1年を過ごす人に参考になればと思います。また、子供にもよって全然違ってくると思います。哺乳瓶

というタイトルでWEB+DB PRESS Vol.85に寄稿しました。発売日は2月24日です。Amazonでは予約もできます。 タイトル的には非常に恐縮で、僕がこんな記事を書いてしまって良いのか不安でしたが、編集者と査読者の方々の支えもあって無事書きあげる事ができました。 WEB+DB PRESS Vol.85｜技術評論社 僕はOSS開発といっても、ほんの数年前の2012年頃までは全くといっていいほどオープンにOSS開発をしていませんでした。そういう意味では、このタイトルからすると非常に遠い存在であったように思います。 ですが、2012年の4月から会社を辞めて大学院の博士課程に入学し、そこからOSS開発を始めました。そう考えても、OSS開発のキャリア的にも約3年になるぐらいでやっぱり非常に短いです。その辺りの背景に関して、寄稿した記事を読むにあたり自分が何故会社をやめ博士課程に入ったのかに