GitHub moro
Comment8
Like
Created atMarch 28, 2018 13:24
Updated atMarch 28, 2018 13:24

Questions and feedbacks (8)

moro
moro commented 4 months

住まう人がフレームワークを作ってしまっている場合も多々あると思います。 こんなとき、「いい感じにする」ためにどんなことをしていますか? また、気をつけていることはありますか?

ありますね。 そこは、フレームワークにするか、制御の方向を手放すかについて、一緒に相談するかなあとおもいます。 「フレームワークになってるための不自由さ」は、エンジニアはよく知ってると思うので、同じようなことが業務にも起こるかも? っていうところを共有した上で、じゃあどこのコントロールを手放せるかを一緒に設計すると思います。

Like(0)

moro
moro commented 4 months

@anonymous

専門家がそんなに知識が堪能ではなかったみたいなケースによく出会うんですが、そういうところを調整するのも「合流する場」の人が調整する責務があると思いますか?

その場でも回答しましたが、義務/duty としての「調整する責務」というと強すぎるかなあと思います。損した気持ちになりますよね。

いっぽうで、「完璧な専門家がいて上手に回る」みたいな状況はなかなかないので、ある種の不足のある者同士のチームとして、その人達とみんなでうまくやる方法を考えるといいんじゃないかなあと思います。

Like(0)

moro
moro commented 4 months

@yuriko1211

「全体をいい感じにする」志向に目覚めたきっかけはありますか?

受託からサービス企業で働き出したときに、運営をしている人たちの業務知識がスゴイなーと思って、いっぽう管理画面がなかなか改修できずに(技術的だったり、優先度が上がらなかったり)で苦労している様子を見た影響は大きいです。

彼ら彼女らの業務知識と課題間をうまくサービスに反映できるといいのにねって思ったのでした。

Like(0)

moro
moro commented 4 months

@colorbox

これまでの経験の中で管理画面で要求されたCRUD以外の機能にはどういったものが多かったですか?

そうですね。承認フローとか権限管理とか、あるいは行動や操作の履歴ですね。 こういったのを、たとえばActiveRecordコールバックで実現した上でCRUDに落とし込む、という作戦もありますが、それが立て込んでくるとだんだん辛くなるなあ。と。

なので、はじめから運営業務として設計すると結果として楽なことが多いと感じています。

Like(1)

moro
moro commented 4 months

@neko314

そうですね。バイネームだと上げきれないのですが、 XP を読んで、いいなあと思う方とは志向が合うことが多いと思います。

たとえば書籍2段落目が

XP とは、自分たちのできることをオープンにして、それを実行に移すことだ。そ して、そのことを他の人にも認めたり、期待したりすることだ。「自分は頭がいいん だから、ひとりで上を目指せばいい」などという未熟な思い込みを克服することだ。 もっと広い世界で成熟した場所を見つけることだ。ビジネスや仕事も含めたコミュ ニティーのなかで、自分の居場所を見つけることだ。自己超越のプロセスのことだ。 そのプロセスのなかで、開発者として最善を尽くすことだ。ビジネスのためになる 優れたコードを書くことだ。

こんな感じなので、その志向が合う人とは音楽性が合うことが多いです。

Like(2)

moro
moro commented about 1 year

@popmac

同じモデルのレコードを複数一括保存するような場合もフォームオブジェクトが最適だったりするのでしょうか?

はい。そういう用途もFOを使うといいんじゃないかなあと思います。一括保存するとき、Railsのフォームで頑張るとこんな感じで来るかと思います。

{
  parent: { name: 'Parent-A' },
  # あるいは children[][name]= みたいなので配列のことも
  children: {
    "1" : { name: 'Child-A1' },
    "2" : { name: 'Child-A2' },
    "3" : { name: 'Child-A3' },
  }
}

FOにて、この children の入力を取り出して、ARオブジェクトにマッピングし、each(&:save!)したりあるいはactiverecord-import などを使ったりするかなと思います。


