CtoCサービスの開発の裏側を公開！ プロダクト責任者、CTOが全て語ります！ に参加してきました

こちらのイベントに参加してきました。
CtoCサービスの開発の裏側を公開！ プロダクト責任者、CTOが全て語ります！
http://connpass.com/event/22515/

メルカリ、フンザ、ココナラのCOO、CTOの方々の話を聞いたり、
実際にCtoCのサービスをやってる方々と話す機会を設けていただき、
自分もCtoCのサービスをやってる身としては、有意義な時間を過ごすことができました。

つらつらとメモったことについて、載せていきます。

◯Founderが語る、プロダクトへの想い
・メルカリ
　従業員200名(日米合計)
　半数以上がカスタマーサポート
　エンジニア、デザイナー40名（9割はアメリカ）

ローンチのときのエピソード
　開発6ヶ月
　ios/android両方
　クオリティを下げないように機能を削った
　　検索ができない→想定以上に出品→　SQLのlikeでとりあえず→ちゃんと検索作る
　　振り込み申請できない→　アプリのアップデートでできればよいよね

　CtoCこのモデルは最初きつい、地道にチューニングしていく。一点越えるとわーっと増えていく。

中長期の話、チャレンジしたい話
　アメリカの改修が日本に反映されたり
　メルカリのID使って、メルカリの経済圏でまわしていきたい
　BtoCでもモバイルで新しい体験を作っていきたい

会社のカルチャー
　ウノウ、mixiからの人多め
　go bold

・フンザ
　従業員23名（エンジニア5名）
　mixi子会社
　2015年9月 流通26.5億円

ローンチのときのエピソード
　チケットなので、写真がないので、人気（ひとけ）がない
　KPI2倍ルール→2倍にならないものはやらない
　退会半年間できない

　 　５ヶ月くらいトラフィックの波が来なかった
　　転機　サマーソニックのチケットだけがやたら売買されている　→恩としてサマソニに協賛（1億円）

　CtoCの機能でブーストかかるようなものはない

中長期の話、チャレンジしたい話
　スマホの中には音楽の情報がつまっている
　　itunesとチケットキャンプの情報をマッチングして、プッシュしたりとか。
　　位置情報とマッチングしてプッシュしたりとか。

会社のカルチャー
　少数精鋭、一人当たりの生産性、責任

・ココナラ
　従業員20名
　ユーザー数20万人、取引件数 26000/月

ローンチのときのエピソード
　クローズドベータでローンチ
　　→一回作り直している wantedlyモデルw
　　長い相談してると時給がさがる
　　　文字を制限したら非難轟々
　　　→作り直す
　買い気
　　コミュニテイっぽい雰囲気→買える感なくなる（商品に見えない）→ボタンとかECっぽくしてみる
　プライシング
　　同じ内容でも価格が違うときに適正がわからない
　　わかりやすいようにワンコインで

　　出品者が増えて慣れてきて窮屈になってきた→価格をあげていった

中長期の話、チャレンジしたい話
　プロダクトを作ったときのモデルを見直した。
　モデルに即した形に機能を減らしたり、fine tuningしたりしてる。
　アプリに。

会社のカルチャー
　サービスに共感してるメンバー
　難しいところが好きみたいなメンバー
　サービスを伸ばすんだという気概があるメンバー
　言いたいことを言って、それがすべてサービスのためになる会社


◯CtoCサービスの裏側
・メルカリ
プロダクト立ち上げ時のチーム体制や採用について
　最初は知り合いに声をかけてウノウのつながりやjingaのつながり
　最初のリリース時も20人いないくらい
　知り合いが知り合いを呼んで
　スキルがあるだけではだめで、文化がマッチするかどうかも含めて

利用している技術の選定
　一番自信のあるものにする
　一人で作っていくものではないので、同じレベルで開発できる人が集められる技術を使う
　PHP
　学習コストが低いもの

機能追加や機能改善の判断軸はどこに置いているか？サービス設計の思想などあれば。
　ディレクターとエンジニアが近いところにいる

会社や開発チームをまとめるためにやっていること
　全体に対して何かをやるのではなく、一人一人に対して話すことを増やしている
　10人以下なら意思疎通は簡単だが、どんどん増えてくとこうやったほうがいい

エンジニアのキャリアパスについて
　急激に成長している会社に身を置くのが大事

　どういうエンジニアがいるか
　　平均年齢が高い
　　10年前とかにばりばりネット企業で活躍していた

技術的に苦労した点
　そんなにない
　ゲームの方が書き込みとか多くて難しい
　CtoCは安定的に動かす、そんなに難しくない

どこまでオペレーションで済ませ、どこから自動化するかの判断のポイント
　まず手動でやることを考え、耐えられなくなったら自動化
　最初にめっちゃがんばって自動化作っても、手でやった方が早いってなるともったいない
　デフォルトは人間にがんばってもらう

・フンザ
プロダクト立ち上げ時のチーム体制や採用について
　元同僚とか紹介などつながりで。
　初めて半年で1人、1年で1人増えた
　カルチャーにマッチするかを重視

利用している技術の選定
　python django
　AWS
　MySQL
自信を持って使える技術

機能追加や機能改善の判断軸はどこに置いているか？サービス設計の思想などあれば。
　技術的負債を残さないようにしたい
　　新しく入った人にがっかりさせたくない
　できませんを絶対に言わない

　納得できないことがあったら、とことん話あって、納得して仕事する

会社や開発チームをまとめるためにやっていること
　チームのモチベーションを下げることは、リーダー的な人のダブルスタンダードな振る舞い

エンジニアのキャリアパスについて
　１つの技術を極めるのが大事。自分の拠り所になる技術があるからサービスが作れたと思う
　限界を定めないことが大事。
　webからアプリにの流れは続く
　データ解析とかやれる人とかいい。

技術的に苦労した点
　どうやってユーザーの書き込みなどをエレガントに監視していくか
　　禁止ワードみたいな
　普通の人がどう使っているかみたいなところが難しい

どこまでオペレーションで済ませ、どこから自動化するかの判断のポイント
　手動か自動かだけでなく、手動でやっていることをいかに短くやれるかも考慮
　手動でのエラーレートが高いものは自動化を考える

・ココナラ
プロダクト立ち上げ時のチーム体制や採用について
　基本１人でシステム作ってる
　内製にこだわる
　一部外注したり、知り合いのフリーランスにお願いしたりとか
　ないところから作っていくのを楽しめるメンバーかが重症

利用している技術の選定
PHP CakePHP
MySQL
最初に担当してたエンジニアが一番得意な言語

機能追加や機能改善の判断軸はどこに置いているか？サービス設計の思想などあれば。
　数字を見て根拠を出してやるかを検討する
　やった後にちゃんと数値を見て反省を行う

会社や開発チームをまとめるためにやっていること
　みんなが目指すべき目標を共有していく
　みんなで一緒にランチを食べるとかも意外と重要

エンジニアのキャリアパスについて
　単に人並みにできるってことがいくらあっても市場的にはつらいかな
　長い時間を培った技術などをつけて差別化していかないとつらい
　10年たっても変わらない技術などを身につけていく

技術的に苦労した点
　いかに運用コストをかけないようにまわしていくかとか。
　決済手段を幅広く用意しているが、各社思想が違うのでどうモデルに組み込んでいくかとか。

どこまでオペレーションで済ませ、どこから自動化するかの判断のポイント
　あえて管理ツールでできないようにしてるフローも残してたりする

JAWS-UG Meguro #2に参加してきました

先週の話ですが、JAWS-UG Meguro #2に参加してきました。
http://jawsug-meguro.connpass.com/event/18162/

正直、今の会社ではまだ使わないような技術の話ばっかりだったのですが、
今後のためにとてもためになったと思います。

特にmyfinderさんの「今更聞けないストリーム処理のあれとかこれ」の話は、
これからどう入れていこうかなってステージの自分にはすごくためになりました。
発表の資料は↑のイベントページにアップされているので、そちらを見ていただくのがよいです、
要約すると、stream処理ってものはどういうもので、
それを処理するための基盤と技術の選択肢はこういうのがあるよっていうのを、
パターンを提示してくれている発表でした。
実際にどうやってみるかは結局手を動かしてみないとわかんないと思うので、
まずどういうのを試してみるのがいいかってのが判断できるだけでも、
この発表が自分にとってはすごくためになりました。

Testing Casual Talks #2に参加してきました

Testing Casual Talks #2に参加してきました。
https://atnd.org/events/66159

他の会社やプロジェクトがどういう風にテストやってるのかすごく気になっていたので聞いてきました。
ユニットテストやServerspecでのインフラのテストだけでなく、
E2Eだったり、ミドルウエアの設定についてのテストや、
脆弱性テストまで行うようになっていたりしていて、
どんどんテストが自動化されていっているのだなぁと感じました。
OWASP ZAPやvaddyは試してみたいなと思いました。

発表聞きながらつらつらとメモってたことを載せていきます。


・mruby のテスト方法についての試行錯誤
@hsbtさん
GMOペパボ
http://www.slideshare.net/hsbt/20150525-testing-casualtalks

ミドルウエアに組み込むことができる
ngx_mruby
nginxの中でrubyが動く

nginxだけでも設定できるが、テストができない

Middleware as a Codeといってもいい

モチベーション
productionにngx_mruby使っている
→動いてるコードはテストしたい

ngx_mrubyとして組み込んだ時のnginxの挙動をするダミーをrubyで書いた
ダミーに対して値をセットして、production用コードのテストを行う

rubyのテストはできているけど、mrubyやngx_mrubyのテストはできてないってのがもやもや

mrubyのテストライブラリを探したところ
mruby-mtestがあった。
ngx_mrubyで動かす時にはmruby-mtestは組み込まれない。

今後やりたいこと
mruby-mtestを組み込んだmrubyとngx_mrubyのmrubyは異なるものになるので、そこの差をなくしたい
CIを回したい。環境別のクロスコンパイルをしたい
積極的にテストのあるmrubyのコードにnginx.confを置き換えていきたい


・スクラム開発において、テストメンバー(非開発者)の関わり方を模索してみた
境野高義 (@sakaimo)さん

ガイアックスの伝統サポーターズでの話
https://www.den-suppo.jp/

プロジェクトのチャレンジ
　スクラムのプラクティスを取り入れた開発プロセス（社内で2例目）
QAのチャレンジ
　このプロセスの中にQA(非開発者)が入っていく

狙い１　要件定義の充実
　QAがジョインする
　→仕様の考慮漏れが事前に指摘できた
　→ストーリー間の整合性を事前に取ることができた

狙い２　スプリントごとにテスト
　→スプリント内にテストが収まらなかった

振り返り(KPT)
keep
　要件ヒアリングの際に指摘できる
　まとめてテストよりも細かくテストする方が早く不具合みつけられる
problem
　スプリント内にテストが収まらなかった
　テスト項目の想定が読み切れてなかった
　ストーリー単位ではなく機能単位でのテストになってしまった
try
　テストのやり方、内容を変える
　　より異常系をやる
　ストーリーごとにテストする
　　フィードバックを早くしていく

まとめ
　スプリントごとにテスト→フィードバックができるのはメリット
　POも交えて軌道修正していける（スクラムのメリット）
　作られたものをテストではなく、一緒にサービスを作っていく感じがよかった


・大規模 Web サービスのブラウザテスト自動化・並列化
@deme0607さん
DeNA

mission
　ゲームプラットフォームの品質保証・向上
　開発生産性の向上

ブラウザ自動テストの構築
　selenium webdriver
　rspec/capybara
　jenkins

自動テスト拡充の利点
効率的なリグレッションテスト
　基本的なテストケースは完全自動化
　リリースサイクルの高速化

　自動テストではカバーできないところに工数を集中させられる
　(UI/レイアウト検証とか)

　問題点
　　テスト実行時間の増加

テスト並列化による高速化
　必要なこと
　　並列実行しているテストの処理が互いに衝突しないようにする
　アプローチ
　　サービス実行環境の独立
　　テスト実行ノードごとに専用の環境を用意する
　問題点
　　環境構築コストが大きい
　　環境依存の問題にテストで気づけない

　テスト専用データの作成
　　テストごとに専用のテストデータを作成
　　→仕様変更に追従しづらくメンテナンスコスト高い
　　→実環境のDBをテストから操作するリスク高い

　テストデータを作成できるAPIを提供
　　テストごとにAPIでデータ生成

　　問題点
　　　サービスも同じAPIを利用してデータを作成
　　　サービスの開発工数かかる

　テスト実行時に作成できないデータは事前に準備
　　UI経由でユーザを事前作成
　　　webdriverで自動化
　　　UI経由のデータ作成は実行時間がかかる

　　事前作成データ利用
　　　テストの後処理に注意

並列化したテストの運用・改善
　新たに顕在化した問題
　　テストが不安定
　　テスト失敗に慣れてしまうと、ほんとの不具合に気づかない

　解決策
　　地道にテストを修正していく

　テスト結果の集計APIを作成
　　失敗しやすいテストの分析を行っている
　　突然不安定になったテストケースをslackに通知

　不適切な実行計画
　　マシンリソースがあまらないように
　　過去のテスト結果の集計結果から、実行計画を作成する

今後の課題
　データ作成APIの充実
　分散実行ノードを動的に増やす仕組み
　並列実行計画の改善


・ECサービスの負荷テストの裏側
@kenchanさん
GMOペパボ
　Gatlingのレポートでは不足していたものの拡充
　データの収集と分析の仕組みづくり

　レポートから見えるもの
　　分布を詳しく見たい
　　　実際のばらつき
　　　ノイズがないか
　　時系列のデータが見たい
　　　リクエスト開始時と処理時間の相関
　　　Min,Maxの傾向がないか

　simukation.log(tsv)に生ログあった
　　google docsにインポート
　　1万行くらいならもっさりするけど行ける


・継続的Webセキュリティテスト
@cakephper / @ichikawayさん
http://www.slideshare.net/ichikaway/web-testing-casual-talks2
webセキュリティテスト
　ホワイトボックス
　ブラックボックス

owasp zap

セキュリティテスト現状の問題点
　リリース直前に大量の脆弱性発見

継続的なセキュリティテストが必要

既存のツールを使う場合
　CIに載せるのが大変

vaddy
　saas型
　CI連携を前提
　テストサーバー必要


・casualにインラフテストへ入門した話
yudoufuさん
https://speakerdeck.com/yudoufu/casualniinhuratesutoheru-men-sitahua

テスト導入以前
　すべてchef
　→チェック作業が手作業でつらい

手元でテストしよう
　test-kitchen
　serverspec

テスト環境構築
　両方chefに含まれてる

実行
　.kitchen.ymlを環境にあわせる

自動テスト化して得たもの
　確認作業が軽減された
　グリーン気持ちいい

その後
　面倒な設定変更が舞い込む
　　複雑な設定は動作確認が増える
　　→振る舞いテストやる

infrataster
基本サーバーの外部から使うツールだがtest-kitchen使う方法がissueにあった

振る舞いテストによってえたもの
　挙動のテストが書ける
　デグレを未然に防ぎやすくなった
　グリーンがさらに気持ちよくなった


・カジュアルなテスト&仕様書としてJSON+node requestのご提案
kawamoto.minoruさん
@k12uさん
https://speakerdeck.com/k12u/kaziyuarunatesuto-and-shi-yang-shu-tosite-json-plus-node-requestfalsegoti-an

面倒でもやらなきゃいけない仕事
　仕様書
　フロントエンドとの連携（外部仕様作りながらAPI開発）

JSON APIの応答をチェックする
仕様もJSONで書く
requestとresponseのjsonを用意

タイトルの元ネタ
WebAPIリクエスト仕様書としてcurlコマンドのご提案
http://qiita.com/Hiraku/items/dfda2f8a5353b0742271

JAWS-UG初心者支部【第1回】に参加してきました

JAWS-UG初心者支部【第1回】に参加してきました。
https://jawsug-beginner.doorkeeper.jp/events/22161

AWSの勉強会を探してみてて、できればレベル低めのがいいなと思ってたところ、
今回の勉強会をdoorkeeperで見つけました。
登録したときはキャンセル待ち50人以上だったけど、無事に参加できました。
隣の人と3分間ずつ話すという出会い系ワークショップがあったりしておもしろかったですw
そしてAWSは目的を決めて、あとは自分でやってみてナンボだなと改めて思いました。

今回メモったことをつらつらと載せていきます。


■オープニング＋JAWS-UGの紹介 ：青木 由佳 さん（株式会社パソナテック）@yuka_jyotei
・JAWS-UG = Japan AWS User Group
読み方はじょーずゆーじー

・AWS関連のイベントいっぱいある
JAWS DAYS https://jaws-days.doorkeeper.jp/
JAWS Festa
AWS Summit Tokyo 2015
re:Invent @ラスベガス

■「社内情シス インフラ運用担当のAWS初心者がJAWS-UG初心者支部で言いたい１０のこと（仮）」：伊藤勇気さん（本田技研工業株式会社）@mogutan1978
・初心者がどう思ってるか話してってことで登壇
1.主催者のみなさまありがとう
2.自己紹介
3.今はAWS抜きにはクラウド語れないよねぇ、以外語れない
4.オンプレ依存症が完治していない
5.OSS/各種サービス利用に抵抗を持っていたりする(優しい顔して近づいてくるw)
6.社内IT運用に辟易している
7.でも変えてやりたいと思っている
8.じゃあ何したいわけ　→　VPCをしっかり勉強することがいいのではと考えている
9と10.なかった

■インフラに苦手意識を持つ女子新入社員がAWSに触れてちょっとありかなと思った話(仮)：橋本さん（株式会社内田洋行）
社会人歴:1年1ヶ月
AWS歴:半年

・インフラに配属
インフラのイメージ
　広い知識がないとやっていけなそう
　アプリより地味
　絶対一度は作業中にサーバー壊す

・仕事とAWS
担当クラウドサービスのインフラをAWSに移行

・半年間のAWS勉強内容
とにかくやってみる
気が済むまでやってみる

参考書1冊やってみた
　さわって学ぶクラウドインフラ Amazon Web Services基礎からのネットワーク&サーバー構築
　http://www.amazon.co.jp/dp/4822262960
ネットで公式や先人の知恵を活用する
　クラスメソッド社のブログで内容・手順確認
　自分のAWS環境で実際に検証
　さらに必要であれば公式で確認

・心境の変化
敷居高くない
サーバーだけじゃなくやることたくさんあってむしろ熱い
サーバー使い捨てできて失敗がいくらでもできる環境ってありがたい
椅子に座ってるだけで仕事できる(DCとか行かない的な意味)

■AWS初心者に贈る〜AWS関連コンテンツを使い倒そう〜：ただあゆみさん (くまモン好き) @applebear_ayu
・AWS Samurai 2014受賞

・好きなAWSサービス
EC2(HPCインスタンス)　IAM,AWS Config
AWSの勉強会では自分の好きなAWSサービスを言うのが定番らしい

・新しいことを勉強する上で大切な２つのこと
何のために勉強するのか？本質目標は？
　「AWSを勉強すること」だと行き詰まってしまう
机上で何かをするのではなく、とにかく飛び込む
　現場、現物、現実が大事

・初心者が抑えたいAWSコンテンツ
無料枠の活用
→とにかく自分の手を動かして経験を積む
　1年間の無料枠を有効に使おう
　新しいアカウント作っても古いやつと一括請求すると無料枠剥奪されるので注意
　$25の無料利用クーポンが今ならゲットできる
　http://aws.amazon.com/jp/campaigns/2015console/

セルフペースラボ
　AWSをオンデマンドで実践的に学習できるサービス

AWSの公式Webiner(オンラインセミナー)
　初心者向けオンラインセミナー
　　非エンジニアにもおすすめ
　Black Belt Tech Webiner（旧マイスターシリーズ）
　　経験者・エンジニア向け
　　過去資料もたくさんあるが、サービスの変化が激しいので可能な限り新しいのを探した方が良い

・書籍を活用しよう
Amazonのクラウドエンジニアが選ぶ技術書35選
http://www.amazon.co.jp/b?node=3517238051

・Blogなど優良なサイトの情報を活用しましょう
Google先生に尋ねるときに足したいキーワード
　AWS blog(またはAWS ブログ)
　　AWSの公式ブログ

　AWS blog SA
　　AWS Solution Architectブログ
　　AWS パートナーSAブログ
　　日本オリジナルの記事が数多くある

　Developers.IO(または classmethod)
　　クラスメソッドのブログ

・Qiitaを活用しよう
AWSの場合はサービス名でしかタグをつけていない人もいるので要注意

・資料共有サイトを活用しよう
slideshareとかspeakerdock

・SNSを活用しよう
AWS界隈の人は有用な情報をハッシュタグ #jawsugをつけてよくつぶやく

今すぐフォローすべきAWS界隈の素晴らしきエンジニア達【2014年版】
http://dev.classmethod.jp/cloud/aws/lets-follow-aws-engineers-now-2014/

・JAWSの他支部の勉強会に参加しよう
全国で50くらいある

■re:Inventへ行こう！ ：榎本さん（株式会社エイチ・アイ・エス）
・re:Inventってなに？
世界最大のAWSグローバルカンファレンス
　キーノート
　技術セッション
　ワークショップ

・技術の勉強だけで行くともったいない
スライドや動画はすぐ公開される
センセーショナルな発表は日本メディアでの扱いも大きい
情報のキャッチアップはこれだけで十分

・技術の勉強以外の目的
人との出会い
会場の熱気や雰囲気を感じる

・出会いのキッカケ
会場にいる人はAWSに興味しんしんで、全員仲間ですよ
ツアー参加するとキッカケが多くなる
ぶっちゃけ喫煙者の方が有利

・出会いのキッカケの後
AWSという共通の話題がある
SNSでつながりを作る
仲間になる
re:InventもJAWS-UGも同じ

・re:Inventの2つの参加方法
ツアーで行く
個人で行く

・FAQ
稟議が取れません
→上司説得テンプレートがあります
http://yoshidashingo.hatenablog.com/entry/2014/09/01/191310

嫁の許可が取れません
→一緒に行けばいいじゃん
　セッション中はシルク・ドゥ・ソレイユやブルーマンとか見ていてもらう

■AWS書籍活用術（仮） ：佐々木さん(NRIネットコム)
http://www.slideshare.net/takurosasaki/jawsug-beginnersbook

AWS歴9年
ブログ : http://blog.takuros.net/

・媒体としての書籍の特徴
AWS本各種
　テーマ・読者層を設定し、網羅率が高い
　最初から読むと、ひと通り通りでマスターできるはず
雑誌 WEB+DB PRESSとか
　特定のテーマに特化して、高度な内容も多い
公式サイト
　すべての情報が乗っているが、検索しずらい
Developers.IO
　AWSでググると必ず引っかかる

・AWS本の定番3冊 日経BP社
クラウドデザインパターン　設計ガイド
http://www.amazon.co.jp/dp/4822211967
　クラウド・ネィティブな設計をする際におすすめ
　改訂版がもうすぐ出るので今すぐ買わないほうがよい
クラウドデザインパターン　実装ガイド
http://www.amazon.co.jp/dp/4822211983
　画面キャプチャ付きの操作ガイドもある
基礎からのネットワーク&サーバー構築
http://www.amazon.co.jp/dp/4822262960
　AWSを使ってネットワーク&サーバー構築の勉強
　AWS全体を学ぶには不向き

・情シス向けの2冊
Amazon Web Services入門 企業システムへの導入障壁を徹底解消
http://www.amazon.co.jp/dp/4844336479
　導入時に突っ込まれやすい内容についての解説
情シス・マネジャーのための早わかりAWS入門
http://www.amazon.co.jp/dp/4822275337
　そのままズバリのタイトル

・概要を理解するのに最適な1冊
Amazon Web Services 徹底活用ガイド(日経BPムック)
http://www.amazon.co.jp/dp/482226999X
　AWSの概要説明と導入企業の事例紹介

・一番分厚いAWS本
Amazon Web Services パターン別構築・運用ガイド（著書）
http://www.amazon.co.jp/dp/4797382570

ある程度AWSを理解した上で、
もう一歩レベルが上げられるような内容を目指しています

AWS初心者にAutoScalingについてヒアリングすると
9割　聞いたことがある
8割　使えるようになりたい
1割　使ったことがある
なりたいからあるへのギャップが大きい


・技術書の読み方（自己流）
目標設定が命
　失敗　「AWSを使えるようになりたい」
　→ゴールが不明確で、何を持って目標達成か測定不能
　成功　「負荷に応じて、自動でサーバーが増減するシステムを作りたい」
　→ゴールが明確で達成度がわかりやすい

読み方
　目次を読む
　15-30分くらいかけて、ぱらぱらとめくる
　必要そうなところだけ読む
　手を動かして、実際に試す
　全部読まない

・余談
書籍について
→1ページ書くのに3-4時間

AWS本が少ない理由
→ユーザーが少ない
→書いているうちに内容が変わっていくので大変

執筆すると儲かる？
→割にあわない

本を出版するには？
→ブログ書いてたら出版社から声かかった

amazonレビュー
→書いてください

書評ブログ
→書いてくれたら嬉しい

書いている間にもAWSがどんどん進化する
→本の増刷が決まったが、マネジメントコンソールが日本語化されたのでキャプチャ取り直してるそうです


■「セルフペースラボで気軽に始めるAWS」 ：にへいさちこさん（あそびにん）
あそびにん=特定の職業についていない

・今回の補足資料
http://bit.ly/1Ef7p01

・セルフペースラボ
https://run.qwiklab.com/?locale=ja
演習問題＋演習環境のセットを時間で利用可能
リソース消し忘れの心配不要
16個の無料ラボあり
無料ラボだけならクレカ不要
無料ラボは利用可能時間が短めなので、手順をしっかり読んでから開始したほうがよい

React.js meetup #1に参加してきました

