何でも屋エンジニアのブログ

Rails中級者向け勉強会Step-to-Rails-Expert.rbや出席した勉強会に関するメモが多い

ExpertTodo(Todoアプリレビュー企画)について

以前から少しずつ触れてきたTodoアプリを作成してきてレビューしあう企画について、fixしたものをまとめておきます。
TODOの箇所について、「こうすれば良いのでは?」など案があれば、ぜひコメントください!

ExpertTodoとは

Todoアプリを作成し参加者でレビューしあうという企画の名称、または本企画で使用されるアプリの名称を指します。 どういう経緯で本企画が企画されてきたのかは、以下のリンクをご覧ください。
http://biibiebisuke.hatenablog.com/entry/2017/05/26/115016 http://biibiebisuke.hatenablog.com/entry/2017/07/19/232203 http://biibiebisuke.hatenablog.com/entry/2017/06/29/121713

目的

同じ仕様のアプリを参加者で実装しレビューしあうことによって、RailsWayがどのような設計・実装によって実現できるかを参加者で議論しながら探求していきます。

背景

Gemやちょっとした機能を実装した知見はweb上にたくさんありますが、それらをRailsWayに乗って書くにはどのように書くべきか、という知見が少ないと感じています。Rubyに関してはOSSのコードを見ることで学べますが、RailsOSSは少なく参考にできるプロジェクトがあまりないのが現状です。 そこで、ExpertTodoではRailsを使ってどのように設計・実装すべきかを、実際のアプリを作成し互いにレビューしあうことによって学んでいきます。その際、追加する仕様をランダムに設定し「仕様が天から降ってくる」実際の業務に近い状態を作り出すことで、変更に強い設計・実装を学ぶことができます。この意味で業務に直結する設計力・実装力の向上を期待できます。

参加することで学べる可能性のある事柄

  • RailsWayを学べる
  • 変更に強い設計・実装を学べる
  • 実装だけでなく開発フローなどの指摘も得られる
  • CI環境の設定方法・Paas/Iaasを使ったアプリプラットフォーム構築の知見を得られる
  • 既存のアプリをメンテする勘所を学べる(他の参加者のアプリをforkして進めることもできる)

開発方法に関して

開発の流れ・開発のルールに関しては、ExpertTodoのREADMEをご覧ください。

ExpertTodoの進め方

  • 基本的にレビューは当日までに行い、気になったことを本番で話す
    • TODO: レビューのアサイン方法などを決める必要あり
  • オフライン/オンライン両方で進めるために当日channelを用意する
  • TODO: たぶん、ある程度事前にどこまで解くつもりかor解いたかを知らせてもらった方がよい

  • 当日1人1つ仕様案を足す

必要なもの

  • TODO: ランダムで仕様を選ぶやつ
  • TODO: 質問・サポートの場(実装というよりは仕組みや運営の不備による不明瞭な事柄についての窓口)
  • TODO: 無料でできる構成のサンプルを提供する(heroku&circleCIなど)

その他

本企画ExpertTodoは、非常に学びがある企画だと考えていますが企画の性質上あまり多くの参加者を受け入れるキャパシティがありません。実際にアプリを作っていなくても参加できる枠組み(オンラインの参加で議論の様子を聞けるなど)を考えてはいますが、運営リソース等の制限で実現できるかは定かではありません。そのため、他のコミュニティや集まりで本企画を実施して頂くのは大歓迎です。その際は、フィードバックを受けたい・場合によっては参加させて頂きたい等の理由から、Step-to-Rails-Expert.rb主催者のebiまで一声かけて頂ければ幸いです。

Step-to-Rails-Expert.rb第9回を開催しました

7/31(月)にStep-to-Rails-Expert.rb第9回を実施しました。

step-to-rails-expert-rb.connpass.com

流れ

当日の流れは

  • 自己紹介
  • 議論
    • レビュー・教育について
    • Todoアプリレビュー企画のレビュー
  • 懇親会

という形で進めました。

議論内容についての感想

  • レビュー・教育については色々なところで議論されているため、方法論についてはある程度セオリーができているのだなと感じました。

  • レビューの手間を削減する便利gemやサービスについて興味があり議題に記載したところ、Rubocop以外にあまり思いつかなかったのですが、

など色々教えて頂きました。 SideCIについて、静的解析ツールの設定方法に長けていなかったり、導入・設定運用のリソースがない場合には非常に魅力的な選択肢だと感じました。

また、 TODOアプリレビューしあう回の企画を相談させて頂きみなさんにレビューしてもらったので、近日中に公開します。

詳しい内容は議事メモをご覧ください。

github.com

反省点

  • 自己紹介もPRで送ってもらうの準備が間に合わなかった

次回について

次回は8/28(月)にもくもく会形式で、「TODOアプリレビューしあう回」のアプリを作る作業や質問をする回にする予定です。 また、本番の回までに本勉強会の様子を体験してみたいという方の参加もお待ちしております。

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アプリなのか

単純なものとても簡単に作れますが、

  • リッチでインタラクティブなview
  • タグ機能など多対多関連の設計・実装
  • 期限到来の通知機能
  • 一括削除
  • 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

詳しい内容は議事メモをご覧ください。

github.com

反省点

  • 今回はテーマが良かったこともあり、議論も非常に盛り上がって良かった
  • 今回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追記: ご本人から資料・動画公開の旨教えて頂きました。ありがとうございます!

下記リンクの「D4T7-4 Dev Day トラック 1」が当該講演です。

aws.amazon.com

メモ

lambdaのテストに関するベストプラクティスはまだない。

お題はlamdbaの公式チュートリアルにテストをつける == testableなコードに書き換える
チュートリアル: Amazon S3 での AWS Lambda の使用 - AWS Lambda

テストの粒度について、テストサイズという概念を用いて解説されていた

  • smallではネットワークアクセスはもちろんデータベースアクセスもしない独立したテスト
  • mediumではネットワークはlocalhostのみ許可、外部サービスは利用をおすすめしない
  • argeでは全部可。外部サービスも含め全部本番と同じものを使うテスト

という感じ。 t_wadaさんが講演で使用していたリンクは以下のものです。詳しくはリンク先をご覧下さい。

testing.googleblog.com

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さん見てオーラを近くで感じるだけでテスト書けそうな気がしてきました笑 大変ためになる講演ありがとうございました。

*1:このようにお話されていたと記憶していますが間違えていたら指摘頂ければ幸いです

*2:以下の2つのリンクが分かりやすいです。

Consumer-Driven Contracts testingを徹底解説! - Qiita
サービス分割時の複雑性に対処する: テスト戦略の話 - クックパッド開発者ブログ

AWS Summit 2017「全部教えます!サーバレスアプリのアンチパターンとチューニング」のメモ

AWS Summit 2017にて全部教えます!サーバレスアプリのアンチパターンとチューニングを聴講したのでそのメモです。 かなり詳しい話を聞けて大変参考になりました。 www.awssummit.tokyo

メモ

パフォーマンスをどう上げるか

プログラム側

各言語のベストプラクティス・最適化方法はそのまま当てはまるので、プログラムのパフォーマンスを上げておく

コンピューティングリソース不足

  • メモリ設定
    • 実際にはリソース全体のパフォーマンスの設定を意味する。
    • メモリに比例してcpuのリソースも上がる。
    • メモリ設定を上げることで実行時間が減り、パフォーマンスが向上し一方でコストが変わらないこともある。
    • 適切なスペックを洗濯することが大事。低スペックからだんだんあげていって、処理時間が変わらなくなるスペックがあるので、そのスペックに決めるのが良い。

コールドスタート

起こる条件
  • 利用可能なコンテナがない場合 
  • そもそも1つもコンテナがない
  • 利用可能な数以上に同時に処理すべきリクエストが来た。
  • コード・設定の変更をした
  • これらの条件にあてはまなければ発生しない。コールドスタートは全体の1%くらい

コールドスタートが許容できないのであればLambdaを使うべきではない

速くするためには
  • コンピューティングリソースを上げる
  • 言語を変える
    javaはコールドスタートが遅い。ウォームスタートの場合、コンパイル言語の方が速い傾向
  • VPC接続ははENIの発生を伴うので必要がなければ使わない(VPCアクセスが必要なければ使わない)
    これだけでコールドスタート時の10秒程度を削減する可能性
  • パッケージサイズを小さくする
    コード量の削減、不要な依存関係の削減、最適化ツールを使用するなど
アーキテクチャ
  • 同期でinvokeすると同時実行数の制限にひっかかる
  • 非同期でinvokeするのがスケーラビリティの観点ではおすすめ
  • api gatewayと組み合わせる場合、putの場合は直接呼び出すのではなくsqs kinesisに流し、それをイベントソースとして実行するべき。getはキャッシュする。

  • 並列実行できるようにする

    • 1回のinvokeでループさせるのでなく、回数分ファンクションを非同期invokeする
    • 長時間実行が減るので、同時実行数の制限にひっかからなくなる
    • ストリームベースの場合は少し考え方が違う。ストリームの中のシャードの数がイコール同時実行数

アンチパターン

  • RDBMSと併用する
    • lamdba + rdbmsは、lambdaの並列実行数分のコネクションが貼られるのできつい。
    • vpc接続が必須になってしまう

dynamoがおすすめ

ログ

cloudwatchメトリクス、cloudwatchカスタムメトリクス、cloudwatch logsへのログ出力を行う

その他

  • 障害を前提に設計する
    リトライ、DeadLetterQueueを活用する

その他

スピーカーの西谷さんの著書が発売されているので、こちらを読むとさらに理解が深まりそうです。

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さんを筆頭に、プライベートでマストドンを運用している方が多く参加して頂き、ソースレベルの質問から、企業で運用している人たちの悩み事まで色々有益な話が聞けました(議事メモに書いていいのかなみたいな話もありました笑)。懇親会もかなり盛り上がっていて、非常に良かったです。 詳しい内容は議事メモをご覧ください。

github.com

反省点

  • ファシリテートはかなり反省点あり
    7~8人と10人以上はやっぱり違う。今回は初参加の人も多かったので、その点も雰囲気が違った。もう少しうまく進めたい。
  • 会の説明や進め方を説明した方が良い
  • 議事メモのレイアウトは改良の余地があり
  • 議題募集はGithubにてPRで追記してもらうような方が良い? 今の方式だと誰にも質問できないし書き込みづらい。初見殺し。

個人の課題

今回も実際にマストドンを作っている方々から色々アドバイスを頂いたにもかかわらず、それを復習しきれていないです。ここ数回でも同じような感じで、色々学ばさせて頂いたことを100%飲み込むような時間を取れていないような現状が良くないと感じています。とはいえ、4週間後には次の開催が待っているのでその準備も必要だし、復習&準備が中途半端になっているような現状があります。その他にも、せっかく習慣づいていたOSS活動も最近はあまりやれていない(興味のあるSorceryの開発自体が進んでいないのもあるが)、フロントエンドをしっかりと勉強したいなど、やりたいことが多すぎるので優先順位をしっかりつけ進めていきたいです。

今後の企画

通常の会の方法とは異なる企画を行おうと考えています。 ベースとなるRailsアプリ、追加する仕様を開催側で用意、勉強会当日までに仕様の機能を実装し、当日はそれらのアプリを参加者でレビューしようという企画です。 書いてきてくれた人は会社以外の人にレビューしてもらう機会、そうでない人もレビュー内容を聞ける機会を得られるのでかなり学びのある企画だと思います。 懇親会で神速さんを始めみなさんから色々アドバイスを頂き考えた結果が以下です。

  • アプリはTodoアプリ
    単純なものは簡単に作れるが、リッチでインタラクティブなviewや、タグ、期限到来の通知、一括削除、todoの終了/削除などの状態管理、間違えて終了してしまったtodoを戻すなど、仕様を増やすとそれに従い難易度が増加するので、様々なレベルの人が楽しめる
  • 実施回数は数回
    仕様を徐々に増やしていくが、最初から全体の仕様をオープンにしない予定。これにより、変更に強いアプリの設計・実装の仕方についても議論できる。実施は隔月かも。
  • 課題
    2回目以降から参加された方も楽しめる方法や、そもそもアプリ作ってきてくれる人いるかな・・など

色々準備があるので、次々回で実現する目標で動いています。次回実施時もしくは懇親会で企画について相談するかもしれないので、もしご意見ある方で参加されている方は色々リクエストください。こういう企画はよちよちさんが実績&知見があると教えて頂いたので、企画の説明やリポジトリを参考にさせて頂こうかな。

次回について

次回は6/26(月)にエラー通知/モニタリングというテーマで実施予定です。 Airbrakeなどエラーモニタリングツールの使い心地は?どういう方法で通知している?どのような体制でエラーに対応している?などの疑問点や、 オオカミ少年のエラー通知に誰も反応しなくなって問題が起きた・・などのツラミなど、様々な視点から議論しましょう!