Ben Morgan I/O

Dear Spree, We Broke Up

Fri, 22 Jan 2016 07:38:02 -0500

https://github.com/spree/spree/pull/6918

I’m sorry Spree. Its not you, its me. I’m not the right developer for you. Not a lot of developers are the right ones for you. But, maybe you’ve found one. And that’s great. I’m dating this new girl. Her names Solidus and we get a long a lot better. I’m sorry Spree, but we broke up.

I hope that the future is bright for you. I’m happy you’re receiving maintenance and that the future looks brighter for you. I hope you find happiness in the future.

I’m writing this letter because I need you to know that there’s a wound in my heart. A while back, a piece of my heart had your name on it, Spree. With FirstData coming into our relationship, we knew things had to end and we needed to both move on. This letter is so that we can move on from each other.

To help this process, I’m using George Lucas’s three commandments of break ups.

1. I will not phone call Spree.
2. I will not drive by Spree’s house and see what she’s doing.
3. I will not show up at her coffee shop.

I’m sorry Spree, but we broke up. Not watching. Unstaring. And most importantly: we can’t fork anymore.

From Spree to Solidus

Thu, 22 Oct 2015 17:35:43 -0400

A long time ago Spree was the go to ecommerce framework for Rails. For those who don’t know, Spree had a lot of bugs. But no one really beat the contributors up on it. Everyone knew: ecommerce is hard.

Over time, the contributors started to disappear. Their Github said they still worked for Spreecommerce, but they were gone. No contributions. Where did they go?

Then Ryan Bigg quit.

You could feel the cogs turning inside of Spreecommerce. Should we support Spree or keep supporting SpreeHub? Then boom! SpreeHub was renamed to Wombat with an all new admin. Now we know what everyone was working on. Now we knew where Spreecommerce was investing in.

We hoped that once Wombat was doing good, they’d focus more time back on Spree. Unfortunately, this never paid off for the Spree community. Spree only had one core contributor and you could tell he was working on the project part time. The most popular ecommerce framework was being neglected.

And so, the community wanted access to the “merge” button. They weren’t getting it. You had to work for Spreecommerce. So, what did the unsung heroes of Spree do? They forked it.

Tons of tiny bug fixes enter Spree. Tons of new and amazing features ended up in Solidus. Solidus was even fix long outstanding bugs. They were on point.

I’m moving to Solidus, are you?

Relying on Blog Posts for Tech Information

Tue, 06 Oct 2015 18:40:36 -0400

Sometimes, when someone is making a recommendation on why they think something is a best practice, they’ll reference a blog post. What’s great about a blog post is that there’s people (like me) that will explain simply why something is a good implementation and why you should do it too.

But here’s the thing, if you look into my blog archive, you’ll discover that you should store Twitter configuration in a global variable. (I broke a production app by implementing that. Worst part: its recommended on the twitter ruby client readme…) I have other _bad_ recommendations as well that I’m sure even a junior dev can find. Don’t trust me.

Oh, but wait, I’m a good dev. I’m a core contributor to Spree! I have to have at least some idea how to program. I mean, I do help out on the biggest ecommerce framework for ruby on rails.

So, why are blog posts bad references? They aren’t peer reviewed and they don’t contain other peoples opinions. You might get another persons opinion, but that’s only if you check the comments; if they have comments turned on and guess what: I don’t.

What are some reliable resources? Popular Stackoverflow questions with tons of activity.

Actually, nvm. I’ve changed my mind. This is now a blog post that is here to be-all-end-all to the discussion of what is a valid reference. Blog posts (especially the ones where comments are turned off) are now the go to reference.

Sir, i am getting a compatibility error for spree auth devise gem while installing spree using your method. Could you please tell me which ruby/rails version should i use?

Wed, 12 Aug 2015 01:19:42 -0400

Which Spree version are you using? 3.0 is for rails 4.2 and 2.3/2.4 is for rails 4.1. If you’re getting an incompatibility error, maybe also point spree_auth_devise to the same gem version.

Hey Ben, we are contemplating using Spree for our web presence/e-commerce. We would like to benefit from a world filled with inexpensive high-quality themes. How easy is it to get any random theme designed for Bootstrap to work with Spree? Thx! Thorsten

Wed, 12 Aug 2015 01:18:36 -0400

They should be just the CSS or SCSS/LESS files. Preferably SCSS. If its just that, then you can plug it into a default spree storefront and customize it from there.

hi Ben. i am RoR programmer how to integrate wombat with spree

Thu, 07 May 2015 20:07:42 -0400

Would love to help you how, but you’re an anon.

Hi ben , i need some support on a spreecommerce project let me know if u have time

Sat, 02 May 2015 05:55:36 -0400

I’d love to help you out Mr. Anon, but let me know when you’re free to not be anonymous.

Spree's API

Sat, 28 Feb 2015 18:16:30 -0500

A long time ago, the issues inside of Spree used to be either silly questions (usually by me) or noting another shipment/adjustment bug. You don’t see that anymore. You see serious performance issues in edge areas or pull requests for new features or to deprecate some not so ideal features.

Spree now has over 6000 stars, 350 people watching, and over 2800 forks. Spree is popular. GoDaddy is building their “Shopify killer” with it and I have no doubt they’ll crush them. They think about marketing and disrupting the media enough to make them, well, far more noticable than the polite Canadian ads from Shopify.

Shopify also has limitations. And people want and need to move off. ShoeMe is on Shopify and they’ve purchased an already established .NET storefront to move everything over to. Its not uncommon for me to check my inbox and read an email from someone wanting to migrate from Shopify. GoDaddy is and has created a marketplace platform, integrated liquid, and built a Rails application structure that will make Shopify rethink its tech stack and its features.

Its also great for the Spree community because of the publicity this gives Spree. And Spree is getting popular. Very very popular.

Its also insanely complex. You have around ~75 tables in your DB with Spree and over 100 models for your business logic. However, this is expected. This is ecommerce. If you think you can make a store with no more than 20 models, I’ll point you to the door and if I’m in a good mood, hold it open for you.

If you think that you can walk into ecommerce and modularize the functionality, lets sit down and talk. The fact that you can walk up and say “Hey, this is big and its messy and its world changing. How to do we contain it and make things easier for people?” then you might find a place in ecommerce in general.