今日はReact.js meetup #1に参加してきました。
http://reactjs-meetup.connpass.com/event/11232/
一人当たりの持ち時間が短くてバタバタしてる感じでしたが、
とても有意義な話が聞けてすごく刺激を受けて帰ってきました。
メモったことや感想をつらつらと載せていきます。


・React 概論 @naoya_itoさん
https://speakerdeck.com/naoya/reactgai-lun
今日発売のWEB+DB PRESSにreact.jsの記事書いたそうです。

PHPフレームワークのXHPの移植として開発されたのがきっかけ
facebookのプロダクションで絶賛使われてるってのがいい

≒サーバーサイド脳で書ける
Viewは常に全更新
Viewは宣言的に定義

従来の手法の難しさ=DOM操作の難しさ
-DOMが状態を持っている
-グローバル　(どこからでも書き換えられる)
-非同期 (外部と通信したりとか)

VirtualDOM
-速度チューニングする余地は残されている
-通常使う時はVirtualDOM気にすることはない

Reactの責務
1 DOMの更新
2 イベントへの反応

サーバーサイド脳でいける
コンポーネント指向(変更がコンポーネントに局所化される)
データフローが明確

生産性より信頼性
-可読性、保守性など長期的な信頼性に重きを置いている
-書く時間より読む時間の方が長いよね

jquery併用できる
-DOM操作はパラダイムが違うのでよくわかんないでやるべきではない
-$ajaxとかは使ってかまわない


・react-rails @hokacchaさん
https://speakerdeck.com/hokaccha/react-rails-1
react-railsはreactjsの公式が作っているgem

mount view helper and UJS
-マウントするコードを書かなくていい
-APIリクエストしない分高速

server side Rendering
-{ prerender: true }をつける
どうやってやっているか
--ExecJSでJSを実行
--therubyracer(V8)推奨

ベンチマーク
-react > haml
-hamlと同等かそれより早いくらい
-死ぬほど遅いわけではなさそうというのがわかるベンチマーク

turbolinks
-普段はまっさきにOFFにするけど、使っても動く

まとめ
-グリングリン動くSPAとかにはたぶん向かない
-部分的に動的コンテンツがあるようなアプリケーションだと使いどころあるかも
-Turbolinksにわんちゃんあるかも


・10分で実装するflux @azuさん
http://azu.github.io/slide/react-meetup/flux.html
#データフローを追っかけていったので、フローがわかりやすかったですが、
#話は難しかったです。。


・mercury/mithril.js @yosuke_furukawaさん
https://speakerdeck.com/yosuke_furukawa/mithril-dot-js
introduction to react=神資料
https://speakerdeck.com/hokaccha/introduction-to-react

react
-shouldComponentUpdate
-子ノードのすべてを再描画しないようにさせる

mithrilのアプローチ
-再描画のタイミングを制御して回数を減らす
-イベントの最後に再描画という形にしなくてよくなる

mercuryのアプローチ
-再描画の回数を減らす
-VDOMのtreeの探索範囲を限定する


・React/SPAの設計と運用 @mizchiさん
https://gist.github.com/mizchi/ee8256f7783dde2bea8d
#実際に開発していってぶちあたった壁とどう乗り越えたかのお話でした


・LT - React.jsと、Railsとかアイドルとか @sugyanさん
http://sugyan.com/presentations/reactjs-meetup-1/#/
@hokacchaさんの話でも出てきたturbolinksではまったのでOFFにしたそうです


・LT - Java+React.jsでServer Side Rendering @makingさん
http://www.slideshare.net/makingx/reactjs-meetupjavassr
javaでも標準でjsのengine使えるよ


・LT - React.js(React Native) + UI Design Prototyping @tsuyoshi higuchiさん
https://speakerdeck.com/tyshgc/rapid-react-prototyping-react-dot-jsdeuidezainpurototaipuwozuo-ru
デザイナーがコンポーネントを意識してデザインを作る
Photoshopのcomponent情報からreactのjsx吐き出すツール作ってた。
#すごい

mixi iOS Training 第8回に参加してきました

mixi iOS Training 第8回に参加してきました。
http://app-training.connpass.com/event/14125/
だいぶ会場に来る人は減ってきた感じがしますが、
その分質問とかしやすそうな雰囲気です、したことないですがw

今回も前回に引き続き、TODOアプリの開発です。
今回はTODOの削除と永続化について学びました。

TODOを削除する
https://github.com/mixi-inc/iOSTraining-TODO-App/issues/3

TODOの永続化
https://github.com/mixi-inc/iOSTraining-TODO-App/issues/4

教材
https://github.com/mixi-inc/iOSTraining-TODO-App

また授業の中でメモったことをつらつらと載せていきます。

・#pragma mark HOGEHOGE
ソースの上にあるパンくずリストにHOGEHOGEが追加されて、選択するとそこに遷移できる

・// TODO: HOGEHOGE
同じくパンくずリストにTODOが追加される(FIXMEでも出る)

・NSArrayをNSMutableArrayに変換するやりかたはいくつかある
NSMutableArray *arr = @[].mutableCopy;
[NSMutableArray arrayWithArray:@[]];

・buildできなくてはまるよくあるパターン
Target Membershipのチェック外れてる

・クラッシュしたときの話
スタックトレースよりもその上のエラーメッセージを読んで解決することが多い

・アプリの状態
Inactive
→アプリを起動してて一番上にいるけど、通知センターを開いている状態
Suspended
→OSがプロセスをkillした

・シミュレータでのHOMEボタンのショートカット
command + shift + h

・plistにセキュリティ的によくないものは保存しない
講師の方曰く、このくらい危険らしいｗ
→UserDefaultsにパスワードを保存しないでください = あなたのamazonのパスワードを手のひらに書かないでください

・ObjectiveCでnilに対してメソッドを実行しても何も起きない（エラーにならない）
javaだとヌルポで落ちるよね


次回はちょっと空いて5/21だそうです。

SmartNews TechNight Vol.2に参加してきました

SmartNews TechNight Vol.2に参加してきました。
https://atnd.org/events/64096

ハッシュタグはこちら
https://twitter.com/hashtag/smarttechnight

聞いてて思ったのは、
大きなサービスもってる大きな会社は大量発注で安くサーバー仕入れるので、
コストという観点からいくとオンプレの方が有利なんだなと。
ただ、どこも便利なものは使っていこうという姿勢だったのでいいですね。

トークセッションはちょっとメモれなかったですが、
その他のプレゼン聞いててメモったことをつらつらと書いていきます。

SmartNews大平さん
・SmartNewsにはインフラ専任がいない
・すべてAWSに乗っている
http://aws.amazon.com/jp/solutions/case-studies/smartnews/
・使ってるSaas
　　Datadog
　　NewRelic
　　pagerduty
　　logentries
　　chartio
・クラウド使うと得意領域は違ってもアプリエンジニアとインフラエンジニアでやることはだいたい同じになってくる

