Skip to content

Instantly share code, notes, and snippets.

@cancer

cancer/cross_2014_memo.md

Last active January 3, 2016 20:39
Show Gist options
  • Save cancer/8516591 to your computer and use it in GitHub Desktop.
Save cancer/8516591 to your computer and use it in GitHub Desktop.
Download ZIP
CROSS 2014のメモ
Raw
cross_2014_memo.md

Session1 現場に聞く！テスト/CI/DevOps、実際のところどうなの

http://www.cross-party.com/programs/testcidevops/ (トークセッション)

gist https://gist.github.com/naoya/8451019

github使ってコードレビューしてるところが増えてるっていう話を去年書いた

http://d.hatena.ne.jp/naoya/20131013/1381651545

  • cookpad

  • CI的なことはやってたけどコードレビューはしてなかった

  • 2012頭ぐらいでgithubを使ったコードレビューの導入について考え始めたのがきっかけ

  • はてな

  • CIにすごい時間かかるようになった

  • 昔はテストの重要性軽視してた

  • 周りでそういう話を聞き始めたから導入した

テストの話

「テスト書きすぎるの良くないよ」派について

  • 長期運用するためには必要

  • 人も入れ替わるし

  • テスト書かない言い訳にしない

  • 一人二人ならいいけどさ…

  • 2,30人とかでレガシーなら書くべき

  • お客さんからお金もらうようなコードも

  • テストの話をするならまず自分の背景を説明してからにしよう(提案

  • 開発規模によってテストの重要性・分量は変わってくるよね

テストの基準について

  • はてな

  • カバレッジ100%は目指すけどいつも100%ではない…

  • mock,stubは自社のテストダブルライブラリを使う

  • cookpad

  • テスト通ったことがはっきりしてると、自分のコードが正しいことの証明になるから楽

  • 明文化はされてないけどコードレビューとかで

  • 実装に対して適度なテストが書いてあることをレビューするのは重要

  • そのテストに本当に価値があるかどうか

controllerのテスト書く？

  • wapだとend to endのテストが重要

  • casperjs簡単

  • rubyはかぴばら

  • いろんなドライバが使える

  • kaizen:そろそろはじめたい

  • widgetみたいなお客さんのところで動くツールだと、実行環境が読めなくて難しい

  • リリースしてユーザーの反応見て直す、っていうのも結構早いよ…？

  • ユーザーデバッグ的な

  • StackOverflowとか

テストを書くコストを渋る経営陣に対して

  • 1年先のメンテナンスコストを武器に攻めると突破できるよ

cookpadの開発基盤グループ

  • ユーザーに届ける上で、開発上の問題を解決するグループ

  • ちゃんこ(ABテストとかするツール)

  • こういうことを組織的にやることが必要になってきたんじゃ…？

  • はてな:メインの業務を横において、開発フローを改善することを優先する文化がある

  • 【悲報】xxブランチのテストがこけました @xxxx ってIRCに流れてきたりとか

  • cookpad:ユーザーにとって何が大切かを徹底的に考える文化

  • ユーザーに利益のあることなら何をしても許される

  • テストを書くこともユーザーのため

「テストから見えてくる グーグルのソフトウェア開発」 "DeveloperProductivity(開発率向上に寄与する部門)"にしたら状況が変わった、っていう話

昔は道具がなかったけど、グーグルは自分たちで作ってた この2,3年流行り始めたのはそういうのが揃ってきたから

情報共有どうしてる？

  • はてな:業務中にブログ書きながら仕事してる

  • はてなグループ

  • メールでのやりとりはほとんどない

  • cookpad:使われてないwikiぐらいしかなかった

  • groupad(はてなグループみたいなやつ)を作ったらすごい使ってもらえてる

  • GREE:cookpadと同じ感じ、グループ作った

  • 日報とかそこで書くようになった。日報ブーム。強制してないけど

  • wikiの最大の問題は、だれがいつどこを更新したのかの通知がこない

  • ほしい情報が書いてあるかどうかすらわからない(=探す以前の問題)

  • チャットツールでやるのもいまいち。ログが流れるから

  • こういうのがしっかりしてないとそれを伝える手段がない

  • テストとかCIとかかっこいいコード書いたぜとか

余談

Jenkinsって…

  • 昔
  • ビルドって概念ないよね…
  • なんか違和感あるよね…
  • 今
  • 無いと無理

github

github使いたいけど自社にサーバー置きたい ->enterprise ->高い ->githubクローン ->コレジャナイ感 やっぱgithubなんですよね

Session2 実況解説つき！ペアプロでわかるJavaScriptテスト入門

http://www.cross-party.com/programs/pairpro/ (ライブペアプログラミング)

テストの環境とテストツールについて

  • testem + mocha + expect + sinon
  • テストツールの分類の話
  • mocha + expect でテストの実行とアサーションを行う
  • mocha + expect(Chai) + sinon = qunit + sinon = Jasmine
  • mocha + expect(Chai) + testem(karma) = qunit + testem(karma) = Buster(jsTestDriver)

テストフレームワークの情勢はJasmine:44% mocha:42%で二強状態

jQueryのテスト

  • $(fn)のテストをしようとするとDOMのロードを待たなければいけなくなってしまう
  • $をstub関数に置き換えることで解決できる
// global
window.testInite = sinon.stub();
(window.testInit || $)(function(){
    // some code
});
var init = window.testInite.args.shift();
init[0]();

非同期(setTimeout)のテスト

  • 10ms待ってテストを実行する
  • 実際の時間待ってしまうと、テストの実行にものすごく時間がかかってしまう
  • sinon.useFakeTimers()を使ってダミーで時間を進めることで解決できる
var fakeclock = sinon.useFakeTimers();

var init = window.testInite.args.shift();
init[0]();

fakeclock.tick(10);

// some code

fakeckick.restore()
  • done()を使ってテストする場合
it('テスト1', function(done){
  setTimeout(function(){
    // some code
    done();
  });
});
  • 非同期のテストは基本的にはuseFakeTimersを使ったほうがよい
  • done()はコールバックのテストに使うのがよい
  • useFakeTimersを使った場合restore()を忘れると後続に影響するので注意

Ajaxのテスト

  • サーバーのレスポンスを待ってテストをしないといけない場合、サーバーの実装とJSのテストを切り離せない
  • sinon.fakeServerを使って、ダミーのレスポンスを返すことで解決できる
var fakeServer = sinon.fakeServer.create();
fakeserver.respondWith('/', responce);

var init = window.testInite.args.shift();
init[0]();

fakeserver.respond()

// some code

fakserver.restore()
  • respondWithをせずにrespond()の中でレスポンスを定義することもできる

formのテスト

時間がないので3分クッキング

その他

sinon.jsについて

  • sinonはドキュメントに書いてないことが多い

mockとspyの違いについて

  • mockは定義してない結果だったらテストを落とす手法
  • spyはテストコードを実行した後に期待する結果と照らし合わせる手法 ex.)fakeServer.respondWith(hoge, fuga)はmock的、fakseServer.respond(hoge, fuga)はspy的