余談ですが「複数一括保存する場合」が、じつはAjaxを使って「下書き状態の Parent に、一件ずつ Child をCRUDしている」という実装に寄せたほうが、サーバ側も楽になりますし、入力中項目の復元などできてUXもよくなったりするかもしれません。

すでに試してらっしゃるかもしれませんが、そういう別解もありかなあと思いました。

Like(0)

moro
moro commented about 1 year

@anonymous

たくさんありがとうございます!

フォームオブジェクトをチームに広めるために何かされましたか?

他の回答と重複しますが、ペア設計/ペアプロなどしながらチームのみんなで一緒に考えていきました。Web側2-3名のそこまで大きくないチームだったからかもしれませんが。 それもあって AMo::Models を使った素朴なフォームオブジェクト(以下FO)からつくり、高機能な gem の導入は「さきざき足りないことがわかってきたらにしよう」と合意していました。

validate は、どこに書きましたか?

そのコンテキストで必要となるバリデーションはフォームオブジェクトに持たせています。

たとえば投稿フォームの「下書き保存」ボタンから飛んでくる処理をするFOでは一部の項目がなくても通すようにしますし、それを「全体公開」する場合の処理を受けもつFOではそのためのバリデーションをします。

いっぽう、テーブル単独というか、コンテキストにかかわらずそのエンティティが必ず備えているべきバリデーションはARモデルに実装することがあります。例えば User#name は必須である場合、RDBレベルでは users.name カラムに non-null 制約がある場合などは AR のほうが良いでしょう。 そこでのバリデーションエラーをちょっと頑張って FO の #errors でマージした形で扱えるようにしています。

また ARレベルでの必須バリデーションだと思っていたらコンテキスト依存だったり、その逆もよく「発見」するので、そこは移したり戻したりしています。 

入力完了後に、メールを送るなど、フォーム + α が多いと思いますが、 + α の部分は、フォームオブジェクトに書きますか?それとも、保存する Model の デコレータを作って行いますか?それ以外の方法をとられますか?

まずはFOの中に書きます。

講演でも触れたように、FOをつくることでいったん View/Controller と Model とのあいだに境界を作り、そこにテストきながら Model 層を多層化していくことをイメージしています。 「保存する Model の デコレータ」は使用するgemにもよりますが AR オブジェクトの論理的な責務が増えてしまうかなと思うので、最初は分けて起きそうですね。

その後、同一のARモデルをさわる複数のコンテキストから同内容のメールを送る、みたいなことがしたくなったら、、、うーん。メール送信を呼び出すためのクラスを新設するかもしれません。。。

その当たり確定的なことは言えませんが、逆に大事なのは、境界を作ってテストを書いたり分割しやすくしておくことかなとおもいます。

Like(1)

moro
moro commented about 1 year

ありがとうございます。お返事遅れてすみません!

@colorbox

フォームオブジェクトを導入するのにおすすめのgemやライブラリなどはありますか?

そのような gem がいろいろあって、メリットも多いとは思いますが、私は素朴に ActiveModel::Model だけを使いました。Rails上でいう標準的なオブジェクトだけで実装してみました。 その中でも、ActiveModel::Validations で入力値セットの検証と、ActiveModel::Attributes あたりの機能を便利に使っています。これらで、

  1. Webフォームなどからの入力値のセットを attributes で受け取る
  2. それらが、そのフォームから入力されるコンテキストにおいて妥当かどうかをvalidationする
    • バリデーションが通ればそのフォームでやりたい処理をする
    • バリデーションエラーになれば、Rails の form_with などよく知られた方法でフォームレンダリングしながらエラーを表示する

という感じになります。

より高機能なgemの導入は、使ってみて不満が出てきたら、あるいは自分たちが書きたいコードのスタイルが見えてきたらでいいかなあと思っていました。いまのところはPOROあるいはAMo::Modelでいいかな、と。

Like(1)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano