Azure Virtual MachineでVisual Studio & JenkinsなCI環境を構築する（２） ～ Githubプライベートリポジトリからのソース取得

「Azure Virtual MachineでVisual Studio & JenkinsなCI環境を構築する（１） ～ インストール編」でAzure Virtual Machineを使ったJenkinsサーバの構築を行いました。今回はそれに続いてJenkinsからgithubのプライベートリポジトリからソースコードを取得してビルドする方法を紹介します。

Azure Virtual MachineでVisual Studio & JenkinsなCI環境を構築する（１） ～ Jenkinsのインストール

Azure Virtual Machine上にVisual StudioとJenkinsサーバを使ったCI環境を構築してみました。今回はそのVS&JenkinsなCI環境の構築手順を紹介します。

Windows Azure Tableの検索パフォーマンス

大分昔（2011年の年末あたり）にAzure Tableへのクエリパターン別の検索パフォーマンスを測って記事を書いていたのですが、公開してませんでした（忘れてた。。。）。

その後いわゆるGen 2のストレージが現れたりしているので、絶対値的には参考にならないと思います。ただ、クエリエンジンがより最適化されるようになったとかっていう話は聞かないので、各クエリ別の相対的な評価としては通用するかと思います。

このまま公開しないのももったいないので、以下最初に書いた時のままですが公開したいと思います。

---

Windows Azure Tableを使うにあたって、どんなクエリだとどの程度のパフォーマンスが出るのかは気になるところだと思います。昨年末あたりにパフォーマンス計測だけして放っていたので、そろそろ書きます。

ここでは単一パーティションでのクエリ性能を調べるため、単一パーティション内における「RowKeyによる検索とプロパティによる検索」と、「レンジ検索とOR検索」でそれぞれパフォーマンス差がどの程度あるかという点をベンチマークします。そこでベンチマーク対象のクエリは以下の6種類です。

1. RowKeyの完全一致
2. RowKeyのレンジ検索
3. RowKeyのOR検索
4. プロパティの完全一致
5. プロパティのレンジ検索
6. プロパティのOR検索

デブサミ2013メモ 【14-D-6】Yahoo! JAPANの新しいクラウドストレージサービス ～Yahoo! JAPANがRiakを選んだ理由とは？～

From Evernote:

【14-D-6】Yahoo! JAPANの新しいクラウドストレージサービス ～Yahoo! JAPANがRiakを選んだ理由とは？～ Clipped from: http://event.shoeisha.jp/detail/1/session/26/

阪田浩隆　ヤフー株式会社 マーケティングソリューションカンパニー 新規事業本部

2004年ヤフー株式会社入社。

認証システム、社内ツールの開発経験を経て、基盤システム開発リーダーに就任。

主に大規模分散コアシステムの開発・保守・運用に従事。

2009年7月よりオブジェクトストレージ開発を開始し、2011年10月Yahoo!ボックスをリリース。

2012年6月よりクラウド基盤・ビックデータインフラ開発のチーフアーキテクトを担当。

＝＝＝メモ＝＝＝
Yahooを支える技術

96年から分散kvsに取り組んできた（独自開発）
認証、課金、広告、cdn すべての基盤となるコアテクノロジになっている

データレプリケーションにも対応
フロントがdcをまたがる構成とか

独自開発のオブジェクトストレージがある
利用実績
Yahooボックス  数TB/dayでデータ増加
天気災害
ブックストア
ロコプレイス
など


Riakの紹介

Riak        kvsエンジン
Riak eds レプリケーションとか
Riak cs オブジェクトストレージ、データはriak,riak edsに保存

ノードをリング状に並べる
Consistent hashing
CAP定理に従う、1ノード壊れても可用性は失わない

Riak eds インストール
Yumでインストール可
設定変更
自分自身のipを設定
Restで受け付けるipの設定
Earlangの設定
じぶんのip
それからクラスターにjoin

利用する場面
高速なデータアクセスが必要な場合
将来的にデータ件数が増える場合

Riak csインストール
Yumでインストール
同時にstanchonコンポーネントをインストール

Bucketを作ってそこにファイルをいれる感じ s3cmdコマンドを使って操作

オブジェクトストレージ自体をマウントできる

事例
Lohaco アスクル
画像ファイルの配信
450req/s

Riak csを利用したyahooストレージ
2013/4 本番


なぜriakをえらんだか？

S3のapiで使えるものが必要だった
運用コスト削減
既存ノウハウを活かしやすいアーキテクチャ

Riak meetup 3/11

デブサミ2013メモ 【14-C-5】O2Oのデザイン

From Evernote:

【14-C-5】O2Oのデザイン Clipped from: http://event.shoeisha.jp/detail/1/session/18/

河村奨　Librize

＝＝＝メモ＝＝＝
Online to offlineの例
クーポン
ソーシャルで伝えたくなる何か
口コミ
在庫の事前確認
など

Offline to onlineの例
qrコード
シェアしたくなるもの
チェックイン

オンラインとオフラインは不可分に
拡張現実の世界へ

リアルなものにオンラインから付加価値を与えることが重要

バーコードUI
バーコードリーダだけでUIを操作する


Tips
バーコードリーダ ー＞キーボードとして認識される

デブサミ2013メモ 【14-A-4】グリーにおけるスマホアプリ開発～ネイティブ編

From Evernote:

【14-A-4】グリーにおけるスマホアプリ開発～ネイティブ編 Clipped from: http://event.shoeisha.jp/detail/1/session/4/

堀田敏史　グリー株式会社 開発本部 Japan Studio統括部 第1プロダクション部

白倉悠祐　グリー株式会社 開発本部 Japan Studio統括部 第1プロダクション部


＝＝＝メモ＝＝＝
サーバサイド
Webアプリとネイティブの違い

通信タイミング

     ウェブは画面ベース

     ネイティブはフローベース、必要なタイミングで行われる
表示データ(アセット)のありか

     ネイティブだとローカルにキャッシュできる

通信タイミングを考える
都度通信
非同期通信
更新タイミングで適宜通信

通信していない時のログ
クライアントで集めて、適宜サーバへ送信する必要あり

データ管理
更新頻度が低い

     キャッシュ
更新頻度が高い

     適宜通信

マスタデータの同期
最初に全部
更新分はテーブル単位でハッシュ値比較して、更新分だけ同期

アセットの同期
最初は全部（容量はコントロールすべき、全部やったら大きすぎるなど
更新分はアセットひとつ単位で同期
アセット管理のテーブルをマスタ上に持ってる雰囲気

APIの構成
JSONフォーマットでデータをやり取り
クライアントとの擦り合わせが重要
Webと同じ技術

     Php,MySQL,flare,memcached

通信タイミングの設計が重要



クライアントサイド

通信と表示で役割分担して開発

使ってる技術
Unity
Gree unity platform
Lightweight swf


ちょっとした工夫

遷移図からコードを自動生成

考えたこと
共通項は何か？
どこまで自動生成するか？
どれくらいなら使いやすいか？

Yamlで遷移を記述
Graphvizで図式化
rubyのコンバータ(独自)でC#のコード生成

良かったこと

遷移図が整備されているため、新しく入った人にも説明しやすい

　これ見といて、で済む

全体のコードに統一感ができて、読みやすい

デブサミ2013メモ 【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～

From Evernote:

【14-B-3】自動改札機の運賃計算プログラムのデバッグ手法 ～10の40乗のパターンをいかにテストするか～ Clipped from: http://event.shoeisha.jp/detail/1/session/9/

幡山五郎　オムロンソーシアルソリューションズ

社内で運賃計算ソフトウェアの開発部署でプログラムのデバッグを担当していました。現在は、社内開発現場への形式手法導入プロジェクトの主担当をしています。

＝＝＝メモ＝＝＝

運賃計算の膨大なテストケース

乗換

特別料金

割引

など、色々なルールがあって、テストケースがあまりにも複雑

西船橋とか鬼門

過去

積み上げ式で属人性が高い

今（運賃検証システムという名前）

まず全体を定義

電車の乗り降りをパターン化(8種類

すべての駅をあてはめると10^40

それから3段階の絞り込みを行って10^8ぐらいまで減らす

利点

積み上げでは見つからないパターンがみつかる

絞り込みに理由があるので、なぜそのテストを行っていないのかに答えやすい

テストの実施

一回流すのに3週間ぐらいかかる

検証用のソフトウェアを独立で開発して答えを突き合わせる

両方間違っているけど、たまたま一致するケースがある

      別のチーム、別の言語、別のプログラムでやって、同じバグが起きにくいようにする

実機と検証用で制約が違う

処理時間50ms

メモリ20MBなど

検証用は制約が緩いため、原則通りのアルゴリズムで計算できる

     駅の増加などでも変更不要

     実機用アルゴリズムでは対応してないパターンにも対応可

最終的に仕様書の問題が残った

VDM++で仕様を記述

        仕様書の暗黙知が列挙できた