namusyakaぶろぐ

やぁやぁやぁ

近況

ここ5-6年の話。 フリーランスを辞めてドワンゴに入社し、いくつかの新規事業の立ち上げに参加しながら、開発基盤グループを立ち上げてマネジメントもどきなことをしていた。

その後、DeNAに転職してモバイルゲームのサーバサイド・インフラ全般を担いながら、共通基盤のアーキテクチャ刷新をしたり、新規の基盤を立ち上げたり、面接官としての採用業務を並行してこなしていた。

その最中にGoogleからスカウトが来て、受けたら受かったので入社して今に至る。

相変わらずエンジニアをやっています。

ドワンゴエンジニアとしてAWS Summit Tokyo 2016で登壇してきた

AWS Summit Tokyo 2016のDevelopers Conferenceで、「ドワンゴがAWSを使ってメディアストレージ基盤を開発してみた」と題して講演してきた。 すでに一週間以上経過しているが、なかなかこのような機会もないので振り返ってみることとする。

登壇してみて

飲みの席で引き受けた話がまさか本当に実現するとは思わなかったが、非常に良い経験になった。

2015年にドワンゴに入社して以来、Rubyなアプリケーションを開発しつつも主務はAWSを用いたインフラエンジニアということで、各プロダクトの環境構築・整備や開発基盤体制を整えつつ、セッションの本題としても取り上げたメディアストレージ基盤を一人で設計・開発・運用するなど、概ね好き勝手にやらせてもらった上で、なんとか成果を出してこれたと考えている。

先日行われたAWS Summit Tokyo 2016では、その取り組みを踏まえて些か駆け足ではあったものの、AWSというlaaS/PaaSが持つ可能性、そしてフルマネージドなサービスを活用したサーバレスなアーキテクチャについて、実例をもとに40分弱ほど、話させていただいた。

以下に示すのは発表時に用いたスライド資料を「ニコナレ」に公開したものである。 ニコナレに公開することで、メディアストレージ基盤についての資料をメディアストレージ基盤が変換し、配信してくれていることになる。

ドッグフーディング最高。

参考資料: RubyとAWSでつくるメディアストレージ基盤

正直テンパりすぎて、何を話したかも覚えていないし、途中、「なぜ自分はここに立っているのか」と考えたことを皮切りに頭が真っ白になっておもむろに腕を組んだのも今となっては良い思い出である。 業務都合上、他のセッションや企業ブースを見て回れなかったことが唯一の心残りかもしれない。

メディアストレージ基盤について

本来の目的である「新規プロダクトの開発効率の向上」については、成功していると言えるだろう。

汎用性が高い実装になっていると思うし、セッションでは語りきれなかったがAutoScalingやそれに付随する自動デプロイ・Lambdaへのデプロイ機構・監視体制など、耐障害性・可用性・保守性についても考慮しているため、今後も使われ続けていくだろうと考えている。

個人的なところとして、AWSに触れた自分が初めてつくるプロダクトというか、習作として作ったものではあるが、AWS Summit登壇という機会に恵まれ、また実際にリリースされたプロダクトからも利用されていることもあり、非常に喜ばしく思っている。

今後、AWSが提供するサービスやリソースも柔軟に組み込みながら、さらに発展させつつ、また新たなアーキテクチャにも挑戦したいところだ。

さいごに

あまり大勢の人の前で話すのは得意ではないが、RubyKaigi・AWS Summitと機会に恵まれた一年だった。

上司にももっと外で話すべきだとご助言をいただいているので、今後も機会があればエンジニアとして、そのような取り組みもしていければと考えている。

何はともあれ、今回のこの登壇について、このような機会に恵まれたのは非常に幸運なことだった。関係者各位には改めて御礼申し上げたい。

おわり。

Rubyで正規表現エンジンを書いた

Rubyで正規表現エンジンを書いた

なぜかいたか

去年くらいに、Padrinoのルーティングエンジンを1から書き直す上で正規表現について色々と考えることになった。 その際に自分が本当に中途半端な理解のまま正規表現を使ってきたことを実感したので、理解を深めるため、というか学習のために実際に正規表現エンジンを書いてみた。

namusyaka/onibi

学習には@hirataraさんが昔連載していた正規表現エンジンを作ろうを使わせてもらった。 この連載をなぞっていくだけで正規表現エンジンができるので、そこに多少アレンジを加えて楽しむのが良いと思う。自分はそうした。 加えて自分は、参考資料として挙げられていた計算理論の基礎をたまたま持っていたので、並行して読み進めた。

元の実装と違うところ

連載に従って進めることで完成する正規表現エンジンよりも、サポートするメタ文字をいくつか増やしている。 といっても、正規表現として扱う文字列を字句解析する前に、解析可能なメタ文字を使った正規表現に変換するだけ。 例えばasdf+はasdff*と意味上は等価であり、変換することができる。 実装はonibi/ast/converter.rbの部分。 最小の実装で、サポートしていないメタ文字を表現することができるのは面白いと思った。当たり前ではあるのだけど。

感想

字句解析やオートマトンの生成、といった部分の実装については、基本的に元の連載の内容をなぞっただけ。 自分は実装時に、連載中に使用されるプログラミング言語(Python)ではなく、Rubyを使って書くだとか、実用する気はないんだからガンガンDSLにしてクールに書こう、みたいなところを意識した。 そのおかげか、部分集合構成法を用いて非決定性有限オートマトン(NFA)を決定性有限オートマトン(DFA)に変換するところなど、理解が難しかった部分を中心に頭をひねって、実際のコードに落とし込むフローを楽しめたと思う。 これに取り組む前と後では、正規表現に対する考え方がかなり変わったので、作ってみて正解だった。

おわり。

Sinatra Sapporoに参加した

まずは簡易的なレポートから。 途中で離席していたところはスライドを見つつ補完した。 実際のところ、このレポートの正確性に自信はない。

自動化のあれこれ (@sinatrasapporoさん)

Vagrant

Chef

Capistrano

  • deployの自動化。
  • Capfile
  • cap install
  • gem install capistrano-rvm etc..

rvm

  • rubyのパッケージ管理システム。
  • (rbenv, ruby-build), (chruby, ruby-install)

Bundler

  • ライブラリをバンドルする。
  • gem 'hogehoge', group: :test, group :test do ~ endによるgemのグループ化。
  • bundle install --without test
  • bundle install --deploymentはプロジェクト直下にvendor/bundleを作成して、そこにgemをインストール。 (追記: bundle install --path vendor/bundleと同義ではなく、.bundle/configにBUNDLE_FROZEN=1が追加されることで、Gemfile.lockを元にgemのインストールを行うようになる)

Docker

  • VMを管理するという概念とは異なり、コンテナを管理する。
  • 「アプリケーション + Dockerfile => myapp」
  • 一番好き。
  • Dockerを最近は使っている。
  • Dockerがどっか行った。

ゲーム vs. Sinatra (@myokoymさん)

スライドが公開されています。

自己紹介

  • 将棋が好き。(アマ三段)
  • Ruby Kaja 2013

第一部

年表

  1. 2013/11/24 - SinatraSapporo初の勉強会
  2. 2014/02/28 - 札幌市中央区Ruby会議01
  3. 2014/05/10 - SinatraSapporo二回目の勉強会、Gosuについて
  4. 2014/06/14 - OSC 2014 Hokkaido, Sinatraの帽子を使ったゲームを展示
  5. 2014/08/17 - SinatraSapporoSaturday#01, ArduinoでLEDをチカチカして納涼
  6. 2014/10/11, 2014/11/16 - SinatraSapporoSaturday#02, SinatraSapporoSunday#03 Padrinoを使い始める

Rabbit

  • Rabbit - プレゼン作成用ツール、装飾(テーマ)をRubyで記述できる。
  • RabbitのキャラクターLavieさん。持っている赤い球体はRuby。

Ruby-GNOME2

Ruby/GTK2
  • gem install gtk2
  • 開発はほぼ終了。
  • Rabbitやmikutterなどで採用、安定している。
  • 初めて使うならこちらがオススメ？
Ruby/GTK3

Gosu

SDL？

第一部のまとめ：「Sinatra最高」

第二部

テーマは「VS.」

対比させる。

ポイントは

  • 動作環境
  • 画面構成
  • 更新方法

動作環境

ネイティブアプリ vs. Webアプリという構図

ネイティブアプリ
  • 動作速度が速い
  • デバイスの機能をいかしたインターフェース(push通知 etc)
Webアプリ
  • リリース、インストールが楽
  • 他のサービスと連携しやすい。つまり使われる技術が限られる。(HTTP, JavaScript etc)

適材適所で。

画面構成

  • GUIアプリ - osと紐づいたパーツを組み合わせる
  • ゲーム系 - 一から形を決めて描画する
  • Webアプリ - ブラウザのパーツを組み合わせる。

「誰もがデザイナー」

更新方法

  • イベント駆動
  • フレームレート
  • HTTP
イベント駆動
  • 起動すると共にイベント待機。起こったイベントにしたがって処理を行う。イベントハンドラ。
  • イベントハンドラはコールバック関数。イベントが起こったときの処理を記述。クリックやアクティブ化 etc
  • イベント駆動はCPUに優しい(当社比)

フレームレート

  • 1秒間に一定回数の処理
  • 1秒間に60回の場合、60fps
  • 1フレームで状態の更新や画面への描画など。
  • 例えば1秒間に約60回呼ばれるメソッドの処理が1秒を超えたらどうなるか => かたまる。自分で計算しながらやるのが肝要？
  • ゲーム系。常にCPU使ってる感。

HTTP

  • 「何を」「どう」したいか
  • リクエスト-レスポンス型
  • 「何を」 = http://<ホスト名>/[パス]
  • 「どう」 = メソッド(GET, POST etc..)
  • Sinatraがわかりやすい。
  • いわゆるクラサバ。サーバがレスポンスを返せば一区切り。 基本的には状態を保存しない。

おわりに

  • Sinatraたのしいょ！
  • ゲームやGUIもたのしいょ
  • 組み合わせても良い。コミュニティ(Sinatra Sapporo)でチーム開発？

Padrino Frameworkのすゝめ (@namusyaka)

  • スライド資料
  • 案の定喋りすぎて最後は駆け足になった。
  • PadrinoやSinatraを知らない人でも、ということを念頭に置いていたつもりだったが、いくつかの部分で説明不十分な箇所が生じていたように思う。準備はしっかりすべきですね。

質疑応答

Q: Webアプリケーションフレームワークのパフォーマンスにおいて、ルーティング処理の占める割合が知りたい

A: Padrinoに関して言えばウェイトはそこまで大きくはない。速度にこだわっていたのはhttp_routerに負けたくなかったため。

LT

Railsでマップを使ったアプリを作ったり。

  • Railsでアプリ。
  • RoSP - railsライクなスマホアプリ開発、webの知識を利用できる。Androidでも安定して動く。

Sinatra風マイクロフレームワークで始めるPython (@kuroneko1988)

スライドが公開されています。

  • 書き方というか手段が多くはない。
  • 故にコードが汚いと叩かれる事も少ない？
  • Python楽しいよPython。

参加した感想

Ruby系の勉強会に参加するのはこれが初めてで、新鮮だった。 Sinatraを普段から使っている人はもちろんのこと、PythonistaやGUIアプリケーション、あるいはAndroidアプリをメインに開発しているが、 レスポンスのテストのために部分的にSinatraを使っている人など、Webケーの枠組みを越えて色々な話を聞けた。

懇親会, 忘年会

ジンギスカン、美味かったです。昼食も用意してもらってすみません。。 改めてありがとうございました。

小説を投稿するWebサービスを作って一年以上が経過した男

webサービス ssnote

小説を投稿するWebサービスを作って一年以上が経過した男

2013年9月12日に小説投稿サービス ssnoteをリリースしてから早いもので一年以上が経過した。 現在登録者数は4600人を越えていて、未登録ユーザーの利用も考慮すると一日約一万人ほどが利用するサービスになっている。 爆発的な右肩上がりというわけにはいかなかったが、それなりに利用されるWebサービスを作れたということで、当初の目的は達成できたといえるだろう。 この記事では、サービスリリース後から現在に至るまでにあった様々な出来事から得た知見や、運営時に気をつけていることについてまとめる。

ユーザー視点とは...

個人法人問わず、自分たちでサービスを展開している人たちならば耳にタコができるほど聞いている事だと思うし、口が酸っぱくなるほど言っていることだとも思う。 ユーザー視点でサービスを開発・運営するということは大切だ。しかし残念ながら、私にとってはこれが難しかった。 サービスを開発する上で、一番やる気が出る時というのは、技術的な問題の解決をはかるときだ。 ところが、それだけに注力していてもユーザーは満足しないし、むしろそういった課題を頑張って解決したところで多くのユーザーはきっと気づかない。それは良いことだとも思うけど。 もちろん大勢のユーザーに使われているサービスということで、どうすればユーザーはもっと満足してくれるかなどということも考えるには考えるし、別に真剣にやっていなかったわけじゃない。 が、ともすればそれは独りよがりなものになってしまいがちで、ユーザーと開発者には想像以上の隔絶があることを知った。

じゃあどうすればいいのということなんだけど、私はファンの意見に耳を傾けるようにしている。 自分自身が真の意味でユーザー視点を持つことができないのであれば、実際にユーザーの視点を持つ人に話を聞くのが手っ取り早い。 幸いにして、ssnoteには熱心な愛好家とでもいうべきユーザーがそれなりにいて、貴重なアドバイスをくれたりする。 そうした愛好家というのはアドバイスをくれるに留まらず、ユーザー間でおこったトラブルを率先して解決してくれていたりするので、非常にありがたい存在だ。 正直、運営する身としては情けないことこの上ないのだが、愛好家のおかげでssnoteの運営が成り立っているという面もある。感謝しています。

UIの改善？

ユーザー視点と被る話ではあるんだけど、いかにもイケてないUIがあったとして、それを改善すると開発者としては「やってやったぜ」っていう感じで満足感に浸ったりする。 ところがユーザーからするとそう簡単な話ではなくて、「前のが良かった！戻せ！」となったりするようだ。 どれだけイケてないUIであろうとユーザーが慣れてしまえばそれはベストなUIに変化するらしい。住めば都的な。 ユーザビリティとかに疎い自分からすると結構ありがたい現象ではあるが、いざ改善するとなったときには厄介だ。 改善はつまり、ユーザーの慣れの破棄を強要する行為だと言えるだろう。 まあ自分としてはそれは必要悪だと認識しているので、ssnoteでは大抵の場合元に戻さない。 その代わりにユーザーに対しての説明責任はあるだろうと思っていて、個別にでもできるだけ親身に対応している(つもり)。 これについては今後も迷惑をかけるかもしれない。デザインとか一ヶ月も同じものが続くと飽きちゃうんだよな。

独自の文化の形成

能力不足故かもしれないが、しばしば自分の思い通りにならないことが起こったりする。 例えばssnoteでは現在、グループコミュニティなる機能が実装されていて、ユーザーがグループを作ってコミュニケーションを楽しむ場を自由に作る事ができる。 もともとこんな機能はなかったし、作る予定もなかったんだけど、ユーザーの間でssを書くためのスレッドを使ってグループを形成する人たちが現れ始めて、運営がそれに迎合する形でリリースした。 正直最初は小説を書くためのサービスなのにな..と当初の構想から離れたものを作るハメになることに対して、少なからず不満を抱いていたりもしたわけだが、結果としてはそれが上手くハマってくれたと思う。 今はメイン機能の一つにまで成長した。ユーザーが独自に形成した文化をサポートするというのも一興。というかやってみると意外と面白かった例。

罵倒される覚悟

サービスを運営していれば色んなユーザーの反応を目にすることがあるし、直接お問い合わせから様々な意見を送ってくれたりもする。 好意的な意見が多いが、中には罵倒するようなものも意外とある。マジかって思うことも多々ある。

「こんなクソサービスさっさとやめろ」

「管理できねえならはじめから作るんじゃねえよ」

「namusyaka死ね」

数を挙げればキリはないが、実際色々言われる。 単なるユーティリティサービスでなく、SNSのような側面を持つWebサービスの開発を考えている人は、こういった降り注ぐ罵倒に耐えるための覚悟は持っておいたほうが良いのかもしれない。 よかれと思ってやっているのに人格否定とかされるのは精神的に辛かったりしそう。

収入的なこと

アクセス数でいうと月４００万PV程度だけど、収益はそんなに多くない。 登録ユーザーに対しては広告を表示していなかったり、そもそも広告をそんなに多く設置していないのが主な理由。 登録ユーザー数が一万人越えたら、有料のプランの提供を考えてみてもいいかもしれないとは思っているがまだ未定。

終里。