by shigemk2

当面は技術的なことしか書かない

ニコニコ静画 (電子書籍)の作りかた みんながニコニコしてくれる読書体験を届けるために #devsumiA

f:id:shigemk2:20131208184157j:plain
@regtan

Taam nicobookとは
github:enterpriseとリリース先輩
ニコ書チームのお約束
It's your turn

ドワンゴ 第二企画開発部 第三セクション(=ニコニコ静画など)

3代目ニコ書System Leader(2012/11より)
前職は中小SIerでB2B開発

デブサミはweb系が多いらしいよ

今日は例のお菓子の日です

Team nicobook

ニコ静は最近課金プラットフォームが確立してきた

2011/11サービスイン
niconicoの電子書籍サイト
ブラウザ/iOSアプリ
124社の出版社と提携しコンテンツを配信
コミック ラノベをやってる

メンバー

開発エンジニア 8名
インフラエンジニア 1名(兼務)
デザイナ 2名(兼務)
企画 運営スタッフ 6名(うち3名兼務)
営業スタッフ 2名

github:enterpriseとリリース先輩

リリース先輩はniconico独自開発

ニコ書プロダクト

  • userfront/API
  • flash client/ios client
  • manage/CPmanage
  • eAPI
  • backend/broadcast(コンバート)
  • tools(業務改善)

それぞれを管理しているのがjenkinsとgithub:enterprise

人間はひとつのバージョン管理システムしか覚えられない(←そんなことないよ)

github:enterpriseについて

  • 企業内で使うgithub
  • もちろんgistも使える
  • わりとブラックボックス
  • 運用もわりと大変
  • でも、お高いんでしょ?(21$/user/month = 雅叙園コーヒー2杯分)

雅叙園のコーヒーは一杯900円くらい
23のレポジトリがある(ircbotとか、業務改善スクリプトとか、勝手に作られたものが多い)
なんかプロジェクトに愛着を持つために自分の嫁をプロジェクト名にしてるのが多い

ニコ書gitの掟

  • pull request前にテストが全て通っていること
  • masterへのmergeはpull requestを投げる(勝手にmergeすんなよ)
  • pull request は本人以外の誰かがチェック(第三者レビュー、誰の目にも見られないコードがmasterにあることは悪)

simple is best
(pushするまえはrebaseしろとか、cherry-pickしろとか)

運用ルールが複雑化すると…

  • どーせ守れない
  • すべてのアクションに対して逃げ腰になる(レポジトリの意味が全くない)
  • それ○○さんのコードなので問題が起こる(コードの私物化)

やりたくないことはやらないほうがいいので、あまり複雑なルールを作らない
めんどうな手間を省くためにルールをシンプルに

Don't ask for permission, beg for forgiveness.
(若手のミスをフォローするのは先輩のしごとです)

  • 得意な人が得意な部分を重点的にみる
  • レビュアを固定しない
  • ダイレクトあり(「俺は良いと思うんだけど、君はどう?」気になるところはリダイレクトしてみる)
  • チェックしたコードのみmasterへmerge

Jenkins

Jenkinsがgreenになっていることが、唯一絶対の掟

(だけどこれが出来るようになるのはしんどいので、どんどんどんどん下り坂になってしまい、しまいにはエラー通知も無視してしまう)

リリース

  1. git->svn(github:enterpriseのバックアップがうまく取れていないから)
  2. リリースtagを切る
  3. リリース手順wikiを書く
  4. インフラ担当者が本番環境へリリース(本番を触れるのはインフラ担当者のみ)

リリースの問題

  • git->svnやるのがめんどう
  • svn怖い
  • svnってftpサーバでしょ?
  • リリース手順wikiを書くのがめんどう(wikiや設計書を書く人が好きって人はそんなにいない)

なんとかみんなのモチベーションを上げようとして「リリース先輩」を開発した人がいた→ircbot rubyで書かれてる

手順

  • release_senpai:リリースおなしゃす
  • ちょいまちー
  • リリースできたぞー
  • wikiかけよーdiffはこっちなー

っていうメッセージが出る

(単に自動化するんじゃつまらないから、意外と楽しくなる)
これbotじゃなくてただのコマンドなら本当につまらない

ニコ書チームのお約束

(社内のスラム街)

  • テストを書け
  • 問題を根性で解決するな
  • 何やってもいい
  • 失敗をひきずるな

テストを書け

  • テストを自動化する
  • デグレを防ぐ
  • リソースの硬直化を防ぐ
  • わたしたちはサービスを提供しつづける

いちいちブラウザぽちぽちやんのはだるい
運用コスト < リソースでなければならない
特にweb開発はめまぐるしいスピードで開発されなければならないので、
運用やbugfixに時間を取られるのはつらい
速く開発するためにテストを書く

徹夜は禁物

  • エンジニアの仕事はエンジニアリング
  • 根性ループは悪
  • 手や目では危険

失敗を恐れない

失敗を引きずらない

  • 反省したら気持ちを切り替え
  • なぜダメだったかを考える
  • 繰り返さない方法を考える(テストなかったらテストを書けばいいし、テストしにくいならアナウンスすればいい。想定していないデータはそういうデータをテストする)

お前ら実際それ守れているの?と言われればちょっと不安はあるが、
きちんと守れていると自負している。

ライトスタッフであれ

light stuff(あっ軽い人々)
right stuff(正しい資質)

ミスキャストがあったら監督は降りるぜ

My Recommend Next Action!

当たり前のことを当たり前に

テストを書く CIを回す アジャイルな開発を行う はもう当たり前になった
当たり前のことは当たり前にできる環境を作りましょう(やっていないと逆にやばい)

空気のようにやっていること+付加価値

it's your turn

我々が今できていない「当たり前のこと」を考える