The web in a whole is moving to an API driven ecosystem. I don’t even use the spree_frontend. I just bundle with the spree_backend and I get the spree_api and the spree_core automatically. This means Spree storefronts are using Backbone, Angular, and Ember. I’m a plus one for Ember due to its convention over configuration. Backbone also has its place for legacy and wider support. Its minimal, its easier to learn, but I also think its more for the experienced to ensure the application follows standard best practices and conventions as well as ensuring its supportive of legacy. Angular seems to be doing its own thing by making antipractices best practices and lying out its teeth in its marketing (you only need angular.js! as 1 dependency, we follow MV*, we’re really good with data. I spent more time trying to work around their BS than anything else. IMO don’t pick a framework that’s marketed by a company. There’s been too much lying to actually get work done. And too many white promises.)

If you’re building your next Spree store with Ember, you’ll probably be wanting an API to work with. Right now, you have to sorta build your own. I’m hoping I can set time away to get an Ember friendly Spree API built for 4.0. Work has already started since 3-0-stable was created.

Making a single page storefront is hard. You’ll have enourmous amounts of data and a lot of components to manage. I highly recommend Ember for the job. It Rails developer-ish friendly. Its also great for people moving from Backbone since it has the same dependencies. Its the type of framework I see surviving the long battle as people discover its doing all the right things and it doesn’t sit and lie to its users (read: angular).

Lets talk about JSON. You know when you do an API request and you want to get your data back? That’s the first thing that’s changing in Spree. I think many people can agree that Spree needs a consistent and established way for serializing the JSON. Spree is currently using Rabl and to be frank, it needs to go. Rabl has not been supportive of multiple rails applications. So, if you’re trying to load a rabl template in Spree from your main application, its not going to work. You just lost all the benefits and you might as well build your own API.

The API in Spree is being switched from Rabl to Active Model Serializers. Caching is going to be a neccessity so we won’t be using 0.9. 0.8 is currently being used and when 0.10 comes out, Spree will switch to that ASAP. I’m looking forward to AMS 0.10.

After the AMS change and all the rabl templates have been deprecated, work can be started on changing Spree’s API up to be more Ember friendly. If it can work on Ember, it can work anywhere, mainly because Ember inforces best practices and if the JSON can be rendered using the best practices, it shouldn’t matter if you’re on Backbone, (Angular,) Knockout, or Kendo.

The aim of this blog post was to communicate three things: (1) Spree is growing and with that, its API is going to be changing, (2) more storefronts are using JS frameworks so the API needs to shape up where it may be lacking, (3) people need to serializer JSON in ruby, AMS is going to support that and that’s also a reason for the change.

My notes on Angular are my opinion. I still work with it and I’m enthusiastic that they might treat their users (read: me) nicer. I still use it on a lot of Rails applications. Its my opinion.

Raptor (Passenger 5) with Ruby on Rails

Sun, 08 Feb 2015 21:58:02 -0500

A while back I remember hearing all the buzz about Ruby Raptor and it was later disclosed that it was actually the fifth version of Phusion Passenger.

For my Rails projects, I’m a user of either Thin or Puma. When I head over to a Spree application using Puma, this was what I received in performance terms:

$ wrk -t10 -c10 -d20s http://localhost:3000
Running 20s test @ http://localhost:3000
  10 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    10.22s    40.55ms  10.31s    77.78%
    Req/Sec     0.00      0.00     0.00    100.00%
  18 requests in 20.03s, 220.84KB read
  Socket errors: connect 0, read 0, write 0, timeout 82
Requests/sec:      0.90
Transfer/sec:     11.02KB

Then I decided to try out Raptor with Spree. I began with a gem install passenger and ran passenger start. This was the output:

$ passenger -v
Phusion Passenger version 4.0.58

$ wrk -t10 -c10 -d20s http://localhost:3000
Running 20s test @ http://localhost:3000
  10 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     6.73s   745.85ms   7.50s    50.00%
    Req/Sec     0.00      0.00     0.00    100.00%
  22 requests in 20.03s, 272.91KB read
  Socket errors: connect 0, read 0, write 0, timeout 75
Requests/sec:      1.10
Transfer/sec:     13.63KB

As you can see, Passenger 4 is already faster than Puma. How about we get going with Raptor and see how it competes?

$ gem uninstall passenger
Successfully uninstalled passenger-4.0.58

$ gem install passenger --pre

$ passenger -v
Phusion Passenger version 5.0.0.beta2

$ wrk -t10 -c10 -d20s http://localhost:8080
Running 20s test @ http://localhost:8080
  10 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.60s     1.06s    6.50s    85.71%
    Req/Sec     0.00      0.00     0.00    100.00%
  31 requests in 20.03s, 379.66KB read
  Socket errors: connect 0, read 0, write 0, timeout 64
Requests/sec:      1.55
Transfer/sec:     18.95KB

You’ll notice that I used port 8080 instead of 3000. This seems to be a passenger bug from my understanding. I kept receiving an error stating tht port 3000 was already in use, so I decided to switch it over to 8080 and everything was working again.

I’m pretty happy with these performance improvements.

Some things that I would like from Raptor is some better documentation on getting started and at least letting us know that you don’t need Nginx running. They also need to make their documentation a lot more readable.

All in all, I can see passenger possibly being used in production, but the difficulty of getting it to work (or at least discovering passenger start) may be a hurdle.

My recommendation:

Stick with Thin or Puma until Passenger makes a deeper commitment in helping simplify their get started page. Otherwise, your app/company may find themselves in some sticky situations, digging through their unorganized, but plentiful docs for a single command that you should have known about from the beginning.

Thin and Puma can both be booted from the very start with a rails s. Passenger is not as friendly.

Building Large Rails Applications: The Comedians Take

Mon, 26 Jan 2015 18:28:36 -0500

I’ve been working on large rails applications ever since I started learning. I remember being recruited at a start up and sitting and looking at a rails app with no less than 100 models. Phew boy.

You don’t even know MVC yet, and you’re looking at an application that even the best will be biting their teeth on. Its scary.

And I’ve been doing this for a while now. Working with large Rails applications. Non-stop. All Spree apps. All of them have more than 100 models. I like to think that a small rails app is one with a single digit models (1 to 9). Medium apps tend to extend into the double digits and stops half way (11 to ~50), BUT you can certainly argue that a large rails app starts to form at around 30 or 40. However, you can argue that the excess 20 models start to become autonomous with the application and their complexity might be more from rails “imperative” conventions, rather than from existing for complex reasons. These could be HABTM models or abstract models. You ge the idea. They may exist only to serve a very basic need, not to add new features to the app.

And then there’s the large rails apps. These come in at around 50 to 100 models. They start to become burdened with complexity and may take months to get a feel for. This is not where Spree falls into.

