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
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!