Developers Summit 2013に行ってきた（2日目）
2日目も参加してきたので、まとめとく。
AmazonのDevOpsを支えるAWSクラウド
Amazon.comでは11秒に1回デプロイしてて、1時間で1079回もデプロイしたことがあるらしい。 そんな回数になるとほとんどのことが自動化されてるんだろうけど、UIの崩れとかはどうやって検知してんだろか。
リソースを調達するのに待ち時間が発生するのはナンセンスだと言ってたけど、確かにそれはそうかもと思う。
Webが生み出し始めた世界
インターネットの物理モデルとかを科学技術館がどっかに作った人の話だった。 色々と宣伝してたけど、ニコニコ学会は超面白そうだなーと思った。
最後のほうの話はちょっと抽象度が高すぎて咀嚼しきれてない。 Webとかインターネットとかではなく、デバイスの話になってたような気もするし、これからは音声に回帰していくんではないかとのこと？（ちょっと自信ない）だった。 他の方のブログみて僕も勉強したい。
単に僕の頭が悪いってことだと思う。
モバイルファースト再考
モバイルファーストをもう一度考えましょうとのこと。 スマートフォンでしかサービスをやらないとかそういうことがモバイルファーストなのではなく、モバイル端末を起点としたサービス戦略や理論がモバイルファーストであると。
モバイルでしかできないことや、モバイルの特性を活かすのが前提で、日々の生活で人々がどんな行動をとっているのかをよく観察することが大事だと言ってた。
端末を色々触らんと理解できないことも多いと思うし、Nexus7買ってよかった。 iOSとAndroidではやっぱ色々と感覚が違うことも多い。
モバイルを使い倒していきましょうとのこと。
SQLアンチパターン
例の本の話。
よさそうな本だった。 あくまでアンチパターンだけでなく解決方法や、アンチパターンを使ってもよい例外的な条件なども載ってるらしい。
これは買いな気がする。
ワンクリックデプロイ
単純にワンクリックデプロイといっても、そこまでにやることは大量にある。 ほとんどすべてのことを自動化していかないと無理。
データベースへの大きな変更が入る（切り戻しができなくなる）場合は、切り戻しできるような工夫、例えば削除するカラムは残しておいて、しばらく運用してから削除するとかが必要そう。 自分に当てはめてみると見た目の部分のテストをどんだけ自動化していくかが課題のような。
アジャイルサムライ
どの現場でも試行錯誤で自分たちなりに色々試してるんだなと言う感じ。
新しいことを始める場合は、まず始めちゃおうということ。 始めて、成果をだして、困ったことがあったらアウトプットとして出して学び合おうよということだった。
一緒に始める人いなかったから一人でペアプロしたと言ってたけど、そのぐらい頭おかしくいきたいですね。
同僚の人とあったんだけど、改善したいと鼻息荒く言ってたのがうれしかった。
とまあ2日目のまとめはこんな感じ。
Developers Summit 2013に行ってきた（1日目）
デブサミ 2013に参加してきたので、ちょっとまとめとこうと思う。
3つの世界
エンタープライズ・ソーシャル/ゲーム・スタートアップという世界にいる3人のパネラーからの視点で話が展開していってた。
個人的にはソーシャル（Web系といったほうがいいかもしれない）・スタートアップ界隈の話になるほどですねと思うことが多かった。 これはエンタープライズがどうのというわけでなく、単純にWeb系にいたりするので、個人の興味がそっちに向いてるというだけの話だと思う。
ソーシャルの話だともはや僕らの考えた最強のインターネットはモバイルネイティブとの間にズレが生じてる感じだった。 モバイルネイティブの考えるインターネットはプライベートであり、クローズであるということも普通であるとのこと。
スタートアップの話だとシリコンバレーではExit戦略としてIPOよりもM&Aの割合がおおくなってるらしい。 イケてるサービスを作る → 資本力のある企業にM&AされJoinする → いいアイディアがでたらスピンオフという生態系ができていて、サービスを作る側としては最初サービスを作ることに注力でき、資本がある企業にM&Aされることでより多くの人に価値を届けられるようになっている。
また最近は英語でUIを作ることを推奨しているらしく、そうすることで言語に依存しないように思考するようになる。 文言もシンプルになったり、より分かりやすい（言語が分からなくてもどうすればいいか分かる）UIになるとのこと。
あとはラグナロクオンラインのログインゲー話が聞けてよかった。
Ruby 2.0
MatzによるGCの改善、新機能の話だった。 prepend、lazyはやっぱいいなと感じた。 refinementsは実験的な立ち位置なのでJRubyなどには入らないとのこと。
デザインをするときにデザイナが考えること
同じデザイナでもこんなにも考え方や物事へのアプローチの仕方が違うのかと素直に驚いた。 中吊り広告のデザインでもなぜこういうデザインなのかということを自分なりに考えるらしく、この辺りはマネしたほうがいい部分だと思う。 コンセプトやターゲットがはっきりしてる方がやっぱりデザインしやすいらしく、プロジェクトのオーナははっきりさせたほうがよさそう。
結局のところ、エンジニアとデザイナはお互いに歩み寄って概要だけでもいいから一般教養レベルの話はお互い把握しておいたほうがよりよいプロダクトをユーザに届けられますよねという話だと思う。
MobiRuby
2万円払ってRubyMotionを買いましょうとのこと。 mrubyを使っているので、mrbgemsで公開されているライブラリ郡を使用できるようになるのは魅力的だと思う。
プラガブルなアーキテクチャになってるんだろうけど、iOSとAndroid両方に対応するって言ってた。 現在の仕様ははっきりいって相当根性がないと書けないだろうけど、目指してる未来の形はかなりRubyらしく書けそうだったので、かなり期待してたい。
ニコニコ静画
できるだけシンプルに気持ちよく開発できる環境をひたすら追求している感じだった。 当たり前のことを当たり前にやるということを意識して実践しているという印象。
22時になると夜のニコ書リンクが出現するとのこと。 みんなベットの下に隠すリスクを取らずに、クラウドに置いておきましょうというアピールだった。
ソーシャルコーディング革命後の受託開発 QA@IT
受託なのに「We are Team!!」「 ぼくらは〜」というキーワードが発注側から出てくるところが新しいパラダイムのように感じる。 サービスのオーナーがコードを pull request するのやばい。 開発する側とオーナーに共に歩み寄りの意識がある。
技術負債についての話はかなり共感した。 テストを書かなかったり、設計を適当に考えて実装すれば、いくらでもスピードはあがるけど、今回のケースでは先がどうなるか分からなかったので、コードに技術的負債を残すわけにはいかず、Cleanに保つ必要があったとのこと。 負債を重ねても誰一人幸せになった人はいないとのことだった。（開発者以外でも） 結局のところ、負債を重ね、簡単に変更が加えられないといって苦しむのはチームや会社の全員だと思うし、プロならばそこをはっきりと諭すことが必要なんだと思う。
プロトタイプを1ヶ月で作ったあとに、それを捨てて（もともと技術検証用と作りたいものをイメージしてもらうために作ったもので捨てると宣言してたらしい）作り直して一から作り始めたらしいのだが、スピードが落ちてモヤモヤしてしまったところでそんな回答をもらったと言ってた。
だいぶと適当に感じたことをまとめたけど、1日目はこんな感じだった。
Railsで送ったメールの本文が空白だった話
ちょっと前にメールの本文が空白になるとの相談を受けた。
再現性がよく分からないが、時間が経つと本文が空白になるとのことだった。
resqueを使った環境とのことで、なんだろーなーと調べてみた。
結果から言うとリリース時にresqueの再起動をしてなかったことが原因だった。
capistranoでリリースをすると世代で管理できるけど、リリースを続けていくと、当然ながらresqueを立ち上げたディレクトリは削除される。
プロセスをロードしなおさないと、対象のviewがディレクトリごと消えてしまうので、当然ながらテンプレートが見つからないことになる。
ロードされるパスは絶対パスだったような気もしてた。
Rails触れるタイミングで裏付けとってみるか。
てことでresqueはちゃんとロードしましょうね。
2012年の振り返り
去年の振り返りを読み返してたら、色々やってた。
今年も終わろうとしてるので、振り返ってみる。
pull requestの初採用
去年の振り返りでpull request童貞を捨てたという話を書いていたが、今年は初めてpull requestが採用された。
delayed_jobのdaemonで使うloggerに対してのpull requestだったと思うけど、コアな人たちにコードを見てもらって色々アドバイスをもらえるのはやっぱり有益だなと思う。
PHPとAWS
色々な事情により、よく知らない人がPHPで作ったプロダクトを引き継ぐことになり、PHPとAWSをやることになった。
会社には運用チームがあるのだが、開発で管理することに決めていて、初めてのAWSで四苦八苦した。PHP自体も軽くしか触ったことがなくて、プロダクトとして扱うのは初めてだった。
色々、辛い面もあったのだけど、AWSやPHPをまともに触れたのは、いい経験だったと思う。それと同時に、自分のスキル不足を痛感した。
AWSでの運用を試験的に導入
新規サービスがたくさん立ち上がる中で、運用チームのリソースが足りない問題と新しい技術導入による運用チームの管理コストの問題があったので、サービスが大きくなるまでは開発側で運用できないかと考えていた。
運用チームは大きなサービスも合わせて管理していて、新規サービスが新しい技術を入れようとすると、統一されてない環境を管理していかなければならず、負担を強いられていたし、開発側は新規サービスだとしても、その負担が増えることが考慮されて、新しい技術を試せない*1という状況だった。
PHPでのプロダクトのおかげで、意図せずAWSを触ることになったのだけど、以前よりその問題を解決するために、新規サービスへのAWSの導入を検討していて、ついに導入することができた。
当然ながらプロである運用チームからすると、サービスレベルが下がってしまう問題はあったが、トラフィックがそんなにない状況では開発での運用でもうまく回っているように思う。色々と運用チームに相談させてもらってアドバイスをもらったことが大きい。
以前は、技術的に試したいことがあっても運用的な視点から導入できない場面が多かったが、新規サービスに限っていえば、色々と試せる環境が出来上がった。
今後は大きなサービスのために色々とフィードバックしていけると思う。
Objective-C
今年はiOSのアプリを作った。
外注という手もあったのだけど、チーム内で内製するという手段を確保しておきたかった。それで自分でチャレンジさせてもらうことにした。
ここでも、スキル不足を痛感した。GUIの設計はWebの設計とはちょっとばかり勝手が違って面白いなーとも感じた。
Shibuya.rb
今年に入ってShibuya.rbに顔を出すようになった。
僕はぼっちで突入したので、なかなか緊張したけど、色んな人と技術の話ができるのはとても楽しい。人見知りなので、技術以外でどんな話していいか分からなくて毎回脇汗がやばかったのを覚えてる。
今年の途中あたりからPHPとObjective-Cが中心になり、Rubyから離れてたこともあって、後半参加しないこともあったけど、来年はなんとかまたRubyをやりつつ、定期的に参加したいなーと思ってる。
コミュニティの人たちは、ぼっちにも優しいので、みんなどんどん参加してみるといいと思う。
地域コミュニティは勉強会ではないとのことで、僕もみんなに有益な情報をLTできるよう頑張りたい。
Sendagaya.rbには一回お邪魔したきりなので、こちらも定期参加したい。
コードレビュー
初めてコードレビューシステムを導入してみた。
コードレビューというとgerritがまず最初に思いつくが、Rubyで書いてあるbarkeepというプロダクトで検証してる。
詳しいことは後にブログにまとめようと思う。
ブログの移行
まあ移行に関しては割とどうでもいいんだけど、定期的にブログを更新してないと振り返りするのもなかなか大変だなーと思った。
まとめ
尊敬してる同僚が野球球団のために退職したりして、ヘコむこともあったけど、今年も色々ないい出会いがあって感謝してる。
健康でコードも書けてるし、僕はラッキーだなと思う。
スキル不足を痛感した一年でもあったので、ますます頑張らねばと思った一年だった。来年もどんどんチャレンジしていきたい。
*1:運用チームから見れば、管理するミドルウェア等を統一しておきたいというのは、当然の判断だった
はてなブログに貼ったgistのスタイルがぶっ壊れた
先日、gistが一新されてよりいい感じになってた。
イカスと思っていたのだけど、はてなブログに貼ったgistの見た目がアッーになってて残念な感じなので、直しておこうと思う。
ぶっ壊れた様子をキャプチャした。
原因は僕が使ってるはてなブログのテーマに関係があって、preタグにbox-shadowが指定されてることが原因のようだ。
単純にgistの場合だけ、preタグについたプロパティを打ち消すようにデザインCSSへ追記するのみでよい。
.gist pre { -webkit-box-shadow: none; -moz-box-shadow: none; box-shadow: none; }
前はなってなかったと思うんだけど、なにぶん はてなブログに移行した話 - ニヤニヤシテル噺 に書いたように、面倒くさい移行をしたので、実はあまり覚えてない。
とにかくダサいし、見にくいので直したほうがいいですね！
はてなブログに移行した話
VALUE DOMAINでドメインを管理していて、XREA.comが無料だったこともあって、今まではWprdPressをXREA.comのサーバにインストールして運用してた。
運用してるとサーバがよく落ちたり、phpMyAdminに入れなくなったり、データベースがぶっ壊れたりとあまりいい思い出がない。
書こうと思ったときに書けないのは、気分で行動してしまう僕にとって都合が悪かったし、ブログのサーバを変えて今までの記事をアーカイブとして残そうと思ったけど、自分のさくらVPSに突っ込んで管理するのも面倒だなと感じた。
ということで、色々調べてはてなブログにアーカイブとして残す目的で移行したわけだけど、これが結構手間がかかったので、一応どんな感じでやったかだけは残しておこうと思う。
簡単なフローは以下のようになる。
- WordPressのエクスポート機能を使ってXMLへ吐き出す
- XMLをMovable Type形式へ変換する
- はてなダイアリーにブログを作成し、インポートする
- はてなダイアリーをはてなブログへインポートする
移行にあたってのポイント
WordPressはWordPress eXtended RSS（WXR）という形式でデータを吐くのだけど、移行しようとした時点で、このデータをそのままはてなブログへインポートすることはできなかった。
色々と方法を探したが、そもそもはてなブログは、はてなダイアリーからのインポート機能しかサポートしていない。
つまり、まず最初にはてなダイアリーにデータをインポートする必要がある。
はてなダイアリーはMovable Type形式のデータのインポートをサポートしているので、WXRを変換できれば大体の問題は片付く。
ググるとたくさん情報が出てくるので、公開されているPHPのスクリプトを使ってもいいし、以下のサイトを利用してもよい。
http://komono.jp/contents/software/web/wxrtomt/
最近、アップデートがあったようなので、ちゃんとメンテナンスもされているように思える。
辛かったこと
僕の場合は、コメントやら削らないと変換がうまくいかなかったので、記事のみの移行に決めた。
あとは、はてなダイアリーにぶっこんで、syntax highlightなどの記法を地道に直していく。なぜか重複した記事ができてたので、それらも削除したりした。
ここは心の折れる面倒くささがあるので、がんばってくださいとしかいいようがない。
はてなダイアリーで綺麗に表示されるようにしておけば、はてなブログにインポートしても問題ない感じがする。
ということで、http://www.terut.net/ は http://action3.hatenablog.com/ に無事移行された。
terut.netはそのうちリダイレクトかけることにしようかな。
今から移行しようとしてる人、辛いけどがんばれ！