GREE梶原さん
・最近の新規のサービスはAWSで取り組んでる
・クラウドかオンプレかの選定基準（現時点）
　　コスト
　　　大規模調達するとまだまだ物理サーバーが安い
　　　年に数回AWSの値下げが実施されるのでもっと安くなってほしい
　　メンテナンスの自由度
　　　サービスによってメンテナンスの調整コストが高いものがある
・使ってるSass
　　PagerDuty
　　SumoLogic
　　DataDog

CyberAgent桑野さん
・クラウドの時代になってもやることは変わらないけど、やり方が変わってきている
　　コード化するためのツールのコモディティ化
　　そもそも１から自分で構築しない
　　基本的な部品のAPI化
　　スピード感がましている／キャッチアップが大変
・いろんな職種のエンジニアがいるのではなくて、得意な技術領域の異なるエンジニアがいるだけ

mixi iOS Training 第7回に参加してきました

またmixiのiOS Trainingに参加してきました。
http://app-training.connpass.com/event/13617/
今回はTODOアプリの2回目で、新しいTODOを追加できるようにしました。

コードはこちら
https://github.com/mixi-inc/iOSTraining-TODO-App
やることはこちら
https://github.com/mixi-inc/iOSTraining-TODO-App/issues/2
今回のスタートはshow-todoブランチで、今回のゴールはadd-todoブランチ。

講義の最初は最近恒例のまずgitの使い方から。
この中でやってたターミナルからFinder開く方法
open .
これ初めて知りました。

講義を受けながらつらつらとメモったことを載せていきます。
・NavigationController の rootViewControllerはデフォルトで表示するもの

・XCodeのSource Controllからgitのcommitもできる
対象ファイルとdiffが見やすくなっているので便利

・Bar Button ItemはNavigationController管理下じゃないと置けない

・メソッドをこう定義した場合
- (void)doneButtonTapped:(id)sender{
NSLog(@"doneButtonTapped");
}
「doneButtonTapped:」の:までがメソッド名。

・storyboardを開いてDebug View Hierarchyで3Dに表示できる。



前回と違って今回は落ちこぼれなかったので、すごく有意義な時間が過ごせました。
ここでしか触ってないけどさすがに7回もやってると少しずつ慣れてきてるのかなぁと思ったりしてます。
中級者くらいまではなりたいなと思う今日この頃です。

mixi iOS Training 第6回に参加してきました

先週の話ですが、mixiのiOS Training 第6回に参加してきました。
これまでとは形式が変わって、TODOアプリを作りながら必要なものを学んでいく形になりました。
http://app-training.connpass.com/event/13059/

教材はこれで、
https://github.com/mixi-inc/iOSTraining-TODO-App
テキストはこれでした。
uitableview

今回はTODOリストを一覧表示するだけの機能だったのですが、
最初の課題のところではまってしまい、あまりメモが取れませんでした。
原因は結局コピペしたところが間違ってたわけですが、
言語の理解が浅いから気づかないのでだめなんだなと反省しています。。。


そんな中メモった内容を載せておきます。
・ショートカット
行を選択してCommand + / でコメントアウト
・pixel指定の話
pixelが少数になった場合は切り捨てられる
・UITableViewのSeparatorは1pxですよ
ここに詳しく載ってます
http://335g.hatenablog.jp/entry/2013/12/25/135219

mixi iOS Training第5回に参加してきました

またmixiで開催されたiOS Trainingの勉強会に行ってきました。
http://app-training.connpass.com/event/12473/

最初のゲストインタビューはトレタの@y_kohさんで、
トレタのサービス紹介と開発手法についての発表でした。
トレタではクラッシュレポートにHockeyAppを使ってるそうです。
詳しくはここにあるそうです。
http://qiita.com/y_koh/items/81d8648914a893ec2d16

授業でメモったことをつらつらと書いていきます。

3.3 UIView Animation
https://github.com/mixi-inc/iOSTraining/wiki/3.3-UIView-Animation

・アニメーション止めたりとかはbegin/commitで実装

・xibはpropertyでIBOutletとして読み込ませる


Auto Layout入門
https://github.com/mixi-inc/iOSTraining/wiki/Auto-Layout%E5%85%A5%E9%96%80

・missing constraintsは今の状態で位置と高さと幅が決定できるかどうかで出る。
xcodeが自動で補完する機能あるが、昔は押した結果また出てくるという無限ループに陥ることがあった

・auto layoutはシンプルにしたほうがいい
複雑なものを後から見たりすると死にたくなる


Auto Layout ドリル
https://github.com/mixi-inc/iOSTraining/wiki/Auto-Layout-%E3%83%89%E3%83%AA%E3%83%AB

・Update Framesで制約に従った場所にviewが移動してくれる
(ずれてないときは実行できない)

・leading edgesとtrailing edges
文章を書くときに先頭に来る方向がleadingで末尾の方がtrailing
多言語対応のためにright,leftではないらしい


次回からはTODOアプリ作りながら学んでく形式。楽しみだ。

mixi iOS Training第4回に参加してきました

またmixi のiOS Trainingに参加してきました。
http://app-training.connpass.com/event/12019/

まず前座でCocoaPodsの紹介がありました。
http://cocoapods.org/
rubyのgemみたいなものだそうです。
プロジェクトを開くときには.xcode.xcodeprojじゃなくて.xcode.xcworkspaceを使う。

今回はUITabControllerとUIViewでした。
またメモったことをつらつらと載せます。

https://github.com/mixi-inc/iOSTraining/wiki/2.2-UITabController

・UITabControllerをてっとり早く試すなら新規でプロジェクト作って実行してみるとよい。

・タブを増やす
ViewControllerを追加してTab Bar Controllerからsegueをはる。
view controllersを選択。

・根っこのcontrollerをtabbarcontrolllerにすることが多い

・ViewControllerをstoryboardで作らないでコードで作るのは
ViewControllerの数が多くなってstoryboardがごちゃごちゃしてきたようなときとか。


https://github.com/mixi-inc/iOSTraining/wiki/3.1-UIView

・ViewControllerは枠組みであって、目に見えているものはすべてUIView

・ViewCOntrollerは作成時にUIViewを一個もっている
viewというやつ。これを消すとビルドできない
viewの内容は画面サイズに合った真っ白い四角

・UIButton
ボタンの表示内容はsetTitleでセットするのがデフォルト

