読者です 読者をやめる 読者になる 読者になる

YAPC::Asia 2015で技術ブログを書くことについて発表しました

YAPC::Asia Tokyo 2015の前夜祭で上記のタイトルで発表しました。 今回が最後のYAPCということで、どのようなテーマで応募するかについてかなり悩みました。 技術的にめぼしい内容はほとんどブログに書いてしまったので、ブログを書くことそのものについて発表してみようと思いました。 内容についても、トークの話の元となる個々の要素についてはほとんど固まっていたものの、どのように構成して取捨選択するかということに時間を使いました。

基本的に難しい話はないので、スライドには極力文字を載せずに口頭の話を聴いていただくという形をとりました。 したがって、スライドだけみても情報量がほとんどなく何の話か全然わからないので、公開はしないでおこうと思います。

トーク内容

トークの内容は前半部分と後半部分に分かれています。 前半は基本的に来ていただいた方々に楽しんでいただくように構成して、トークの主旨は後半部分に集約させています。

前半部分は自分が書いた記事がインターネットで注目されるためにどのような工夫をしていたかというものでした。 工夫といってもそんなに大したことはしていなくて、これまでブログを書いたときに、こういう記事タイトルの付け方を自分はしていましたというものです。 最初から意識していなくてあとで分析したり人に聞いた結果 タイトルというと、タイトル芸や煽りタイトルと呼ばれるようになんとなく揶揄されがちです。しかし、ブログに限らず書籍や雑誌、論文、その他のメディアにおいてもタイトルというのは非常に重要なものだとみなされているはずです。 煽ってタイトルをつけていたこともあったのですが(そんなに伸びるとは思っていなくて驚いたことがあります)煽りタイトルで注目されても、そんなに嬉しくはないなという気持ちが自分にはありました。特にあとで見なおしたときに嬉しいどころか恥ずかしくなるということもあります。 最近では、正統的に内容を表現しつつ、うまく多くの人に読んでもらうためにはどうするかという観点でタイトルをつけています。(このブログの最近の記事を読んでいただければ伝わるかと思います。)

トーク本番では前夜祭ということもあってビールが振る舞われていました。なおかつ最終時間帯ということもあり、結構酔っておられた方が多かったのでオーバーに受け取られた?かもしれません。当日発表者が妙に調子が良かったのでそのせいもあるかもしれませんが。 あまり小手先のテクニックばかりが注目されるのは本意ではないので、具体的な内容は当日トークを聴いて下さった方々の酒の肴にでもしていただければと思います。

後半部分は特にここ半年の月刊ブログ活動において、記事の裏にこめた自分なりの哲学みたいなものを語りました。 サマセット・モームの「どんな髭剃りにも哲学はある」という言葉がありますが、気軽に書ける特性をもつブログにも込められる哲学はあると思っています。 哲学というにはちょっと大げさですが、トーク内容を構成する過程で、僕の場合は6つほどの哲学のようなものを記事に込めているかなということがわかってきました。

知識と感動

「お前が伝えたいのは知識なのか感動なのか?感動がなければどうして知識を伝えられようか」というような言葉を海原雄山という昔の偉い人が言っていました(細部を忘れてしまって多分正確な引用ではないと思います...)。 この言葉は、本当に人に何かを伝えたいときは知識だけでは人には伝わらないから感動を伝えよという意味だと解釈しています。 さすがに今回のコンテキストでは大げさですが、この言葉は自分の心のなかに沈み込んでいるもののうちの1つです。 技術ブログの話に置き換えると、単なる情報だけじゃなくて、どうしてその技術に興味があるのか、どうしてその記事を書こうと思ったのかなどのその人なりの考え方や意見が現れる文章が

ウェブに関する技術情報というのは毎日山のように発信されています。 その中で、単なるツールの使い方のように役に立つけどだれでも書けてしまうものや、バージョンがあがったりすると古くなってときには有害となるようなものもあります。 自分ももちろんそのような内容を書くこともあります。 とにかく発信することが大事だと言われてきましたし、今でもそう思います。 一方で、その人なりの考え方や思想のようなものはもっと息が長いと考えています。 知識は古くなっても、読んだときにこの人おもしろいなとかこのブログおもしろいなと思った気持ちはずっと続くと思います。

ブログ=自己表現の場

人間は褒められた方向にのびると思っています。 もちろん良い面も多いですが、悪い面もあると思うときがたまにあります。 Dockerみたいな新しいツールは若者でも先輩と同等かそれ以上に詳しくなれることがあります。 それがうれしくて新しいツールの使い方をひたすら調べて書きまくるというようなこともあるでしょう。 自分も新しいツールが好きでいろいろ調べてたりしていました。 ただあるとき、新しいツールに詳しいだけの人でいいのかという疑問がではじめました。 アルゴリズムとか計算機そのものの仕組みなど、情報科学の基本的な知識がおろそかになってるんじゃないかといった不安がありました。 今も当然あります。

そんなときに自分の自己表現の場だと思って自分のブログを見返してみて、自分の本来の興味が反映されているかとかを考えてみました。 反映されていなかったらアウトプットの方向性を考えてみてもいいかもしれません。 キャリアとかを見直すきっかけになると思います。

僕の場合、DockerとかGoとか流行っているものに結構飛びついていたんですが、本当はもうちょっとOSとかシステムのアーキテクチャとか、硬派な内容に興味があったはずだと思い直しました。 昔書いた新しいツールの記事は今すでにバージョンが新しくなっていて、あの記事はもう古すぎて意味ないなと感じることもあります。 一方で、OSとかアーキテクチャの話は数年後、がんばれば10年後にも読める内容になるのではないかと思います。 話題に限らず自己表現の場だと思って記事書くと、人間は数年でかわったりしたりないと思うので、勝手に息が長くなるような気がしています。

寝かせる

硬派な内容を書きたいと思っても、硬派な内容というのは得てして難しいのでググって調べたことをそのまま書くだけになりがちでした。 ただ、この技術よくみかけるんだけど、前からよくわからなくてたまに調べてはまだわからん、みたいなことを繰り返して徐々に理解してきてるみたいな内容があるということに気づきました。 自分にとっては、Webサーバアーキテクチャとかコネクションプールがまさにそれでした。 最初にこれらを調べたのが数年前で、その間本を読んだり実際に本番システムの運用経験を積んで学んで寝かせていたことになります。

寝かせることで内容の深みが違ってくると思っています。 例えば、仕事ではPerlとScalaの両方を運用しているので、特定の言語に偏らない話になったとか、もともとつながりのなかった話同士が実は関連していることがわかったりするということがあります。 コネクションプールの文脈で接続コストのTCPだと3-way スライディングウィンドウで輻輳制御のために徐々にウィンドウサイズあげていくみたいな挙動になるから データベースの話にからめて、ネットワークの話をしているみたいな感じですね。

アウトプットベースで考える

ブログを普段から書いていると普段の仕事や趣味をアウトプットベースで考えるようになりました。

突然ですけど、CentOS 5は2017年にサポート切れるという問題がありますよね。 当然、DebianやCentOS 6/7に置き換えていく作業が必要です。 一見めんどくさくてやりたくない最悪の仕事にみえますが、それまで応急処置でメンテナンスしてきたシステムを大幅に刷新できるチャンスだと思いました。 ただし、泥臭いものを単に泥臭く解決すると体面を気にしてアウトプットしづらいため、スマートに解決する方法はないかと考えるようになります。 アウトプットベースで考えることにより、どうすれば技術的におもしろいかを考えて、モチベーションにつなげたりしています。

さらに、なるべく多くの人にみてもらうということを考えるということは、いろんな人に自分のもってる技術をみせられるかということを考えることなので、自分の強みとは何なのかということを客観的に考える機会だと思います。

神は細部に宿る

読みやすさを追求するために、文章自体を書くときに結構細かいことを意識しています。 意識しているのは以下のような内容です。

  • 段落のトピックセンテンスを意識する。その段落で述べることの概略を述べた一文を含める
  • 文をなるべく短くする。とはいえやり過ぎは返って流れにそって読みにくくなるため、きれいに読み下せるなら多少長くなってもよい
  • 箇条書きに頼らない。箇条書きは文と文とつなぐことに向いていないため、あくまで強調したいものを列挙するだけにとどめる
  • 「〜を行う」は冗長な表現なので使わない。大抵は「〜する」でシュッと言い切れる
  • 文の格を揃える。主語と述語が対応しているかを常に意識する
  • 不自然な体言止めを控える。小説やエッセイのようなものには向いているかもしれない
  • 適度にひらがなを混ぜる。漢字ばかりだと日本人には読みにくい。文の密度のバランスをとる
  • 同じ言い回しの連続を避ける。例えば、「〜だと思う」が連続しないようにする
  • 事実と意見を区別する。意見を述べた文の末尾は「〜だと考える。」「〜だと思う。」でくくる
  • 「〜だと考えられる」という表現を避ける。「考えられる」は考えている主体は自分なのに受け身になっていて、考えている主体を曖昧にしている

曖昧な部分やわかりにくかったりぼかしたり部分は突っ込まれることもあるので、細部までこだわって丁寧に書こうとしています。 エンジニアは基本的にそんなに怖い人はいないと思っているので、丁寧に書けば伝わると思います。 もちろん、自分のブログでこれを全てできているわけではなくてブーメランではあるんですが、なるべく意識しようとしています。

文章の書き方については、「理科系の作文技術」をいつも参考にしています。

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

時間をかける

多分数年前の自分がこの文章をみたらブログを書くためだけにこんなのやってるかと考えるでしょう。 もちろんすばやく深い内容を書ける人もいると思いますが、自分のような凡人は記事の品質をあげたかったら時間をかけるしかないと思っています。 1時間で書いた内容はたとえ注目を集めたとしてもやはり1時間の内容でしかありません。 気軽に文章を投稿できるのがブログの良いところです。しかし、ブログに時間をかけてはいけないとは誰も言っていません。 コード書いたり、本を書いたり、論文書いたりするときはやはりそれなりの時間をかけていると思います。 僕の場合は、最近だと調査とか仕込みの部分を除いて1記事書くのに3日から2週間程度かけています。

ただし、2週間もかけて記事を書いて相応のフィードバックをもらえなかったら、自分の場合はモチベーションを維持して書き続けることは難しいと思います。 ちょっとした工夫でモチベーションを持続できるのであれば、それを逃すのはもったいないですよね。 そこで最初の話に戻り、うまく多くの人に読まれる工夫をやってみてもいいんじゃないかなと思います。

もちろんフィードバックとしてインターネットで注目を集めることに興味がなければ別の何かを見つける必要があります。自分の場合も複数のモチベーションをもってブログを書いています。 数値的な指標ももちろんよいのですが、いつも書いた記事を話題にして意見してもらえる身近な人は大事なモチベーションだと最近思っています。

いただいた感想のうちうれしかったもの

yusukebeさんには発表前にも挨拶していただきましたし、はてなブログにも移行していただけて最高という気持ちです。

moznionからもユニークな感想を口頭でいただきました。

あとがき

思い切り自分の内面が全面にだした部分もあるので、人によっては全く考え方が違うということもあると思います。 これは当然のことです。 それでも、「心に響いた」という今までえられなかった感想を何人かの方にいただけました。 技術カンファレンスでこのような話をするのもどうかと多少心配していましたが、発表してよかったと思えました。 ファンだとおっしゃられる方も来ていただいて、数年前書いた記事にも目を通していただいていると聞いて、感激というかそんなこともあるのかという気持ちでした。

本題と直接関係ないですが、ちょうど昨日の夜に@matsumotoryさんが「技術者が研究者のように論文を書くメリットはあるか」というエントリを書かれていました。 実際に論文を書くまでのハードルは高いですが、自分だったらどんな論文をかけるかという観点で自分が持っている技術を見なおしてみるとおもしろいのではないかと思いました。 技術ブログとはまた異なった考え方が見えてきそうな気がします。

運営スタッフの皆様、すばらしいイベントを開催していただき本当にありがとうございました。

はてなで大規模サービスのインフラを学んだ

中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。

続きを読む

Webシステムにおけるデータベース接続アーキテクチャ概論

先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。

今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。

続きを読む

2015年Webサーバアーキテクチャ序論

主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。

この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。

また、HTTP/2がいよいよRFC化し、既にh2otrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。

ところが、Webサーバアーキテクチャを学ぼうとすると、情報は古いものから新しいものまで山のようにあり、まさに海のものとも山のものともつかない、ググる度に翻弄されているという若者には厳しい状況があり、一旦自分の中でまとめてみようと思いました。

序論ということで、Webサーバアーキテクチャの基本を俯瞰できるということと、より発展的な話題へ進んでいくためのルーターのような役割を目指しています。

続きを読む

Mackerelを支える時系列データベース技術

サーバモニタリングサービス Mackerel で採用している時系列データベース Graphite を用いたシステムの構築と運用事情を紹介します。Graphiteについては、プロビジョニングやアプリケーションからの使い方、Graphite自体のモニタリングなど様々なトピックがありますが、特に大規模ならではのトピックとして、Graphiteの内部アーキテクチャ、パフォーマンスチューニングおよびクラスタ構成についての知見を書こうと思います。

背景

Munin、Zabbix、Growthforecastなどに代表されるサーバモニタリングツール、特にグラフによるメトリック可視化機能をもつようなツールを運用する場合、時系列データの扱いが重要になってきます。サーバのメトリックはCPU利用率やメモリ使用量などのOSのメトリックに加えて、JVMやMySQLなどのミドルウェアのメトリックを加えると、 1ホストあたりのメトリック数は100を軽く超えます。仮想化したものも含めてネットワークカードやブロックデバイスが複数ある場合は、デバイスごとにメトリックを収集するので、さらに多くのメトリックを収集することになります。

続きを読む

Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング

HAProxy や Nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を紹介します。

Redis や Nodejs のような1プロセス1スレッドで動作するアプリケーションをマルチコアスケールさせるような話ではありませんのでご注意ください。

続きを読む

Ansible + Mackerel APIによる1000台規模のサーバオペレーション

Ansible と Mackerel API を組み合わせて、1000台規模のサーバ群に対して同時にパッケージの更新やその他のサーバオペレーションのための方法を紹介します。 タイトルに Mackerel とありますが、それほど Mackerel に依存しない話です。

背景

社内では、サーバ構成管理ツールとして Chef を使用しています。 Chef Server は運用が大変なので使用しておらず、knife-solo と Mackerel APIを組み合わせてホストと Chef role とのマッピングに Mackerel のロール情報を用いています。 また、Mackerel の Ruby クライアントを利用して recipe 内で API を叩いて、Mackerel から動的にホスト情報を参照するといったこともやっています。

続きを読む