Slide 1

Slide 1 text

How I learned to stop worrying and use the Spree ࢲ͸೗Կʹͯ͠৺഑͢ΔͷΛࢭΊͯ
 4QSFFΛ࢖͏Α͏ʹͳ͔ͬͨ Tokyo Rubyist Meetup, 2014.05.14(Wed) ന౔ܛ, Shiratsuchi Kei, @kei_s

Slide 2

Slide 2 text

@kei_s •ന౔ܛ Shiratsuchi Kei •Web app engineer •http://github.com/kei-s

Slide 3

Slide 3 text

•Thank you for coming!!

Slide 4

Slide 4 text

Questionnaire A. Now using Spree. B. High probability to use Spree. C. May use spree. D. Seems unlikely to use Spree.

Slide 5

Slide 5 text

Agenda 1. Why we use spree? 2. Spree’s structure 3. Spree’s good parts and bad parts 4. How to use Spree in OhMyGlasses 5. Difficult parts in real life 6. If I reinvent now

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

OhMyGlasses http://www.ohmyglasses.jp

Slide 8

Slide 8 text

OhMyGlasses •E-commerce site selling eyeglasses and sunglasses. •Built w/ Ruby on Rails, Spree.

Slide 9

Slide 9 text

OhMyGlasses •Public release in January 2012. •Containing 15,000+ products. •5 Engineers+.

Slide 10

Slide 10 text

We use Spree •Our own store, not hosting store. •Rails, not PHP framework. •Spree, not from scratch.

Slide 11

Slide 11 text

Our own store •Not hosting store • like Shopify, Χϥʔϛʔγϣοϓ •Pros: Business scalability •Cons: Need development

Slide 12

Slide 12 text

Our own store •We are engineers developing business value. •We choose building own store to control development.

Slide 13

Slide 13 text

Rails •Not PHP •There are some well-made EC softwares written by PHP. •Magento, EC-Cube

Slide 14

Slide 14 text

Rails • We need a familiar platform. • At least for me, it’s Ruby on Rails. • There are many knowledge about developing web app(not only building EC site). • Testing, deploying, better coding.

Slide 15

Slide 15 text

Spree • First time to develop an E-Commerce service. • We need to build well structured cart/payment features. • Open source. We can read the codes. • I could rely on official documents only for partial to extend Spree codes.

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Spree E Commerce Platform Ruby On Rails 100% Open Source

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Spree’s structure Rails spree_core Ver 2.3.0 spree_api spree_frontend spree_
 auth_devise spree_cmd Ruby spree_backend Optional

Slide 22

Slide 22 text

Spree’s structure Rails spree_core Ver 2.3.0 spree_api spree_frontend spree_
 auth_devise spree_cmd Ruby spree_backend Optional Kaminari Paperclip ActiveMerchant Devise Cancan RSpec FactoryGirl

Slide 23

Slide 23 text

spree_core •The basic models of Spree. •Products •Orders, payments, shipments •Users

Slide 24

Slide 24 text

spree_frontend •Shop interface • Product page, its index page • Checkout controller • Payment views

Slide 25

Slide 25 text

spree_backend • Order control: canceling order, shipping units • Product control: editing product’s info, image, stock • Site configuration interface: • Configuring payment method, Tax rate, promotion(Coupon)

Slide 26

Slide 26 text

Spree’s design concept •Configure without development. •By business owner, site admin. •Customize with development. •By developer.

Slide 27

Slide 27 text

Spree's good parts • Well structured cart/payment. • Statuses of payment, shipment. • Extensible price adjustments. • Tax, shipping cost, discount.

Slide 28

Slide 28 text

Statuses of payment, shipment Order Payment 1 1 Shipment 1 1 • Order has (at least) one payment and shipment objects. • Payment conducts paying affairs: amount, payment method(e.g. credit card) and paying status. • Shipment conducts shipping affairs: shipping address, tracking number, and shipping status.

Slide 29

Slide 29 text

Statuses of payment, shipment Payment statuses Shipment statuses • Ship after paid. • When payment goes “Completed”, shipment goes to “Ready”.

Slide 30

Slide 30 text

Order line_items 1 * adjustments 1 * Product A : Product B : 20000 JPY 23000 JPY Shipping : Coupon : Tax : Item total : 43000 JPY 500 JPY -3000 JPY (included) 0 JPY Total : 40500 JPY { { Extensible price adjustments

Slide 31

Slide 31 text

Order line_items 1 * Product A : Product B : 20000 JPY 23000 JPY Shipping : Coupon : Tax : Lens : Item total : 43000 JPY 500 JPY -3000 JPY (included) 0 JPY 1500 JPY Total : 42000 JPY adjustments 1 * { { Lens adjustment Extensible price adjustments

Slide 32

Slide 32 text

Spree’s bad parts • Product information modeling • EAV (Entity, Attribute, Value) • SQL anti-pattern • Due to control product information without database migration.

Slide 33

Slide 33 text

Product information modeling Property 1 * ProductProperty 1 * id product name 1 Glass1 2 Glass2 id property name 1 lens_width 2 material Product

Slide 34

Slide 34 text

Product information modeling id product_id property_id value 1 1 1 52 2 1 2 metal 3 2 1 49 4 2 2 cellulose • “value” column must be string to store various data. • Can’t validate value on database. Property 1 * ProductProperty 1 * id product name 1 Glass1 2 Glass2 id property name 1 lens_width 2 material Product

Slide 35

Slide 35 text

How to use Spree in OhMyGlasses • Customize aggressively. • Two customizing example: • Treat lens in ordering eyeglasses. • “Home-try” feature.

Slide 36

Slide 36 text

Treat lens in ordering eyeglasses •Added “lens data” to order. •Order has_many LineItems. • LineItems = each items in cart. •LineItem has_one LensData.

Slide 37

Slide 37 text

Treat lens in ordering eyeglasses • When extending class, Spree recommend to • name file with “_decorator.rb”, • use `.class_eval` to inject logic. Spree::LineItem.class_eval do! has_one :lens_data, dependent: :destroy! ...! end app/models/spree/line_item_decorator.rb

Slide 38

Slide 38 text

“Home-try” feature • Spree::HometryOrder inherits Spree::Order. • Change order number rule. • And various tangled logics. class Spree::HometryOrder < Spree::Order! # OVERRIDE! def generate_order_number! ...! end! end

Slide 39

Slide 39 text

Difficult parts in real life (1) • Developing promotion(coupon). • There seems to be various requirements by your own business. • Promotion modeling on Spree is well structured but still complicated.

Slide 40

Slide 40 text

Difficult parts in real life (2) • Testing • It’s difficult to setup statuses of order, payment and shipment in specified situation. • Some statuses get tangled up as indicated above.

Slide 41

Slide 41 text

Difficult parts in real life (3) • Upgrading Spree • When it has changes around business core, they’ll be annoyances. • Order, payment, product’s stock. • Upgrading Rails requires upgrading Spree. • Be sensitive to upgrading Spree.

Slide 42

Slide 42 text

If I reinvent now •Use Spree as needed, •Not entire feature. •In spree_core, frontend, backend

Slide 43

Slide 43 text

If I reinvent now • In spree_core, • Still use models around order. • Order, payment, shipment and so on. • Build own structure to store product info. • It would be better performance and robustness than Spree’s.

Slide 44

Slide 44 text

If I reinvent now • In frontend, • Still use controllers around cart and paying. • They are closely related to order models. • Building own controllers about products or so on. • If necessary, use spree_api to separate apps.

Slide 45

Slide 45 text

If I reinvent now • In backend, • Still use entire backend system. • It has coordinated views about order. • And extend own views as needed.

Slide 46

Slide 46 text

And, We are hiring: Engineer, Designer
 http://tech.ohmyglasses.jp/
 https://www.wantedly.com/projects/545 Thank you!