VOYAGE GROUP　エンジニアブログ

こんにちは。システム本部　三浦@hironomiuです。

今年も11/9,10,11/16,17でVOYAGE GROUPの冬のエンジニアインターンSunrise2013が行われました。

本エントリーは週末4日間と言う短い期間で全力で学びそして全力でアウトプットしたSunriseの様子をお伝えしたいと思います。

なお、VOYAGE GROUPではエンジニア職の新卒採用を行っております。
本エントリーを見てVOYAGE GROUPのエンジニア職に興味を持って頂けましたら、「古より伝わりし大陸の秘宝」という面白いグループワークも行っておりますので、ぜひご応募ください！！
また、通年で募集している就業型実践インターンGuildもありますので、そちらへのご応募もお待ちしています！！

Sunrise生集合写真


Sunriseは「100万人が使うWebサービスを創造せよ」を趣旨に学ぶインターンです。
そのため個々の細かい技術に対してはあまり深掘りせずサービスを構築、運営していく上で
強く必要となるであろう勘所や考え方を中心に講義は進みます。講義は座学、ワークショップの両方を行います。
又、全てチーム単位で章毎に学んだ事や疑問に思ったことを発表する形で進みます。

スケジュール

月日（曜日）	講義
11/9（土）	ネットワーク サーバヘルスチェック 事例紹介（広告配信システム）
11/10（日）	データベースサーバ（運用、拡張戦略）
11/11-15	中間課題
11/16（土）	最終課題
11/17（日）	最終課題、発表

初日（11/9）
ネットワーク構成（総評解説　小賀さん@makoga）
Webサービスはインターネット上で展開されるものであるためネットワークに対する知識は必須と言う観点から事前課題でネットワークに対する調査課題が出されます。その課題についてチーム毎に発表を行いました。

発表を行う一枚


サーバヘルスチェック（講師　三浦@hironomiu）
サーバの稼働状況を把握し将来予測を行うことはサービスを拡張する上で重要だと言う観点から
実際のサーバに対して負荷を掛けサーバの稼働状況を様々な観点（コマンド）から計測し考察を行いました。
講義は4章構成で各章毎にチーム単位で考察について発表を行いました。

チームでサーバに負荷を掛け稼働状況から考察を行う一枚


広告配信システム事例紹介（講師 大谷さん@katzchang）
弊社スーパーエンジニア 大谷さん@katzchangより広告配信システムZucks AdNetwork（開発プロジェクト名Zgok）の紹介を行いました。
広告配信システムの説明をしながらZucks AdNetworkを構築していく上で気にかけた事などを織り交ぜた事例紹介でした。

講義中の一枚


番外編　カレー料理対決（運営　人事 長ちゃん）
Sunriseはただ全力で学ぶインターンではありません！！
VOYAGE GROUPは仲間と事を成すと言うCREEDがあります。
裏ミッションでは仲間と事を成す楽しさを学ぶべく2チームに分かれ美味しいカレーを作る勝負を行いました。
そしてCTO小賀さん@makoga、総合プロデューサー佐々木Hさん、スーパーエンジニア 大谷さん@katzchang の豪華3名が各チームの料理に対してジャッジを行います。

料理風景


ジャッジ中の一枚



二日目（11/10）データベースサーバ運用、拡張戦略（講師　三浦@hironomiu）
大規模Webサービスを運営していく上でデータベースサーバは必ず肝になると言う観点から
データベースサーバの運用の勘所（SPOFの対策、I/O戦略、バックアップリストア、拡張戦略）やVOYAGE GROUPのデータベース事例を座学で行いました。
6章構成で進み各章毎にチームで学び取ったことや疑問点を発表する形で進みました。

座学中の一枚


中間課題
初日のサーバヘルスチェックの講義で用いたサーバ環境を使って平均レスポンスタイムによるパフォーマンスチューニングコンテストを行いました。
上位5位が0.01秒単位での団子状態となる熾烈な争いとなりました。
課題を出した側としても僅差の接戦は嬉しい結果でした。

三日目（11/16）最終課題
最終課題は4チームに分かれ各チームに一人社員がサポータとしてついて課題制作を行います。

チーム　GiantMAK（かずき、まさや、あんなたん、ぶーちゃん、サポータ　三浦@hironomiu）
チーム　Great Shining Dragon だっち（だっち、りゅう、こうき、サポータ　ゆうくん）
チーム　Ogyaaaaaaaaaaa!! （もぐ、West、わっさん、サポータ　のっかさん）
チーム　らすと（おだし、そうくん、琉玖、あきら、サポータ　こてつさん）

CTO小賀さん@makogaより最終課題のお題が発表されます。初日、二日目、中間課題で学んだ内容を用いて提示したお題に対するサービス設計を行います。
今年のお題はSNSサービスでした。そこからサービス概要と共にサービスのアクティブユーザ数（月あたり、日あたり）、
アクセス傾向（書き込み、読み込み）など提示された各種数値を元に
必要となるプロダクト、サーバ台数、ネットワーク構成、月間辺りの費用、データフロー、プラスアルファで
独自のアイディアを盛り込み四日目14:30までにアウトプットし15:00から各チームプレゼン発表することが最終課題となります。
又、費用の算出やH/Wの選定を行う際に同じ目線にするため「さくらクラウド」にて実装する縛りを設けました。

アウトプット風景



四日目（11/17）
最終課題制作、発表
前日から引き続き夜通しで各チームは最終課題のサービス設計を行いました。
各チームさくらクラウドの環境を用いて実機テストによりサーバ台数や費用の算出
実際のサービスのイメージをメンバー間で目線を合わせながらアウトプットしていました。

プレゼン風景




GiantMAK資料抜粋


Great Shining Dragon だっち資料抜粋


Ogyaaaaaaaaaaa!!資料抜粋


らすと資料抜粋


各チームとも特色があり素晴らしい資料とプレゼンになりました。
Sunriseではプレゼン後に順位発表が行われます。短期間でのアウトプットでしたが
各チームのレベルが高く審査は凄く難航しました。

まとめ

初日から最終日まであっという間のインターンでした。
短期間でしたがSunrise生、サポータ含め深く打ち解け全てのメンバーが最終発表に向けてぶれずに進んだ結果ハイレベルな成果につながったと思います。
ここで得た仲間や経験を通じて、これからも「未知」なるサービスを「創造」し続け、価値のある素晴らしいモノ創りに挑戦し続けて欲しいです。

こんにちは。VOYAGE GROUPの駒崎です。

ECナビ のエンジニアをやっています。つい先日入社しました。

試してみること

まず準備

測定結果

	Chrome	Firefox	Safari
HTTP	1.140	2.234	2.928
HTTPS	1.372	6.312	2.618
SPDY	0.4896	7.492	2.908

評価

その他

おわり

こんにちは、RPAの関口です。

最近週に一度、来年の新卒達と一緒にTDDをやりながらワイワイガヤガヤしております。そのなかで「プライベートメソッドのテストはどうすれば良いのか？」 という話題がありました。プライベートメソッドのテストについては
プライベートメソッドのユニットテストは書かないもの？
がよくまとまっていると思います。プライベートメソッドのテスト方法について考える中で「TDDの手順に従えばプライベートメソッドのテストがしたくなることは無い」のではないか？と思うようになりました。

プライベートメソッドはリファクタリングの結果現れる！

数値の配列を渡すと平均を計算して返してくれる機能を持ったクラス、AverageCalculatorを作りたいとします。平均計算の手順をまとめると以下のようになります。

1. 配列の合計値を計算する
2. 合計値を配列の要素数で割って返す

ここで「よし！まずは配列の合計値を計算する機能をつけよう！」と思って次のようなテストを書くと

calcSumメソッドの可視性について

• 途中計算でしか使わない合計値の計算は、プライベートメソッドにしたい
• でもプライベートメソッドだとテストのためにReflectionを使う必要があって面倒

という悩みが発生してしまいます。最初「平均値を返すメソッドを追加」しようと思っていたのに「合計値を返すメソッドを追加」しようとしたためです。平均値計算の手順はあくまで手順、初心に帰って平均値を返すテストを書きましょう。
そして合計値計算のメソッドは分離したいなぁと思ってリファクタリングする際に、calcSumという名のプライベートメソッドが自然と現れます。 このプライベートなcalcSumメソッドのためにテストを追加する必要はありません。中身がどのような実装になっていようと外部から呼び出されるcalcAverageメソッドが期待通りの結果を返してくれれば良いのです。またcalcSumメソッドはパブリックなcalcAverageメソッドを通じてテストされている、とも言えます。
 

パブリックメソッド経由でテストする
多くの場合、そのクラスのパブリックメソッド経由でプライベートメソッドのテストも同時に行えます。テストできているか不安があるならカバレッジを測定しましょう。

プライベートメソッドのユニットテストは書かないもの？より。

もしcalcSumの代わりに大変複雑な処理だった時はどうするの？

そのような場合、いきなりcalcAverage相当のメソッドを作るの事は難しいでしょう。一旦calcSumのメソッドの追加を行う必要が出てくるかと思います。もちろんテスト付きで。 でもそのcalcSumはAverageCalculatorクラスがやるべき事なのでしょうか？実はSumCalculatorという名の新しいクラスを作って、その中にパブリックメソッドとして書くのが正しいのではないでしょうか？

別クラスのパブリックメソッドとする
プライベートなメソッドのテストを書きたいということは、実はテスト対象の責務が多すぎることを示唆している場合があります。テストがどうしても書きたい場合は、その責務はテスト対象のプライベートな振る舞いでは無く、誰かのパブリックな振る舞いなのでしょう。テスト対象のプライベートメソッドを「クラスの抽出」や「メソッドの移動」を使って、テスト対象のコラボレータのパブリックメソッドとして抽出し、普通にパブリックメソッドとしてテストしましょう。

プライベートメソッドのユニットテストは書かないもの？より。

他の方法

ここまで書いておいてなんですが

そんなこんなでプライベートメソッドのテストは必要ない！！・・・のではないかと最近思い始めました。

パターンマッチ

{ x, y } = { 1, 2 }

x #=> 1

y #=> 2

defmodule Fib do

  def fib(0), do: 1

  def fib(1), do: 1

  def fib(n), do: fib(n-1) + fib(n-2)

end

Fib.fib(5) #=> 8

def parse(<< length :: [size(16), big, unsigned, integer],

                     data :: [size(length), binary, unit(8)],

                     rest :: binary >>)

  { data, rest }

end

軽量プロセス

defmodule Parallel do

  def pmap(collection, fun) do

    me = self()

    collection

    |> Enum.map(fn(elem) ->  

         spawn_link(fn -> (me <- { self(), fun.(elem) }) end) 

       end) 

    |> Enum.map(fn(pid) ->

         receive do 

           { ^pid, result } -> result 

         end

       end)

  end

end

Parallel.pmap(1..10000 fn(x) -> x + 1 end)

#=> [2, 3, 4, …]

Enum.map(fn(elem) ->  

  spawn_link(fn -> (me <- { self, fun.(elem) }) end) 

end)

Enum.map(fn(pid) ->

  receive do 

    { ^pid, result } -> result 

  end

end)

マクロ

  assert 2 > 3 

  ** (ExUnit.ExpectationError)

               expected: 2

    to be more than: 3

まとめ