Rails Developers Meetup 2018: Day 2 大阪会場

Microservices における次なる課題について、Cookpad における observability engineering や service mesh の構築の側面を中心にお話する予定です。前提となる、microsrvices を適用することで得られるプロダクト開発上のメリットや、解決すべき技術的課題についても触れる予定です。

Observability engineerging とは、microservices において次の課題となるシステム全体としての振る舞いの把握に焦点を当てています。今までブラックボックスになりがちであったサービス間の通信周りで起こっていることを記録・分析・アラーティングできるようにすることで、production issue の解決やキャパシティプランニング等、複雑なシステムの運用を適切に行えるようにします。

Service mesh を構築することで、ネットワーク層の関心事をアプリケーションから分離しながら、observability、fault isolation や production testing を実現します。Cookpad で構築している AWS ECS と Hako に特化した service mesh について、利用している Envoy proxy の詳細に触れながらお話します。

その他、AWS X-Ray を使った distributed tracing の実現、gRPC を使った API 通信のためのインフラ構築といった内容になる予定です。

keywords: observability, service mesh, distributed tracing, fault isolation, prodution testing, gRPC, Envoy proxy, AWS ECS

弊社では自社開発の OSS を含む大量のライブラリに支えられてサービスを提供しています。

多くのライブラリは毎日のように機能追加・バグ修正・パフォーマンス改善などが行われ、生きているように変化しています。一方で「眠っている」ともいえるライブラリもあります。サービスを提供し続けるため、生きたライブラリ・眠ったライブラリそれぞれとうまく付き合っていく手法や新しい仕組みづくりについてご紹介する予定です。

AWS + Nyah(OpenStack) で稼働中の minne のサービスの 2018年末の CM 対応時の構成変更やアプリケーションのパフォーマンスチューニングについてご紹介する予定です (Rails はあまり関係ないかもしれない)

エンジニア業務経験なし、Rails経験なしなどの人を採用してチームの戦力になってもらうまでにやっている事を色々とお話しできればと思います。

「コードレビュー自動化」というと、「RuboCopとESLintでインデントが崩れたコードがないか自動でチェックします」みたいな話を想像されるかもしれません。それはそれで悪いことではないのですが、2018年の人類としては、もっと上を目指していきたいものです。このトークでは、私たちがどのようにコードレビューを自動化しているかを紹介します。

私たちは、特に「チーム内のローカルルール」に注目しています。チームローカルなルールは「どれだけ優れた開発者であっても、そのチームに長くいる人しか知らない」「一般のベストプラクティスとは一致しないことがある」という特徴から、RuboCopやESLintなどの一般的な検査ツールではカバーできない厄介者です。SideCIでは、QuerlyとGoodcheckというこの問題にフォーカスした検査ツールを開発しており、SideCIそのものの開発に活用しています。これらのツールを使うことでどのような体験が得られるのか、皆さんと共有したいと思います。

当社ではPerl製フレームワークで作成したウェブサービスをRailsに置き換えるべく積極的に活動しています。Railsに置き換えるにあたって遭遇した不都合をいかにして乗り越えているかをご紹介したいと思います。

お弁当スポンサーによるセッションとなります（大阪会場ではお弁当の提供はございません）。ご参加されない場合は、会場周辺で各自昼食をおとりください。

アンチパターンのオンパレード、テストコード1行もなし、のべ4.5万行のレガシーRailsアプリ。

そんなアプリの、Railsバージョンアッププロジェクトが発足。炎上覚悟のこのプロジェクトを支えたのが「リファクタリング」でした。

テストコードを書きながらリファクタリングし、半年で約1.5万行を削り、Railsバージョンアップも成功させた弊社のリファクタ話、ランチのお供に聞いてみませんか?

お弁当スポンサーによるセッションとなります（大阪会場ではお弁当の提供はございません）。ご参加されない場合は、会場周辺で各自昼食をおとりください。

esaについてのLT (5分) を行います (\( ⁰⊖⁰)/)

esaの使い方や情報共有で工夫していることなど、esaに関することならなんでもOK! esaについてのトークをお待ちしています。

LTご登壇者にはもれなく、お弁当が提供されますのでお楽しみに。

新人研修で新人さんへ教えるべきことについて考察します。Railsエンジニアを育てる定番の研修内容と、より長いエンジニア人生で役立つであろう「知性」の習得方法について考察します。

あなたのプロジェクトには、バスに轢かれたらプロジェクトが破綻する人が何人いますか?

自社サービスを運営している組織において、サービスのスケールのためには開発組織のスケールが必要不可欠です。

急成長中である日本初の Ruby on Rails で作られているフリマアプリ フリルを開発するFablicのエンジニア組織において、バス因子である私が、組織のスケールのために脱バス因子するために同僚と行ってきたことを成功失敗両事例お話します。

