「Azure Virtual MachineでVisual Studio & JenkinsなCI環境を構築する（１） ～ インストール編」でAzure Virtual Machineを使ったJenkinsサーバの構築を行いました。今回はそれに続いてJenkinsからgithubのプライベートリポジトリからソースコードを取得してビルドする方法を紹介します。
2013年2月20日
2013年2月19日
Azure Virtual MachineでVisual Studio & JenkinsなCI環境を構築する（１） ～ Jenkinsのインストール
Azure Virtual Machine上にVisual StudioとJenkinsサーバを使ったCI環境を構築してみました。今回はそのVS&JenkinsなCI環境の構築手順を紹介します。
2013年2月18日
Windows Azure Tableの検索パフォーマンス
大分昔（2011年の年末あたり）にAzure Tableへのクエリパターン別の検索パフォーマンスを測って記事を書いていたのですが、公開してませんでした（忘れてた。。。）。
その後いわゆるGen 2のストレージが現れたりしているので、絶対値的には参考にならないと思います。ただ、クエリエンジンがより最適化されるようになったとかっていう話は聞かないので、各クエリ別の相対的な評価としては通用するかと思います。
このまま公開しないのももったいないので、以下最初に書いた時のままですが公開したいと思います。
Windows Azure Tableを使うにあたって、どんなクエリだとどの程度のパフォーマンスが出るのかは気になるところだと思います。昨年末あたりにパフォーマンス計測だけして放っていたので、そろそろ書きます。
ここでは単一パーティションでのクエリ性能を調べるため、単一パーティション内における「RowKeyによる検索とプロパティによる検索」と、「レンジ検索とOR検索」でそれぞれパフォーマンス差がどの程度あるかという点をベンチマークします。そこでベンチマーク対象のクエリは以下の6種類です。
- RowKeyの完全一致
- RowKeyのレンジ検索
- RowKeyのOR検索
- プロパティの完全一致
- プロパティのレンジ検索
- プロパティのOR検索
2013年2月15日
デブサミ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の紹介
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
バーコードリーダ ー＞キーボードとして認識される
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アプリとネイティブの違い
通信タイミング
＝＝＝メモ＝＝＝
サーバサイド
Webアプリとネイティブの違い
通信タイミング
ウェブは画面ベース
ネイティブはフローベース、必要なタイミングで行われる
表示データ(アセット)のありか
表示データ(アセット)のありか
ネイティブだとローカルにキャッシュできる
通信タイミングを考える
都度通信
非同期通信
更新タイミングで適宜通信
通信していない時のログ
クライアントで集めて、適宜サーバへ送信する必要あり
データ管理
更新頻度が低い
通信タイミングを考える
都度通信
非同期通信
更新タイミングで適宜通信
通信していない時のログ
クライアントで集めて、適宜サーバへ送信する必要あり
データ管理
更新頻度が低い
キャッシュ
更新頻度が高い
更新頻度が高い
適宜通信
マスタデータの同期
最初に全部
更新分はテーブル単位でハッシュ値比較して、更新分だけ同期
マスタデータの同期
最初に全部
更新分はテーブル単位でハッシュ値比較して、更新分だけ同期
アセットの同期
最初は全部（容量はコントロールすべき、全部やったら大きすぎるなど
更新分はアセットひとつ単位で同期
アセット管理のテーブルをマスタ上に持ってる雰囲気
APIの構成
JSONフォーマットでデータをやり取り
クライアントとの擦り合わせが重要
Webと同じ技術
最初は全部（容量はコントロールすべき、全部やったら大きすぎるなど
更新分はアセットひとつ単位で同期
アセット管理のテーブルをマスタ上に持ってる雰囲気
APIの構成
JSONフォーマットでデータをやり取り
クライアントとの擦り合わせが重要
Webと同じ技術
Php,MySQL,flare,memcached
通信タイミングの設計が重要
クライアントサイド
通信と表示で役割分担して開発
使ってる技術
Unity
Gree unity platform
Lightweight swf
ちょっとした工夫
遷移図からコードを自動生成
考えたこと
共通項は何か？
どこまで自動生成するか？
どれくらいなら使いやすいか？
Yamlで遷移を記述
Graphvizで図式化
rubyのコンバータ(独自)でC#のコード生成
良かったこと
通信タイミングの設計が重要
クライアントサイド
通信と表示で役割分担して開発
使ってる技術
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++で仕様を記述
仕様書の暗黙知が列挙できた
デブサミ2013メモ 【14-C-2】決済だけではないペイパル（ペイパルアクセス活用事例）
From Evernote: |
【14-C-2】決済だけではないペイパル（ペイパルアクセス活用事例）Clipped from: http://event.shoeisha.jp/detail/1/session/15/ |
植野稔之 PayPal Pte. Ltd, インテグレーションマネージャー
1985年に富士通に入社し、ワークステーション向けアプリケーション及びマルチメディアアプリケーションの開発に従事。
その後1997年よりシリコンバレーのベンチャー企業数社にてシステム運用やバックエンドシステム開発を経験後、2001年に独立。
独立後は決済システムやWebサーバシステムのコンサルティング、開発を行う。
2010年からはペイパルジャパンのインテグレーションマネージャとして、ペイパルの日本での導入・普及活動中です。
志水信也 PayPal Pte. Ltd, インテグレーションマネージャー
日系電機メーカ米国支社において、ウェブデータベース開発等に携わる。
その後、決済関連ベンチャーにてシステム運用、インフラ構築や新規サービスの企画・開発を行う。
外資系EC関連オンラインサービス会社を経て、2012年よりインテグレーションマネージャとしてペイパルの導入支援を担当。
＝＝＝メモ＝＝＝
決済総額1450億ドル/年
activeaccount1.23億
Ebayの決済は全体の32%
Paypal access
Openidの一種(Oauth 2.0 / opened connect standard 1.0準拠
登録されている住所、電話番号データの信頼性が高い
クレジットカード情報は提供されない
x.com デベロッパーポータル
github.com/paypal/paypal-access
PayPal accessと決済の連携
現状
Paypalaccessとcheckoutの両方でログインが必要
近い将来(数ヶ月後？
Checkoutでのログインをスキップ
PayPal here
ユースケースの動画(コーヒーの移動販売
1 クレジットカード払い
2 事前チェックイン&paypalアカウント決済
Api（2種類）で利用可能
Paypal Here mobile apps API
自前のレジアプリケーション内にPayPal hereのカード決済を組み込める
アプリ間連携を利用
Paypalのモバイルアプリに決済する商品情報を渡す(json形式
まだドキュメント等は公開されてない
Paypal Here API
商品情報の登録とかができるみたい
mobile apps APIよりももっと低レベルなAPIな雰囲気
登録:
投稿 (Atom)