When you start to reach a rails application with more than 100 models, you know you’re in for a ride. The thoughts of abstraction and “feature removal” start to fill your mind. How do you handle this? You make effectively bad decisions of course!

Goodbye shoulda

Your behemoth doesn’t need simple line by line testing. You can trust me on that. Things are so interconnected that a simple change will cause your app to crash. Shoulda matchers start to add a burden and from this, you aren’t writing unit tests anymore, you’re writing more and more complex BDD features.

(I’d like to note that this is where BDD starts to shine is in the “larger than life” rails apps. BDD might take 2 seconds to cover the model to controller to view to the god-knows-what-else-got-added and the same for unit tests might take 5 seconds to cover. Constantly starting and stopping as it moves through. the BDD doesn’t stop. It just washes over your code. Dropping its TDD coverage red and green slime wherever it goes.)

The Namespacing of the Rails App

Bet you never thought this was going to happen. You have a nice and lovely rais app. You’ve called it Articlz. That’s a nice name. Now be prepared to add a Articlz::Base model prefixing all your tables with "articlz_". Get ready for some serious namespacing issues >:-). Instead of making a Post model, you’re making an Articlz::Post model. It seems silling to namespace your own application, but guess what, it happens.

The Monthly Gemfile Refactor

Its actually quite common for a Gemfile to get bigger than 100 lines, but 500? Oh yeah, you’re going to want some organization. You learn to make you’re own meta gems.

The I-<3-Hexagonal-Architecture

Nope. Still don’t love it. But your app is so big, you have a HABTM merge belonging to eight models. At some point, you start to use hexagonal here and there. Biting you teeth as you try to keep to MVC. Its more of an unfortinate and unpleasent experience than anything else. You turn them as “exceptions to the rails-way”, but you know you could have done better.

The CI Server Meltdown

Your app is so big, you don’t just use some CI server like CircleCI. You’re to the point that any Github merge goes through at least 5 CIs. And if you’ve ever used CircleCI, you might have ~5 test suites to run inside of it… Page… by… page….

And then God said, let there be linting.

You can’t stand the 250,000 lines of crap. You’ve got rubocop running constantly in the one directory you’re working on not by Guard, but from some ruby script. Its customized to your development hidden from everyone through your git ignore. You’re still Hounded.

The hiding-systems-languages-in-your-lib-dir

You need your app to actually perform as the loading of 10 includes through rails is taking 7 seconds. You tell yourself you could just cache it, but you don’t want to have to cache on development (even though you’re already doing it). You end up doing a cd lib && cargo new rust --bin and add to the readme under some “quick install” that also lists installations via Bundler, Bower, npm, and some other utilities in the kitchen sink:

Rust is also used to allow for faster DB queries and joins/includes.
We chose it over Go because it has a package manager (Cargo).
This way we don't have to check in vendor code and not accidentally
make our app even bigger...
Be sure to check in the compiled rust code BTW.

The Lets-Find-Waldos-View-Game

Someone had a great idea of rendering views and compiling them into that god aweful JS language. You’re jumping from views, to assets/javascripts, to public, and for some reason even vendor/assets just to find some HTML that really should be in the views directory. You think it only happens once. You open the views page, there’s one file called index.html.haml. Two lines of “HTML” and they go like this:

#app-name
  %div{"ng-view" => true}

Then you realize it could be refactored to one line.

You end the day going, Where’s 99% of the HTML? Angular Templates…

Conclusion

If you have anything to add to this blog post about behemoth rails apps and the new/modern (dumb, stupid, and poorly thought out) conventions used by the “Rails” developers that don’t actually use the Rails-Way, I’d love to add it in :)

Disclaimer: This blog post is meant for humour. Its not meant to degrade any rails developers or JS developers. Some of these points are actually quite valid and you can actually find quite a bit of meaningfullness from them. Large apps are generally difficult to maintain and those that do manage them do deserve respect. Especially Spree developers :)

hi Morgan, Glad to meet you, may i seek your guidance regarding spree platform, and other ecommerce platforms,thanks,Rao,india

Sat, 17 Jan 2015 02:39:40 -0500

I hope my blog posts are helpful. Spree is just a rails application. Quite often the best way to work with Spree is to simple understand that its just another Rails app. I don’t actually have a knowledge base of other ecommerce platforms besides Spree.

Is it possible to enhance spree to allow vendor to login in backend and add their own products?

Sat, 17 Jan 2015 02:37:17 -0500

You could in theory, but I wouldn’t recommend it. I would recommend creating a new model (MyApp::Vendor) and let it have many products. OR you could assume that all users can have their own “marketplaces”. Basically saying a User has one Marketplace and that Marketplace has many products. That would actually be pretty easy work. Once you’ve built a simple CRUD where a user can list their products, you can start to think about shipments and promotions.

If you truly want to let users access the Spree Admin dashboard, you should take a look at Spree::Ability and Spree::Role.

Hope this helps :)

Customizing Spree: Some Best Practices

Mon, 17 Nov 2014 21:27:00 -0500

In this blog post, I’m going to go over some best practices that I follow with Spree. They come in very handy as you customize it and as your application grows.

Namespace Everything: This is not as simple as you might think…

Quite often I find myself class_evaling Spree. I also find myself including extra Rails Engines into the application such as AlchemyCMS and Forem. Its usually a Spree + Alchemy merge. This can lead to a lot of folders. When I open up the models folder I tend to get this as a list: alchemy, concerns, spree, .keep.

The .keep is a file for version control. Please delete these as you build your application. I find it a best practice to remove .keeps when their presence is no longer needed. I’m also a really good developer, so I know the file structure by heart. Since I can autonomously put files in the correct folder by nature, I simply delete all .keeps and their folders in a rails app. After I’ve removed all the empty folders, I can immediately see how small or large an application is and what they’re doing and what they are not doing. Very nice visual trick; I’m a visual learner.

When I open the spree folder in a model I usually see a mix of models and decorators. Decorators should go into the models folder. They are there to mimic and reopen a current model. But, you shouldn’t place new models inside of a Rails Engine.

Let’s say you decorate the products model from Spree as so:

Spree::Product.class_eval do
  belongs_to :vendor, class_name: Spree::Vendor
end

And then you have your vendor model as so:

module Spree
  class Vendor < Spree::Base
    has_many :products, class_name: Spree::Product
  end
end

I think its great that the product model is being decorated inside of the models folder, but there’s something wrong with the vendor model. You’re going to have a mix of decorators and models all at once, where you should only have those decorators inside of spree, not a new model. We need to put it somewhere else.

Usually, this would mean that the developer would put it at the root of the models, making it Vendor < Spree::Base; end, but again, I don’t think that’s right. The best solution is to actually make a namespace for your own application. Lets say your app is called GroceryStore, then you should name your vendor model:

module GroceryStore
  class Vendor < ::Spree::Base
  end
end

This is much more organized and much more Railsie. You’ll notice that the Spree::Base is being inherited. To remove this, we’ll make our own base model and have it include Spree::Base naturally.

module GroceryStore
  class Base < ActiveRecord::Base
    include ::Spree::Base

    self.abstract_class = true
  end
end

A note on concerns: If you’re making a new concern, it goes into your application namespace (ex: `GroceryStore::MyNewConcern`). If you’re decorating a concern, that goes into the respective engines namespace.

I highly recommend namespacing everything. Especially if you are going to have to be working with one or two or even three Rails Engines.

Deface: No Laundry Lists

I remember working on my first Spree application and phew boy, were the overrides just a laundry list! Basically, you should not be coding your overrides like its 2003.

This is an example of a laundry list.

This is an example of a clean overrides folder.

Notice how in the latter one you can easily find what is and isn’t being overrided, but not in the first one? This is what I mean and its a best practice when it comes to deface. Your file structure in your overrides should match your views file structures. And your views file structure is dictated by Rails, not by you. So if you turn and say “Hey, what if I change the name of my index to home?” then we have some problems; you’re fired.

Use Before Actions

I can’t tell you how many times I see this:

Spree::SomeController.class_eval do
  alias_method :orig_method_name, :method_name

  def method_name
    some_awesome_code
    that_does_something
    hey_there
    orig_method
  end
end

This isn’t good code. This is code that goes against the Rails-Way. Please use before_actions. Please. The corrent way is:

Spree::SomeController.class_eval do
  before_action :awesome_code, only: :method_name

  private

  def awesome_code
    some_awesome_code
    that_does_something
    hey_there
  end
end

And that’s it. Also, please don’t use orig_method or old_method or whatever you can think up. Ruby already has the naming convention down and you should be using that and not your own. Its called super.

super won’t work in this case since we’re overwriting the method and not overriding it. Therefore, when you know you have to do that icky alias_method trick to store the original method, I would actually rather you do this:

Spree::SomeController.class_eval do
  alias_method :super_method_name, :method_name

  ...
end

Mailers

When creating mailers, I expect them to be completely overwritten due to the nature of some applications and of emails in general.

I was once on a project where a team was using Ink. They used Mailchimps inliner to put the CSS inline and then commit the HTML. Don’t ever do this. Please to gosh don’t ever do this. Ever. Ever. Ever. You’ll dig your own hole faster via emails then anywhere else. This is a complete Rails antipattern in everything that Rails stands for.

Due to this, I had to go out and create Blot. Blot is fantastic. I’ve been using it in all my emails and its just made everything so simple. It has a bit more work needed so that you don’t have to do wrapper(class: 'wrapper'), but its already very mature as a solution to keep you from coding like its 1998. To inline your CSS, I would recommend using premailer-rails. (I would recommend to turn comment removal off since Ink uses comments to work with Outlook responsively.) There’s also a lot of work going into the Ink project. I highly recommend you check it out if you haven’t yet and use their CSS as a boilerplate.

Conclusion

When you see something making a mess, take a step back and stop digging your hole. Follow the Rails-Way.

Due to the enormous amount of anti-patterns that I see day in and day out, I have come to the realization that a book is needed to help train people for Spree.

Spree is not for beginners. You should already feel comfortable in Rails before using Spree. This is the #1 reason for poor Spree applications and to change this, I’m writing a book.

If you would like to contribute, please email me and then let me know. The more input and authors, the more we can help the community develop.

Adding Preferences to Spree 2.3

Fri, 12 Sep 2014 20:15:47 -0400

If you checkout this CHANGELOG diff for the Spree 2.3.0 tag you’ll see that preferences were removed from all the models except for Spree::Calculator, Spree::PromotionRule, and Spree::PaymentMethod. If you’re wanting to store some preferences information, I’ll show you how in this blog post.

For our example, we’re going to assume that we have a store that requires us to collect the first and last name of a user. To do this, we’re going to have to add a new column to our user model.

$ rails g migration add_preferences_to_spree_users

Then, within your migration, you would add the new column and its rollback:

class AddPreferencesToSpreeUsers < ActiveRecord::Migration
  def up
    add_column :spree_users, :preferences, :text
  end

  def down
    remove_column :spree_users, :preferences
  end
end

When I was first doing this, I thought that I would use :hstore instead of :text, but it turns out that they actually don’t store it within PG as JSON, just a textual form of some YAML. I can confirm this when I hit up the rails c and investigate the Spree::Calculator model:

pry(main)> Spree::Calculator
=> Spree::Calculator(id: integer, type: string, calculable_id: integer, calculable_type: string, created_at: datetime, updated_at: datetime, preferences: text)

As we can see, it is a text field that :preferences gets stored as.

Once you have this code, we need to actually set up preferences within the spree user model. Here, I show you how to #class_eval it and add in the preferences:

Spree::User.class_eval do
  preference :first_name, :text
  preference :last_name, :text
end

And that’s it! You’re done!

Now its up to you to be able to setup the views/controllers properly, this blog post was just about setting up preferences for Spree 2.3.

Passing Spree Objects from Rails to JavaScript

Sat, 06 Sep 2014 00:42:52 -0400

I hate JavaScript. I really hate JavaScript. Everyone knows I hate JavaScript. I really hate it. Although I do love Dart. I freaking love Dart! I’d substitute “freak” with another word to go along with the way I usually talk, but considering this blog is public, I’ll be polite. JS sucks!

But lately I’ve been working with AngularJS and having to do some frontend development on not just one, but two spree applications at the same time. At first, I thought it was cool. I could collect the data through the Spree API, but somehow that didn’t seem plausible. the Object can be grabbed from the database via the rails and be passed off to the JavaScript via a rails controller and into an AngularJS controller. Hello headache!

This works actually quite well when you’re on development, but it completely falls apart in production. You have to seperate every single JS file for Angular out from Sprockets and that just not fun. When this occurred, I began using Gon gem. Gon was actually quite efficient in sending over some information, but I couldn’t figure out how to sending over the large amounts of information that Spree comes with even at its bare minimums, pushing me to forfeit this attempt and move onto a new way: inline JS or data hooks. I did inline JS…

Then, on my second Spree project, I gave Gon another try. This time I succeeded and carried my knowledge back over to my original project, further developing my knowledge.

First, lets get you Gon:

# Gemfile
gem 'gon'

Now do a bundle and add this line of code directly before your javascript_include_tag:

<!-- app/views/spree/_head.html.erb -->
<%= include_gon %>

That’s it! You have gon installed!

Now then, lets reopen the products controller and give Gon some data:

# app/controllers/spree/products_controller_decorator.rb
Spree::ProductsController.class_eval do
  alias_method :super_show, :show

  def show
    super_show
    gon.product = @product.gon_object
  end
end

Now, Spree uses a before_action to load up the @product method for the #show page. So we know we have access to @product. The original #show method has also been overwritten, so we’ve just aliased a method called super_show to show and continued with our work.

Once done, when you reload the page you’ll get a method missing for the #gon_object method. Lets fix that by reopening the product model class.

# app/models/spree/products_decorator.rb
Spree::Product.class_eval do
  def gon_object
    {
      id: self.id,
      name: self.name,
      description: self.description,
      available_on: self.available_on,
      deleted_at: self.deleted_at
    }
  end
end

Now if you reload the browser, head on over to the product show page, you’ll see your product, but if you head on over to the console, the gon object will be available to you. (One of the reasons I hate JS is how it defines “hashes/dictionaries” as “objects”. This I find straight up vexing. One small reason I <3 Dart.) Now lets write some JS.

If you type gon.product you’ll notice that you get that product hash right back out. I’m going to let you in on a secret, we didn’t have to write that #gon_object method. We could have just said that gon.product = @product and be done with it. Except this wouldn’t work because this is the exact same hash that you get when you set it equal to @product; there’s too little data.

Try this:

> gon.product.price
undefined

And that is why we have our own custom #gon_object method my friend. You see, the price of an object is stored not in the spree_products table, but in the spree_prices table. You can see an example here of the SQL doing on via the Rails console:

> Spree::Product.first.price
  Spree::Product Load (18.3ms)  SELECT  "spree_products".* FROM "spree_products"  WHERE "spree_products"."deleted_at" IS NULL  ORDER BY "spree_products"."id" ASC LIMIT 1
  Spree::Variant Load (3.4ms)  SELECT  "spree_variants".* FROM "spree_variants"  WHERE "spree_variants"."deleted_at" IS NULL AND "spree_variants"."product_id" = $1 AND "spree_variants"."is_master" = 't' LIMIT 1  [["product_id", 1]]
  Spree::Preference Load (0.6ms)  SELECT  "spree_preferences".* FROM "spree_preferences"  WHERE "spree_preferences"."key" = 'spree/app_configuration/currency' LIMIT 1
  Spree::Price Load (1.1ms)  SELECT  "spree_prices".* FROM "spree_prices"  WHERE "spree_prices"."variant_id" = $1 AND "spree_prices"."currency" = 'USD' LIMIT 1  [["variant_id", 1]]
 => #<BigDecimal:7ff17a31f218,'0.1599E2',18(18)>

Now then, lets edit that hash inside from the #gon_object method inside of Spree::Product. To get the price, we’ll just add a new key called price and give it a pretty simple key:

{
  ...
  price: self.price,
  ...
}

Now, if you go back into the browser console, you’ll notice that it gets written out as a string. (Why is everything saved as a freaking string in JS? Did you know that Dart is optionally typed?) To fixe this, we update the value to self.price.to_f to make it a float number.

Now that you have a way to get custom information from your model to your JS, lets give you a way to get those ActiveRecord relationships working.

Since you’re on the product page, I’m going to assume you need to get at all the different variants for your product. Luckily in spree we can just do:

{
  ...
  variants: self.variants,
  ...
}

That’s awesome! Now we have access to an array of variants! If you have to make variants customized (and I bet you will at some point to get anything useful out of it) then you’ll need to reopen the variants model and add a #gon_object method inside of it as well.

To do so, lets first update our variants value:

{
  ...
  variants: self.variants.map(&:gon_object)
  ...
}

Now, lets reopen the Spree variants model and give it some awesomeness!

Spree::Variant.class_eval do
  def gon_object
    {
      id: self.id,
      sku: self.sku,
      weight: self.weight.to_f,
      height: self.height.to_f,
      width: self.width.to_f,
      depth: self.depth.to_f,
      deleted_at: self.deleted_at,
      is_master: self.is_master,
      cost_price: self.cost_price.to_f,
      position: self.position,
      cost_currency: self.cost_currency,
      track_inventory: self.track_inventory,
      tax_category: self.tax_category
    }
  end
end

This is awesome! Now we know exactly what what data we’re sending to the browser! If you look at the very last piece of data in the hash, you can see that we’re trying to get the tax_category for the variant. This requires use to traverse from our initial variant model, over to the product, and out to the spree_tax_categories table to get our row of data. I’m mentioning this for two reasons. One, its a really good reason for writing your own method for Gon and two, you need to think about n+1 problems. When this happens, please head over to where you originally called the #gon_object and add an #includes method for that table:

# app/models/spree/product_decorator.rb
{
  ...
  variant: self.variants.includes(:variants).map(&:gon_object)
  ...
}

And there we go, you’re all set. You now know how to pass data from Spree to JS large frontend applications. Woot!

Background Jobs and Spree

Fri, 29 Aug 2014 15:10:44 -0400

When working with Spree, you’ll need to at some point move some of the work onto a backgorund process. When this happens, you end up having a background smackdown on what to use. There’s delayed jobs, resque, and sidekiq. Not only that, but how optimized is Spree for background jobs?

Well, to start I’ve worked on 3 spree applications in total. Yes, 3. One used delayed jobs, one used resque, and one used sidekiq.

Now, delayed jobs is great if you don’t want to hook redis up. Personelly, I don’t think its the best option for Spree. Spree already goes a bit overkill on ActiveRecord and I feel like delayed jobs might just add more of a weight to it. Not only that, but both resque and sidekiq provide better services via redis, which is a lot faster. In other words, I don’t care if you don’t want to hook redis up to an app, you need to.

When I began working with resque, it was just amazing. Setting up a worker class was also pretty easy and sending all the data over to redis was handled from the app’s end. When something went wrong, I went straight to the dashboard to figure it out. Moving to resque? Do it.

But here’s the thing about resque: its for applications that are high in CPU, but from my experiences, Spree is more memory high than anything else. This is where sidekiq comes in. Not only that, but from working with Rails Dog, I’ve discovered that resque can have a bit of a “split brain”. Due to this, I think it would be best to switch from resque over to sidekiq if one is using resque. The best part: its an easy process.

Getting Started with Spree, Wombat, and Ninefold

Mon, 18 Aug 2014 20:58:00 -0400

Imagine developing an application where you need to grab shipping data in real time, send products, inventory, and order information over at least ten different APIs including Amazon and eBay. When I first heard that I had to do this, there could only be one answer: “Challenge accepted”.

If you’re reading this, then you probably know what Ninefold does and why you would use Spree, but let me introduce you to Wombat: the operating system for ecommerce applications.

Now, Wombat has an enormous amount of documentation on how to use their app, but to be frank: they don’t have a lot yet when it comes to hooking Wombat up to Spree.

In this blog post, we’re going to go from start to finish on building a Wombat application and then deploying it onto Ninefold.

Getting Started with Wombat

Lets first install spree with these commands:

$ rails new wombat_app --database postgresql
$ cd wombat_app
$ spree install -A

Now that your store is set up, lets get Wombat installed. Simply add Wombat to your Gemfile:

gem 'spree_wombat', github: 'spree/spree_wombat', branch: '2-3-stable'

And when you’re ready:

$ bundle
$ bundle exec rails g spree_wombat:install

Once that is finished, head over to Wombat and sign up for a two week trial. When you’re set up, update config/initializers/wombat.rb to include your connection token and ID.

Wombat Configuration

Inside of the Wombat configuration, you’ll see that there’s a #push_objects method. In here, you will have an array of strings that Wombat can use to identify which object you want to send up to Wombat.

Inside of the #payload_builder this is where you’ll add the JSON to get pushed up to Wombat. The :root is used to tell Wombat exactly what type of JSON you’re giving it. You want this because in Wombat, you call your users “customers”, therefore you would need a way to specify how Wombat should interpret the data vs your application (this is how Wombat is made universal and app-agnostic). Now, to grab the JSON that Wombat will need to send up to cloud, you use a serializer. Wombat comes with some serializers upfront (except a user serializer, but I’ll show you how to make that further on).

Finally, we have #push_url which will push the data to wombat. Leave it to its default unless you customize your Wombat profile; you’ll know if you need to change it.

Pushing Data Manually to Wombat

If you set up Spree and Wombat correctly, then you should be able to send two Spree example orders up to Wombat. To do this, lets enter the rails console (with rails c):

> Spree::Wombat::Client.push_batches("Spree::Order")

If you check out your Wombat page, you should see that those orders have been pushed up. If you want to send all of the objects that you have defined in Wombat (and there are times that you will want to do this), then you would use Wombat’s built in rake task:

$ bundle exec rake wombat:push_it

If you check out Wombat, you should see all of your products up there as well.

Adding a Wombat Serializer

This is all fine and dandy, but you happen to have some shipments you want up on Wombat as well. Thankfully, Wombat already has this shipment serializer predone for you! Lets set this up within our application.

Set your #push_objects to include the "Spree::Shipment" model:

config.push_objects = ["Spree::Order", "Spree::Product", "Spree::Shipment"]

Now, inside of your #payload_builder, you’ll want to make sure you add it as a key ("Spree::Shipment") with a Hash as a value ({ serializer: "Spree::Wombat::ShipmentSerializer", root: "shipments" }). This should give you:

config.payload_builder = {
  "Spree::Order" => { serializer: "Spree::Wombat::OrderSerializer", root: "orders" },
  "Spree::Product" => { serializer: "Spree::Wombat::ProductSerializer", root: "products" },
  "Spree::Shipment" => { serializer: "Spree::Wombat::ShipmentSerializer", root: "shipments" }
}

Now, if you perform Spree::Wombat::Client.push_batches("Spree::Shipment") you should be able to see it in Wombat.

Adding a Custom Serializer

You now have three objects hitting Wombat. Wombat lists four objects it will take by defualt. Let’s give it the final one: customers!

To begin, we will generate the serializer using Wombat’s serializer generator:

bundle exec rails g spree_wombat:serializer Spree::User UserSerializer

Within the app/serializers/user_serializer.rb this is the code that I use:

require 'active_model/serializer'

class UserSerializer < ActiveModel::Serializer
  attributes :id, :firstname, :lastname, :email, :shipping_address, :billing_address

  def id
    object.id
  end

  def firstname
    object.try :first_name
  end

  def lastname
    object.try :last_name
  end

  def email
    object.email
  end

  def shipping_address
    address_hash object.shipping_address
  end

  def billing_address
    address_hash object.billing_address
  end

  private

  def address_hash(address)
    {
      address1: address.address1,
      address2: address.address2,
      zipcode: address.zipcode,
      city: address.city,
      state: address.state.name,
      country: address.country.name,
      phone: address.phone
    }
  end
end

Your #push_objects should now look like:

config.push_objects = ["Spree::Order", "Spree::Product", "Spree::Shipment", "Spree::User"]

And your #payload_builder should be:

config.payload_builder = {
  "Spree::Order" => { serializer: "Spree::Wombat::OrderSerializer", root: "orders" },
  "Spree::Product" => { serializer: "Spree::Wombat::ProductSerializer", root: "products" },
  "Spree::Shipment" => { serializer: "Spree::Wombat::ShipmentSerializer", root: "shipments" },
  "Spree::User" => { serializer: "UserSerializer", root: "customers" }
}

Using After Commits with Wombat

Now that this is all done, you’re probably tired of doing it manually. Using decorators, you can add some after_commits to push the model’s data up to Wombat when an ActiveRecord transaction has finished. Here’s an example using the Spree::Shipment model:

# app/models/spree/shipment_decorator.rb
Spree::Shipment.class_eval do
  after_commit :wombat_push_spree_shipments, on: [:create, :update]

  private

  def wombat_push_spree_shipments
    Spree::Wombat::Client.push_batches("Spree::Shipment")
  end
end

Now, if you create a new shipment (and follow this pattern for your other three models) then you should be able to get your data up to wombat in realtime.

Using Workers with Wombat

There’s an issue with this though. What if the page takes two seconds to load and eight seconds to get updated on Wombat? That means that you’ll have eight seconds of blocking code and the amount of time on the server to render the next page for the user would be ten seconds. To get around this, we’re going to set up a Wombat worker and get it done using Resque.

To begin, we’re going to need to install Redis. To do so, follow Redis Rails installation instructions. When finished, add Resque to your Gemfile:

gem 'resque', '~> 1.25', require: 'resque/server'

After bundling, start up these three servers:

web: rails s
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

You should be good to go. Now, inside fo your Spree::Shipment model, update it to:

Spree::Shipment.class_eval do
  after_commit :wombat_push_spree_shipments, on: [:create, :update]

  private

  def wombat_push_spree_shipments
    Resque.enqueue(WombatWorker, "Spree::Shipment")
  end
end

The only ine that we’ve changed is line 7 where we state that we’re going to be using Resque. The first argument is WombatWorker which is the class of the worker that will handle anything and everything Wombat. First, in your application.rb add the workers directory to your load path:

# Load application's workers
Dir.glob(File.join(File.dirname(__FILE__), "../app/workers/*_worker.rb")) do |c|
  Rails.configuration.cache_classes ? require(c) : load(c)
end

When finished, restart your web server and make a new file called app/workers/wombat_worker.rb:

# app/workers/wombat_worker.rb
class WombatWorker
  @queue = :wombat_worker_queue

  def self.perform(wombat_payload)
    Spree::Wombat::Client.push_batches(wombat_payload)
  end
end

Using @queue we name the queue using a symbol and then use #perform to execute the worker code. Here, wombat_payload will be whatever our second argument is in the Resque.enqueue method that we added within the spree shipment decorator.

Deploying to Ninefold

Lets get this app onto Ninefold. First, we’ll need a Procfile:

# Procfile
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

Push up all your code to Github and then head over to Ninefold to sign up as a new user.

When done, sign in and create a new application. Select where you’re storing your code (such as Github) and then you should be on step 2. If not, you’ll be asked to sign into Github through Ninefold. Now, you specify the account, repo, and which branch or release that you would like to deploy to. It will then ensure that you are using PostgreSQL, that you do not have rails_12factor gem, and that your application is a valid Rails app.

On step 3, you get to choose your architecture. You’re going to need a web server, so go ahead and make sure you’re using the 2GB - 1vCPU in whichever region is closest to you. Make sure you have a dedicated PG database server for your app (makes it easy to scale). Yes, you would like a background worker for your app and you will want it dedicated. Also make sure that this is a 1GB - 1vCPU server. Finally, push the “Next” button and you should be on Step 4 deployin gyour application

Wrapping Up

Throughout this blog post, you have discovered how to install Spree and Wombat, send data to Wombat, set up serializers, set up a WombatWorker, and finally deploy it onto production using Ninefold. I hope this blog post was informative and useful. Have fun!

Zeus with Foreman

Tue, 05 Aug 2014 18:02:42 -0400

Quite often, I find that Foreman and Zeus don’t always go hand in hand, so in this quick write up, I’m going to show you how to get the power of Zeus inside of the great Foreman.

To start, lets assume that this is what our Profile looks like:

web: bundle exec thin start -p $PORT
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

That’s great, except if we want to run zeus with it, we have to have two tabs open. One tab runs zeus start and the other tab run the Procfile as:

web: zeus s
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

OK, that’s kinda works, but now we have two tabs. Let’s change that:

zeus: zeus start
web: zeus s
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

This breaks one in a while since Foreman will start each process randomly giving us the Can't connect to master. Run zeus start first. error.

To get past this, we will update the Procfile to:

zeus: zeus start
web: sleep 2 && zeus s
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

Now we can have web sleep for 2 seconds, giving it enough time to detect zeus start and therefore stalling until it receives the green light from Zeus.

We’re not done yet. You may notice that the output is not so pretty anymore. Instead, try this:

zeus: zeus start &> /dev/null
web: sleep 2 && zeus s
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

This is great, but now we don’t know when Zeus is starting. To fix this we’ll add a simple echo:

zeus: echo "Starting Zeus..." && zeus start &> /dev/null
web: sleep 2 && zeus s
redis: redis-server redis.conf
worker: bundle exec rake resque:work QUEUE=* TERM_CHILD=1

And there we go, you now know how to get Zeus and Foreman running together. Have fun!

We are unable to calculate shipping rates for the selected items.

Sat, 19 Jul 2014 00:59:00 -0400

In Spree, I run into this error a LOT and it always takes some time to debug, so here, I am not only going to solve it and make a detailed listing of what the possible issues are, but make sure that I don’t spend another two hours going through this head ache.

What happens is that when you are using Spree, you will hit the checkout page and you will submit your address information. On submission you ge this infamous error.

This error is caused because you have either made a product with no shipping information (which is easy to solve) or your tax information is not correct…

to solve the shipping method error, just slip over to the admin product edit page and see if the product you’re trying to but has a shipping method. It usually does and this unlikely the error. Anywho, just select Default in the drop down if you’re on a brand new store.

If, however, this is not the solution (and it probably isn’t), then you need to do some taxes. To start, lets talk about zones. Zones in spree define exactly in what areas of the world some tax information applies to. This a great junction to introduct the problem because (a) you might not have a zone set up for your default tax or (b) the problem now lies in either the countries/states or the tax information.

In the right side bar to the configuration, do you see a “States” button? If you don’t you might want to load up this data into your app:

The Countries.

The States.

The Zones.

And since Spree (as of 2.3.1) does not contain the Canadian states:

canada = Spree::Country.find_by_name('Canada')
Spree::State.create!([
 { "name" => "Yukon", "abbr" => "YT", country: canada },
 { "name" => "Nunavut", "abbr" => "NU", country: canada },
 { "name" => "British Columbia", "abbr" => "BC", country: canada },
 { "name" => "Alberta", "abbr" => "AB", country: canada },
 { "name" => "Saskatchewan", "abbr" => "SK", country: canada },
 { "name" => "Manitoba", "abbr" => "MB", country: canada },
 { "name" => "Ontario", "abbr" => "ON", country: canada },
 { "name" => "Quebec", "abbr" => "QC", country: canada },
 { "name" => "New Brunswick", "abbr" => "NB", country: canada },
 { "name" => "Newfoundland and Labrador", "abbr" => "NL", country: canada },
 { "name" => "Nova Scotia", "abbr" => "NS", country: canada },
 { "name" => "Prince Edward Island", "abbr" => "PE", country: canada },
 { "name" => "Northwest Territories", "abbr" => "NT", country: canada }
])

And now your app works for the geography. Lets hook up the tax information.

There are currently three settings for taxes: Tax Categories, Tax Rates, and Tax Settings.

We’ll go ahead and create a tax category and tax rate for clothing using Spree Sample’s data.

Spree::TaxCategory.create!(:name => "Clothing")
north_america = Spree::Zone.find_by_name!("North America")
clothing = Spree::TaxCategory.find_by_name!("Clothing")
tax_rate = Spree::TaxRate.create(
  :name => "North America",
  :zone => north_america,
  :amount => 0.05,
  :tax_category => clothing)
tax_rate.calculator = Spree::Calculator::DefaultTax.create!
tax_rate.save!

Now, if you head into the admin section and set clothing as the default and the North America zone as your default you should be good to go from the tax/geo section of this error.

But, wait, remember that this was also being caused because of the shipping information?

Well, you can solve this by adding in shipping information, or rather, shipping methods:

begin
  north_america = Spree::Zone.find_by_name!("North America")
rescue ActiveRecord::RecordNotFound
  puts "Couldn't find 'North America' zone. Did you run `rake db:seed` first?"
  puts "That task will set up the countries, states and zones required for Spree."
  exit
end

europe_vat = Spree::Zone.find_by_name!("EU_VAT")
shipping_category = Spree::ShippingCategory.find_or_create_by!(name: 'Default')

Spree::ShippingMethod.create!([
  {
    :name => "UPS Ground (USD)",
    :zones => [north_america],
    :calculator => Spree::Calculator::Shipping::FlatRate.create!,
    :shipping_categories => [shipping_category]
  },
  {
    :name => "UPS Two Day (USD)",
    :zones => [north_america],
    :calculator => Spree::Calculator::Shipping::FlatRate.create!,
    :shipping_categories => [shipping_category]
  },
  {
    :name => "UPS One Day (USD)",
    :zones => [north_america],
    :calculator => Spree::Calculator::Shipping::FlatRate.create!,
    :shipping_categories => [shipping_category]
  },
  {
    :name => "UPS Ground (EU)",
    :zones => [europe_vat],
    :calculator => Spree::Calculator::Shipping::FlatRate.create!,
    :shipping_categories => [shipping_category]
  },
  {
    :name => "UPS Ground (EUR)",
    :zones => [europe_vat],
    :calculator => Spree::Calculator::Shipping::FlatRate.create!,
    :shipping_categories => [shipping_category]
  }
])

{
  "UPS Ground (USD)" => [5, "USD"],
  "UPS Ground (EU)" => [5, "USD"],
  "UPS One Day (USD)" => [15, "USD"],
  "UPS Two Day (USD)" => [10, "USD"],
  "UPS Ground (EUR)" => [8, "EUR"]
}.each do |shipping_method_name, (price, currency)|
  shipping_method = Spree::ShippingMethod.find_by_name!(shipping_method_name)
  shipping_method.calculator.preferences = {
    amount: price,
    currency: currency
  }
  shipping_method.calculator.save!
  shipping_method.save!
end

Hope that works for you! It works for me. Have at it.

Getting Started with Spree

Tue, 24 Jun 2014 23:43:04 -0400

Spree is an ecommerce framework for Ruby on Rails that is currently at version 2.2.2. I often find that individuals come to spree when Magento or Shopify just can’t serve their needs anymore and they need an even more custom solution.

To get started, we first need to install spree:

$ gem install spree

OK, that was fun, now let’s go ahead and make a new rails project:

$ rails _4.0.5_ new spree_app

Now that you have that done, try this out:

$ spree install spree_app

Or, if you’ve already navigated into spree_app:

$ spree install .

You will get a number of questions:

Would you like to install the default gateways? (Recommended) (yes/no) [yes]
Would you like to install the default authentication system? (yes/no) [yes]
Would you like to run the migrations? (yes/no) [yes]
Would you like to load the seed data? (yes/no) [yes]
Would you like to load the sample data? (yes/no) [yes]

Right now, please answer yes (the default) to all of them. When starting a new spree project, I often do spree install . -A which auto-accepts all parameters.

Now, as its installing, it will stop and ask you to create an Admin user:

Create the admin user (press enter for defaults).
Email [spree@example.com]:
Password [spree123]:

Just push the default options so that we can get going.

Throughout the installation, you might have noticed this warning:

[WARNING] You are not setting Devise.secret_key within your application!
You must set this in config/initializers/devise.rb. Here's an example:

Devise.secret_key = "a0c5e56c8764a93b03fce02083f4aed18aef63ef4d7be33f351accb002d4e2187ac6ba4a78090c341281f51a6abebd4fe499"

Now I’m going to tell you how to solve this. If you open up your Gemfile it should look like this:

source 'https://rubygems.org'

gem 'rails', '4.0.5'
gem 'sqlite3'

gem 'sass-rails', '~> 4.0.2'
gem 'uglifier', '>= 1.3.0'
gem 'coffee-rails', '~> 4.0.0'

gem 'jquery-rails'
gem 'turbolinks'
gem 'jbuilder', '~> 1.2'

group :doc do
  gem 'sdoc', require: false
end

gem 'spree', '2.2.2'
gem 'spree_gateway', github: 'spree/spree_gateway', branch: '2-2-stable'
gem 'spree_auth_devise', github: 'spree/spree_auth_devise', branch: '2-2-stable'

Notice at the bottom there were 3 gems that got installed. spree is the main project and is definately what you wanted to install. There’s also two more: spree_gateway and spree_auth_devise. spree_gateway basically handles active merchant, stripe, checks, stuff that allows you to receive money. spree_auth_devise is used for authenticating users. Its different from devise in that it requires you to be running devise; since bundler detects that you don’t have it in your Gemfile, it does it for you - the magic of Bundler.

Because spree_auth_devise is its own gem, it actually never got installed fully when you ran spree install. Therefore, we have to do another installation for spree_auth_devise. Here’s how you install spree_auth_devise:

$ bundle exec rails g spree:auth:install

you will see the error pop up one more time and then directly after that you get:

create  config/initializers/devise.rb

And there we go, its gone. Alternatively, you could have also created the initializer yourself and copy and pasted the devise secret key. To generate secret keys, you can use rake secret like so:

$ rake secret
9ba50700679fc17712ce1a1538bb9dd05c31038e12d1155cb8d437a9dd69a0a2fc8b7f9425f254c77d5bfa0587c9e50df0931f3803d947eb5fe13c7d1b6cec00

And there you go, now lets start the application:

$ rails s

IF you head over to localhost:3000 you will see the spree skeleton. Awesome! But, you probably don’t like that design, so lets get bootstrap in there! In your Gemfile, add:

gem 'spree_bootstrap_frontend', github: '200Creative/spree_bootstrap_frontend', branch: '2-2-stable'

Now, bundle and then run:

$ rails generate spree_bootstrap_frontend:install

It should now ask you if you would like to overwrite one of your assets. Answer Y.

If everything is working for you right now, just go and type in rails s and watch the design completely change for the better.

You can now change the theme of you spree application with ease!