Submit Search
Upload
ふつうのRailsアプリケーション開発
•
55 likes
•
30,876 views
Takafumi ONAKA
Follow
2017-06-22 Rails Developers Meetup #2
Read less
Read more
Technology
Report
Share
Report
Share
1 of 90
Download now
Download to read offline
Recommended
例外設計における大罪
例外設計における大罪
Takuto Wada
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
Recommended
例外設計における大罪
例外設計における大罪
Takuto Wada
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
テストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
リッチなドメインモデル 名前探し
リッチなドメインモデル 名前探し
増田 亨
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
目grep入門 +解説
目grep入門 +解説
murachue
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
Developers Summit
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
Masahito Zembutsu
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
Gosuke Miyashita
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
kwatch
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
Docker Tokyo
Docker Tokyo
cyberblack28 Ichikawa
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
Oss貢献超入門
Oss貢献超入門
Michihito Shigemura
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
DIVE INTO CODE Corp.
マイクロサービスにおける非同期アーキテクチャ
マイクロサービスにおける非同期アーキテクチャ
ota42y
More Related Content
What's hot
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
onozaty
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
Twitterのsnowflakeについて
Twitterのsnowflakeについて
moai kids
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
目grep入門 +解説
目grep入門 +解説
murachue
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
Developers Summit
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
Masahito Zembutsu
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
Gosuke Miyashita
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
kwatch
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
NTT Communications Technology Development
Docker Tokyo
Docker Tokyo
cyberblack28 Ichikawa
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
Oss貢献超入門
Oss貢献超入門
Michihito Shigemura
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
What's hot
(20)
40歳過ぎてもエンジニアでいるためにやっていること
40歳過ぎてもエンジニアでいるためにやっていること
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
TLS, HTTP/2演習
TLS, HTTP/2演習
Twitterのsnowflakeについて
Twitterのsnowflakeについて
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
目grep入門 +解説
目grep入門 +解説
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
【16-E-4】残業ゼロで開発スピードが10倍に!もう元の開発体制には戻れないデンソー流のアジャイル開発
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
Pythonによる黒魔術入門
Pythonによる黒魔術入門
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
分散トレーシング技術について(Open tracingやjaeger)
分散トレーシング技術について(Open tracingやjaeger)
Docker Tokyo
Docker Tokyo
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Oss貢献超入門
Oss貢献超入門
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Similar to ふつうのRailsアプリケーション開発
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
DIVE INTO CODE Corp.
マイクロサービスにおける非同期アーキテクチャ
マイクロサービスにおける非同期アーキテクチャ
ota42y
Application Bootstrap
Application Bootstrap
Takafumi ONAKA
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
DIVE INTO CODE Corp.
Ruby on Rails を用いたWEBアプリケーションの開発
Ruby on Rails を用いたWEBアプリケーションの開発
Koichi Shimozono
Ruby 2.4 / Rails 5.0に上げた際のパッチ5選
Ruby 2.4 / Rails 5.0に上げた際のパッチ5選
Koichi ITO
つながるロボット 〜分散協調ロボットの開発を加速化するROSの紹介〜
つながるロボット 〜分散協調ロボットの開発を加速化するROSの紹介〜
Hideki Takase
Introduction of Rhodes
Introduction of Rhodes
Hitoshi Kuroyanagi
シラサギハンズオン 1015 1016
シラサギハンズオン 1015 1016
Yu Ito
ドリコムJenkins勉強会資料
ドリコムJenkins勉強会資料
Go Sueyoshi (a.k.a sue445)
OSC福岡 20111203
OSC福岡 20111203
Hiroshi Bunya
Rails解説セミナー: リリースノート解説編
Rails解説セミナー: リリースノート解説編
Yohei Yasukawa
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
DIVE INTO CODE Corp.
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
Yuki Ando
Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較
Kazuto Kusama
Rubyプログラミング教育に対する取り組みと事例紹介
Rubyプログラミング教育に対する取り組みと事例紹介
Yasushi Ishikawa
Python におけるドメイン駆動設計(戦術面)の勘どころ
Python におけるドメイン駆動設計(戦術面)の勘どころ
Junya Hayashi
Railsの開発環境作るぞ
Railsの開発環境作るぞ
Yoichi Toyota
20190621_RDBMSのVIEWを使ってRailsのデータアクセスをいい感じにする【銀座Rails#10】
20190621_RDBMSのVIEWを使ってRailsのデータアクセスをいい感じにする【銀座Rails#10】
Masato Mori
Ruby on Rails3 Tutorial Chapter1
Ruby on Rails3 Tutorial Chapter1
Sea Mountain
Similar to ふつうのRailsアプリケーション開発
(20)
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
マイクロサービスにおける非同期アーキテクチャ
マイクロサービスにおける非同期アーキテクチャ
Application Bootstrap
Application Bootstrap
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
Ruby on Rails を用いたWEBアプリケーションの開発
Ruby on Rails を用いたWEBアプリケーションの開発
Ruby 2.4 / Rails 5.0に上げた際のパッチ5選
Ruby 2.4 / Rails 5.0に上げた際のパッチ5選
つながるロボット 〜分散協調ロボットの開発を加速化するROSの紹介〜
つながるロボット 〜分散協調ロボットの開発を加速化するROSの紹介〜
Introduction of Rhodes
Introduction of Rhodes
シラサギハンズオン 1015 1016
シラサギハンズオン 1015 1016
ドリコムJenkins勉強会資料
ドリコムJenkins勉強会資料
OSC福岡 20111203
OSC福岡 20111203
Rails解説セミナー: リリースノート解説編
Rails解説セミナー: リリースノート解説編
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
【入門】3時間でアプリ公開!ゼロからのプログラミングRails講座
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ~エンタープライズのDevOpsを加速させる運用改善Tips~
Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較
Rubyプログラミング教育に対する取り組みと事例紹介
Rubyプログラミング教育に対する取り組みと事例紹介
Python におけるドメイン駆動設計(戦術面)の勘どころ
Python におけるドメイン駆動設計(戦術面)の勘どころ
Railsの開発環境作るぞ
Railsの開発環境作るぞ
20190621_RDBMSのVIEWを使ってRailsのデータアクセスをいい感じにする【銀座Rails#10】
20190621_RDBMSのVIEWを使ってRailsのデータアクセスをいい感じにする【銀座Rails#10】
Ruby on Rails3 Tutorial Chapter1
Ruby on Rails3 Tutorial Chapter1
More from Takafumi ONAKA
不正のトライアングルとコードベースの治安維持
不正のトライアングルとコードベースの治安維持
Takafumi ONAKA
技術記事を書く&楽しむチームの作り方
技術記事を書く&楽しむチームの作り方
Takafumi ONAKA
グルーミングしながら進めるプロダクト開発
グルーミングしながら進めるプロダクト開発
Takafumi ONAKA
Hatena::Letの式年遷宮
Hatena::Letの式年遷宮
Takafumi ONAKA
pt-query-digest は Perl!!
pt-query-digest は Perl!!
Takafumi ONAKA
アプリケーションを作るときに考える25のこと
アプリケーションを作るときに考える25のこと
Takafumi ONAKA
cpanfileがRubyでパースできることに気づいた俺たちは
cpanfileがRubyでパースできることに気づいた俺たちは
Takafumi ONAKA
Perl使いの国のRubyist
Perl使いの国のRubyist
Takafumi ONAKA
ApplicationTemplateのススメ
ApplicationTemplateのススメ
Takafumi ONAKA
RSpecしぐさ
RSpecしぐさ
Takafumi ONAKA
クローズドソースから始めるオープンソース
クローズドソースから始めるオープンソース
Takafumi ONAKA
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術
Takafumi ONAKA
ドリコム×ピクシブ 社会人交換留学説明資料
ドリコム×ピクシブ 社会人交換留学説明資料
Takafumi ONAKA
すこやかRails
すこやかRails
Takafumi ONAKA
マジカルsvnとキュアgit
マジカルsvnとキュアgit
Takafumi ONAKA
Github Enterprise じゃなくてもいいじゃん
Github Enterprise じゃなくてもいいじゃん
Takafumi ONAKA
ターミナルで画像確認するヤツ作った
ターミナルで画像確認するヤツ作った
Takafumi ONAKA
Webアプリケーションは難しい
Webアプリケーションは難しい
Takafumi ONAKA
Rails3.2ってどう変わるの?
Rails3.2ってどう変わるの?
Takafumi ONAKA
ドリコム的Railsアプリ開発流儀
ドリコム的Railsアプリ開発流儀
Takafumi ONAKA
More from Takafumi ONAKA
(20)
不正のトライアングルとコードベースの治安維持
不正のトライアングルとコードベースの治安維持
技術記事を書く&楽しむチームの作り方
技術記事を書く&楽しむチームの作り方
グルーミングしながら進めるプロダクト開発
グルーミングしながら進めるプロダクト開発
Hatena::Letの式年遷宮
Hatena::Letの式年遷宮
pt-query-digest は Perl!!
pt-query-digest は Perl!!
アプリケーションを作るときに考える25のこと
アプリケーションを作るときに考える25のこと
cpanfileがRubyでパースできることに気づいた俺たちは
cpanfileがRubyでパースできることに気づいた俺たちは
Perl使いの国のRubyist
Perl使いの国のRubyist
ApplicationTemplateのススメ
ApplicationTemplateのススメ
RSpecしぐさ
RSpecしぐさ
クローズドソースから始めるオープンソース
クローズドソースから始めるオープンソース
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術
ドリコム×ピクシブ 社会人交換留学説明資料
ドリコム×ピクシブ 社会人交換留学説明資料
すこやかRails
すこやかRails
マジカルsvnとキュアgit
マジカルsvnとキュアgit
Github Enterprise じゃなくてもいいじゃん
Github Enterprise じゃなくてもいいじゃん
ターミナルで画像確認するヤツ作った
ターミナルで画像確認するヤツ作った
Webアプリケーションは難しい
Webアプリケーションは難しい
Rails3.2ってどう変わるの?
Rails3.2ってどう変わるの?
ドリコム的Railsアプリ開発流儀
ドリコム的Railsアプリ開発流儀
Recently uploaded
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Hiroshi Tomioka
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
sn679259
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
WSO2
Recently uploaded
(11)
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
知識ゼロの営業マンでもできた!超速で初心者を脱する、悪魔的学習ステップ3選.pptx
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Utilizing Ballerina for Cloud Native Integrations
Utilizing Ballerina for Cloud Native Integrations
ふつうのRailsアプリケーション開発
1.
ふつうの Railsアプリケーション開発 2017-06-22 Rails Developers Meetup
#2 大仲 能史 a.k.a. @onk
2.
自己紹介 • 大仲 能史
a.k.a. @onk • 株式会社ドリコム • Railsエンジニア歴8年ぐらい – 1.2.6から触り始めた – 本格的にproductionで使ってるのは3.0から 1
3.
過去のRailsっぽい発表 2 https://www.slideshare.net/takafumionaka/
4.
今日の話 ふつうのRailsアプ リケーション開発 3
5.
ふつうの、とは Railsエンジニアが Railsエンジニアらしい 作業に集中できる 4
6.
例えば •bin/setup •bin/update 知っている人ノシ 5
7.
bin/setup git clone後に これを叩くだけで すべての準備が整う 6
8.
bin/update git pull後に これを叩くだけで すべての準備が整う 7
9.
別の方法でも構わない docker-compose up –d でも構わないが、 1コマンドで開発環境が 立ち上がるのが大事 8
10.
bin/setup, bin/update READMEに環境構築手順 を細かく書いて伝える作 業から解放される 楽にするための努力を惜 しむな 9
11.
みたいな話をします よろしくお願いします <(_ _)> 10
12.
simpleとeasy 11
13.
simpleとeasy simpleとeasyの違いを 知っている人ノシ 12
14.
simpleとeasy simple 設計に筋が通って すっきりしていること easy 使うときに 簡単・便利だということ 13
15.
simpleとeasy simple 絶対的な概念 easy 相対的な概念 14
16.
simpleとeasy simple 絶対的な概念 easy 相対的な概念 15
17.
easyかどうか 使う人のコンテキストによって 変わる 今までに触れたことのある概念 に近いとeasyと感じる 16
18.
easy=驚き最小の原則 最近言わなくなりましたね その人のバックグラウンドに よって驚き最小かどうかが変わ るので、設計哲学として成立し づらい 17
19.
コンテキストによってeasyな例 FileUtils.rm_f(list) シェルのコマンド体系に慣れて る人ならrm -fとすぐに分かる 18
20.
コンテキストによってeasyな例 FileUtils.rm_f(list) シェルのコマンド体系に慣れて る人ならrm -fとすぐに分かる FileUtils.rm(list, force: true)
と同じ 19
21.
simpleとeasyの例 kaminari gem v1.0.0 kaminari-core kaminari-activerecord kaminari-actionview kaminari-mongoid kaminari-sinatra 20
22.
simpleとeasyの例 各環境向けのコードをプラグイ ンとして切り出すことでコアの 設計指針をsimpleに保つ 導入や使い方のeasyさはプラグ イン側で担保する 21
23.
simpleとeasyの他の例 同じプラグイン機構でも、 某認証系のgemはeasyだけど simpleではないかもしれない すべての要望を満たすライブラ リはsimpleを保ちづらい 22
24.
Railsとeasy 23
25.
Railsとeasy Railsはもともとeasyであること を目指しているフレームワーク 24
26.
Railsとeasy 90%のことをうまくやる [要出典] 出典忘れたし、80%だったかもしれないので 後で誰か教えてください<(_ _)> 残り10%はeasyにはできないこ とが分かっているので本体では 対応しない 25
27.
Railsとeasy CoCは「規約を知ってる人」に とってeasyになる仕組み 何がどこにあるか分かる 設定を書かなくてよい 26
28.
最近見た象徴的な例 shared section of
secrets.yml Rails v5.1.0から config/secrets.ymlにshared機 能が増えてる 27 https://github.com/rails/rails/commit/e530534265
29.
shared section of
secrets.yml # shared: # api_key: a1B2c3D4e5F6 development: ... test: ... production: ... 28
30.
shared section of
secrets.yml Rafael 「独自ルール持ち込まなくても 普通のYAMLで十分じゃね?」 29 default: &default api_key: 3b7cd727 development: <<: *default
31.
shared section of
secrets.yml DHH 「その書き方ないわー。マジ分 かりづらいし見つけづらい」 「でも書けなくするわけじゃな いから、YAMLに則りたいなら そうすればええんちゃう」 30
32.
ここから分かること 一般的でなくても、使うときに よりeasyになるなら取り入れて いく姿勢=Rails Way 31
33.
Rails is opinionated
framework 認識を合わせて、共通認識のも とでeasyであることで加速しよ うというフレームワークを僕た ちは使っている Rails Wayに全力で乗っかるこ とで、easyになる 32
34.
simpleでなくても良いの? simpleなライブラリを組み合わ せたり、simpleなライブラリに 薄いwrapperをかませたりする ことでeasyにすることができる easyを目指してsimpleを捨てる わけではない。両方取る。 33
35.
ここまでのまとめ • 「ふつう」とは何か (再定義) –
共通認識のもとでeasyになっていること • simpleとeasy – easyはsimpleの上に成り立っている – easyを維持しているのが良いRailsアプリケー ションだと言える • easyだとどうなるか – 消耗しづらく、実装に集中できる – 「普通にやれば普通にうまくいく」状態 34
36.
ドリコムとeasy 35
37.
WillPaginate2Kaminari Kaminariへの移行時の注意点 ARとArrayで書き方が違う 36 # AR の場合 User.page(params[:page]) #
Array の場合 array = Array(100) Kaminari.paginate_array(array).page
38.
WillPaginate2Kaminari Arrayでも同じメソッドで使え るようにして移行を簡単に 37 # AR の場合 User.paginate(page:
params[:page]) # Array の場合 array = Array(100) array.paginate(page: params[:page])
39.
to_id 38 class Integer def to_id self end end class
String def to_id Integer(self) end end class ActiveRecord::Base def to_id self.id end end
40.
to_id 必ずidにできる安心感 AR本体で対応してるので不要では ある 39 class Book <
ActiveRecord::Base scope :author_is, ->(author) { where(author_id: author.to_id) } end
41.
count_by どのユーザにいくら詫び石を配 れば良いのかを集計するのによ く使っていた(過去形 40 %w[a a b
c c c].count_by(&:itself) # => {"a"=>2, "b"=>1, "c"=>3}
42.
activerecord-unsigned-column- ext create_table, referencesに 何もオプションを書かなくても 主キーが必ずunsigned bigint になる 41
43.
activerecord-turntable アプリケーションが何も指定し なくても水平分散できる痛みの 少ない複数DB SQLをパースしてuser_idを取り 出し、自動的に接続するDBを決 定する 42
44.
ユーザ認証 自作はするが、業界スタンダー ドとインタフェースを合わせる current_userでログインユー ザが取れるとか、 authenticate_user!で強制的 にログインさせるとか 43
45.
(ちょっと休憩) 44
46.
ここからのアジェンダ 共通認識を作る easyを作る easyを作る体制を作る 45
47.
共通認識を作る 46
48.
まずは個人で始める 自分の認識と、世の中の一般的 なRailsエンジニアとの認識を合 わせる 47
49.
大量にインプットする はてブ、Qiita、StackOverflow 等を「Ruby」「Rails」で購読 し、眺める 眺めていると感覚が身に付く 定番ライブラリの使い方 ハマりがちな罠 48
50.
bundle update当番 使っているgemがどんなもので、 どのように開発しているのかを 眺める 面白いし、興味が沸くのでgem と仲良くなれる 人に注目するようになる 49
51.
野良コードレビュー 社内の複数アプリを全体的に眺 め、同じ轍を踏まないようにと か便利そうだったら横展開とか 「同じ指摘を何度か見たぞ」と いう共通認識が増えていく 50
52.
野良コードレビュー 頻出 NOT NULL制約 UNIQUE
INDEX 51
53.
野良コードレビュー 頻出 DateTimeは使わない Time -
DateTimeでエラーに なったりDateTime -1で1日減っ てしまったりして罠が多い 52
54.
野良コードレビュー 頻出 同値比較したいならeqです。同 一性を比較したい時だけbeを使 いましょう ruby2.4からはIntegerなので、 Fixnumの同一性に頼るのは避け たい 53
55.
野良コードレビュー 頻出 ユーザの持ち物は必ずcurrent_userか ら関連を辿って取得する where(user_id: current_user.id) はミスすると他人の持ち物が見えてし まったりするので。 Friendshipでsrcとdstを間違えるミスに も繋がる 54
56.
野良コードレビュー 頻出 UserItem, UserActivity等、クラ ス名のprefixとしてUserを付け ることでルール違反に気づきや すくしている。クラス名が現れ た瞬間に大抵ミス (ASTで違反チェックできそう…… 55
57.
重複コードをライブラリ化 社内gemをバンバン作り、同じ gemを使うことでコードの書き 方が似ていく 「見慣れた書き方かどうか」と いう共通認識が増えていく 56
58.
最後まで直しきる 「一部だけ導入して残りは順 次」だと、共通認識にたどり着 けない 数百ファイルぐらいなら気合い で直そう。やっていきです 57
59.
複雑なことをしない Controller, Model, View, FormObject以外はほとんど使 わない Service層はやりきる覚悟があ るなら使ってよし 58
60.
OSSの文脈に乗る • コード規約がある – onkcop •
テストがある – rake (default task) でテストが走る • CIが回っている – rubocop, rspec, deploy • READMEにバッヂを載せる 59
61.
easyを作る 60
62.
発生しないようにする 効果的なのはAとC Aは自動化、Cはそもそも発生 しないようにする 61
63.
自動化の鬼になる 手順書を見かけたら自動化可能 だと思え まずは自動化を考え、全自動が 無理ならせめてスクリプト化 スクリプト名とEnter以外を叩 きたくない 62
64.
時間がかからないようにする 時間は全員に共通する原資 例えばdb:migrate:resetでは なくdb:setupを使う 複数DB環境でdb/schema.rbを 整備し続けるのは少し努力が必 要だが、やる 63
65.
デフォルト値を入れる 書きたくないものを書かなくて も良いようにしたい とはいえ書き忘れが不具合に繋 がるものは早期にエラーになる ようにする(バランス 64
66.
デフォルト値を入れる 例えば認証をbefore_actionで やっているなら、 ApplicationControllerに書けな いかを考える only指定だと漏れたときに困る ので安全に振る理由もある 65
67.
一般的かどうかを意識する 判断基準の大本に常に「この書 き方は一般的かどうか」を持つ 逸脱するときは、共通認識のも とでeasyかどうかで殴り倒す 冒頭で紹介したDHHを思い 出して自らに乗り移らせる 66
68.
コミュニケーションの境目 コミュニケーションコストの改 善はとても考えやすい 会話しなくても進められるよう に、パラレルにするには何が 整っていれば良いのかを考え、 そう動けるようコードを変える 67
69.
コミュニケーションの境目 クライアント・サーバー間のイ ンタフェースをYAMLで定義し て、このYAMLさえあれば開 発・検証ができるようにすると か 68
70.
easyを作る体制を 作る 69
71.
“木を切り倒すのに8時間与え られたとしたら、斧を研ぐの に6時間使うだろう” 70 Abraham Lincoln
72.
楽をするための努力を惜しまない 未整備による無駄なコストを避 けるために、有限時間内で最大 の準備をしたい また、イテレーションで分かっ た内容をもとにどんどん改善し ていきたい 71
73.
足回りは最初に整える 「これを保っていれば速度が落 ちない」という最低ラインを 持って、それを守れる環境づく りを行う これを一言で言うと「ふつう」 になる 72
74.
足回りは最初に整える テスト もちろん書く テストがないとPRマージし ないのが「ふつう」 73
75.
足回りは最初に整える CI/CD もちろん回す 継続的にデプロイし続けら れるのが「ふつう」 74
76.
足回りは最初に整える メトリクス もちろん取る エラーやパフォーマンスを 継続的にチェックできるの が「ふつう」 75
77.
足回りは最初に整える Chat連携 通知が一か所に集まってく る仕組みを導入する 気づける、即対応できるの が「ふつう」 76
78.
足回りは最初に整える Issue/Pull Request テンプレートを書いておく すべてのPRについてWhyが 分かるのが「ふつう」 77
79.
simpleに始める ブランチ運用 GitHub Flow 78
80.
simpleに始める routes REST準拠を最初に考える schema 正規化を崩さない counter_cacheの無い状態 でまず作る 79
81.
改善が回る環境づくり ふりかえり どうだったらもっと生産的 だったかをイテレーショ ンごとに考える 80
82.
改善が回る環境づくり 改善工数の確保 思いついた改善を入れるた めに毎週数時間を使えるよ う、チームにネゴっておく 81
83.
改善が回る環境づくり 定点観測 取得しているメトリクスが 悪化傾向にないかの確認 改善が回っていない環境 だと絶対に悪化している 82
84.
まとめ 83
85.
まとめ(1/3) • 「ふつう」とは何か – 共通認識のもとでeasyになっていること •
simpleとeasy – easyはsimpleの上に成り立っている – easyを維持しているのが良いRailsアプリケー ションだと言える • easyだとどうなるか – 消耗しづらく、実装に集中できる – 「普通にやれば普通にうまくいく」状態 84
86.
まとめ(2/3) • 共通認識を作る – まとまったインプットを入れて自分の中で基 準を持つ –
「見たことがある」から雰囲気を醸成する • easyを作る – 繰り返してはならない、を刷り込む – 一般的かを意識して書く • それしか書けない仕組みづくりを行う 85
87.
まとめ(3/3) • easyを作る体制を作る – どうあれば「ふつう」なのかの基準がもうあ るはずなので、そこに辿り着けるようにする –
準備に時間を掛けるのを許容する • 走りながら考えるのも大事なのでバランス – 改善・挑戦がチーム課題に含まれ、時間が確 保されている • 挑戦はもはや福利厚生 86
88.
まとめ 今日の内容、一つ一つの「ふつ う」は聞いたことのある話だっ たと思う 87
89.
ふつうの、とは(再掲) Railsエンジニアが Railsエンジニアらしい 作業に集中できる 88
90.
まとめ 「ふつうのRailsアプリケーショ ン開発」とは、どこかで見聞き したことのある、現状の自分た ちの状況より良さそうな開発環 境に辿り着く努力をし続けるこ と 89
Download now