YAPC::Europe 2014 と YAPC::Asia 2014 に行ってきました
YAPC::Asia 2014が開催されました & 参加してきました。
昨年のベストトーク副賞でJPAさまから渡航滞在費用を提供いただけたので、今年はAsiaだけでなくYAPC::Europe 2014にも参加してきました。
所感
今回、YAPC::EuropeとYAPC::Asia両方に参加して、もっとAsiaでも盛り上がったほうがいいと思う点が幾つかありました。
特にトーク中でも質問が入ったり、トーク後にもスピーカーを捕まえて話したりする点などはAsiaでも積極的にやって良いのではと思います。
また、周りの人が積極的に話しかけてくれた点もすごく良かったなと。
なのでYAPC::Asiaでも参加者、スピーカーにとどまらず海外から来るゲストにはもっと積極的に話に行くことをお勧めしたいです。
一対一なら多少ブロークンな英語でも聞こうとしてくれるし、なかなか表現がわからない時でも皆もってるスマホのGoogle翻訳アプリを使うと相手も合わせてくれたりします。
「せっかく来たけど話しかけても逃げられちゃうし全然交流できなかった」と思われるより「いやー日本人の英語全然わかんねぇけど活発に交流できたわ〜また来たいわ〜」って思ってもらったほうがポジティブでしょうし、自分自身もより多くのことをYAPC::Asiaで得られるようになるのではないでしょうか。
YAPC::Asia 2014 で YAPC::Europe 2014 についてトークします
トークが無事採択されましたので、改めてご報告致します。
YAPC::Asia 2014 2日目 2014/8/30 15:40 - 多目的教室3 にて YAPC::Europe 2014 に行ってきました というトークをします。
脂質さん の Perl入学式 in YAPC::Asia Tokyo 2014 の直後なので、特にこれからPerl始めよう/知りたいという方にも親しめるような内容にしていこうと思います。
それでは皆様YAPC::Asia 2014でお会いしましょう。
YAPC::Asia 2014 で YAPC::Europe 2014 についてトークしたい
YAPC::Asia 2013 の Best Talk Awards 副賞でYAPC::Europe 2014に参加してくる予定です。
海外のこの手のカンファレンスで、ヨーロッパ圏のものって日本人には馴染みが少ないのでいい機会だという観点で
というタイトルでトーク応募しています。
JPAの会長が
#yapcasia にトーク応募している人、もう少しがんばってソーシャルボタン押してもらわないと今年は特に倍率高くてヤバい気がしてるのは俺だけか…
— Daisuke Maki (@lestrrat) 2014, 7月 9って言ってて危機感感じたので、僕しゃべりたいのでYAPC::Europe 2014 に行ってきましたのページの中にあるソーシャルボタンでガンガン拡散してもらえると嬉しいです！
よろしくおねがいします！！！
そろそろ自作サーバ同窓会についてひとこと言っておくか
だいじなこと
同窓会にはそんな人は居なかったのですが "自作サーバ" という手段を目的化してしまうのはNGですね。
兵站の件
自作サーバの是非を話すときには、そのサービスを成立させる価値の流れにマッチしておりサービスにどういうアドバンテージをもたらすのかという点をズラしてしまうと趣味トークにしかならないのでもったいないなと。
また、トークの中でも言いましたが、単にサーバを組み立てるだけの話ではなく、それらを計画して実行して運用して廃棄してまた新しいのに入れ替えて、という一連のシステムライフサイクルを回せるようにすることのほうが重要で、そこまでやりきることを要求されることは忘れないでいたいものですね。
最近はクラウドサービスの隆盛がめざましく、x86サーバも年々出荷台数が減りIBMがレノボへ事業売却というような件に象徴されるように、既に価値創造における直接的な差別化要因ではなくなりつつあるわけです。
というわけで本来の意味での "Logistics" を下敷きにしないで "自作サーバは楽しいです勉強になりますやったほうがいいです" という話をしてもサービスになんの付加価値ももたらさないわけで、そういうのはぜひ自身のおうちで、おこづかいの範囲でやってください。
え？ぼく個人的にどうかって？自作インフラたのしいです(^p^)
おわりに
id:stanaka さんならびに登壇者の皆様ありがとうございました。
各社各様で、様々な思いを聞くことができた良い機会であったと思います。
ただ、各社各様といいつつ "某100Sなんとか" で卒業するケースが多かったのは興味深い話でございました。
私からは以上です。
フリークアウトに転職して丸2年が経った
前職は3年弱で辞めたので、前職生活の2/3以上をすでにフリークアウトで過ごしたことになる。
最初から何でもやるつもりでjoinして、まずは下回りからサーバサイドのことをやってたんだけど、その時はサービスに対する危機意識が低かったと思う。大きいサービスを運用するのはやってきていたけどネット広告は初のことで、いざ入ってみるとソーシャルメディアとは全然違う。単にシステム規模ではなく、運用のシビアさとか、直接的に金銭に関わってくる度合いとか、そういうビジネス的な要求が高い。サービスとして緊張感をより高く持つ必要があると思った。
サービスの成長を支えてリードすべくガンガンインフラ業務を進めていくといろんな問題が起こることに気づいた。
例えば調達戦略。何を、どこから、いくらで、いつまでに調達して使えるようにするか。自前で基盤を作っていると、既に基盤部門のあった会社では見えていなかった問題がたくさん見えてくる。
サービス基盤は空気みたいなもので、問題がないときは意識されないけどひとたび問題が起こると、サービスの将来に深刻な問題を残す可能性も多分にある。
この辺りの基盤づくりについて誤ると中長期的にみればサービスの成長可能性を大きく下げてしまう。
自分はサービスの成長をサービス基盤要因で止めることがないように努めた。サービス基盤を成長にあわせて問題なく構築運用できるプロとして仕事をすることだ。
取り組んだ大きなトピックはふたつで、ひとつはサービス基盤の再構築、もうひとつはエンジニアが増えてもリリース速度と品質を落とさないための施策だ。
サービス基盤の再構築は2つのフェーズに別れる。まず最初は既存の自作サーバを中心としたサービス基盤の改善だ。
いちからインターネット回線を引いて、ケーブルの一本からすべてを調達してシステムを構築する経験は乏しかったが、過去に経験した中古PCを数十台使ったインフラでの知見を活かしてネットワークを構築することができた。
以前はカスケードしまくりで拡張が難しかったネットワークを改善して3倍くらいの規模にはできるようにした。この再構築の時に得た知見は良いことも悪いこともたくさんあるが今も業務に活きている。
しかしながらこの対応も長くはもたず、様々な要因があって次の大きな改善をすることになった。新たな基盤構築である。
サービスのパフォーマンスを損ね、拡張性に乏しいサービス基盤は事業の成長に著しくブレーキをかけることになる、しかしサービス開発エンジニアは全員が必ずしも基盤技術に長けているとは限らないし、そういった作業に当てる時間を作るとサービス開発の速度が落ちてしまう。そこでもう一段階上のサービス基盤構築を模索し始めた。
幸いにも多くの外部事業者の方とお話をさせていただくことができ、多くのインプットを得ることができた。
システムの移行も大きな問題はなく実施できた、クラウド全盛の時代にこのような仕事はそうそう発生するものではないし、そのような機会を数多く経験出来たことは得難い財産になっている。
そんなことをしているうちに、いつの間にか開発エンジニアがえらい勢いで増えた。
この時点でサービス基盤は安定して運用/拡張できるようになっていたし、インフラを担う仲間も増えたがそれを上回るペースで開発者が増えていたのだ。
当然書かれるコードの量も増えていたし、リリース頻度も多くなっていた。必然的にテストの量も内容も様々に増え、テストを通す時間も右肩上がりになる。
ある時必要があってコードに手を入れ、手元の環境でmake testをした時に30分ほどかかった時にとてもイラッとして、開発している人はこんなことをずっと我慢していたのかと思って改善に取り組むことにした。
その内容はYAPC::Asia 2013のトークに詳しいのでそちらを見ていただくとして、この取り組みによって幸いにもBest Talk Awards 2位をいただくことができた。
自分は事業に比較的早いタイミングでjoinしたことで、他ではできなかったであろう多くのことを経験することができた。
これは元から狙っていたことでもあったが、思った以上にいろいろできたので幸運でもあったと思う。
mirakuiさんのエントリにもあるが、急速に成長するサービスを運営するときには開発だけでなく基盤側にも積極性/創造性が多分に要求される。
基盤チームであってもコードを書かないということはありえないし、必要なものは積極的に書いている。
多くのことに取り組んできて実感を持っているのだけど、バックエンドだろうがUIだろうがAPIだろうが基盤だろうが、そこに境界はないと考えている。
フリークアウトでの3年目を迎えたけど、会社もサービスもこれからもっと盛り上がって行くし、やるべきこと、やりたいことがまだまだ山のようにあり、日々戦いを続けていてこれからも楽しみですね。
あとこれだけは言っておきたいんだけど、 フリークアウトはエンジニアを募集しております ！！！！！！！
MySQL::Sandboxのこと、時々でいいから思い出してあげてください #mysqlcasual
はじめに
かじゅある！
この記事はMySQL Casual Advent Calendar 2013 2日目の記事です。
カジュアル詐欺とかガチュアルとかいわれのない誹謗中傷を受けることの多いMySQL Casualですが、私はカジュアルな記事を書きます。
みんなも Casual に記事を書けばええんやでヽ(´ー｀)ノ
石狩DC記事の方もよろしくお願いします。
MySQLはもはや説明不要のRDBMSかと思いますが、"使える"ようになるためには情報収集もさることながお試し環境をカジュアルに作れるようにすることが重要です。
ということで、まだMySQL Casual Advent Calendarではネタに上がってないMySQL::Sandboxをカジュアルに紹介します。
MySQL::Sandbox はその名の通り手元にきれいかつ閉じた MySQL の検証環境を作れます。
複数台構成も簡単にできて大変便利です。
MySQL::Sandboxを動かす環境を作る
Perlが必要なので、plenvとかで環境をこさえましょう
$ plenv install 5.18.1 $ plenv global 5.18.1 $ plenv install-cpanm
MySQL::Sandboxをインストールする
cpanm時代なので簡単にインストールできます
$ plenv exec cpanm MySQL::Sandbox
Sandbox環境を作る
以降はMySQL::SandboxのSYNOPSISに詳しいわけですが、各動作環境用のMySQLのtarボールがあれば起動可能です。
下記は単独のサーバの構築です。とても簡単です。
$ mkdir $HOME/opt/mysql $ cd $HOME/opt/mysql $ wget どこかのサーバから取ってきたMySQL-VERSION.tar.gz $ make_sandbox VERSION
接続や停止は下記の通り
$ sandboxes/msb_x_x_xx/use $ sandboxes/msb_x_x_xx/stop $ sandboxes/msb_x_x_xx/start $ sandboxes/msb_x_x_xx/restart $ sandboxes/msb_x_x_xx/send_kill
とりあえずここまで試して、再度作り直したいときは
$ sandboxes/msb_x_x_xx/clear $ sbtool -o delete -source_dir $HOME/sandboxes/msb_x_x_xx
という感じでなかったことにできます。
更に進んだ使い方
make_replication_sandboxコマンドを使うと、複数サーバを立ち上げてレプリを作ってくれたりします。
クラスタを作って実験したいときには持ってこいな感じです。
さらに環境変数 MASTER_OPTIONS, SLAVE_OPTIONS に my.cnf を指定しておけばその設定で立ち上げてくれて cool ですね。
$ export MASTER_OPTIONS="--my_file=/path/to/my.cnf" $ export SLAVE_OPTIONS="--my_file=/path/to/my_other.cnf" $ make_replication_sandbox x.x.xx
このくらいできるようになると、カジュアルに新しいバージョンのMySQLが試せるし気に入らなければ虚空の彼方へ消し去ることもできるのでカジュアルでよろしいかと思います。
他にもレシピを見るといろいろとオプションがありますので、複数台構成やらを試したい方はご確認をば。
明日
MySQL Casual常連の @kamipo さんが12/3を担当します！お楽しみに！！
