読者です 読者をやめる 読者になる 読者になる

りあるふぁいとぷろぐらまー

IT系の技術ネタと格闘技(ブラジリアン柔術)ネタを徒然なるままに綴る予定。

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さんのランチおいしゅうございました。

https://s3-ap-northeast-1.amazonaws.com/uploads-jp.hipchat.com/91954/754129/bIuJ3BxBJHOHuqI/20150129_125005.jpg

  • Python.jpの使い方 石本さん
  • どこでなにをどう活動している?Python.jp?
    • 石井さんの個人サイトらしい
  • Pythonのいいところ
    • 技術情報の調査がしやすい。(石井さんならでは)
    • コミュニティにどっぷり使っているから、誰がどこのライブラリをどう修正したのかがわかる
寺田さん PyCon JP の紹介
pydata tokyo 柴田さん
  • 通常は、「Rで分析 ⇒ Javaで開発 ⇒ Excelでまとめる」
  • Pythonで分析 ⇒ Pythonで開発 ⇒ Pythonでまとめる」一貫性がある
  • Pythonでできること
    • csv分析
    • アドサーバー
    • 深層学習
  • 3月7日にチュートリアルやるらしい。行きたす。。
野球クラスタ 中川さん

  • ほかのpythonコミュニティが100人、500人規模の中、1人で活動中。
django-ja 清原さん
  • 2015年のdjango
    • Django1.8がくる
    • テンプレートエンジンの差し替えが可能
    • Jinja2が使える
    • 1.8aが公開されている
    • RestFrameworkが面白い
  • PythonFramework について
    • 色々あるけど、とりあえず、Djangoっていう選択肢はあり。
    • コミュニティ大きいし、フルスタックだから。
その他pythonコミュニティの紹介
  • NVDA日本語チーム
  • Plone Users Group Japan

第一部:先達の個体生存戦略

Q:不連続な進化をしたと感じた時は?その時の進化圧とは?

よしおかひろたかさん
  • 環境変化もある
  • OSSとの出会い
  • 自分の価値観と180度違うものと出会ったとき
伊勢 幸一さん
  • 一般的なターミングポイントはその時気づかない。後になって気づく。
  • 転職や部署移動がいい例
  • 環境変化がポイントになる。
  • 上司の無茶ぶりもきっかけ。
  • できないと言いたくないから引き受ける。きついが成長につながる
及川 卓也さん
  • 及川さんはMらしい。。
    • 自分からそういう状況に身をおく。
    • 自分から仕事をとりにいって、「やる」といって、そこから勉強
    • 自分ではできないことをチャレンジして、そこから頑張る
    • 追い込まれないとやらないタイプだから、追い込まれる状況に身を置く。

Q:自分のバリューについて意識して心がけていること 個の戦略としての転職とは?

よしおかひろたかさん
  • 会社にいると自分から学ば無い人8割
  • 学ぶ人は2割
  • 学び方を学ぶ
  • 新しいことをどうやって学ぶか
  • 学び方を考えるべき

そもそも師匠いないのでは?という質問に対して

  • そう考える人もいる。
  • ある分野に対する師匠は必ずいる。
  • 同じ会社にとんがった人いるから!!
伊勢 幸一さん
  • 頼まれたら断らない
  • できない、しらない、やったことないを言わない
及川 卓也さん
  • 信用にある転職コンサルタントに毎年あう
    • 自分の価値を知る
    • 年収より低かったら、危機感ある。
    • 自分が人材市場において、どこに価値があるのか?
    • 弱点は何か?第3者に見てもらう。

第二部 先達の遺伝子生存戦略

Q:働き蟻の法則から、8割の安定志向が増えるのでは?
成長志向を見抜く方法

よしおかひろたかさん
伊勢 幸一さん
  • 2:8の割合は変わらない。
  • 2割の連中は目に付くからわかる。目立つから。
  • 2割の連中にアドバイスを送る。8割の人間には特になにもしない。
及川 卓也さん
  • 評価システム
    • 8割の人間やめればいい。
    • また、人を入れればいい。
    • 10割にして、8割きって、の繰り返し。
    • いずれ、みんな働く。
  • 人材の流動性が大事
  • きちんとした成果を評価システムが確率されることが大事。
  • 文化だけでは変わらない。
  • 自分と同年代の人間が高く評価されると、自分は頑張るかいづらくなる、やめる。

Q:技術者にとってよい経営者とは?その役割分担について
昨今のCTO議論の加熱について?→エンジニアのゴール?

よしおかひろたかさん
  • いい経営者は利益をあげられること。利益をあげられる仕組みを作ること。継続して。
  • CTOといえど、経営が先。
  • 経営の勉強しようよ。
  • 経営層に理解をさせるより転職した方が楽。
  • 時間がもったいない。
伊勢 幸一さん
  • 理想は技術をリスペクトする経営者がいること。
  • だけど、技術に理解のない経営者が多いのは現実。
  • 会社を継続させることが経営幹部の役目。
  • CTOになった人は大抵なりたくてなった訳じゃない。
及川 卓也
  • エンジニアのゴールは多様性があっていい。
  • マネジメントに進むだけがキャリアパスだけではない。
  • 経営幹部に技術を理解して欲しい面もある。
  • 経営はやりながら、学べる所もある。
  • 自分たちが技術の会社として自分の製品を使って、愛しているかどうかが経営者の指標

第三部:これからの生存戦略

Q:自分を成長させるために8割の蟻から2割の蟻になるめには?

よしおかひろたか
  • 自分で考えろよ。
  • 学び方を学ぼうよ。
伊勢 幸一さん
  • 自分以外の人のことを考えないから、ミスキャストwww
  • 自分の思った通りにやりたいことをすればいい。
  • そのためには、やりたくないこともやる必要はある。
  • 結局、全部やるってことですね
  • 頼まれたら断らないに通じる
  • できない、しらない、やったことないを言わないにも通じる
及川 卓也さん
  • 自分より若い人と会う。
  • 説教しちゃ駄目。若い人から学ぶ姿勢。
  • アウトプットを意識する
  • 勉強会はでりゃいい訳ではない。
  • LTやるとか質問するとか(質問する気で聴くだけでも違う)
  • スルー力大事。
  • ちょっと批判されたら、凹むのはNG
  • 受け入れるようにしよう。
  • 一貫しているのは学び続ける。

最後に一言

よしおかひろたかさん
  • 大学の学びのメソッドを再評価してもいいのでは?
  • 古い学び方の再評価。
  • 日本では社会人から大学へ戻るのは2%
  • 外国は20%
  • 欧米では普通にあるのに、日本ではない。
  • 勉強会だけでない違う学び方を考えた方がいい。
  • MBAとっているやつは仕事をとめて、2年間時間とお金を使って、学んでいるのは強い意思の現れ。
  • 結局、自ら学んで、アウトプットして継続が大事

Q:若い人のやる気をあげるには?

及川 卓也さん
  • モチベーションは自分からでるもの。
  • 潜在的に持っているものを引き出す。簡単に答えを言わない。
  • 色々やらせて、試させて、失敗させて、時間を。
  • 結論:我慢

Q:全く知らない分野に取り組みかた

伊勢 幸一さん
  • アウトプットを出して、きっかけを作る。
  • それ以上のものが返ってくる。

雑感

  • 最後のセッションのよしおかさん、伊勢さん、及川さんに共通して見えたのが
    • 勉強し続けることは共通している。
    • 外から刺激を求め続けている。

というところだった。 学び続けるのは大事だと思うが、よしおかさんが言ってたように学び方は考えた方がいいかな。

  • いろんな人に会えたので、楽しいイベントでした。
  • Python面白そうですね。3月のpydata tokyo を密かに楽しみにしています。

小さな越境を繰り返すことが、とんでもないところに行くただ一つの道だと感じた一年

このエントリは、DevLOVE Advent Calendar 2014「越境」の31日目(12/8)の記事です。

自己紹介

まっくマクサカ (@chakasaka9) | Twitterです。
少し前まで、VB.NETでサーバサイドの開発をしていました。
最近はRubyRails と戯れています。

小さな越境を繰り返すことが、とんでもないところに行くただ一つの道

イチローの名言からパク引用
振り返ると、この言葉の力を感じた一年でした。

この一年の小さな越境を挙げてみる

  • ブログを始めた
  • セミナー・勉強会に行き始めた
  • Seleniumという武器を手に入れた
  • 初めてのLT
  • 初めてのAdvent Calender
    etc

一部、振り返る

セミナー・勉強会に行き始めた

初めて参加したイベントが DevLOVE現場甲子園2014 東日本大会だった。
いままで、社外の人たちと関わりを持ったことが無かった自分にとっては、全てが新鮮に感じた。
このイベントが自分の世界を一気に広げてくれて、すごい楽しかったです。
それと同時に自分より、若い人たちがスピーカーとして堂々と話している姿を見て、刺激もたくさん受けたいいイベントでした。
誘っていただいた @kentana20さん、運営されているDevLOVEの方達には本当に感謝です。

初めてのLT

DevLOVE現場甲子園2014 東日本大会が終わり、「自分も冬ぐらいにスピーカーとして参加したなぁ」とぼんやり思っていたら、DevLOVE現場甲子園2014 日本シリーズ編 〜東西開発現場の集結〜で初LTデビュー。

f:id:RealFightProgrammer:20141208132217p:plain


拙い発表でしたが、これで終わらせたくないですね。
これも自分にとっては大事な越境の一つです。

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(x86Mozilla Firefox¥filefox.exe -p

でプロファイルを作成

参考

[Selenium 2] Firefox起動時のポートロック待ち時間変更方法 - 僕らはみんな歪ている

Special Thanks

この事象を解決するにあたり、
日本Seleniumユーザーコミュニティの伊藤望さんからアドバイスを頂きました。

Selenium のことで困ったら、ここのオンラインフォームで質問してみるといいかもですね。
日本Seleniumユーザーコミュニティ オンラインフォーム
Seleniumについて調べると、記事は散在しているし、日本語の情報少ないし(英語の記事よめば済む話ですが)、けっこう大変だと思うので、助けになると思います。

プレイバックDevLOVE現場甲子園 参加レポート

プレイバックDevLOVE現場甲子園

11月8日に「プレイバックDevLOVE現場甲子園」に行ってきました

イベント詳細はこちら

プレイバックDevLOVE現場甲子園 - DevLOVE | Doorkeeper

以下、参加レポート
※集中力の低さ故、所々メモとれていないです。ごめんなさい。。

開会宣言

  • DevLoveとは

    • 開発の楽しさを発見、広げる
    • 開発現場の前進
  • 現場甲子園とは

    • 各現場の代表者が集結し、挑戦を語る場所
    • 6つの切り口から互いの技を見せ合う
    • そして、現場へと戻る

2013創トラック:及部 敬雄(@TAKAKING22)選手

  • エンジニアリングにチームビルディングは必要なのか

    • 正直わからない
    • でもチーム開発は重要
    • いい開発現場はみんなで作るもの
  • ヒアリング

    • 1 on 1 ランチ
    • 聴き方重要
  • 人は変化を好むが、他人に変化させられることを好まない By Henrik

  • 変化できる状況を作る

  • 現状の問題を共通認識にする

  • 振り返りとメトリクスはセット

    • 振り返りの積み重ね
  • 振り返りの積み重ね

    • 1発で今の形になったわけではない
    • Perfect を狙うのではなく、BetterをBestにしていく

<自分を振り返ると>

  • メトリクスをしていない

    • リリース成功率
    • リリース所要時間
    • チケット消化率 etc
    • 効果の程が実感できない
  • でも、ちゃんと?頑張って計測する必要はないと思っていて

    • 一人一人が変化できていることを実感できていれば、いいかなと思っていて
    • でも、そのためにはメトリクスが手っ取り早いのかなとも思う

2013考トラック:志田裕樹選手

  • ユーザーインタビューから価値をマップ化して、仮説検証っていうプロセスは使えそう
  • ただ、ヒアリング結果が残酷だと心が折れそう

2013守トラック:坂部 選手

  • そもそものアンチパターンは組織チームとしてのリスクを持っている状態や主観文化が引き起こす
    • 仲間を作るためにベクトルをあわせる ← コレむずいかも。。
      • お互いに共通の問いを持つことが重要
    • 自分のメディア力の認識
      • 何を言うかより誰が言うかが大事
      • 印象 or 信頼が変わる
      • メディア力をあげるには調べたことを見えるか、報告や共有の場で広がりを持たせる
    • 企業TCP/IP が存在する ← SIer の人は「確かに!!」って思うかも。自分も共感
      • 企業をTCP/IPに落とし込む考えは面白かった

2013団トラック:すぎいまさかつ 選手

  • 大きな会社にありがちな、育たない人・チームは共感
  • アジャイル大好き
    • Fearless Change をベースに実践
      • 組織を変化に導くパターン集
    • 根回し大事

2014創トラック:秋葉ちひろ 選手

  • デザイナーの関わり方
    • 仕様が固まってから入る
      • なぜコレを使うのかという理由やバックグランドの説明は必要
      • ある程度、仕様に満足がいけば、UIに集中できる
    • 仕様を一緒に決める場合
      • サービス企画をやりたい人は入ればいい
      • 価値検証のためのデザインで仕様を固めていく
      • 価値がわかったらガチデザインに入り、演出も考える
  • ガチデザインは最後までとっておく
    • どこでデザインをはめ込むか
  • 価値検証のためのデザイン力
    • 最低限の価値がわかるもの
    • 最低限のテイストがわかるもの
    • それを素早く実装
  • 必要に応じて、必要な段階でデザイナーは入ればいい
  • 価値検証のためのデザイン力は必要

飛び込み:Can We Change The World

  • 勢い大事

2014守トラック:ふじもと 選手

  • 入門Chef solo が Infrastructure as as code を意識するきっかけとなった

    • GitHub 実践入門
    • Chef 実践入門
    • チーム開発 実践入門
  • 経験した現場

    • 2004 大学内ネットワーク 教育システム 
    • 2008 ベンチャー社内インフラ
    • 2013 官公庁のインフラ更改案件
    • 2014 輸送システムの開発運用インフラ
      • GitHub利用者0人。バージョン管理のできない世界に絶望。
  • インフラ構築手順書がなく、作業スキルが属人化
  • 人海戦術で、構築も試験も月数sむ
  • root権限を持った紙がたくさん
  • Infrastructure as as codeに見る本質
  • DevOpsが協力した継続的デリバリー
  • 職人芸エンジニアによるインフラ構築からの脱却
  • 共有したCodeが正しく動作することを試験するCodeを書く
  • 継続的に試験実施

  • Codeを書くと

    • 暗黙知形式知
    • 形式値のバージョン管理
    • 人が操作する回数を軽減 ⇒ 属人化の排除
    • 人に依存すると危うい
  • 空気を変える

    • 空気で人を動かす
    • 大好きなことをやって生きよう

2014心トラック:江森真由美(emorima) 選手

  • 最初
    • RubyRails をいじっててもぼっち
    • ずっと一人でコーディング
  • 2010年、Asakusa.rb にJoin
    • 最初はぼっちだったけど、続けた(ぼっちはなれてた)
      • コレ(継続)が大事なのかも知れないと個人的に感じた
    • 同じRubyを使っている人の話を聞くだけでも楽しかった
    • Ruby のコミュニティを通じて世界が変わった I can change the world
  • Tokyu.rbの帰り道にRails Girls 誕生のきっかけ
    • Join ⇒ Organize
    • かつての自分をひとりでも少なくする
    • 新しいことを学んでいる時、人は輝いている
  • コミュニティの関わり方
    • 参加:Join
    • 手伝う:Help
    • 誘う:invite
  • スキル向上だけでなく、かつての自分、未来の自分のためになる
  • 近くの人の助けになりうる

2014技トラック:増田亨 選手

  • ドメイン駆動設計をがんばるとソフトウェアの変更コストが劇的に下がる
  • ソフトウェアの変更コストが下がると、成長の可能性が広がる
  • モデル駆動で単純化する
  • 単純化しても1回でうまくいくことはない
  • 改善を繰り返す
  • 単純化 ⇒ 模型を作る ⇒ コードを書く をサイクルでまわす
  • 3層+ドメインモデルがターニングポイントになった
  • MVC アーキテクチャーのあるある問題は、すごいよくわかる。

2014隊トラック:西 秀和 選手

  • IT人材白書より統計情報を調査。
    • 日本のエンジニアは約110万人。
    • プロジェクトマネージャーは約15%。
    • 開発者5人に対してプロマネが2人??
    • IT人材が足りていないと82%の企業が回答
      • そして足りない職種はプロマネ。まだ、増やしたいのか??
    • 経営層はプロマネをほしがり、現場はエンジニアをほしがる
    • 加えて、経営層は現場のエンジニアを信用していない
  • 実は現場のエンジニアはすごいんだぞ話
  • とあるプロジェクトが。。。
    • 部門が自分たちの責任範囲内でのみ仕事をしていた
    • 全体を把握する人がいない
    • プロマネが減り、エンジニアが増えた
    • 現場のエンジニアだけで何をするか話した
    • 全員で同じゴールを共有
    • 自発的に最前の行動をとった
  • Why ⇒ How ⇒ What を考える
    • 現場のエンジニアにWhat を与えると動けなくなる
    • 現場を変える可能性を一番持っているのは現場のエンジニア
      • 特別な権利
        • 案件の選択
        • リリース判断
        • チーム編成

おまけ

  1. 参加者同士の交流タイム的なイベントで、ぼっちになっていたら、流れでegapool (@egapool) | Twitterさんと話す機会があって、色々話を聴いてたら、どうやらSeleniumをやってらしゃるという。この前のSeleniumユーザーコミュニティ勉強会にも参加していたとか。「自分も行きました〜」的な話で盛り上がりました。
    その時の参加レポートはこちら
    世界は狭い。。

  2. 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テスト@サイボウズ(仮)

パフォーマンスについて3点

  • 実行時間
  • 安定性
  • メンテナンス性

Jenkins + Pipeline Plugin
Git のメインブランチにマージされるたびにテスト実行は、これからやりたい。

【実行時間】

  • 余計なテストは作らない
    • メインシナリオのテストぐらいが無難
  • 並列実行
    • 個々のテストの時間短縮よりも効果的

並列化はリソースとの戦い

【安定性】

  • リトライ設定 ⇒ サイボウズは3回
  • 明示的なWait
    • sleep より Explicit wait の方がいいとか 

【メンテナンス性】

  • PageObject は必須 ⇒ 納得

【松尾和昭さん(@Kazu_cocoa)】クックパッドアプリの開発を支援するAppiumの話

OS バージョンアップを老い続けていくのが大変そう。 だけど、アプリのテストも自動化させたい、今日この頃

これベースでいじってみるかな。

所感というか雑記

  • 雰囲気が暖かい。
    • 拍手や笑い声が所々あり、参加していて非常に楽しかったです。
  • テッキーな本が多そう
  • Selenium Webdriver in Python
  • Selenium Webdriver in Ruby
    • 表紙の差に笑えましたww
    • ほぼ同じ内容でサンプルコードが違うだけってww
  • 後ろの会議室でなにかイベント的なやつをやってて、若干ノイズになってたww
  • 第3回あたりで自動テストの導入事例について、話せれば嬉しい。

DevLOVE現場甲子園2014 東日本大会 行ってきた

DevLOVE現場甲子園2014 東日本大会が終わった勢いに身を任せて、ブログを綴る。

背景

1週間ぐらい前に 発表者の kentana20さんから連絡がきてスタッフとして急遽参加が決定。。 初めてのセミナー?なるものに参加することになった。

ちなみに kentana20さんのスライドはこちら

所感〜その1〜

打ちのめされた。。発表している人たちみんなすごい。自分よりも若いであろうエンジニアが雄弁に話す姿をみて、「見てるだけの俺ってなんなん?」って感じざるを得なかった。 悲観している訳ではないです。世界が広がって、楽しかったし、むしろモチベーション上がったし。 何より、見ていて勉強になったし、楽しかった。 スタッフ的な仕事はあまりしていないが(ごめんなさい)、行ってよかったなと思ってます。

刺さったプレゼン

気になったものをいくつか紹介。

あてはまる部分がある気がする。

直接聞いてはいないけど、スライドが気になった。人生相談したいなぁ。。

コレ実践したい!!たしかに観点を明確にしないで、漠然とレビューをお願いしていた部分があった。

小さく失敗、小さく学ぶことは スクラム や LEAN に限らない話なのかなと個人的には感じる。

まさかの飛び入り参加が藤吾郎さん。Webアプリの開発とネイティブアプリの開発は別物だし、自動化の難しさや属人化、社内受託体制になりがちの部分はすんごい共感できました。事実、そうなっている感がある。

所感〜その2〜

「小さい」とか「短い」というのがキーワードになっている気がした。 西見さんのコードレビューで「小さい単位でレビューを繰り返す」とか 松浦さんのアジャイル開発現場で「短いカイゼンのフィードバックサイクルをまわす」っていうところが気になった。

所感〜その3〜

世界が一気に広がった。貪欲に吸収して、アウトプットだして行ければ、自分もDevLOVE現場甲子園球児になれる・・・はず。。

あぁ、とりあえずRailsでもやるかな。

おまけ

kentana20さんプレゼン前の一枚。 コレ以外、まともな写真を撮っていなかったことに、激しい後悔に苛まれる。。 f:id:RealFightProgrammer:20140823234130j:plain

RSpecによるユニットテスト~セットアップ~

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 

f:id:RealFightProgrammer:20140803224148p:plain

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

できたからよしとするす。

初期設定だけで、色々つまづいたお。

長くなってきたから、モデル・コントローラ・ビュー・ヘルパーごとのテストに関しては追々書きます。

パスの設定とか色々とすっ飛ばしているのがちょっと不安や。