Kaizen Platform は創業から5年になるスタートアップですが、その成長の過程で様々な成功や失敗をしてきました。

プロダクト開発に起きる諸問題には技術、人的リソース、事業構造など様々なものが存在しますが、Kaizen Platform ではこれらの問題に対してたくさんのチャレンジと失敗とその先の良い開発プロセスを模索し続けています。

そのなかで培ってきて実践しているプラクティスを失敗したものも合わせて紹介しつつ、エンジニア, デザイナー, プロダクトマネージャー, セールスなどプロダクト開発に携わる全ての人達が、どのような取り組みをしていくことができるかについてお話しします。

チームはどこかの誰かが作ってくれるものではありません。チームにいるメンバーが1人1人動くことによって作られていくものです。

メンバーが動きやすいきっかけ作りが大切だと考えています。

Railsを使って、チームで開発をするようになって9年。さまざまなチームで積み重ねた知見を共有します。

開発をたのしくするきっかけになれたらうれしいです:)

Quipper では学習サービスを展開していますが、先生向け、生徒向け、保護者向け、管理者向けといったように多くのアプリケーションが存在しています。

アプリケーションを跨いだ機能を開発するにあたって、これらを全てセットアップする必要があります。また、機能の追加により依存するパッケージやミドルウェアが追加される場合もあり、これらの管理は非常に煩雑です。

この問題を解決するため、1 コマンドで全ての環境を Docker 上に構築できる Qall を作成しました。

Qall 自体の構成や、Qall を作って日々の開発に利用している中で分かった、開発環境として Docker を利用するにあたってのハマりやすい点やその解決方法、現在抱えている問題について共有する予定です。

ここ数年盛り上がりをみせるFintech。その中でも私達は、第一種金融商品を扱い、投資一任を主軸としたロボアドバイザーTHEOを提供しており、まさにレガシーな金融とWebのようなTechとの中間に位置します。

そんな私達が、どういうところでRailsを使い、またサービス全体をどのように構成しているかを全体的にご紹介します。

また、最近私達はアプリとAPIサーバの通信を中心にgRPCを導入しはじめていますが、これをRailsでどのように扱うかついて、実験的ではありますが、現在の取り組みをご紹介します。

Railsの会社として知られているマネーフォワードですが、もうすぐ2年目を迎える子会社MF KESSAIがどの様な体制で、どの様なアーキテクチャを選択してきたのかをお話したいと思います。

弊社はGo言語をメイン言語として採用しておりますので、この場では言語の話ではなく、新規事業を立ち上げる際に何を考えて、何を採用してきたのか。そして現在どのようなアーキテクチャでサービスを運用しているのかを中心にお話しする事になると思います。

ここ数年でリモートワークを導入している会社はだんだんと増えてきましたし、その良さと難しさについては各所で語られるようになってきました。

わたしはここ七年間、リモートワークという働き方で多くのチーム多くのプロダクト開発に関わってきました。

その経験を通してわかったことは、リモートワークとは個人の働き方ではなくチームのあり方だということです。

リモートワークをしたいモチベーションはひとによって様々でしょう。

しかしチームが違えば価値観が違うように、チームに合うリモートワークのやり方も違ってきます。

この発表では、わたしのいままでの経験から見えてきたリモートなチーム開発をよい感じにするための心がけをお話しいたします。

これからリモートワークを始めようとしているチームにとってなにかのヒントになれば幸いです。

esa.io が、とある趣味の開発合宿で初めてデプロイされてから、もうすぐ4年になろうとしています。

この発表ではesa の開発や運用・ユーザーサポート等について、技術的/心理的な側面から、様々なリソースが制限されている中でどのように自分達なりに工夫してきたかを共有できれば幸いです。

ActiveRecordはWebエンジニア達が嫌う（？）SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。

本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。

※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。

イベント管理ツール「DATND」
ドキュメント共有ツール「Diita」
スケジュール調整「調整ちゃん」
ソーシャルブックマーク「だてブ」
スライド共有ツール「sharedoc」
の他、自動出退勤打刻や近所の飲食店のスクレイピング、slackbot、ChromeExtension、その他こもごもとした「隣の人を笑顔にする何か」を作るサークル活動をしています。

社内用のライブラリ/サービスを作ったり、それをメンテしたり広めたりする際に考えたことを共有させていただきます。

日本時間1月31日に、Rail 6.0の開発が始まりましたが、『これからの Ruby on Rails』について、Railsコミッターの3名様より、皆さまから事前に募った質問にご回答いただきます。

質問は、未来のRailsの話だけでなく、これまでのRailsの話や、日頃の疑問など、ささいなことでも結構です。

ぜひこの機会に、いろいろな質問をご投稿ください。最後のセッションですので、リラックスした雰囲気のもと、Ruby on Railsという“我々のフレームワーク”について、理解を深められたらと思います。

なお、質問の投稿先はこちらをご覧ください。