CROSS2015参加レポート
1月29日(木)に横浜大さん橋ホールで開催されたCROSS2015に行って来ました。
イベント詳細はコチラ CROSS 2015 | エンジニアサポート CROSS 2015
和田卓人さんバックグラウンド
- テストの話
- 品質と一言でいっても、めっちゃある（なんちゃらility）
- TDDと黄金の回転
- テスト駆動開発入門によると、動作するきれいなコードはあらゆる理由で価値がある
- テストとはエラーを見つけるつもりでプログラムを実行する
- Testing vs Checking
鳥居 剛司 さんバックグラウンド
- TV連動プラットフォームサーバー開発（M.I.E.S）
- TVとスマホが連動する視聴者参加型番組の政策
- TV連動向けの特徴
- その他機能テスト
- プラットフォーム
- プロジェクト毎に結合テスト
- ランスルー（内部リハ）
成田 伸一郎さんバックグラウンド
- 話が宇宙すぎて、全くついていけなかった。。
テストの優先順位、重み付けの価値判断
- 鳥居さん
- リスク表で一覧を洗い出す
- 発生率、損害額、対応工数とかを考慮してコスパベースで順位付け
- 費用対効果をみて、上から潰していく
- 費用対効果の出し方は、経験から
- 局、チーム内で想定&共有
一度限りのテストを書いたきっかけ
- 成田さん
- 宇宙に飛ばすことがある意味テスト
- 一発勝負で闇雲にやれない
- 地球で再現できるものはできる限り実証するが、実際に飛ばさないとわからないこともある
- ランチにつられて来てしまった。
- Oisixの認知度up&採用が狙い？
- サラダの紹介、人事からの会社説明、エンジニアから開発現場
- iPhoneアプリの紹介&Swift Tips がメイン
- エンジニアの現場紹介
- 勉強会を主催したり、交流は多め
- メインはJava,Swift
- Swift Tips
- ネギを指揮棒にして、くそコードをレビューする会もあるらしい。
Oisixさんのランチおいしゅうございました。
- Python.jpの使い方 石本さん
- どこでなにをどう活動している？Python.jp？
- 石井さんの個人サイトらしい
- Pythonのいいところ
- 技術情報の調査がしやすい。（石井さんならでは）
- コミュニティにどっぷり使っているから、誰がどこのライブラリをどう修正したのかがわかる
寺田さん PyCon JP の紹介
pydata tokyo 柴田さん
- 通常は、「Rで分析 ⇒ Javaで開発 ⇒ Excelでまとめる」
- 「Pythonで分析 ⇒ Pythonで開発 ⇒ Pythonでまとめる」一貫性がある
- Pythonでできること
- csv分析
- アドサーバー
- 深層学習
- 3月７日にチュートリアルやるらしい。行きたす。。
野球クラスタ 中川さん
- ほかのpythonコミュニティが１００人、５００人規模の中、１人で活動中。
django-ja 清原さん
- 2015年のdjango
- Django1.8がくる
- テンプレートエンジンの差し替えが可能
- Jinja2が使える
- 1.8aが公開されている
- RestFrameworkが面白い
- PythonFramework について
その他pythonコミュニティの紹介
- NVDA日本語チーム
- Plone Users Group Japan
第一部：先達の個体生存戦略
Q:不連続な進化をしたと感じた時は？その時の進化圧とは？
よしおかひろたかさん
- 環境変化もある
- OSSとの出会い
- 自分の価値観と１８０度違うものと出会ったとき
伊勢 幸一さん
- 一般的なターミングポイントはその時気づかない。後になって気づく。
- 転職や部署移動がいい例
- 環境変化がポイントになる。
- 上司の無茶ぶりもきっかけ。
- できないと言いたくないから引き受ける。きついが成長につながる
及川 卓也さん
- 及川さんはMらしい。。
- 自分からそういう状況に身をおく。
- 自分から仕事をとりにいって、「やる」といって、そこから勉強
- 自分ではできないことをチャレンジして、そこから頑張る
- 追い込まれないとやらないタイプだから、追い込まれる状況に身を置く。
Q:自分のバリューについて意識して心がけていること 個の戦略としての転職とは？
よしおかひろたかさん
- 会社にいると自分から学ば無い人８割
- 学ぶ人は２割
- 学び方を学ぶ
- 新しいことをどうやって学ぶか
- 学び方を考えるべき
そもそも師匠いないのでは？という質問に対して
- そう考える人もいる。
- ある分野に対する師匠は必ずいる。
- 同じ会社にとんがった人いるから！！
伊勢 幸一さん
- 頼まれたら断らない
- できない、しらない、やったことないを言わない
及川 卓也さん
- 信用にある転職コンサルタントに毎年あう
- 自分の価値を知る
- 年収より低かったら、危機感ある。
- 自分が人材市場において、どこに価値があるのか？
- 弱点は何か？第３者に見てもらう。
第二部 先達の遺伝子生存戦略
Q:働き蟻の法則から、８割の安定志向が増えるのでは？ 成長志向を見抜く方法
よしおかひろたかさん
- ハッカー文化を根付かせる。
- ８割の人間を引き上げる。
伊勢 幸一さん
- ２：８の割合は変わらない。
- ２割の連中は目に付くからわかる。目立つから。
- ２割の連中にアドバイスを送る。８割の人間には特になにもしない。
及川 卓也さん
- 評価システム
- ８割の人間やめればいい。
- また、人を入れればいい。
- １０割にして、８割きって、の繰り返し。
- いずれ、みんな働く。
- 人材の流動性が大事
- 日本は人材の流動性がない。
- きちんとした成果を評価システムが確率されることが大事。
- 文化だけでは変わらない。
- 自分と同年代の人間が高く評価されると、自分は頑張るかいづらくなる、やめる。
Q:技術者にとってよい経営者とは？その役割分担について 昨今のCTO議論の加熱について？→エンジニアのゴール？
よしおかひろたかさん
- いい経営者は利益をあげられること。利益をあげられる仕組みを作ること。継続して。
- CTOといえど、経営が先。
- 経営の勉強しようよ。
- 経営層に理解をさせるより転職した方が楽。
- 時間がもったいない。
伊勢 幸一さん
- 理想は技術をリスペクトする経営者がいること。
- だけど、技術に理解のない経営者が多いのは現実。
- 会社を継続させることが経営幹部の役目。
- CTOになった人は大抵なりたくてなった訳じゃない。
及川 卓也
- エンジニアのゴールは多様性があっていい。
- マネジメントに進むだけがキャリアパスだけではない。
- 経営幹部に技術を理解して欲しい面もある。
- 経営はやりながら、学べる所もある。
- 自分たちが技術の会社として自分の製品を使って、愛しているかどうかが経営者の指標
第三部：これからの生存戦略
Q:自分を成長させるために８割の蟻から２割の蟻になるめには？
よしおかひろたか
- 自分で考えろよ。
- 学び方を学ぼうよ。
伊勢 幸一さん
- 自分以外の人のことを考えないから、ミスキャストwww
- 自分の思った通りにやりたいことをすればいい。
- そのためには、やりたくないこともやる必要はある。
- 結局、全部やるってことですね
- 頼まれたら断らないに通じる
- できない、しらない、やったことないを言わないにも通じる
及川 卓也さん
- 自分より若い人と会う。
- 説教しちゃ駄目。若い人から学ぶ姿勢。
- アウトプットを意識する
- 勉強会はでりゃいい訳ではない。
- LTやるとか質問するとか（質問する気で聴くだけでも違う）
- スルー力大事。
- ちょっと批判されたら、凹むのはNG
- 受け入れるようにしよう。
- 一貫しているのは学び続ける。
最後に一言
よしおかひろたかさん
- 大学の学びのメソッドを再評価してもいいのでは？
- 古い学び方の再評価。
- 日本では社会人から大学へ戻るのは２％
- 外国は２０％
- 欧米では普通にあるのに、日本ではない。
- 勉強会だけでない違う学び方を考えた方がいい。
- MBAとっているやつは仕事をとめて、２年間時間とお金を使って、学んでいるのは強い意思の現れ。
- 結局、自ら学んで、アウトプットして継続が大事
Q:若い人のやる気をあげるには？
及川 卓也さん
- モチベーションは自分からでるもの。
- 潜在的に持っているものを引き出す。簡単に答えを言わない。
- 色々やらせて、試させて、失敗させて、時間を。
- 結論：我慢
Q:全く知らない分野に取り組みかた
伊勢 幸一さん
- アウトプットを出して、きっかけを作る。
- それ以上のものが返ってくる。
雑感
- 最後のセッションのよしおかさん、伊勢さん、及川さんに共通して見えたのが
- 勉強し続けることは共通している。
- 外から刺激を求め続けている。
というところだった。 学び続けるのは大事だと思うが、よしおかさんが言ってたように学び方は考えた方がいいかな。
- いろんな人に会えたので、楽しいイベントでした。
- Python面白そうですね。３月のpydata tokyo を密かに楽しみにしています。
小さな越境を繰り返すことが、とんでもないところに行くただ一つの道だと感じた一年
このエントリは、DevLOVE Advent Calendar 2014「越境」の31日目(12/8)の記事です。
自己紹介
まっくマクサカ (@chakasaka9) | Twitterです。 少し前まで、VB.NETでサーバサイドの開発をしていました。 最近はRuby や Rails と戯れています。
小さな越境を繰り返すことが、とんでもないところに行くただ一つの道
イチローの名言からパク引用
振り返ると、この言葉の力を感じた一年でした。
この一年の小さな越境を挙げてみる
- ブログを始めた
- セミナー・勉強会に行き始めた
- Seleniumという武器を手に入れた
- 初めてのLT
- 初めてのAdvent Calender etc
一部、振り返る
セミナー・勉強会に行き始めた
初めて参加したイベントが DevLOVE現場甲子園2014 東日本大会だった。 いままで、社外の人たちと関わりを持ったことが無かった自分にとっては、全てが新鮮に感じた。 このイベントが自分の世界を一気に広げてくれて、すごい楽しかったです。 それと同時に自分より、若い人たちがスピーカーとして堂々と話している姿を見て、刺激もたくさん受けたいいイベントでした。 誘っていただいた @kentana20さん、運営されているDevLOVEの方達には本当に感謝です。
初めてのLT
DevLOVE現場甲子園2014 東日本大会が終わり、「自分も冬ぐらいにスピーカーとして参加したなぁ」とぼんやり思っていたら、DevLOVE現場甲子園2014 日本シリーズ編 〜東西開発現場の集結〜で初LTデビュー。
拙い発表でしたが、これで終わらせたくないですね。 これも自分にとっては大事な越境の一つです。
Seleniumという武器を手に入れた
これが、この一年で大きかったと個人的に思ってます。 日本Seleniumユーザーコミュニティの伊藤望さんから直接教わったのは、本当にいい経験でした。 リグレッションテストで手動作業満載の現場を完全自動化することができたのは自信になった（当然、自分一人で全てをやりきった訳ではないが）。
これからの越境を考える
いきなり大きいことをやろうと思っても、いまいちピンとこないので、
小さな越境を繰り返すことを、これからも大事にしていければいいかなと思ってます。
お次は？
ひろねんさんです。お願いします。
FireFox多重起動時の「unable to bind to locking port 7054 within 45 seconds」の対処法
現象
Jenkins から Firefox 多重起動時に下記のエラーが発生
unable to bind to locking port 7054 within 45 seconds
前提(使用環境)
対処法 ~ Pattern 1 ~
待ち時間変更
lib/selenium/webdriver/firefox/launcher.rb でSOCKET_LOCK_TIMEOUT = 45 と定義されている部分があるので、そこの値を変更。
SOCKET_LOCK_TIMEOUT = 45
直接、gemをいじっちゃうという。まぁ、定数定義しているところだし、特に問題なし。
対処法 ~ Pattern 2 ~
ポート番号変更
webdriver 設定時にポート番号を指定する
例
port = 7000 driver = Selenium::WebDriver.for(:firefox, :port => port, :profile => profile)
port は動的にできるといいかな。
対処法 ~ Pattern 3 ~
Firefox Profile を各テストケース毎に設定
同じProfileに対して、複数のテストケースを同時に実行している状況はよろしくないと思われるので、各テストケース毎にProfile を設定した方がよさげ
Firefox Profile 設定方法
ウィンドウズボタンの「プログラムとファイルの検索」から
C:¥Program Files(x86)¥Mozilla Firefox¥filefox.exe -p
でプロファイルを作成
参考
[Selenium 2] Firefox起動時のポートロック待ち時間変更方法 - 僕らはみんな歪ている
Special Thanks
この事象を解決するにあたり、 日本Seleniumユーザーコミュニティの伊藤望さんからアドバイスを頂きました。 Selenium のことで困ったら、ここのオンラインフォームで質問してみるといいかもですね。 日本Seleniumユーザーコミュニティ オンラインフォーム Seleniumについて調べると、記事は散在しているし、日本語の情報少ないし（英語の記事よめば済む話ですが）、けっこう大変だと思うので、助けになると思います。
プレイバックDevLOVE現場甲子園 参加レポート
プレイバックDevLOVE現場甲子園
11月8日に「プレイバックDevLOVE現場甲子園」に行ってきました
イベント詳細はこちら
プレイバックDevLOVE現場甲子園 - DevLOVE | Doorkeeper
以下、参加レポート ※集中力の低さ故、所々メモとれていないです。ごめんなさい。。
開会宣言
DevLoveとは
- 開発の楽しさを発見、広げる
- 開発現場の前進
現場甲子園とは
- 各現場の代表者が集結し、挑戦を語る場所
- ６つの切り口から互いの技を見せ合う
- そして、現場へと戻る
2013創トラック：及部 敬雄(@TAKAKING22)選手
エンジニアリングにチームビルディングは必要なのか
- 正直わからない
- でもチーム開発は重要
- いい開発現場はみんなで作るもの
ヒアリング
- 1 on 1 ランチ
- 聴き方重要
人は変化を好むが、他人に変化させられることを好まない By Henrik
変化できる状況を作る
- チェンジインセプションデッキ
- チェンジロードマップ
現状の問題を共通認識にする
振り返りとメトリクスはセット
- 振り返りの積み重ね
振り返りの積み重ね
- １発で今の形になったわけではない
- Perfect を狙うのではなく、BetterをBestにしていく
<自分を振り返ると>
メトリクスをしていない
- リリース成功率
- リリース所要時間
- チケット消化率 etc
- 効果の程が実感できない
でも、ちゃんと？頑張って計測する必要はないと思っていて
- 一人一人が変化できていることを実感できていれば、いいかなと思っていて
- でも、そのためにはメトリクスが手っ取り早いのかなとも思う
2013考トラック：志田裕樹選手
- ユーザーインタビューから価値をマップ化して、仮説検証っていうプロセスは使えそう
- ただ、ヒアリング結果が残酷だと心が折れそう
2013守トラック：坂部 選手
- そもそものアンチパターンは組織チームとしてのリスクを持っている状態や主観文化が引き起こす
2013団トラック：すぎいまさかつ 選手
- 大きな会社にありがちな、育たない人・チームは共感
- アジャイル大好き
- Fearless Change をベースに実践
- 組織を変化に導くパターン集
- 根回し大事
- Fearless Change をベースに実践
2014創トラック：秋葉ちひろ 選手
- デザイナーの関わり方
- 仕様が固まってから入る
- なぜコレを使うのかという理由やバックグランドの説明は必要
- ある程度、仕様に満足がいけば、UIに集中できる
- 仕様を一緒に決める場合
- サービス企画をやりたい人は入ればいい
- 価値検証のためのデザインで仕様を固めていく
- 価値がわかったらガチデザインに入り、演出も考える
- 仕様が固まってから入る
- ガチデザインは最後までとっておく
- どこでデザインをはめ込むか
- 価値検証のためのデザイン力
- 最低限の価値がわかるもの
- 最低限のテイストがわかるもの
- それを素早く実装
- 必要に応じて、必要な段階でデザイナーは入ればいい
- 価値検証のためのデザイン力は必要
飛び込み：Can We Change The World
- 勢い大事
2014守トラック：ふじもと 選手
入門Chef solo が Infrastructure as as code を意識するきっかけとなった
- GitHub 実践入門
- Chef 実践入門
- チーム開発 実践入門
経験した現場
- インフラ構築手順書がなく、作業スキルが属人化
- 人海戦術で、構築も試験も月数sむ
- root権限を持った紙がたくさん
- Infrastructure as as codeに見る本質
- DevOpsが協力した継続的デリバリー
- 職人芸エンジニアによるインフラ構築からの脱却
- 共有したCodeが正しく動作することを試験するCodeを書く
継続的に試験実施
Codeを書くと
空気を変える
- 空気で人を動かす
- 大好きなことをやって生きよう
2014心トラック：江森真由美(emorima) 選手
- 最初
- 2010年、Asakusa.rb にJoin
- Tokyu.rbの帰り道にRails Girls 誕生のきっかけ
- Join ⇒ Organize
- かつての自分をひとりでも少なくする
- 新しいことを学んでいる時、人は輝いている
- コミュニティの関わり方
- 参加：Join
- 手伝う：Help
- 誘う：invite
- スキル向上だけでなく、かつての自分、未来の自分のためになる
- 近くの人の助けになりうる
2014技トラック：増田亨 選手
私がドメイン駆動設計をやる理由 from 増田 亨
- ドメイン駆動設計をがんばるとソフトウェアの変更コストが劇的に下がる
- ソフトウェアの変更コストが下がると、成長の可能性が広がる
- モデル駆動で単純化する
- 単純化しても１回でうまくいくことはない
- 改善を繰り返す
- 単純化 ⇒ 模型を作る ⇒ コードを書く をサイクルでまわす
- 3層＋ドメインモデルがターニングポイントになった
- MVC アーキテクチャーのあるある問題は、すごいよくわかる。
2014隊トラック：西 秀和 選手
- IT人材白書より統計情報を調査。
- 実は現場のエンジニアはすごいんだぞ話
- とあるプロジェクトが。。。
- Why ⇒ How ⇒ What を考える
- 現場のエンジニアにWhat を与えると動けなくなる
- 現場を変える可能性を一番持っているのは現場のエンジニア
- 特別な権利
- 案件の選択
- リリース判断
- チーム編成
- 特別な権利
おまけ
参加者同士の交流タイム的なイベントで、ぼっちになっていたら、流れでegapool (@egapool) | Twitterさんと話す機会があって、色々話を聴いてたら、どうやらSeleniumをやってらしゃるという。この前のSeleniumユーザーコミュニティ勉強会にも参加していたとか。「自分も行きました〜」的な話で盛り上がりました。 その時の参加レポートはこちら
世界は狭い。。DevLOVE Advent Calendar 2014 「越境」申し込みました。 担当は12月8日(月)です。申し込みページはコチラ 帰り際にDEVLOVERからの強烈な勧誘に断りきれず（嘘） というのも全くなかったわけではないが、単純に面白そうだったし、イベント参加後の勢いで申し込んだのかな？ なに書こう。。
「第2回 日本Seleniumユーザーコミュニティ勉強会」参加レポート
第2回 日本Seleniumユーザーコミュニティ勉強会
10月18日（土）に「第2回 日本Seleniumユーザーコミュニティ勉強会」に参加してきました。
イベント詳細はこちら 第2回 日本Seleniumユーザーコミュニティ勉強会 - connpass
以下、参加レポート
【玉川竜司さん】Seleniumをもっと知るための本の話
英語の技術書を読む話
英語の技術書読もう。。 総合的な本は翻訳で読んで、周辺情報は英語で埋める。 Selenium はその例にあたる。 Kindle Fire 買おうかな。 たしかに洋画を英語で聞いたところでって言う話だし、わかる。 Rebuild でも、英語やろうよっていう話でているし、 英語の重要性を最近ひしひしと感じる。
英語のスライド読むのもあり？
【玉川紘子さん】脱・独自改造！GebでWebDriverをもっとシンプルに
Javaで WebDriver 書くと長い。そのままでは微妙。。 Groovyを用いたWebアプリケーション向けの機能テストライブラリであるGebでシンプルにかける方法やTips、注意点について
Rubyで書いているし、 そもそも、Javaがそんなに好きじゃない。。 といいつつ、食わず嫌いはよくない気がする。。
玉川さんはIntelliJっていうIDEを使っているらしい。 IntelliJ IDEA :: Download Latest Version of IntelliJ IDEA Eclipseが好きじゃないから、コレ使うかな。
リファレンスはコレでだいたい事足りるらしい。 The Book Of Geb - Table of Contents - 0.9.3 リファレンス英語。。やっぱり英語必要。
【伊藤望さん】海外のSeleniumカンファレンスではどんな発表がされているのか2014
ページオブジェクト
Saleforce がRCテストをいかにしてWebDriverへ移行したかという話。 下記、 @a_kuratani さんのツイートから
Allure Framework
リッチな感じで面白そう Allure | Test report and framework for writing self-documented tests Allure Framework · GitHub
スライドが英語。。（当然ですけど。。） 結果、英語はできた方がいい。
【宮田淳平さん】ハイパフォーマンスSeleniumテスト＠サイボウズ（仮）
パフォーマンスについて３点
- 実行時間
- 安定性
- メンテナンス性
Jenkins + Pipeline Plugin Git のメインブランチにマージされるたびにテスト実行は、これからやりたい。
【実行時間】
- 余計なテストは作らない
- メインシナリオのテストぐらいが無難
- 並列実行
- 個々のテストの時間短縮よりも効果的
並列化はリソースとの戦い
【安定性】
- リトライ設定 ⇒ サイボウズは３回
- 明示的なWait
- sleep より Explicit wait の方がいいとか
【メンテナンス性】
- PageObject は必須 ⇒ 納得
【松尾和昭さん(@Kazu_cocoa)】クックパッドアプリの開発を支援するAppiumの話
OS バージョンアップを老い続けていくのが大変そう。 だけど、アプリのテストも自動化させたい、今日この頃
これベースでいじってみるかな。
所感というか雑記
DevLOVE現場甲子園2014 東日本大会 行ってきた
DevLOVE現場甲子園2014 東日本大会が終わった勢いに身を任せて、ブログを綴る。
背景
1週間ぐらい前に 発表者の kentana20さんから連絡がきてスタッフとして急遽参加が決定。。 初めてのセミナー？なるものに参加することになった。
所感〜その１〜
打ちのめされた。。発表している人たちみんなすごい。自分よりも若いであろうエンジニアが雄弁に話す姿をみて、「見てるだけの俺ってなんなん？」って感じざるを得なかった。 悲観している訳ではないです。世界が広がって、楽しかったし、むしろモチベーション上がったし。 何より、見ていて勉強になったし、楽しかった。 スタッフ的な仕事はあまりしていないが（ごめんなさい）、行ってよかったなと思ってます。
刺さったプレゼン
気になったものをいくつか紹介。
あてはまる部分がある気がする。
直接聞いてはいないけど、スライドが気になった。人生相談したいなぁ。。
コレ実践したい！！たしかに観点を明確にしないで、漠然とレビューをお願いしていた部分があった。
小さく失敗、小さく学ぶことは スクラム や LEAN に限らない話なのかなと個人的には感じる。
まさかの飛び入り参加が藤吾郎さん。Webアプリの開発とネイティブアプリの開発は別物だし、自動化の難しさや属人化、社内受託体制になりがちの部分はすんごい共感できました。事実、そうなっている感がある。
所感〜その２〜
「小さい」とか「短い」というのがキーワードになっている気がした。 西見さんのコードレビューで「小さい単位でレビューを繰り返す」とか 松浦さんのアジャイル開発現場で「短いカイゼンのフィードバックサイクルをまわす」っていうところが気になった。
所感〜その３〜
世界が一気に広がった。貪欲に吸収して、アウトプットだして行ければ、自分もDevLOVE現場甲子園球児になれる・・・はず。。
あぁ、とりあえずRailsでもやるかな。
おまけ
kentana20さんプレゼン前の一枚。
コレ以外、まともな写真を撮っていなかったことに、激しい後悔に苛まれる。。
RSpecによるユニットテスト~セットアップ~
ターミナルを立ち上げて、Ruby 2.1.2 と SQLite 3 をhomebrewでインストール。 Mac 初心者のため、homebrewのコマンドに感動するwww
$ brew search ruby
とか
$ brew install sqlite
とか。お恥ずかしいかぎりです。
Rails4をインストールする
$ gem install rails
⇒You don't have write permissions for the /Library/Ruby/Gems/2.0.0 directory.
…権限がないって。。ざっけんなww
$ sudo gem install rails;
でインストールするし。。
アプリケーションの作成
$ rails new blog
blogフォルダができたす。
rspec-railsのインストール
gemfileに下記のコードを追加するし。
group :development, :test do
gem "rspec" , "3.0.0.rc1"
gem "rspec-rails" , "3.0.0.rc1"
end
Rspec,rspec-railsと依存しているライブラリをインストール
bundle install
bundle could not locate gemfile
で怒られた。。 gemfileがない・・・だと。。。
cd blog
gemfile がいるとこに移動せんとね。凡ミス（爆）
bundle install
今度はOKす。
Rspecの設定ファイルを生成するために、次のコマンドを実行。
rails generate rspec:install
Warning: You're using Rubygems 2.0.14 with Spring. Upgrade to at least Rubygems 2.1.0 and run gem pristine --all for better startup performance.
Warning 出てきたけど、シカト。Rubygemsのバージョンが古いっぽい。
create .rspec
create spec
create spec/spec_helper.rb
できたからよしとするす。
初期設定だけで、色々つまづいたお。
長くなってきたから、モデル・コントローラ・ビュー・ヘルパーごとのテストに関しては追々書きます。
パスの設定とか色々とすっ飛ばしているのがちょっと不安や。