・UIImageの画像の追加
Images.xcassets開いて、そこに画像をドラッグアンドドロップ
画像の種類
2x retina
3x iphone 6 plus
1x それ以外

・Textview
editableをYESにすると編集可能

・コードでViewを追加するのは出したり消したりってのを細かく制御したいときとか

・マルチサイズのデバイスに対応するにはautoLayoutで設定するので座標位置指定したりとかはあんまりやらない

・Viewのグルーピング（labelとbuttonとimageを一括で操作）をするとき
Viewを一個作ってそれのsubviewに追加するような感じ


そろそろお寿司が出るようです。

mixi iOS Training第3回に参加してきました

またmixiの勉強会に参加してきました。
http://app-training.connpass.com/event/11598/

今回もまずアプリエンジニアの方の話があり、先週のandroid trainingに続いての
drivemodeの@KeithYokomaさんの話でした。
iOSの勉強会でandroidメインの方だったので、少し微妙そうでした。。

また講義の中でメモったことをつらつらと書いていきます。

1.5 UIViewController3 ライフサイクル

・UIViewControllerの生成方法
生成方法はいくつかあるが、どの初期化メソッドで呼ばれてもいいように、
共通化した処理を作っておくのがよい。

・didReceiveMemoryWarningメソッドについて
動画開いたりとか他のアプリでメモリが圧迫されたりとかしたときによばれる。
ここで画像のメモリキャッシュをクリアしたりとかする。
しないでほっとくとOS側にプロセスがkillされる。
ちなみにiOS Simulatorのメニューの
Hardware - Simulate Memory Warning
から発生させることが可能。

2.1-UINavigationController

・ツールバーとタブバーは似てるけど別物ですよ。

・UIBarButtonItemのstyleはplainを指定するか、ゴリゴリに実装するかが多い

・@selector
メソッド名を関数にしてくれるような何かと思ってて。



会も3回目になったので、だんだんとあ〜こういう動きするアプリあるなぁみたいなことを思ったりしてます。
このまま続けていったら楽しい気がしてます。
あと、最近mixiの勉強会参加してきたのブログばっかりなので、次は違うこと書きたいと思います。

mixi iOS Training第2回に参加してきました

前回の第1回に引き続き、mixiで開催されたiOS Trainingの第2回に参加してきました。
第1回の時のメモはこちら

最初にまず5分程、hentekoさんからdeploygateの話がありました。
ちなみにhentekoさんがobjective-c最初に勉強した時ははてなのドキュメントだったそうです。

で、講義に入ったわけですが、今回も講師の方の説明を受けて、
そのあとに自分で実習するという形式でした。

まず最初にこちらの説明がありました。
https://github.com/mixi-inc/iOSTraining/wiki/1.3-UIViewController1---UIViewController-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA(storyboard)
UIViewControllerをstoryboardを使って作成していきました。

以下、講義中にメモったものです。
・新しいファイルを作るときにはCocoa Touch classを選ぶとmとhを両方作ってくれる
・storyboardにラベルなどが配置できないときはstoryboardの方をダブルクリックして大きくすると配置できる
・起動時に表示される画面はLaunchScrean.xibで設定できる。昔は画像でやってた(xibでやれるのはxcode6から)
・storyobjectでひも付けたobjectを削除したいときはstoryboardから×で削除する必要あり。
　ソースコードでプロパティ消すだけだと実行時にクラッシュするらしい
・ボタンタップした時のアクションは、5年くらいやってるけどtouch up inside これ一択らしい
・カーソルあわせてcommand+clickでソース見れる
・ソースのところで指2本で左右にフリックすると前後に開いてたファイルが開ける

次にこちらの説明がありました。
https://github.com/mixi-inc/iOSTraining/wiki/1.4-UIViewController2-ModalViewController-(storyboard)

以下、講義中にメモったものです。
・モーダルの出し方いくつかあるが、inspectorをいちいち見ないとわからないのでコードでやることが多い
・モーダルを閉じるときは自分で自分をdismissしないようにする。
・delegateの利用用途は、モーダルで入力した内容を呼び出し元に反映させたりするときとか
・delegateパターンでのモーダルがわのプロパティはweakにしておかないと、めっちゃクラッシュするらしい。


普段の業務でやらない領域なだけに、講師の人がやりながら説明してくれるのを
見ながら勉強できるのはなんかいいなぁと感じています。また次回も参加したいですね。

mixi iOS Training第1回に参加してきました

mixiで開催されたiOS Training第1回に参加してきました。
http://app-training.connpass.com/event/10754/

内容はconnpassに貼ってあるgithubのドキュメントに沿って講師の方に説明をしていただいて、
それから用意してあったプログラムをテストが通るように修正しながら学んでいく実践形式で進められました。

まず最初にあったのはスポンサー？のFind Job!の宣伝でした。
なんか面談に行くとQUOカード5000円分くれる券をもらえました。

講義の中でメモったことを以下に載せていきます。

・iOSについて
https://github.com/mixi-inc/iOSTraining/wiki/0.1-iOSについて
iOSヒューマンインターフェイスガイドライン
はエンジニアに限らず絶対読んでおいてほしいとのこと。

・Xcode最初のステップ
https://github.com/mixi-inc/iOSTraining/wiki/0.2-Xcode最初のステップ

ショートカットをいくつか教わりました。
実行
command + r

シミュレータのwindowサイズ変更
command + 1 or 2 or 3

テスト実行
command + u


・Objective-C入門
https://github.com/mixi-inc/introduction-for-objective-c
https://github.com/mixi-inc/iOSTraining/wiki/1.1-Objective-Cの基礎

print debugのやり方
NSLog(@"here!! %@", obj);
%@のところがobjで置き換えられる

Xcodeの行番号の表示
Xcode - Preferenceから
Text EditingでLine Numbersにチェックを入れる。


参加した感想としては、普段サーバーサイドのプログラムしか書いてない自分には
とてもいい機会がもらえてよかったなぁと思いました。
ただ、ここに参加するだけでは全然書けるようにはならなそうな気もするので、
結局は自主トレ必須ですね。でもやれるだけやりたいと思います。

あと、最後の時間にテスト通るようにしましょうって時間があって、
なんかその時間はちょっとタイムアタックみたいな気分がして楽しかったです。

次回は1/28だそうです。

Travis CI Meetup Tokyoに参加してきました

本日開催されたTravis CI Meetup Tokyoに参加してきました。
Travis CIは名前と概要はなんとなく知ってたのですが、使ったことはなかったです。
今日話を聞いてきた限りはかなり便利でぜひ使いたいなと思いました。
jenkinsでもできそうだけど、実行するたびに毎回vm立ち上げてやってくれるのは
環境の変な影響とか受けなくてよさそうだなと感じました。

以下メモしたやつを載せてます。

・Asariさん
主にTravis入門のデモという感じでした。
デモに使われたリポジトリはこちら
https://github.com/BanzaiMan/travis-intro-tokyo
https://travis-ci.org/BanzaiMan/travis-intro-tokyo

Travisを使う上で、どういう流れで動いているかを理解することは大事。
setup/install/buildに関してはtravisの責任で実行する。
travisでsudo使いたい時はメールしてくれるとよいそうです。

matrix: allow_failures:
に書いた設定は失敗してもよい設定になる。
#今動かしてるバージョンより新しいバージョンでテストするときとか便利そう。

rubyだとrvmのバージョン指定で
rvm - ruby-head
で最新版のテストできる。

servicesでredisやelasticsearchを使うことができる

addonsでpostgresqlのバージョン9.1,9.2,9.3を使うことができる


・Joshさん
当然、英語の発表でした。。

サービスの説明
サーバー台数とか使っているサービス数とか1日のjob数とか
メモりきれませんでした。。。

使われてる言語の割合
オープンソースだとnode.jsが多い
.com(商用？)だとrubyが多い

B.I.W.O.M.M
but it works on my machine!
みんな同じようなこと言っちゃうよね、だからtravis使うといいよ的な話と受け取りました。

みんなmacで開発するけど、本番はmacで動かさないよね？的なことを言ってました

質疑応答で出てきたのが、
travis_waitでタイムアウトを変更できる。ドキュメントにはない、秘密コマンドらしい。


・pinzoloさん
Travis API

株式会社 空
redmineのプラグインを作ってる
redmine本体が壊れてないかテストできるので便利

過去のビルド情報が取得できる

TravisのAPIをたたくためのgemがある
インストールするとtravisコマンドが利用できる

access tokenはtravis tokenで取得できる
プロフィールページのtokenではない

durationはダウンロードや準備の部分の時間も含まれちゃうので、
フェーズごとのdurationが取れるといいなぁってお願いされてた。

プレゼン資料あがってました
https://speakerdeck.com/pinzolo/travis-ci-api-lt


・岸川さん
Automated releasing iOS app with Travis CI

Ubiregi Inc
申請は手作業だけど、それ以外はtravisでやってる
TestFlightとかxcodebuildでやってる
申請するためのビルドをそのまま使って配布用に使えるようにしている

プレゼン資料あがってました
https://speakerdeck.com/kishikawakatsumi/automated-releasing-ios-app-with-travis-ci


・shigemk2さん
QUnit on Travis CI

自作JSライブラリをQUnitでテストしつつ継続的インテグレーションしてみた
ハンドルネームのmk2はマーク2。ガンダムではなくエルガイムらしい

リポジトリ
https://github.com/shigemk2/regexp-js

ブログあがってました
http://shigemk2.hatenablog.com/entry/2014/09/17/QUnit_on_Travis_CI%E3%81%A8%E3%81%84%E3%81%86%E5%90%8D%E5%89%8D%E3%81%A7LT%E3%82%92%E3%82%84%E3%81%A3%E3%81%9F_%23travisci_jp


・sanematさん
When was the build passing?

githubのreadmeにはってあるbuild passingがいつのやつかぱっとわからない
自分のプルリクで壊したのじゃないのに、failureになっちゃうのとか嫌だよね

http://tachikoma.io/
使うといいよ
定期的にpull requestを送ってくれて、
いつからビルドがこけてるかがわかるようになる

bundle updateしたものをプルリク投げてくれるらしい

travis ciがやれることはtravis ciに任せる

プレゼン資料あがってました
http://sanemat.github.io/talks/20140917-travis-ci-meetup-tachikoma-io/


・yandoさん
Testing your App with Selenium on Travis CI

PHP NZでやってきた話をかいつまんで。
PHP CONFERENCE2014の宣伝あり

僕らの共通言語はtravis.yml
travis.ymlで動くjenkinsのプラグイン作った人がいるらしい
#これかなぁhttps://wiki.jenkins-ci.org/display/JENKINS/Travis+YML+Plugin

seleniumはtravisでやりやすい
travisのvmにはfirefoxとX入ってるしjavaも入ってる
wgetでselenium-server落として来て起動するだけ

プレゼン資料あがってました
https://speakerdeck.com/yandod/testing-your-app-with-selenium-on-travis-ci-1



あ、ステッカーもらいそこねました。。。

JJUG ナイトセミナー 「6.11 ドメイン駆動設計特集！ 」の勉強会に行ってきました

勉強会に行くのは数年ぶりだったのですが、
久々なので実装メインよりは設計とか思想メイン的な勉強会をってことで、
JJUG ナイトセミナー 「6.11 ドメイン駆動設計特集！ 」@グリーに行ってきました。
詳しいことはもうブログ書かれてる方がいたので、そちらを見ていただいた方がよさそうです。
よしだのブログ(http://blog.yoslab.com/entry/2014/06/11/201103)

1.コードに語らせるために
和智 右桂氏 (グロースエクスパートナーズ株式会社)

DDDとはDomain Driven Designのこと。
Domain=業務と考えてよい。
ユビキタス言語とは図やドキュメント、会話の中で同一の言語を用いること。
チーム内のすべてのコミュニケーションとコードにおいて、言語を厳格に用いるのが大事。
会話ではお客さん、設計書では顧客、コードでは客、みたいな別々の言葉にするのではなく、統一するのがよい。
「エリック・エヴァンスのドメイン駆動設計」をまだ読んでない方は、
第一部と第三部を先に読むのがよいそうです。
第二部は具体的すぎるのでついていけないかもしれないと。


2.DDDで実践する時に役に立つ話し
加藤 潤一氏 (グリー株式会社)

GREEチャット(限定公開)でDDDを実践。
メンバーは8人。
ユビキタス言語と実装をプロトタイプで説明。
DDDを浸透させていくためにほぼ毎日読書会を実施。
言語を合わせていくために議論をかなり重ねたらしい。
大規模サービスでよくやるシャーディングなどとは相性があまりよくない。
テーブル設計はするが、通常のやり方とは視点が違うので、
ドメインモデルをまず決めて、それをテーブルの形式にするにはどうエンコードしたらよいかを考えていくような形になる。


個人的に気になったところだけを書き出してみました。
何度も重ねて話されてたのは、関係者の言語を合わせていくことが大事ということでした。
これまでDDDでの開発をやったことはないし、
実は「エリック・エヴァンスのドメイン駆動設計」読んだことがないので、
今度読んでみようと思います。
久々の勉強会としてはかなり有意義な時間が過ごせたかなと。