Step-to-Rails-Expert.rbの7・8月開催回の位置付けと9月開催回の企画の概要について
本記事では、次回7/31のStep-to-Rails-Expert.rbと今後の企画についての関連について、募集要項に記載していない内容を補足します。 次回の募集要項はこちらです。
step-to-rails-expert-rb.connpass.com
7・8月開催回の位置付け
9月開催回（9月下旬実施予定）に「TODOアプリを作ってきてレビューしあう」という企画を実施予定です。
少人数の勉強会で気軽にアプリレビューをしてもらうという企画は、中級者から上級者までとても学びが多い企画と考えていますので、今まで本勉強会に参加したことのない方にも参加頂きたいと思っています。しかし、TODOアプリレビュー企画で本勉強会に興味を持って頂いたとしても、初参加で雰囲気も知らない中にアプリを持ち込み、レビューしてもらおうと思える人は多くないと想像します。
そこで、次回7/31と8月開催回についてはTODOアプリレビュー回の導入回（初参加の人が顔を出して様子を把握できる回）とすることに決めました。実際の内容として、まず次回7/31は「レビュー・教育について」というテーマで開催します。指導する側、される側どちらにしても業務で高確率で経験できる話題なので気軽に参加できることと、アプリレビュー回と親和性の高い話題だからです。
そして8月開催回ではもくもく会として開催し、アプリレビュー回のアプリを作成したり、その関連の話題について話すのをメインとする回にする予定です。その時に初参加の方は作業しつつ雰囲気をつかんでもらい、アプリレビュー回にお披露目させるか決めて頂くと良いと思います。
TODOアプリを作ってきてレビューしあう回について
実施方法
開催日までに公開されている仕様のアプリを作成し、当日実際に動かしたりソースを見ながらレビューしあいます。
目的
作ってきた人
- 普段指導されることが多い人向け
- 社外の様々な人からレビューしてもらう機会を得る
- 指導することが多い人向け
- 他の人がレビュー・指摘しているところを見て、注意すべき指摘点や指摘の仕方を学ぶ
- 社外の様々な人のソースをレビューすることによって、「このような考え方（間違い方）をする人がいるのか」という気づきを得る
- 改めて他の人からレビューされることで、自分の設計・実装方法に対する新たな気づきを得る
作ってきていない人
- 普段指導されることが多い人向け
- 他の人が指摘されている点を普段の自分の設計・実装方法に生かすことができる
- 指導することが多い人向け
- 他の人がレビュー・指摘しているところを見て、注意すべき指摘点や指摘の仕方を学ぶ
- 社外の様々な人のソースをレビューすることによって、「このような考え方（間違い方）をする人がいるのか」という気づきを得る
なぜTODOアプリなのか
単純なものとても簡単に作れますが、
など、仕様を増やすとそれに従い難易度が増加するので、様々なレベルの人が楽しめるのでテーマをTODOアプリとしました。
最後に
TODOアプリを作ってきてレビューしあう回に興味を持って頂いた方もそうでない方も、次回7/31（月）は通常通りの議論形式で行うのでぜひご参加ください！
Step-to-Rails-Expert.rb第8回を開催しました
6/26(月)にStep-to-Rails-Expert.rb第8回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介
- スタッフのtwo_sannによるLT
- 議論
- 懇親会
という形で進めました。
会の様子
今回のテーマはエラー通知でした。 最初にスタッフのtwo_sannの各エラー通知サービスの横断的な比較のLTから始まりました。使い始めたら移行することが少ないため色々なエラー通知サービスを使ったことがある人は少なく、料金やプランまで詳細に比較したことがないので非常に参考になりました。各サービス競争が激しいのか変動も多いが似たような価格帯になる、といった考察もなるほどと感じました。
そして、このLTをきっかけに機能やUIの比較の議論も盛り上がりました。結果としてSentry無双だったのが印象に残っています。とはいえ通常必要な機能はだいたいどのサービスにも揃っているようなので、価格帯や使用しているプラットフォームとの相性も加味し選んでいくのが大事だと再認識しました。 「lamdbaでslack通知ってどうやるの？」という疑問や、根本的なログと通知すべきエラーの違いなどの考え方も改めて知ることができ、非常に勉強になった回でした。 LTの資料はこちら（何と1人で2つも用意してくれました！）
lightning_talks/error_monitoring.pdf at master · Step-to-Rails-Expert-rb/lightning_talks · GitHub
lightning_talks/errbit.pdf at master · Step-to-Rails-Expert-rb/lightning_talks · GitHub
詳しい内容は議事メモをご覧ください。
反省点
- 今回はテーマが良かったこともあり、議論も非常に盛り上がって良かった
- 今回AWSでのエラー通知について聞きに来た方がいて、AWSが絡むような議題が挙がっていたのにそちらにあまり時間が割けず申し訳なかった
自己紹介時に聞きたいことを伝えてもらっているので、関連する議題があったらそれを優先的に扱うようにするなど工夫した方が良い。 時間配分を考えるべきだが、どの議題がどのくらい盛り上がるのかはなかなか予想できないので難しい - 自己紹介もPRで送ってもらう
TODO: フォーマットを作る
今後の企画
TODOアプリレビューしあう回
前回の記事でも書いた「TODOアプリを作ってきてレビューしあう回」は9月に開催予定です。 biibiebisuke.hatenablog.com
- rails newするところから参加者にしてもらう
デプロイ先をどうするのか・Dockerを使うのか・Rspecを使うのかなど各自の色が出てその方が面白い。 - 導入回を実施する
色々な人にレビューしてもらいたい・レビューしたいという人は一定数いると想定しているが、参加したことのない人がいきなり本番の回から参加するのは心理的障壁が高そう。そこで次回7月は「レビュー・教育について」というテーマで実施し、その次の8月を「9月にレビューしてもらうアプリを作るための回」として実施することで、9月に参加したい人の心理的障壁を下げる。
Rails Developers Meetupさんと共同の企画
Rails Developers Meetupにて企画中の「Gemを作るハッカソン」の導入回として、本勉強会で「作り方・運用方法を含めGemを作ること」についての回を実施しようと考えています。Gemを作る手順のLTから開始し、その後gemを作る際の知見やはまりどころを議論したいと考えています。 Rails Developers Meetup#2に参加した際に主催者のyhiranoさんとお話させて頂いた縁で、この企画をご提案させて頂いたところ快諾頂きました。誠にありがとうございます。
次回について
次回はレビュー・教育についてというテーマで実施予定です。 教育する際に気をつけているところ、レビューで決まりきった指摘をしないために使うGem、（レビュー・教育される側から）こういう指摘の仕方はNG！など、様々な視点から議論しましょう！普段レビューする人もされる人も楽しんで頂けるテーマとなっております。上述の「TODOアプリレビューしあう回」の導入回としての機能も有していますので、まず本勉強会の様子を知りたいなという方もぜひご参加ください。
AWS Summit 2017 serverless時代のテスト戦略（仮）を聴講したので、そのメモと感想
serverless時代のテスト戦略（仮）を聴講したので、そのメモと感想を書きました。
資料が後日公開されるとのことなので、そのスライドと一緒に読んで頂ければ分かりやすいかと思います。メモなので流れが異なりますがご了承ください。
テーマとしては、テストコードのないlambdaにどう向き合っていくかというお話です。
ハッシュタグは#testlambdaでした。
2017.06.21追記: ご本人から資料・動画公開の旨教えて頂きました。ありがとうございます！
すばらしいエントリをありがとうございます！ この講演ですが、先日講演資料とセッション録画が公開されました。
— Takuto Wada (@t_wada) June 20, 2017
下記リンクの「D4T7-4 Dev Day トラック 1」が当該講演です。
メモ
lambdaのテストに関するベストプラクティスはまだない。
お題はlamdbaの公式チュートリアルにテストをつける == testableなコードに書き換える
チュートリアル: Amazon S3 での AWS Lambda の使用 - AWS Lambda
テストの粒度について、テストサイズという概念を用いて解説されていた
- smallではネットワークアクセスはもちろんデータベースアクセスもしない独立したテスト
- mediumではネットワークはlocalhostのみ許可、外部サービスは利用をおすすめしない
- argeでは全部可。外部サービスも含め全部本番と同じものを使うテスト
という感じ。 t_wadaさんが講演で使用していたリンクは以下のものです。詳しくはリンク先をご覧下さい。
smallのテスト
例外系に対するテスト
mediumのテスト
デプロイなしでローカルでテストするには？ - fake objectを使う。 fake objectとはtest doubleの一種。test doubleには
- Test Stub
- Test Spy
- Mock Object
- Fake Object
- Dummy Object
がある（stub/mockくらいしか知らなかった・・・）。 stub/mockと違い、fakeはテスト用の別実装を誰かが作っている。本番ではoracle databaseを利用するが、ローカルではsqliteやインメモリDBを使うなどもfakeの一種。*1
lambdaに話を戻すと、awsのfake実装であるlocalstackを利用する（atlassianすごい）。 本物とendpointが違うだけ。ライブラリではないので言語依存もない。 github.com
largeのテスト
本番のlambdaのテスト。Lambdaだけでなく、S3も全部本物。 ブランチごとにSAMの定義を行い、複数人でも自動テストを運用可能にする
その他
lambdaの固有のコードは呼び出し部分、S3、エラーリトライだけなので、そこを外に出してあげることで移植性の高いコードができる
運用監視
監視もテストのうち
不具合が出たら、それを再現させるテストコードを書いて、それが落ちることが確認できてから、書く
microservice間連携のテスト（E2Eテスト)
テストサイズの概念で言えば、largeの更に上。
マイクロサービス間のテストの課題として、モックしたリクエストやレスポンスが実際のものと異なるとき、テストは通るが本番で落ちてしまうという問題がある。
これを解決するため、Consumer-Driven Contracts testing*2に則りテストする。
CDC testingを実行するためのpactというGemがある。 github.com
consumer側の想定をファイルを用意し、それをprovider側からその想定があっているかテストをする。このテストをCIで定期的に回すようにする。
感想
とても興味深い内容で非常に面白かったです。知らない概念を知ることができたという点だけでなく、知っているが理解が曖昧だった概念や方法論が自分の中でかなりクリアになりました。 t_wadaさんの講演を聞いたのは初めてでしたが、その分かりやすさにとても驚きました。概念の説明も実例の説明もすごく分かりやすく、一度聞いただけなのにすんなりと頭に入ってきました。 TLにオーラでテストを書かせてこそ本物と流れていましたが、たしかにt_wadaさん見てオーラを近くで感じるだけでテスト書けそうな気がしてきました笑 大変ためになる講演ありがとうございました。
そういえば、今日初めて生twadaさんを見たけど、歩いている時のテスト書けオーラが半端なかった。
— tdual (@tdualdir) 2017年6月2日
オーラだけでテストを書かせてこそ本物（？）
— Takuto Wada (@t_wada) 2017年6月2日
オーラにコードを投げてテスト生成
— azu (@azu_re) June 2, 2017
オーラか…… pic.twitter.com/U2nzS4yMIE
— null (@yuroyoro) June 2, 2017
*1:このようにお話されていたと記憶していますが間違えていたら指摘頂ければ幸いです
*2:以下の２つのリンクが分かりやすいです。
Consumer-Driven Contracts testingを徹底解説！ - Qiita
サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ
AWS Summit 2017「全部教えます！サーバレスアプリのアンチパターンとチューニング」のメモ
AWS Summit 2017にて全部教えます！サーバレスアプリのアンチパターンとチューニングを聴講したのでそのメモです。 かなり詳しい話を聞けて大変参考になりました。 www.awssummit.tokyo
メモ
パフォーマンスをどう上げるか
プログラム側
各言語のベストプラクティス・最適化方法はそのまま当てはまるので、プログラムのパフォーマンスを上げておく
コンピューティングリソース不足
- メモリ設定
- 実際にはリソース全体のパフォーマンスの設定を意味する。
- メモリに比例してcpuのリソースも上がる。
- メモリ設定を上げることで実行時間が減り、パフォーマンスが向上し一方でコストが変わらないこともある。
- 適切なスペックを洗濯することが大事。低スペックからだんだんあげていって、処理時間が変わらなくなるスペックがあるので、そのスペックに決めるのが良い。
コールドスタート
起こる条件
- 利用可能なコンテナがない場合
- そもそも１つもコンテナがない
- 利用可能な数以上に同時に処理すべきリクエストが来た。
- コード・設定の変更をした
- これらの条件にあてはまなければ発生しない。コールドスタートは全体の1%くらい
コールドスタートが許容できないのであればLambdaを使うべきではない
速くするためには
- コンピューティングリソースを上げる
- 言語を変える
javaはコールドスタートが遅い。ウォームスタートの場合、コンパイル言語の方が速い傾向 - VPC接続ははENIの発生を伴うので必要がなければ使わない（VPCアクセスが必要なければ使わない）
これだけでコールドスタート時の10秒程度を削減する可能性 - パッケージサイズを小さくする
コード量の削減、不要な依存関係の削減、最適化ツールを使用するなど
アーキテクチャ
- 同期でinvokeすると同時実行数の制限にひっかかる
- 非同期でinvokeするのがスケーラビリティの観点ではおすすめ
api gatewayと組み合わせる場合、putの場合は直接呼び出すのではなくsqs kinesisに流し、それをイベントソースとして実行するべき。getはキャッシュする。
並列実行できるようにする
アンチパターン
dynamoがおすすめ
ログ
cloudwatchメトリクス、cloudwatchカスタムメトリクス、cloudwatch logsへのログ出力を行う
その他
- 障害を前提に設計する
リトライ、DeadLetterQueueを活用する
その他
スピーカーの西谷さんの著書が発売されているので、こちらを読むとさらに理解が深まりそうです。
実践AWS Lambda ~「サーバレス」を実現する新しいアプリケーションのプラットフォーム~
- 作者: 西谷圭介
- 出版社/メーカー: マイナビ出版
- 発売日: 2017/06/09
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Step-to-Rails-Expert.rb第7回を開催しました
5/22(月)にStep-to-Rails-Expert.rb第7回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介
- 議論
- 懇親会
という形で進めました。
会の様子
本家マストドンcollaboratorの@ykztsさん、pawooの中の人の@alpaca-tcさん、friends.nicoの中の人の@masarakkiさんを筆頭に、プライベートでマストドンを運用している方が多く参加して頂き、ソースレベルの質問から、企業で運用している人たちの悩み事まで色々有益な話が聞けました（議事メモに書いていいのかなみたいな話もありました笑）。懇親会もかなり盛り上がっていて、非常に良かったです。 詳しい内容は議事メモをご覧ください。
反省点
- ファシリテートはかなり反省点あり
7~8人と10人以上はやっぱり違う。今回は初参加の人も多かったので、その点も雰囲気が違った。もう少しうまく進めたい。 - 会の説明や進め方を説明した方が良い
- 議事メモのレイアウトは改良の余地があり
- 議題募集はGithubにてPRで追記してもらうような方が良い？ 今の方式だと誰にも質問できないし書き込みづらい。初見殺し。
個人の課題
今回も実際にマストドンを作っている方々から色々アドバイスを頂いたにもかかわらず、それを復習しきれていないです。ここ数回でも同じような感じで、色々学ばさせて頂いたことを100%飲み込むような時間を取れていないような現状が良くないと感じています。とはいえ、4週間後には次の開催が待っているのでその準備も必要だし、復習&準備が中途半端になっているような現状があります。その他にも、せっかく習慣づいていたOSS活動も最近はあまりやれていない（興味のあるSorceryの開発自体が進んでいないのもあるが）、フロントエンドをしっかりと勉強したいなど、やりたいことが多すぎるので優先順位をしっかりつけ進めていきたいです。
今後の企画
通常の会の方法とは異なる企画を行おうと考えています。 ベースとなるRailsアプリ、追加する仕様を開催側で用意、勉強会当日までに仕様の機能を実装し、当日はそれらのアプリを参加者でレビューしようという企画です。 書いてきてくれた人は会社以外の人にレビューしてもらう機会、そうでない人もレビュー内容を聞ける機会を得られるのでかなり学びのある企画だと思います。 懇親会で神速さんを始めみなさんから色々アドバイスを頂き考えた結果が以下です。
- アプリはTodoアプリ
単純なものは簡単に作れるが、リッチでインタラクティブなviewや、タグ、期限到来の通知、一括削除、todoの終了/削除などの状態管理、間違えて終了してしまったtodoを戻すなど、仕様を増やすとそれに従い難易度が増加するので、様々なレベルの人が楽しめる - 実施回数は数回
仕様を徐々に増やしていくが、最初から全体の仕様をオープンにしない予定。これにより、変更に強いアプリの設計・実装の仕方についても議論できる。実施は隔月かも。 - 課題
2回目以降から参加された方も楽しめる方法や、そもそもアプリ作ってきてくれる人いるかな・・など
色々準備があるので、次々回で実現する目標で動いています。次回実施時もしくは懇親会で企画について相談するかもしれないので、もしご意見ある方で参加されている方は色々リクエストください。こういう企画はよちよちさんが実績&知見があると教えて頂いたので、企画の説明やリポジトリを参考にさせて頂こうかな。
次回について
次回は6/26（月）にエラー通知/モニタリングというテーマで実施予定です。 Airbrakeなどエラーモニタリングツールの使い心地は？どういう方法で通知している？どのような体制でエラーに対応している？などの疑問点や、 オオカミ少年のエラー通知に誰も反応しなくなって問題が起きた・・などのツラミなど、様々な視点から議論しましょう！
「社内横断の技術組織を終わらせました」を読んで思ったこと
を読んで、思ったことがはてぶコメントに書ききれなかったから、ブログで書いた。思ったより長くなった。 割りと思ったことベースでそのまま書いているので駄文です。あと、会社の元記事も合わせて読んでいますが、認識に間違いがあったらすみません。
はじめに
まず最初に、筆者の方には辛い話を共有していただけて本当にありがたいです。色々勉強にになりましたし、今後私にもこのような知見が生きるときがあると思うので、参考にさせて頂きます。 以下に書くことは誰への批判でもありません。客観的に聞いて考えたことです。
思ったこと
複数の事業部が荒く速く進めていることで生じる問題を抑制するために横断的な別の組織が責任を持つようになると、インセンティブが異なる組織になってしまうが、そこに歪みが発生してしまったのだと感じた。事業部は速く進めようとする方にインセンティブ向くけど、横断組織は問題を抑える（極端に言えば0にする）方に向き、異なるインセンティブが生じ断裂を生んでしまう。事業部は速く進めれば勝ちだし、横断組織は問題を起こさなければ勝ちという構図に陥っているように見えた。本当は「なるべく」速く「なるべく」問題を起こさないのが目的なのに。 なので、横断組織はレビューを過度（？）に行い、新技術導入も同類のプロダクトを比較するという慎重な姿勢にならざるを得なかったのではないかと推察している。
新規技術の導入に関して、クリティカルに生じている問題に対しての技術導入は（誰が行っても良いが）横断組織としてでなく事業部としての仕事の成果として計上するような方式で進める方が良かったのではないかと考える。そうすれば、必要以上に慎重になる必要がなく、「とりあえず」今の問題を抑える技術導入ができればOKラインだろうし（横断組織の技術導入はこの成果ではOKラインは出ないでしょ）。逆に、ある程度長期的な新規技術導入なら、しっかり調査&比較して決断し、横断組織の成果とすれば良いと思う。 レビューに関しても、横断組織は推進だけ行い、とりあえず粒度は事業部ごとに自由度を持たせ事業部の責任にした方が良かったのかな。
まとめると、やる内容で責任主体を分けるだけでは不十分で
- インセンティブの向き
- 施策内容の目的（喫緊の問題に対するパッチなのか長期的な根本解決なのか）
- 施策内容の緊急度
あたりで責任の主体を分けるのが良いのかなと思った。
会社名出ている元記事のミッションを見ていると組織は割りと中・長期的な方向性が想定されているのに、実態はそうでなかったりしているので、中・長期的なことをやる組織が必要に追われ喫緊の課題を解決するようなミッションに追われてしまったのが不幸だったのだと思う。 横断組織で喫緊の課題を解決する場合は、もっと厳しいトップダウンではないと難しいのかな・・・
Step-to-Rails-Expert.rb第6回を開催しました
4/24(月)にStep-to-Rails-Expert.rb第6回を実施しました。
step-to-rails-expert-rb.connpass.com
流れ
当日の流れは
- 自己紹介
- 議論
- 懇親会
という形で進めました。
会の様子
今回のテーマは認可でした。主な内容としては以下を議論しました。
- テーブル設計・アプリ設計について
- Gem導入時に検討すべき観点について
- 認可Gemの比較や認証Gemの相性など
- 権限の管理について
人数が少なかったのですが、その分いろいろディープな話ができ面白かったです。個人的には、参照系ではcurrent_userからレコードを引っ張ることでシンプルに実装できるというテクニックが非常に参考になりました。
詳しい内容は議事メモをご覧ください。
運営について・感想
前回の反省点を踏まえ、議事メモは推敲したので、参加していない方からも見やすくなっていると思います。会場の雰囲気が伝わり参加したいと思って頂ければ幸いです。 あとは、実施中にスライドに移すブラウザのサイズが小さくて少し議論しづらかったので、会場の担当の方に教わって調整できるようにしたいなと思いました。
次回開催
次回は5/22（月）に開催予定です。テーマはマストドンソースコードリーティングです（予定）。 おそらく次回開催までに色々な勉強会で触れられると思いますが笑、
などを予定しています。マストドンソースの疑問点・指摘点の議論に関しては、Step-to-Rails-Expert.rbっぽく議論形式で行いたいと思います。ソースコードを読んでいる方も多いと思うので、その時に思ったことや抱いた疑問があれば、次回の議題リストに書き込んで頂いたり、参加して頂ければ嬉しいです。