テストケースを日本語で書くことについて

  • 英語で書くことでテストを書くハードルが上がるなら日本語でいい

テストをするためにプロダクトコードに手を加えることについて

  • Backbone/Angularが流行ってるのは、後からテストしやすい構造になっているから
  • レガシーなコード = テストがしにくいコード
  • フロントエンドの人たちはそこら辺頑張って解決していこう

Session3 次世代Webセッション

http://www.cross-party.com/programs/next/ (トークセッション)

※ 名前に釣られて聞きに行ったもののプロトコル関連の知識不足で理解できず。 　以下聞き取れたキーワードのみ列挙。

テーマ 「何が起こっているのか」 「どこに向かっているのか」

予習: http://jxck.hatenablog.com/entry/20131211/1386719942

Session4 技術書の未来はどっちだ

http://www.cross-party.com/programs/book/

gist https://gist.github.com/takahashim/8454906

技術書出版周りの話

  • The Pragmatic Bookshelf http://pragprog.com/

  • no starch press http://www.nostarch.com/

  • Packt Publishing

  • http://www.packtpub.com/

  • オンデマンド印刷。オンライン販売しか対応していない

  • 在庫リスクが無いので、マニアックな書籍が出る

  • 内容と写真は全く関係ない

  • 日本国内だと↓

  • マイナビ『31バイトでつくるアセンブラプログラミング　～アセンブラ短歌の世界～』

  • https://book.mynavi.jp/ec/products/detail/id=24267

  • Rubyで作る奇妙なプログラミング言語　～ヘンな言語のつくりかた～

  • https://book.mynavi.jp/ec/products/detail/id=24268

  • 顧客を知るためのデータマネジメントプラットフォーム　DMP入門

  • http://nextpublishing.jp/book/2045.html

  • プリント・オン・デマンドは一つの手段になっていく

  • 日本国内だと単価が高くなる。印刷会社がんばって

  • Amazonでも最近国内向けにはじめた

  • 入門chef solo

  • http://www.amazon.co.jp/%E5%85%A5%E9%96%80Chef-Solo-Infrastructure-as-Code-ebook/dp/B00BSPH158

  • 紙の本だとページ数が足りないのでkindleで出した

  • 売上は紙と比べて変わらないか少ない

  • 編集者がいないと好きにかけるから楽じゃない？

  • 編集者は内容よくわかってないからあんま変わらない

  • 文章がおかしいかどうかとか見てくれる

  • 編集者がいるとモチベーションを保ってくれる。一人だとつらい

  • 電子書籍だと訂正が楽

  • ユーザーが手動でアップデートしないとなのであまり変わらない

  • iBooksだと自動で通知してくれる

  • 出したあとのメンテナンス

  • サンプルコードが動かないからといって修正してアップデートをするのもコストがかかる

  • バージョンアップのアップデート要求なんかは全くうまみがない

  • 翻訳の場合、ツールを使って同じ表現は同じ翻訳になるようにしてる

HTML5 Booksの話

  • HTMLBook Specification: Working

  • Draft https://github.com/oreillymedia/HTMLBook/blob/master/specification.asciidoc

  • CSSによる本作りの未来を占う―HTMLBookとはどのようなものか？　果たして普及するだろうか？

  • http://blog.cas-ub.com/?p=5657

  • W3C DIGITAL PUBLISHING ACTIVITY

  • http://www.w3.org/dpub/

  • アンテナハウス Formatter V6

  • http://www.antenna.co.jp/AHF/

  • CSSとXSL-FOで電子書籍と紙のどっちも作れる

  • オライリーが使ってる

  • ファイルそのものじゃなくて閲覧権を売ってる問題

  • サービス終了すると買ったのに読めなくなる

  • デジタルデータであるメリットが活かされていない

  • 出版側の利益のみでユーザーの利益が考えられていない

  • なんで各社バラバラのフォーマットなの？

  • 印刷機とかの都合。かなり密結合

  • InDesign使ってるとmarkdownとかつらい

  • md2inao

  • https://gist.github.com/inao/baea09bc6fc53551886b

  • 技評のイナオさんの記法(20年ぐらい技評で使われてたやつ)

  • O'Reilly Atlas

  • https://gist.github.com/inao/baea09bc6fc53551886b

  • Sphinxみたいなドキュメントシステムとgithubみたいなバージョン管理システムを組み合わせるとかなり強力になるのでは？

  • オライリーから本が出てる(Sphinx)

  • http://www.oreilly.co.jp/books/9784873116488/

  • VCSが無いと仕事できなくなってる

  • 結局のところレポジトリを売りたい

  • 買ったくれた人がコミット権持ってたり

  • 取り込まれるかは著者次第

  • 未来の本の形のひとつ

  • …ってなるとHTMLになっていくのでは…？

  • HTML生成のツール(markdownなど)が使えるようになってくる

  • ただクソみたいな組版が普通に本屋に並んでるという悪い未来の可能性もある(一部はリッチになってるかもしれないけど)

  • 電子と紙の販売部数のギャップをどうやって埋めていくか そこを解決しないと著者は電子で出そうとしない

  • そこはこれから出版社が考えないといけないこと

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment