勉強会のレポートです

私は如何にして心配するのを止めて Spree を使うようになったか

良いところと悪いところを話してもらいましょう
スピーカー @kei_s 白土 慧

Spreeの構成

oh my glasses

Rails と spreeでつくられてるよ
エンジニアは 5名

なんで?

Shopify とか カラーミーショップとかあるけど
自分たちでショップを構築したかった(開発の部分をコントロールしたかった)。

ECCubeあるじゃん

僕がRails知ってたから。
Railsに乗っかっていると良いもの(エコシステム とか gem)が使える。

Spreeの構成

• いくつかのgemから成り立っている
• spree_coreの中でも色々gemをつかっている (kaminariとかオーソドックスなやつ)
• spreeはRails Engineでつくられている

spree_core

基礎的なモデルが含まれている(商品とか注文とか)

spree_frontend

コントローラとビュー

spree_backend

• いわゆる管理画面
• 注文の管理
• 商品の管理
• クレカ決済とか税率の設定
• クーポンの仕組み

spree_api

スピーカーの思うspreeの設計思想

• 開発しないでconfigurationする
• 適宜カスタマイズする

Spreeの良いところ

• カートとか決済の仕組みがよくできている(自分でつくると、うぐぐ、となるやつ。ステート管理とか) ← (kitak: kitecoとかSUZURIとか今後つくられるかもしれないサービスの参考になりそう。コードリーディング会とかやろうかな)
• モデリングよくできている

モデリングの例

• Orderに紐付いたadjustments等 (これはコード読まないと分からん)

Spreeの悪いところ

• Product informationのモデリングがまずい
• EAV(SQLアンチパターンのひとつ)をつかっている
• Valueで色々な種類の値を扱うため、全部String
• Valueになんでも入れるゆえ、バリデーションができない

oh my glassesでの活用事例

oh my glassesは、めっちゃカスタマイズしてます

• LineItemを拡張するために、classevalで開いて hasoneメソッド呼び出す

• お試し注文のidを割り振るために、注文番号の生成メソッドをオーバーライドしてます
  他にもアレコレ... (大変そうだった)

• OrderとPaymentとか色々なオブジェクトの状態が絡み合ってて、カスタマイズするテスト書くが大変

• Spreeのアップグレードは大変... (思ってもみない変更がある。在庫管理のやり方がおもむろに変わったりして怖い)

• SpreeがRailsの特定のバージョンに依存しているため、Railsのバージョンだけあげるわけにはいかない

もしこれからspreeつかうなら

spree全部をつかわずに必要なものだけつかったらよいと思うとのこと

• 注文周りのモデルはそのまんまでよい(よくできている)
• プロダクトの情報の管理は自分たちでやったほうがよい (EAVはバリデーションするのも大変だし、パフォーマンスもでない)
• カートもつかってよい
• カートより手前のビューは、自前でつくったほうがよい
• アプリをふたつに分けたらよいのでは (spreeつかったやつ と 純粋なrails app) 純粋なrails app から spreeのAPI叩けばよいのでは
• 管理画面もつかってよい(管理画面をRailsAdminとかで1からつくるのはつらい)

質問

Active Merchantつかってるけど日本の決済サービスつかうときどうすんの？

自前で日本の決済サービスのgatewayをつくってる

コンビニ決済どうやってんの？

注文の状態を変えるのが大変でやっていない(どういうことだろう?)

OrderとShipmentがいいかんじのモデリングらしいけどShipmentなしで使えるの？(オンライン決済とか)

たしかShipmentなしで使うみたいな設定があった、とのこと。

いま使っているRubyとRailsのバージョンは？

• Rubyは 2.0系
• Railsは 3.1系 (Rails4まであげるのは大変)

Rails4まであげるの大変なの？

管理画面をめっちゃカスタマイズしていたんだけど、spreeのあるバージョンから管理画面の仕組みがガラッと変わってつらいそうな。

Degica on Spree

スピーカー: Chris Salzberg

Spreeのいいところだけ話すよ！

僕のこと

• モントリオール、アムステルダム、東京とあちこちで仕事してきた

Degica and Spree

• Leading E-Commerce Solutions in Japan
• 日本だと吉祥寺にオフィスがある

spreeの歴史

かつて

色々な要求を取り入れて、時と共に一枚岩のなんともいえない複雑なかんじになっていった...

今は？

いいかんじに機能がgem単位に分割されてる (spree-multi-domain, spree-kanaとか)

Spree and the State Machine

• ルーティング見るとわかるけど、ステートフル
• Order, Payment, ShipmentでStateMachineつかってる
• (以下、状態遷移図をみたりコード読んだほうがいいと思う)
• Order State Machineの説明
• Transition Callbacksの説明 (core/app/models/spree/order/checkout.rb)
• Payment Flowの説明
• Shipent Flowの説明

いいかんじにOrder, Payment, Shipmentが歯車のように噛み合っている

Extending Spree

• モデルの拡張にはデコレーターで対応 (keisさんの話にでてきたclassevalの話と同じ)
• ビューはフックで上書きする(Deface gemをつかう)

最後に

• 実際の複数のECサービスのフィードバックをもとにつくられてるよ
• 理由のある制約を課して、その中で最大限の柔軟性を与える
• オープンソースコミュニティによる多大なサポートと成長
• Ruby/Railsでつくられてる！

質問

海をまたいだ国際的なサービスの場合、お金まわりとかどうやってんの？(通貨単位違うし)

いまのところそういうやつはやってないから分かんね

なんかセキュリティの質問だけど聞き取れなかった...

懇親会

• STORESの中の人と話した。同じ石川県出身。STORESはRails3.2でJSのフレームワークはAngularJSだそうな(Angularが流行る前の初めのほうのバージョンをずっと使っているらしい)。
• igaigaさんと挨拶した。
• ハセコさん、刺身さんと話した。フィリピンからきている同僚をもてなすために渋谷の天ぷらのうまい店(is どこ)にすぐいってしまわれた。鹿さんによろしくとのこと。

kei_sさんとのやりとり

• 「hsbtさんから若者を送り込んだと聞いております」
• 「あー、kitakさんって、あんちぽさんにいじられてることで有名な」

spreeのコードリーディング会やりたいんですけど

• 全部は大変だけど、Orderモデルを中心にShipmentモデル, Paymentモデルまわりを読むといいかも。
• おもむろにモデルのコード読むと訳が分からんので、サンプルアプリを立ち上げて、注文までやってからのほうがよい。
• nested attributesでガッとコントローラ アクションでパラメータを受け取って、ガッとモデルを生成しているので、なんだかんだビューのコードも読む必要がある。
• 一度、注文までやった後は管理画面ベースでコードを読んでみるとよさそう。

ECのエンジニアでやってみたらいいかもしれない。
ところで今日こんなのみつけたんですけど、どうなんだろう https://github.com/drhenner/ror_ecommerce