Jenkins 導入事例

Jenkins

John Ferguson Smart

継続的インテグレーションのCIツールの導入で成功している企業は、最初から戦略的に導入を計画していた訳では

なく、実験的な導入からだんだんスケールを大きくして実際のプロジェクトでも利用できるまでにしていったという

事例が多いです。これは、導入を急いだとしても、それを利用する人のスキルが追い付かないことが理由だと思います。

ツールが進化することは良いことですが、使う人の進化も必要なため、共に進化していくことが必要です。

また、実験的な段階ではいくらでも失敗ができるというメリットがあるので、できるだけ本番環境に近い実験環境の

整備は特に必要なことだと思います。

jenkinsはプロジェクト管理のマスターノードのみではなく、それぞれのローカル環境にも配備する必要があると

思います。コミット前にあらかじめCIによるテストの自動実行をしておけば、不要なコミットも減らせるし、

デグレーションも減らせると思います。

リリース以降にも多くの修正を必要とする場合、不具合の早期発見が急務になると思うので、アプリケーションを

自動でテストする環境を作って、コンピュータに常にチェックをさせれるシステムを作る必要があると思います。

機械学習ライブラリ Mahout Hadoop

機械学習におけるHadoopの利用

従来のデータ処理

1. WEBサーバで収集したデータをDBへ集積
2. DBのデータを元に分析サーバ上でプログラムが解析処理
3. 分析結果を保持
4. クライアントへ表示

高速化、機械学習、データ精度を加味した処理

1. WEBサーバで集積したデータをクラウドストレージのKVSへ集積
2. 解析、分析プログラムをHADOOPで分散処理
3. 分析結果をクラウドストレージで保持
4. WEBサーバでクラウドのKVSから結果を取得
5. クライアントへ表示

ビッグデータになった場合、従来のRDBSでは処理完了までの時間が長くかかってしまう。

---

分散処理をしない場合

昨今のCPUの進化により処理速度は速くなっているが、 結局、RDBSのI/Oで時間がかかってしまうため、 従来のRDBSではCPUの処理性能を十分に発揮できない。

HADOOPなら

複数台のマシンに処理を分散させることができるため、 I/Oの時間のボトルネックは解消される。。。とのことだが、 正直どういうことかがまだわからない。。。

機械学習ライブラリ Mahout

課題を解決するプログラムを開発するのではなく、解決するための方法を学習するプログラムを開発する。

機械学習が利用できるケース

• Recomendation
• ニュースのグループ化
• スパムメールの判別

Hadoopとの関連

1. データが多くなると精度が高まる
2. データが多くなると処理速度が遅くなる

新しい案件をスクラッチ開発する機会は減っている。 勝手に生成される機械学習に注目が集まっている。

次なる難問は，すべての商品の組み合わせに対してこうした判断を行う必要があるということです。 商品が1万点あれば，組み合わせは約5,000万通りにもなります。10万点あれば，約50億通り。 一緒に売れたことのある組み合わせのみ考えたとしても，膨大な件数になるでしょう。 サービスとして実現するには，これらを「現実的な時間で計算」できなければなりません。 機械学習はこれらを，具体的には以下のような問題を解決します。

• 一つ一つは人間には簡単。コンピュータには難しい
• 複雑すぎて，隠された規則性を見出せない
• データが多すぎて，処理が終わらない

中でも線形代数（行列）と解析（微積分) は必須です。 数学：物理を学び楽しむために

モデル

機械学習でもっとも重要なことは，「解決したい問題を数値化する方法」です。 これを「モデル」と言います。 「モデル」があって初めてコンピュータが問題を解く（判断する）ことができる状態になります。 そして，問題を解く精度や性能は，この「モデル」の良し悪しで大部分決まってしまいます。

ソーシャルコーディング

ソーシャルコーディングとは

• ソースを誰もが変更する権利を得て、
• 誰もが自由にソースを変更
• これまでのソフトウェア開発と一線を画し、限られた開発者以外でもソースをいじれる
• ソフトウェア開発のスピード感がUPされる
• ソースコード改変の民主化

職業プログラマこそソーシャルコーディングすべき

人材の流動性が高まっているため、職業プログラマがこれまでに作ったものを把握し、 最新情報の取得、多様な文化の取得のためにソーシャルコーディングは注目されている。

採用担当者視点からどちらがほしいプログラマか？ - 今までに書いてきたコードを閲覧できるorできない。 - 最新のソフトウェアに精通しているorしていない。 - 多言語や異なるソフトウェアの多様な文化を理解しているorしていない。 後者にならないために、ソーシャルコーディングは必要。

世界を閉ざさず、多種多様な文化を見る

会社という閉ざされた世界の中でプログラミングをしていたのでは、 いつの間にか扱っている技術が陳腐化していることもありえる。 世界中で使われて、日々変更されるコード、設計、文化に目を向け、 よければ採用する眼力が必要。

コードを書けるプログラマが求められている

• facebookのプロフィールのように自分が書いたソースをポートフォリオとすることができる。
• 自分がどれほどのコードを書いたかを面接時に提出することができる。
• 人間性を見るため意外に、ソースでどのレベルのプログラマかをアピールできる。

GitHubとは

集中型と分散型

Subversion=集中型 M 管理がシンプル D サーバに接続できない状態だと最新ソースコードが取得できない(svnサーバがダウンしたら終わり)

Git=分散型 M 複数リポジトリで管理できることになる D 管理ルールを明確に決めないと、管理が面倒になっていきやすい

※分散型で集中型のような管理もできる。

GitHubのメリット

これまでのGit歩スティングサービスでは、人にフォーカスできなかった。 Git+SNSのようなもので、有名なスーパーハッカーや、 有名企業のPGとも接点を持てる、または、その人の興味に触れることができる。

GitHub機能

• Gitリポジトリ
• organaization(企業用)
• Issue(バグトラッキング機能)
• Wiki
• Pull Request(変更を相手に取り込んでもらう機能)

リーンスタートアップ

1. リーンスタートアップという考え方

   1. リーンスタートアップとは

      自身の体験をもとに成功するサービスを作り上げるためのプロセスをまとめた手法

   2. リーンスタートアップの特徴

      失敗することを前提に、失敗後いかに早く成功に辿り着くかをまとめたもの

   3. リーンスタートアップの実施方法

      1. 仮説の設定
      2. 仮説の検証
      3. 方向転換(ピボット)

2. 共感する点

   1. なぜ共感するか?

      早期のサービス立ち上げは無駄な開発を防ぐために必要である。 誰にも使われないサービスを長時間作り続けることはむなしい。

   2. 同じ問題から発生した考え方

      • ユーザはなかなか集まらない
      • 一度は利用してくれるが2、3度利用したら離脱してしまう。
      • 収益が想定したよりも上がらない。

   3. 共感する事例

      DropBoxで取られた手法 →GoogleAdwordsを展開したが、集まらず →サービスの市場が存在しない時期からの宣伝は無意味との検証を得た →Digg,Redditなどでサービス説明の動画を流した →ユーザー増加

3. 得られたもの(開発に活かせると思った点)

   1. (仮説)価値仮説シートと、成長仮説シート

      [価値仮説シート]

      (ユーザー)＿＿＿は、(欲求)＿＿＿＿たいが、(課題)＿＿＿なので、(製品の特徴)＿＿＿に価値がある。 レシピを探すユーザーは、今日のメニューを早く決めたいが、多くのレシピから決められないので、人気レシピが探せる検索機能に価値がある。

      [成長仮説シート]

      (ユーザー)＿＿＿は、(きっかけ)＿＿＿＿することで、(需要の発生)＿＿＿するようになる。 (ユーザー)レシピを探すユーザーは、毎日のレシピ選び時間が短縮されることで、人気検索を使い続けるようになる。

   2. (検証)実際に開発する前に検証

      アナログなツールによってユーザーの反応を見る

   3. ピボットによる方向転換

      ピボットの方向転換は、検証結果による仮説の再構築です。 これによりユーザーのニーズに対する最適なサービスにたどり着ける。

4. 得られたものを取り入れるための行動改善

   構築、測定、学習を繰り返す。 仮説立案と検証サイクルを明確にし、いかにすばやくそのサイクルを回すか