https://ginza-rails.connpass.com/event/152498/ の発表資料です。 Read less
serviceクラスをやめようサブクラスを使おう
https://ginza-rails.connpass.com/event/152498/ の発表資料です。 Read less
操作履歴/時点指定アクセスの実現 - BiTemporal Data Model の実践 / Implementing command history and temporal access
この資料で説明している ActiveRecord::BiTemporal は https://github.com/kufu/activerecord-bitemporal よりアクセスできます。 以下、セッション説明: データはWebアプリケーションの中心であり、最も重要なものです。私の勤めるSmartHRでも、人事情報を軸とするWebサービスを展開する事業者として最大限の注意を払って運用を行っています。 データは活動によって刻々と変わっていくものですが、通常のWebアプリケーションでは最新の情報しか表現できていません。そのため、いつ・どのような変更を加えたのかを知りたい、あるいはある時点の情報にアクセスしたいといった要望には応えることができませんでした。SmartHRでは入退社や被扶養者の追加など多様なライフイベントに応じてデータの変更が発生するため、その変遷も表現したいというニーズが
ユーザー基盤を作り直しながらRailsでのサービス層に向き合う - クックパッド開発者ブログ
こんにちは。パートナーアライアンス部の諸橋 (@moro) です。 突然ですが、わたしはいまクックパッドの「ユーザー基盤」を再構築しようとしています。 一口に「ユーザー基盤の再構築」といっても、そのゴールが何を指すかは(わたし自身にとってもまだ)漠然としており、固定されたゴールは見いだせていません。しかし後述するように、いくつかの問題は明確な形を取っています。言い換えると、それら明確な問題と向き合いながら『柔軟でいい感じのユーザー基盤を目指す』というのがこの再構築プロジェクトの目的です。 その第一歩目として、ユーザー登録部分を現状のクックパッド本体とは別の小さなRailsアプリケーションとして実装を進め、つい先日、一部の限定された利用者の方に向けて公開することができました。 今後も様子を見ながら公開範囲を拡大していく予定です。 再構築の背景 ではその「明確な問題」とはなんでしょうか。 最大
Large Scale Payments Systems and Ruby on Rails
I’ve been writing code for fun and for work at both small startups and large companies for the past 30 years. Over the years I’ve become fascinated with the payments industry, and I have spent the past decade working in payments related companies. Before coming to work on Payments at Airbnb, I worked for PayPal, for a few startups and then was part of the NFC Wallet project at Google. The payments
Fastly 前提で設計したほうがいい理由
Ginza.rb 63th で「新規開発で Fastly を使おうと思っている場合、最後に Fastly を入れるのではなく、最初から Fastly 前提で設計したほうがいいですよ」という話をチラッとしたんだけど、終了間際で時間も残っていなくて言葉足らずになってしまったので文章化しました。最初から Fastly 前提で設計すべきと思う理由は以下の3点です。 (1) サイドバーなど、メインのコンテンツとライフサイクルが異なるコンポーネントは非同期にすべきだから (2) バックエンドのキャッシュ（例えば Rails の MemCacheStore など）はそもそも不要になる可能性があるから (3) アクセスランキングやアクセスカウンタを作る場合、発想を根本的に変える必要があるため サイドバーなど、メインのコンテンツとライフサイクルが異なるコンポーネントは非同期にすべきだから 例えばウェブメディ
Railsアプリケーションでフォームをオブジェクトにして育てる - クックパッド開発者ブログ
ユーザーエンゲージメント部の諸橋 id:moro です。 わたしはずっと、ユーザー登録やログイン周りという、サービス的には基盤的なところ、技術スタック的にはアプリケーション寄りのところに取り組んできました。関連する話を何度かこの開発者ブログにも書いています。 ユーザー基盤を作り直しながらRailsでのサービス層に向き合う 巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと この記事で触れている「電話番号による登録」について、チームメンバーが別の側面を紹介してくれています。 今日はそのあたりの開発を通じて考えた、Railsアプリケーションでのフォームオブジェクトやサービス層といったものが何であるか、という問いに対する、現在の自分のスタンスを紹介します。 サービス層、サービスオブジェクト、フォームオブジェクト もともと Railsは Web 画面から DB 構造までをあえて密
オブジェクト指向Rails - よりよいコントローラーを書く - 有頂天Ruby
Ruby 5で紹介されていたObject Oriented Rails - Writing better controllers - Pivotal Labsの訳です。(翻訳の質はうんこかもしれません、元記事読みましょう) 私は最近、Objective-Cを使ってiOS、Javaを使ってAndroid、たくさんのモバイル開発をしている。 私はRuby開発者でもあるので、それらの言語やフレームワークから学んだことを可能な限りRubyでも試し、適用してみようとするのは当然のことだろう。 今日はRailsアプリでよりよいコントローラを書くため、僕のベストを尽くそうと思う。 私はAndroidやiOS向けのアプリを書くとき、スタブやモックを使わないよう、自分自身に強制している。それは、オブジェクトの設計を向上させ、DI(依存性の注入)を使ってテストを書くことを意図している。 では、コードの例を見て
Railsの太ったモデルをダイエットさせる方法について - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。最近はよくリファクタリングをしています。 今回は、最近僕がリファクタリングしている内容についてまとめようと思います。 メドピアではFat Model/Controllerを避けるために、rubocopの設定を利用しクラスの行数が300行以下になるよう制限しています*1。最近300行を超えるモデルが出てきたので、一部の処理を別のクラスに切り出し始めました。 このとき、Railsが提供している機能であるconcernsを利用すると楽に行数を減らすことができますが、それだとrubocopの指摘を回避できるという意味しかないので、なるべく委譲(composition)を利用して処理を別クラスに移していっています*2。 複数モデルにまたがる処理を切り出す Railsアプリケーションを書いていると、複数のモデルを一度
form objectを使ってみよう - メドピア開発者ブログ
こんにちは。メドピアのRuby(Rails)化をお手伝いしている@willnetです。 Ruby化のプロジェクトが始まって1年が過ぎました。新しいメンバーも入り、Railsのコード量は日に日に多くなっています。可読性を保ちつつアプリケーションを大きくしていくために、使える知見をチームメンバーに効率よく伝えていくのが大事だと感じる今日このごろです。 普段メドピア内ではコードレビューや社内勉強会などで知識のシェアを行っています。そんなとき、ブログ記事や書籍などのまとまった文章があると「これ読んでおいて」と言うだけで良くなるので楽です。先日form objectを使ったほうがいいですよーという内容でレビューコメントをつけようとしたところ、日本語で詳しくまとまった文章が見当たりませんでした＞＜なければ自分で書くしかありません。そこで今回はRailsにおいて可読性を保つための知見である、form o
amakan の React コンポーネント設計 - ✘╹◡╹✘
説明用の図 例として、amakan anime のトップページ https://anime.amakan.net/ の構造を挙げながら説明する。(ところで amakan anime は今月中に完成予定のサービスで実験的に公開している状態なので、まだまだ至らないところが多々あります…) 登場するコンポーネント一覧 React.Component クラスを継承したクラスをコンポーネントと呼ぶ。主に登場するコンポーネントは以下の通り。 Header Layout Router VideoPrograms Router コンポーネント 最上位のコンポーネントとして、Router コンポーネントが存在する。このコンポーネントを利用して、ページごとにどのコンポーネントを表示すべきかを分岐させる。amakan anime のトップページでは VideoPrograms コンポーネントを描画し、amaka
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
Railsにおける「サービスレイヤ」「サービスオブジェクト」について – recompile.net
Railsを使ったアプリケーションの特定の場面では、「サービスレイヤ」や「サービスオブジェクト」という概念を導入すると有効に機能することがあります。今回は、その紹介をします。 まず、サービスレイヤとは何でしょうか。『Patterns of Enterprise Application Architecture（以下、P of EAA）』では「サービスレイヤは利用可能な操作を定め、各操作へのアプリケーションレスポンスを取りまとめる」と定義されています（参照）。ユーザーインタフェースなどからの呼び出しを受け付けるアプリケーションの境界として、ビジネスロジック、トランザクション制御、レスポンスなどの取りまとめをするのが、サービスレイヤの役割です。 では、どのようなときにサービスレイヤを導入するのでしょうか。P of EAAには、次のように記述されています。 You probably don’t
DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
Atlas: Building with Rails and Go Microservices
Atlas is a recently announced service by HashiCorp that provides a single platform to take an application from development through to production. The complexity of the problem makes Atlas a sophisticated web service that is composed of many moving pieces. This article covers the design of Atlas, and specifically the use case of pairing a front-end Rails application with a collection of Go microser
複数認証を例にしたポリモーフィックとSTIの設計紹介 #shibuyarb - Qiita
sue445 2015/06/17 Shibuya.rb 自己紹介 sue445 株式会社ドリコム 所属 社内ツールとか社内ライブラリとか TDDおじさん プリキュアおじさん 【今期の嫁】キュアトゥインクル 【本妻】キュアピース Agenda 前置き（やりたかったこと） ポリモーフィックとSTIでのそれぞれの設計 ポリモーフィックでよかったこと (≒ STIのデメリット) ポリモーフィックでつらかったこと (≒ STIデメリット) まとめ おまけ（reveal.jsのこと） やりたかったこと とある社内アプリの開発にて下記の要件があった 1ユーザで下記のいずれかの認証を利用 普通の従業員であればLDAP認証 LDAPに紐付かないユーザ（常駐でない外部委託業者など）のでLDAP以外の認証 今回はメアドとパスワード認証を採用 両方の認証を同時に利用するのは無し その他は特に指定なかったので R
RailsでInteractorをうまく利用する - ワザノバ | wazanova
http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors 3 comments | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 飲み会アレンジサイトGrouperが、同社のエンジニアブログで、規模の大きなRailsアプリをパフォーマンスよくつくるときの工夫を提案をしてますが、それに対してRailsのクリエーターのDHH (Basecamp / 37 Signals) が厳しいコメントを残しています。 1) Grouperの提案 問題意識 Railsは、コードベースが千行を超えると、テストスイートが遅くなりがちで、フレームワークのロードタイムが増える。 よくあるのは、ビジネスロジックのほとんどがActiveRecord /m
Favoriteの設計実装はパターンとして使える - Qiita
RailsでのfavoriteのURL設計 http://d.hatena.ne.jp/tkawa/20110508/p1 かなり前にこういう記事を書いたのですが、最近たまたま似たものをRailsで何回か実装する機会があって、これはいろんなところで使えるんじゃないかと思ったので、その設計実装パターンを紹介してみます。 モデル 任意のツイートに任意のユーザーがお気に入りをつけられるというもの。別にツイートじゃなくても何でもOKです。 class Tweet < ActiveRecord::Base has_many :favorites end class User < ActiveRecord::Base has_many :favorites end class Favorite < ActiveRecord::Base belongs_to :tweet belongs_to :use
Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb
