One of the most important decisions you will make when launching your digital brand is which eCommerce platform you build your store with. Typically, there are three categories to choose from:

* **SaaS platforms** are online software solutions that handle all the complexity of building and running a store. In exchange for a recurring license fee, these tools provide a storefront your customers can access as well as a backend to to manage your store. They are by far the quickest and easiest solution to get started. Popular examples in this category are [Shopify](https://www.shopify.com/) and [BigCommerce](https://www.bigcommerce.com/).

* **Open-source platforms** are ready-made software packages that provide similar functionality to what you could get with a SaaS platform. Because they are open-source, these platforms can be customized, although many of them are not built for that. Furthermore, you have to host them in your own infrastructure. Popular examples are [WooCommerce](http://woocommerce.com/) and [Prestashop](https://www.prestashop.com/).

* **Open-source frameworks** are software solutions that provide the basic functionality you need to build your store. They vary in functionality and underlying technology, but most of them are built to create extremely custom experiences and provide a very high degree of flexibility, at the cost of a steeper learning curve and a larger upfront investment. Popular examples are [Solidus](https://solidus.io/) and [Saleor](https://saleor.io/).
The main difference between SaaS platforms and open-source platforms is the pricing model: SaaS platforms require paying a recurring license fees, while most open-source platforms are free. In terms of functionality, however, they are pretty similar, so we will instead focus on the differences between SaaS platforms and open-source frameworks.

## Cost of ownership

SaaS platforms have two main pricing models: you either pay a fixed fee every month/year, or a percentage of your store’s sales volume. This results in a pricing model that scales with your store, but **it also means you are paying money just to keep your store online instead of investing in its continuous evolution.**

Most open-source frameworks, on the other hand, are entirely free to use, but you need to hire a development team that will build, launch and maintain your store. While this model requires a larger upfront investment, **it’s also a better fit for those entrepreneurs who are serious about investing in the technology that powers their business.**

If you can afford a larger upfront investment and you expect your brand to scale seriously, going with an open-source framework will reduce your total cost of ownership while creating more opportunities than you could get with an off-the-shelf solution.

## Customization possibilities

SaaS platforms offer a great starting experience with no customization work needed. This is really helpful for people who are just getting their feet wet in the eCommerce industry: **if you don’t know how to create a good UX and just want to start selling, a SaaS solution will help you.** This kind of simplicity doesn’t come for free, though: **SaaS platforms are not always easy to customize, and in certain cases you are stuck with the default experience they provide.**

Going with an open-source framework means you’ll have to figure out more stuff by yourself, but **it also affords you the flexibility to customize each and every aspect of your store however you see fit,** allowing you to truly innovate the buying experience rather than being one more droplet in a sea of digital brands.

The most prominent online brands became memorable not just because of their products, but because of the experience they created around all brand interactions. **If eCommerce is an important channel for you, you need to start seeing yourself as an experience company,** and treat technology as a first-class citizen.

## Data ownership

**SaaS platforms, unfortunately, act by their very nature as middlemen between you and your customers.** Because you are not hosting your infrastructure when you adopt a SaaS solution, you lose direct access to a lot of potentially useful information. These platforms try to make up for the lack of data ownership by providing out-of-the-box reporting tools, but they often fall short of brand expectations.

**With an open-source framework, you will always have complete access to all the data generated by your store.** This data can be used in any way you see fit: you can either customize your platform to generate advanced reports internally, or connect an external business intelligence tool that will help you take full advantage of all the information at your disposal.

Being a digital brands allows you to use data to your advantage: by accessing information that is not always available to traditional brick-and-mortar retailers, you can make smarter decisions, which reduces your costs and helps you stay competitive. The paradox here is that **data ownership is even more important for smaller brands, which don’t have access to economies of scale and can afford fewer mistakes.**

## Time to market

Because most SaaS solutions provide all the tools you need to start an online business out of the box, it will always be quicker to get your brand started with a SaaS platform than with an open-source framework, at least for a basic store. **If you’re in a hurry to get started and cannot afford to wait, you should definitely look into SaaS.**

With that said, one aspect to keep in consideration is the velocity of your team when evolving your store in response to market conditions. **In the hands of a skilled engineering team, an eCommerce framework will be not only quicker to adapt, but because it’s built to be customized, it will also allow you to make optimizations that stand the test of time.** SaaS platforms, on the other hand, often require ugly hacks that cost you more time in ongoing maintenance than for their initial development.

For most brands, time to market for the initial launch is not a relevant factor. On the other hand, time to market in capitalizing new opportunities and evolving your eCommerce experience can make or break a digital brand.

## So… which one is it?

As you have seen, there are different factors to take into consideration when choosing the best eCommerce platform for your needs. Most of them boil down to two key aspects: experience and vision.

**If you are only getting started in eCommerce, or think of your brand mainly as a product company, you should probably consider SaaS options.** They will make selling online a no-brainer, at the cost of technical limitations and a higher total cost of ownership.

**If you are an eCommerce veteran, or consider customer experience to be paramount in building your brand, you should instead going with an open-source framework**, making a larger upfront investment in order to have a flexible platform that will allow you to deliver a completely custom experience.

What Can Open Source Do for eCommerce?

Nebulab is one of the most involved companies in Solidus' growth, and we
couldn't miss this year's [**SolidusConf**](https://conf.solidus.io/) in
wonderful Salt Lake City.

The conference format has always been quite unique: two days of talks and two
more spent hacking on Solidus with the rest of the Community on whatever could
benefit our beloved open-source platform.

What better way for the community to step up and show how much they care about
Solidus?

We've spent four incredible days in Salt Lake City at SolidusConf 2019, and
here's a recap of what we loved the most about this conference.

### 1. Transversal topics content

One great thing about SolidusConf is not being too Solidus-centered. At each
edition, the Solidus platform is the center of gravity naturally, but the
talks cover all aspects of the eCommerce industry. This makes the conference
enjoyable both for people that are new to Solidus and for experienced Solidus
developers that want to look at new things.

This year was no different, and I'm proud to say that we covered topics well
outside the typical eCommerce conferences. In fact, we had presentations
about **Tech Leadership** from Ryan Cromwell, **Code Quality Metrics** from
Ernesto Tagwerker, **Accessibility** from Jen Luker,
**Breaking Up The Monolith With Emotional Intelligence**
from Braden Douglass, and **Refactoring Legacy Code** from Jason Swett.

There were also tech talks on practices that are being used in Solidus apps,
but which can also be employed in any Ruby on Rails application. To name a
few: Taylor Scott showed **How to deploy Solidus on AWS Elastic Beanstalk,**
automating operations with GitLab CI/CD, and Thomas Sample presented an
impressive **Ultimate guide on SEO** techniques to improve website pages
(Thomas is one of the Solidus Stakeholders, and he also made a very inspiring
call for technical and financial support for the Solidus platform).

Of course, we had a few talks strongly tied to the Solidus world too. Peter
Berkenbosch talked about **Solidus' less-known extension points**. Joel Saupe
presented the work he and his team did to create a useful
**Solidus JavaScript SDK** that interacts with the Solidus API. Sean Denny
explained how Solidus stakeholders are bringing Solidus from being dependent
on a single company to being "**Community-Driven Solidus"**, which means a
self-organized, financially independent project based on community donations
and volunteer work.

### 2. The opportunity to talk to anyone

Small conferences are fantastic because they give you the opportunity to
meet and talk to anyone involved easily: attendees, speakers, and organizers.
We had a great time discussing ideas presented in the conference talks, trying
to get more information and better understand the motivations behind them.

The two late-evening parties, in particular, were ideal for this purpose. We
could hang out in front of a tasty beer (well.. more than one!) in spectacular
Salt Lake City spots.

The first party, sponsored by Engine, was at the **Quarters Arcade Bar**, a
place with delicious drinks and all kinds of arcade videogames and pinballs:
the perfect place for a bunch of nerds!

[![](https://cdn.sanity.io/images/kqgmf0g2/production/d2fe8d7721e636de093eb350cc62f1c427a7008e-1386x1634.png?w=450&fit=scale)](https://twitter.com/pberkenbosch/status/1186886104374534144?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1186886104374534144%7Ctwgr%5E25be1bece76187b176825291e46b6b2e7d032c80%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnebulab.com%2Fblog%2Fsolidus-conf-2019-3-reasons-that-made-us-love-it)

The second party, sponsored by Boomer Digital, had fewer video games, but a
wider choice of high-quality local craft beers. The **Beer Bar** context
was excellent for creating small discussion groups about Solidus, eCommerce,
and our life outside this world! It was so delightful to build real human
connections with people from all over the world.

### 3. Directional and effective for the Community

Another reason why we loved this edition is that we had the opportunity to
talk to other Community members about the direction of Solidus.

This is something we discussed a lot both internally and with the rest of the
Solidus stakeholders, and we couldn't be happier to share our current plans
with the Community at large.

Curious to know the big news about the future of Solidus? Here you are!

#### Solidus Extensions

Our teammate Alessandro presented Nebulab's vision for
**the future of Solidus extensions**.

Extensions used to be second-class citizens, from now on they will become the
standard way to build new business value for Solidus online stores.

[![](https://cdn.sanity.io/images/kqgmf0g2/production/e5f4c2bcfa78e1faa53ec459ae364988c1120f17-1386x1490.png?w=450&fit=scale)](https://twitter.com/SolidusIO/status/1186397535302238208?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1186397535302238208%7Ctwgr%5E25be1bece76187b176825291e46b6b2e7d032c80%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnebulab.com%2Fblog%2Fsolidus-conf-2019-3-reasons-that-made-us-love-it)

There's so much work to do, but now that this goal is public and shared,
it will be easier to accomplish it together with other Community members.

#### Solidus Roadmap

We've also opened a discussion about the **Solidus Roadmap**.

It was clear that the Community was expecting something from Nebulab. Being
the main contributors at the moment, we have the responsibility to direct
the Community's efforts towards shared goals.

This is important for two main reasons:

* It helps contributors understand how to prioritize their time;
* It helps the Community understand what they can expect from the future of
  the platform, and how Solidus will help them meet their business objectives.

Gregor MacDougall and I, as Core Team members, did a quick lightning talk to
explain the purpose and process behind the roadmap's creation. Instead of
starting from the high-level needs of a single company, we created a framework
that allows us to do the opposite: we analyzed the market size, segmentation,
and trends, competitors, etc. ... All these data led to a SWOT analysis, that
enabled us to better understand Solidus' weaknesses and threats and then how
to transform them respectively into strengths and opportunities.

[![](https://cdn.sanity.io/images/kqgmf0g2/production/c8986d07ab4e1555f06c1154662ca9cd924d8174-1386x1488.png?w=450&fit=scale)](https://twitter.com/explore?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1186765383182749701%7Ctwgr%5E25be1bece76187b176825291e46b6b2e7d032c80%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnebulab.com%2Fblog%2Fsolidus-conf-2019-3-reasons-that-made-us-love-it)

This conversation continued on the first Hack Day, during which we had our
first open stakeholders meeting ever! The main topic was the presentation
of the roadmap with a more in-depth explanation of the rationale behind each
topic and task.

[![](https://cdn.sanity.io/images/kqgmf0g2/production/92a607c783b139228f821dcccf950218dc14463c-1380x1370.png?w=450&fit=scale)](https://twitter.com/explore?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1187519153499987970%7Ctwgr%5E25be1bece76187b176825291e46b6b2e7d032c80%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnebulab.com%2Fblog%2Fsolidus-conf-2019-3-reasons-that-made-us-love-it)

We are planning to publish an official Roadmap as soon as we reach a
consensus on the roadmap's priorities. If you want to have a voice in the
future of Solidus, you can join the stakeholders' group with a monthly
donation through
[**Solidus' Open Collective page**](https://opencollective.com/solidus)!

## More committed than ever

For us, being part of the Solidus Community is about sharing our enthusiasm
for open-source eCommerce with our fellow community members. That's why we
loved attending and speaking at SolidusConf 2019. We learned a lot, and we
hope that this kind of initiative will communicate how strong and cohesive
the Solidus Community is.

[![](https://cdn.sanity.io/images/kqgmf0g2/production/2fec6f853fe49d7519d6b52fe1df8c05e1979768-1386x1428.png?w=450&fit=scale)](https://twitter.com/SolidusIO/status/1187398717776769026?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1187398717776769026%7Ctwgr%5E25be1bece76187b176825291e46b6b2e7d032c80%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnebulab.com%2Fblog%2Fsolidus-conf-2019-3-reasons-that-made-us-love-it)

I'm sure to speak on behalf of everyone in the Community when I say that we
are now more committed than ever and already looking forward to the next
SolidusConf!

Here are some extra pictures:

![SolidusConf 2019 Speakers Dinner](https://cdn.sanity.io/images/kqgmf0g2/production/405bd74631219c0d1a0e5b7e895faf9ee5b33731-800x601.jpg?fit=clip)
*Having fun at the speakers dinner.*

![SolidusConf 2019 Salt Lake Marina](https://cdn.sanity.io/images/kqgmf0g2/production/a57d1ad27fb5529e4d3365ca409a316db5feea85-800x458.jpg?fit=clip)
*A quick tour at the Salt Lake Marina.*

![SolidusConf 2019 Mouintains view](https://cdn.sanity.io/images/kqgmf0g2/production/c4e104faea3123311a874da0fb8d0dd1cdb4b15c-800x500.jpg?fit=clip)
*Mountains you can see from Salt Lake City.*

![SolidusConf 2019 Roadmap discussion](https://cdn.sanity.io/images/kqgmf0g2/production/878edbb9ed26108d95c40a23e0c527e8ea57f841-800x509.jpg?fit=clip)
*A frame from the Roadmap discussion.*

![SolidusConf 2019 Hackdays](https://cdn.sanity.io/images/kqgmf0g2/production/1ef790cea9ca4bdbb9e20ed509430b4dcd9fe21b-800x516.jpg?fit=clip)
*The Hack Days context was very productive.*

### Useful resources about Solidus:

- [Solidus.io](https://solidus.io/)
- [Solidus GitHub Repository](https://github.com/solidusio/solidus)
- [Solidus Slack](http://slack.solidus.io/)
- [Solidus Stack Overflow](https://stackoverflow.com/questions/tagged/solidus)

SolidusConf 2019: the 3 reasons that made us love it

At Nebulab we are encouraged in [spending Fridays][playbook-friday] on open
source projects, and I simply love it.

[Solidus eCommerce ecosystem][solidusio] and [its extensions][solidusio-contrib] is
where I usually hang out, you never get bored with so many different
projects and things to do.

A few Fridays ago I started working on a [flaky spec][flaky-spec] that failed
often on Solidus CI builds. This is pretty annoying as flaky failures mean the
test suite must be run again with the usual consequences of uncertainty of
results, wasted time, longer queues, wasted CPU time, CO2 buildup, seven years
of famine and hordes of locusts (not necessarily in this order).

Most of the times flaky specs happen on Selenium tests, where JS interactions
may take a bit more time to complete and some parts of the HTML may not be yet
present or visible (want another example from Solidus codebase?
[Here you are][another-flaky-spec]). But this time it was different: the spec
failed with `Rack::Test`, which is usually very deterministic by nature, no
javascript interaction was involved, so I was quite puzzled about it.


## The error

This is the relevant code of the tentative spec:

```ruby
it "can sort desc" do
  within_table(table_id) do
    click_link sort_link, exact: false
    expect(page).to have_selector '.sort_link.desc'
  end
end
```

It basically clicks on the sorting triangle icon visible in this screenshot:

![solidus admin sorting before click](https://cdn.sanity.io/images/kqgmf0g2/production/6a30a35ed44519c26b70c7af41a076247404e010-1000x536.png?fit=clip)

and checks that the triangle sorting direction has changed (this happens with
a page refresh, no JS involved):

![solidus admin sorting after click](https://cdn.sanity.io/images/kqgmf0g2/production/cade368cad9d9615c1d213979c50f634df036bbc-1000x528.png?fit=clip)

Quite surprisingly, this spec fails with the current version of Capybara (3.13.2):

```ruby
expected to find css ".sort_link.desc" within #<Capybara::Node::Element tag="table" path="/html/body/div[5]/div/div/fieldset/table"> but there were no matches
```

If you change Capybara driver to Firefox or Chrome, for example by changing
the first line to:

```ruby
it "can sort desc”, :js do
```
then the spec passes without errors, so it must be an issue with `Rack::Test`.
After digging a bit inside Capybara source code I confirmed that what happens
here is that the Capybara node that represents the HTML of the selected table
is not refreshed after the page reload, so changes that happen within that
block are not visible.
## The fix
There’s an easy workaround that solves this issue: you just need to close the
`within` block after clicking the link and reopening it before checking the
page, actively forcing Capybara to reload the HTML block from the table:
```ruby
it "can sort desc" do
  within_table(table_id) do
    click_link sort_link, exact: false
  end
  within_table(table_id) do
    expect(page).to have_selector '.sort_link.desc'
  end
end
```
## OSS Collaboration
I won't claim to be the first man on earth that encountered this issue, but
I think it's quite rare as nobody here at Nebulab had seen this before, and
also a few internet searches did not bring any results to me. This bug is
barely worth noticing, the fix is very simple and makes perfect sense: if
you need the node to be updated, just close and reopen the block.
Still, I decided it was worth digging a bit deeper and notify the
[Capybara team][capybara-issue] about the issue. After a few days they fixed
it.
I think this is a good example of [OSS][oss] cooperation between different
projects, this kind of interactions are good for the community as they lead
to improvements that will benefit everybody.
Years ago I was amazed by the simple truth of this quote from (or [maybe not?][maybe-not]) [George Bernard Shaw][gb-shaw]:
> If you have an apple and I have an apple and we exchange these apples then
you and I will still each have one apple. But if you have an idea and I have
an idea and we exchange these ideas, then each of us will have two ideas.
I think that software is more like ideas than apples, as it's much easier to
do good to others while still pursuing your (selfish) interest: _if I share
my apple with you, we both have only half an apple. But if I write some software
and share it with you, then we both can benefit from the code._
Happy coding!
[flaky-spec]: https://github.com/solidusio/solidus/pull/3089
[another-flaky-spec]: https://github.com/solidusio/solidus/pull/3110#issuecomment-466177067
[playbook-friday]: https://playbook.nebulab.com/personal-growth/fridays/
[solidusio]: https://github.com/solidusio
[solidusio-contrib]: https://github.com/solidusio-contrib
[capybara-issue]: https://github.com/teamcapybara/capybara/issues/2157
[oss]: https://en.wikipedia.org/wiki/Open-source_software
[maybe-not]: https://quoteinvestigator.com/2011/12/13/swap-ideas/
[gb-shaw]: https://en.wikipedia.org/wiki/George_Bernard_Shaw

A weird Capybara error in `within` block

We've been to London for [SolidusConf 2017][conf-site] and after a long week
made of code, friendship and eCommerce, we're back on regular work, more
thrilled than ever to be part of the Rails eCommerce revolution.

## What happened there

Solidus' third main event. After Whistler, BC (which unfortunately was a private
event) and Toronto, ON, this year SolidusConf happened in London!

The formula is almost identical to the previous one, a two days hacking session
followed by two single-track conference days. Of course we used the conference
as excuse to arrange a trip abroad with all the team, from Monday to Saturday.

We had a ton of fun while having a great chance to meet fellow Solidus
developers from all over the world (Canada, UK, USA, Mexico, France, ...).

Considering the amount of work we do with eCommerce in Italy and abroad, it was
a pleasure for us to sponsor the event to make [Solidus eCommerce][solidus-nebulab]
better and better.

### The hack days

Monday and Tuesday were probably the best part of the conference. We were able
to do what Solidus nerds like the most: sit with their laptops to
code/design/document software.

[![](https://cdn.sanity.io/images/kqgmf0g2/production/d7633d8f7124e36e85f979ec305f8dac97f4a559-1106x1046.png?w=450&fit=scale)](https://twitter.com/SolidusIO/status/866604005350395906?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E866604005350395906%7Ctwgr%5Ec145746734e8f4a82d04732b65f6b866a288bbfb%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnebulab.com%2Fblog%2Fsolidusconf-2017)

Many great developers and designers were involved in improving Solidus and
making it more stable and refined. A lot of code was coded during those two days
and a huge amount of work was put into an open source project without any kind of
funding from big companies. Take a look at the number of [PRs we worked on][hackdays-prs].

### The conference

The following two days went on with talks about technical matters as well as
business and marketing aspects of the Solidus eCommerce ecosystem. Through the
eyes of the speakers we gained a lot of interesting insights on the eCommerce.

The best talk was probably the first day's opening keynote by
[Clarke Brunsdon][clarkino], Solidus core team member and [Stembolt][stembolt]
co-founder.
Clarke always makes a lot of promises about the future of Solidus and usually
manages to accomplish (with the help of the Solidus community) everything he
says.

[![](https://cdn.sanity.io/images/kqgmf0g2/production/620d3f2929f66a976f33d6e915c28ad6abb33bf1-1100x1111.png?w=450&fit=scale)](https://twitter.com/SolidusIO/status/867317493509091328?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E867317493509091328%7Ctwgr%5Ec145746734e8f4a82d04732b65f6b866a288bbfb%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fnebulab.com%2Fblog%2Fsolidusconf-2017)

After a short introduction about how Solidus is becoming the best Ruby on Rails
eCommerce implementation and how so many of the things we only dreamt about in
the previous SolidusConf are now a reality (like the growing number of stable
and tested [Solidus extensions][extensions]) he talked about Solidus' future:
better documentation, a complete rebranding and a new website.

This is pretty big: Solidus greatest weak point is its not-so-fresh brand image
and a lack of guides for both new developers and end-users. This will make it
easier for stores and entrepreneurs to choose Solidus, since moving to the new
platform won't require any prior developer knowledge about it.

The keynote ended with huge news for us: [Alberto Vena][alberto]
(Nebulab co-founder) is becoming part of the Solidus core team. This means a lot
for the whole Nebulab team and we hope it'll bring us closer to the project.
Congrats Alberto!

![SolidusConf core team](https://cdn.sanity.io/images/kqgmf0g2/production/6b18b88db71a4fa73f97703d788639479ea4a342-633x446.jpg?fit=clip)

## The days after

When the conference was over we had the best fun we could have. We walked all
over the place and drank all kind of booze and ate so much street food. London
is really a great city when it comes to all that.

Given that we spend most of our time working remotely, it was a great time for
our team to be together, laugh and party hard!

Here are some pics!

![Millenium Bridge](https://cdn.sanity.io/images/kqgmf0g2/production/46cc5b99b6dbedaaa9124af36d6737ef0f26e835-1280x719.jpg?fit=clip)
*Awesome London scenery on the Millenium Bridge.*

![Near the conference venue](https://cdn.sanity.io/images/kqgmf0g2/production/8998847686ff3f099e942a02fe3412e1a9cef52f-960x1280.jpg?fit=clip)
*Strolling outside the conference venue.*

![Near the conference venue](https://cdn.sanity.io/images/kqgmf0g2/production/102fc385fbe76718e82dfad2602f6e9ef9d37378-3264x2448.jpg?fit=clip)
*Relaxing times in Camden Town.*

![London parks](https://cdn.sanity.io/images/kqgmf0g2/production/10fb32850ae4c7e521dc67ee2b25d6d8a2e5aaea-3264x2448.jpg?fit=clip)
*London is a huge city but also has many parks.*

![Thai restaurant](https://cdn.sanity.io/images/kqgmf0g2/production/8ed0bd06f1910876f9fcf6a4013dee01280000d2-3128x2346.jpg?fit=clip)
*Eating out at a Thai restaurant.*

![Conference party](https://cdn.sanity.io/images/kqgmf0g2/production/e13091c06040e604c6346eea6421e8be286c479b-1200x914.gif?fit=clip)
*Having fun at the conference party.*

[conf-site]: http://conf2017.solidus.io/
[hackdays-prs]: https://github.com/solidusio/solidus/pulls?q=is%3Apr+label%3A%22SolidusConf+Hack+Day%22
[clarkino]: https://github.com/cbrunsdon
[stembolt]: https://stembolt.com/
[extensions]: http://extensions.solidus.io/
[alberto]: https://github.com/kennyadsl
[solidus-nebulab]: https://solidus.io/

SolidusConf 2017

In this article we'll create a simple application to show how to
integrate and use [Cangaroo][cangaroo] to handle any external service
integration with your [Solidus store][solidus]. Our goal will be to send a
tweet out each time a new product is created. Accomplishing this task will
allow us to walk you throught *Cangaroo* installation and basic functionalities.

*In [my previous article][previous_article] I told the full story about why we
created Cangaroo and I promised to write a tutorial that explains how to
set it up to use an existing integration.*

So let's go ahead and make a plan. The steps we'll follow are:

1. [Add Cangaroo to our Solidus application.](#add-cangaroo)
2. [Setup solidus_cangaroo extension to send products to Cangaroo](#setup-solidus-cangaroo)
3. [Add Twitter Integration](#add-twitter-integration)
    - [The Hard Way](#the-hard-way)
    - [The Easy Way](#the-easy-way)
4. [Add the TweetProduct Cangaroo Job](#add-cangaroo-job)

To follow this tutorial you need:

1. A working *Solidus* store (check out [how to boostrap a solidus store and
     deploy it to Heroku][solidus_to_heroku]).
2. A Twitter account and a Twitter application
   ([https://apps.twitter.com/][twitter_apps]).

After that, we are ready to go!

<a name="add-cangaroo"></a>Add Cangaroo to our Solidus application

*Cangaroo* is a *Rails* engine and can be mounted on any Rails application. In
this case we are going to mount it on our Solidus store just for the sake
of simplicity but keep in mind that you can (and we advice to) use it also
on a separate *Rails* application.
In the real world the best way to use *Cangaroo* is into a
standalone application; that way it can serve multiple storefronts and
applications like an ERP and a CMS.

To add *Cangaroo* to our application we just need to follow the README:

Add *Cangaroo* gem to Gemfile

```ruby
# Gemfile

gem 'cangaroo'
```

Run `bundle` as usual, then you have to install and run the needed migrations

```shell
$ bin/rake cangaroo:install:migrations
$ bin/rake db:migrate
```

The last step is to add the routes needed from *Cangaroo* to receive data from
our apps:

```ruby
# routes.rb

mount Cangaroo::Engine => "/cangaroo"
```

Now Cangaroo is configured into our app and ready to receive data and perform
Jobs, but first we have to create a `Connection`. Basically a connection is an
external app that can send and receive data from Cangaroo.
To create the connection in the `rails console` run:

```ruby
Cangaroo::Connection.create(
  name: 'mystore',
  url: 'http://localhost:3000',
  key: 'secretkey',
  token: 'secrettoken'
)
```

The Connection has four fields:

- `name`: is used to identify the connection from *Cangaroo* jobs
  (we'll see this later);
- `url`: is the connection url, in our case we are running rails locally so it's
  `localhost:3000`;
- `key`: it's used for authentication, you can set it to your liking;
- `token`: also used for authentication, you can set it to your liking;

<a name="setup-solidus-cangaroo"></a> Setup solidus_cangaroo extension to send products to Cangaroo
---------------------------------------------------------------------------------------------------

[solidus_cangaroo][solidus_cangaroo] is a *Solidus* extension that provides the
push API that we'll use to send our products to *Cangaroo*.
Again, to setup it up we can just follow its README:

Add *solidus_cangaroo* gem to our Gemfile as usual:

```ruby
# Gemfile

gem 'solidus_cangaroo', github: 'nebulab/solidus_cangaroo', branch: 'master'
```

then run `bundle` and `bundle exec rails g spree_wombat:install`.
Now we have to add our Cangaroo credential into the file
`config/initializers/cangaroo.rb`

```ruby
# config/initializers/cangaroo.rb

Spree::Wombat::Config.configure do |config|
  config.connection_id = 'secretkey'
  config.connection_token = 'secrettoken'
end
```

As you can see the `connection_id` is the `key` that we previously added to the
connection and the `connection_token` is the `token`. This way *Cangaroo* will
authenticate the store when it sends data to *Cangaroo*.

The next step is to specify which objects we want to send to Cangaroo, in our
case just the products.
To do so we use the `push_objects` configuration:

```ruby
# config/initializers/cangaroo.rb

config.push_objects = ["Spree::Product"]
```

Then we have to configure the `payload_builder`, which is needed to normalize
the data and make it understandable to *Cangaroo*. Fortunately
almost all the work is done from *solidus_cangaroo* that already has the
[Serializers][solidus_serializers] for nearly all the *Solidus* objects.
The `root` key (of the json object the app is sending to *Cangaroo*) is needed
to let *Cangaroo* understand what kind of data the app is sending:

```ruby
# config/initializers/cangaroo.rb

config.payload_builder = {
  "Spree::Product" => { serializer: "Spree::Wombat::ProductSerializer", root: "products" }
}
```

At last we have to setup the `push_url` with the path to our *Cangaroo*
installation. In our case it's the same path of our store (but remember that
it can be another application):

```ruby
# config/initializers/cangaroo.rb

config.push_url = "http://localhost:3000/cangaroo/endpoint"
```

Now our `config/initializers/cangaroo.rb` should look like this:

```ruby
# config/initializers/cangaroo.rb

Spree::Wombat::Config.configure do |config|
  config.connection_id = "secretkey"
  config.connection_token = "secrettoken"

  config.push_objects = ["Spree::Product"]
  config.payload_builder = {
    "Spree::Product" => { serializer: "Spree::Wombat::ProductSerializer", root: "products" }
  }
  config.push_url = "http://localhost:3000/cangaroo/endpoint"
end
```

Finally we can check if our application sends products to *Cangaroo*
correctly. First, start our `rails server` and from `rails console` run:

```ruby
Spree::Wombat::Client.push_batches("Spree::Product")
```

after some info logs you should see the return message:

```ruby
=> 9
```

this means that 9 products are sent to *Cangaroo*. On your project this number
can change, it depends on how many products you have in your database.
Somewhere in your rails logs you should be able to spot:

```
Completed 202 Accepted in 43ms (Views: 0.2ms | ActiveRecord: 0.9ms)
```

This confirms that *Cangaroo* has received our products, anyway nothing
happened because for now we didn't configure any job. A job is an action
triggered when an object is received and uses integration to "talk" with
external services. In the next step we are going to add the twitter
integration that will be used by a job to let the world know about our
amazing new products.

<a name="add-twitter-integration"></a> Add Twitter Integration
--------------------------------------------------------------

### <a name="the-hard-way"></a> The Hard Way

At first we have to pull the [twitter_integration][twitter_integration] repo and
make it run. Available integrations are made of simple Sinatra apps that
you can find here: [https://github.com/cangaroo][cangaroo_integrations].

The first step is to clone the integration from *GitHub*:

```shell
$ git clone https://github.com/cangaroo/twitter_integration
```

then `cd` into the directory and run `bundle`. After that run the *Sinatra*
app with:

```shell
$ bundle exec rackup
```

To check if everything is working you can visit `http://localhost:9292/` and
look for `TwitterIntegration ok`.

### <a name="the-easy-way"></a> The Easy Way

To make it even simpler, we have added the
<a href="https://heroku.com/deploy?template=https://github.com/cangaroo/twitter_integration" class="button-img">
  <img alt="Deploy" src="https://www.herokucdn.com/deploy/button.svg">
</a>
button on the integration [README][twitter_integration].
If you push this button and follow the instructions you will have a working integration
on Heroku that you can eventually use also for production.

To check if you have correctly deployed the integration on heroku go to your
application root path and check that it responds with `TwitterIntegration ok`.

To add a security layer we need to set the environment variable `ENDPOINT_KEY`
with a private token that will be used with the Connection that we are going to
create in the next step:

```shell
ENDPOINT_KEY=secrettoken
```

Now is time to teach our *Cangaroo* how to tweet. First of all, we have to
create the connection for this integration, we create it from `rails console`:

```ruby
Cangaroo::Connection.create(
  name: 'twitter',
  url: 'http://localhost:9292',
  key: 'secrettoken',
  token: 'secrettoken'
)
```

Change `url` and `token` accordling to values of your app url and your
security token.

**Note:** *Even if key is not used for the integrations, Cangaroo will still validate
its presence, so you have to set it. This strange behavior comes to support
the old Wombat behavior. We hope to find a better way to implement it soon.*

<a name="add-cangaroo-job"></a> Add the TweetProduct Cangaroo Job
-------------------------------------------------------------------

We are finally ready to create the job to send tweets. To do so we run the
generator:

```shell
$ bundle exec rails g job Cangaroo::TweetProduct
```
now we have to change this job.
First of all it must inherit from Cangaroo::Job.
Then we need to remove the queue_as :default, because Cangaroo::Job already
uses the cangaroo queue (you can change it if you want).
At this point, we have to specify connection, path and parameters that the job
will use:

```ruby
# app/jobs/cangaroo/tweet_product.rb

class Cangaroo::TweetProductJob < Cangaroo::Job
  connection 'twitter'
  path '/send_tweet'
  parameters {
    consumer_key: 'your_twitter_consumer_key',
    consumer_secret: 'your_twitter_consumer_secret',
    access_token: 'your_twitter_access_token',
    access_token_secret: 'your_twittwr_token_secret'
  }
end
```

`path` and `parameters` are relative to integration you are using.
For now the integrations don't have much documentation, so you have to refer
to the code in the [integration file][twitter_integration_code].
In case you want to go deeper, you could also take a look at the
[endpoint_base][endpoint_base] gem.

*We plan to improve integrations and the endpoint_base gem.
However this is quite a lot of stuff, so contributions are very welcome.*

After that we have to implement the `perform?` method.
*Cangaroo* uses this method to understand if this job should be performed. In
our case we have to check if the type is a `product` and if it's a new product
(please refer to the [README][cangaroo_job_doc] to see which variables can be
used inside the `perform?` method):

```ruby
# app/jobs/cangaroo/tweet_product.rb

...
def perform?
  type == 'products' &&
    payload['created_at'] == payload['updated_at']
end
...
```

Sometimes integrations don't understand the data that we send to them, so we
have to `transform` it. In our case we want to write a tweet with the product's
name and link so we'll use the `transform` method to convert the product's data
coming from the store into a JSON that will be sent to the integration.
Our `transform` method looks like:

```ruby
# app/jobs/cangaroo/tweet_product.rb

...
def transform
  {
    tweet: {
      body: "Hey, we have a new awesome product #{payload['name']} http://localhost:3000/products/#{payload['permalink']}"
    }
  }
end
...
```

and then our job should look like:

```ruby
# app/jobs/cangaroo/tweet_product.rb

class Cangaroo::TweetProductJob < Cangaroo::Job
  connection 'twitter'
  path '/send_tweet'
  parameters {
    consumer_key: 'your_twitter_consumer_key',
    consumer_secret: 'your_twitter_consumer_secret',
    access_token: 'your_twitter_access_token',
    access_token_secret: 'your_twittwr_token_secret'
  }

  def transform
    {
      tweet: {
        body: "Hey, we have a new awesome product #{payload['name']} http://localhost:3000/products/#{payload['permalink']}"
      }
    }
  end

  def perform?
    type == 'products' &&
      payload['created_at'] == payload['updated_at']
  end
end
```

We are now lacking just the last thing: we have to inform *Cangaroo* about
this job. This is an easy task: we just have to add our job to the right
configuration, in this case Rails.configuration.cangaroo.jobs.
To do so we need to add it in the cangaroo initializer:

```ruby
# config/initializers/cangaroo.rb
...
Rails.configuration.cangaroo.jobs = [Cangaroo::TweetProductJob]
```

All done! Now is time to test our integration:
create a new product on *Solidus* then run from `rails console`:

```ruby
Spree::Wombat::Client.push_batches("Spree::Product")
```

And...if everything is working you should see a tweet about your new awesome
product!!!

Take note that, at the moment, our project doesn't use any queue system and
*Cangaroo* jobs are just simple Rails jobs.
You can therefore use any backend queue system that is currently
supported by Rails.

Also, in this tutorial we pushed objects from the rails console.
Conversely, in a real application you would probably want to use the
proper rake task:


```shell
$ bundle exec rake wombat:push_it
```

I hope you now have a better understanding of how *Cangaroo* works and how to
use integrations.
There's still a lot of work to be done, both on *Cangaroo* and the integrations.
We'll welcome anyone that wants to work on the projects with us.

You can find the code used for this tutorial on this [repo][cangaroo_tutorial].

[cangaroo]: https://github.com/nebulab/cangaroo
[previous_article]: /blog/the-birth-of-a-cangaroo/
[solidus]: https://solidus.io/
[solidus_readme]: https://github.com/solidusio/solidus#getting-started
[solidus_to_heroku]: /blog/deploy-solidus-to-heroku-like-a-boss/
[solidus_serializers]: https://github.com/nebulab/solidus_cangaroo/tree/master/app/serializers/spree/wombat
[twitter_integration_code]: https://github.com/cangaroo/twitter_integration/blob/master/twitter_integration.rb
[endpoint_base]: https://github.com/spree/endpoint_base
[cangaroo_tutorial]: https://github.com/nebulab/cangaroo_tutorial
[twitter_integration]: https://github.com/cangaroo/twitter_integration
[solidus_cangaroo]: https://github.com/nebulab/solidus_cangaroo
[twitter_apps]: https://apps.twitter.com/
[cangaroo_integrations]: https://github.com/cangaroo
[cangaroo_job_doc]: https://github.com/nebulab/cangaroo#cangaroo-jobs

Integrate Solidus with external services using Cangaroo

Before getting deeper into some technical [Cangaroo][1] guide I wanted to give
some more insights about how **Cangaroo** was born. This is the story that tells
how the death of a *SaaS* gave us the opportunity to create a brand new
**open-source** project.

One of our clients has many Spree stores, almost ten and all of these stores
share the following features:

* send order information data to a third-party application;
* receive stock updates from that application;
* receive shipments updates from that application;
* send an email to the customer service when an order is considerd risky.

In the first place you can think that the easier way to accomplish this is
updating each store code to "speak" directly with that application in order to
send and receive data. This introduces a lot of code duplication and is really
error prone.

Another solution could be to create a gem that is included in all stores.
At the beginning it looked like a good solution but what happens if you had to
add another feature? For example what if you have to send an email for each new
customer? At this point you had to:

* update the gem to include this feature;
* update the new ref of the gem into the `Gemfile` of each store;
* run tests (often duplicated) on each store;
* deploy each store.

Now, it can seems like reasonable approach but think at each time you find a bug
and you have to replicate all the steps above. It's time consuming and we love
to use our time to build new features instead of repeating actions mechanically.

Another problem comes when any third-party application endpoint has some
problem, like a downtime. In order to don't loose data you need to add a queue
system to retry the request. Of course each store needs its own queue system
with all performance related stuff that increases infrastructure costs.

With the primary aim to solve this scenario the Spreecommerce created a Saas
named Wombat, whose claim said:


> "Wombat is your store’s integration platform; connect any store to any
service. Wombat gets you up and running in minutes, no custom code required.".

With Wombat an user can configure what to do on a particular event, with a UI
interface, for example you can setup something like


```
When a new Order comes in from the store A, send an email to the customer and
tweet an happy face.
```
or

```
When a new Order comes in from any store, send an email to the customer
service.
```

Wombat talks with external services API using [integrations][2] that
live in the middle between Wombat and third-party services. Each external
service has its own integration, for example there are integrations for
Mailchimp, SalesForce, etc.

Everything was working fine until the day the Spreecommerce was aquired,
Wombat died and the source code was released only to customers.

At this point we had to decide how to go ahead, and the alternatives were:

1. to take Wombat source code and to host it on our servers;
2. to reintroduce features back into the stores with all the issues described
   above;
3. to create an alternative system that replaces Wombat behavior.

Accordling to one of our cool clients, we decided to go with the latter and, since
we strongly believe in open-source we also decided to publicly release it.
**Cangaroo** was born.

**Cangaroo** is named after the Kangaroo animal, which I've seen together with a
real wombat during one of my trips across Australia. Unfortunately Kangaroo gem
name was already taken so we changed it a bit.

![Wombat and Kangaroo](https://cdn.sanity.io/images/kqgmf0g2/production/cc6571173aaf14682ce59d847f829ffb80add623-770x578.jpg?fit=clip)
*A picture with a Wombat and a Kangaroo taken by me in Australia.*

**Cangaroo** is a Rails Engine that you can mount on a new or exsisting Rails
application. One cool thing about this project is that it uses the same API
specification of Wombat so we don't have to change anything into our client
stores repo continuing to use the code that was acting as an adapter for Wombat
(via the `spree_wombat` extension).

The main differences from Wombat are:

* **Cangaroo** is designed for developers, not for endusers.
As a developer I prefer to use my editor to configure behaviors instead of
clicking around a web page; this is why it's developer friendly,
it doesn't have a UI like Wombat, everythings is done via code.
* **Cangaroo** doesn’t store data like Wombat did, it just receives data and
decides what to do based on how it's configured.
* Lately Wombat added the possibility to also schedule recurring requests to
external services in order to receive data without having an event that triggers
that call. For now **Cangaroo** doesn't have this feature but it's something
we are planning to add as soon as possible.

This is the whole story about **Cangaroo** and why we decided to create it.
To learn more you can take a look at [README][1] and stay in touch with our
blog. We are planning to post soon a tutorial that explains how to setup
**Cangaroo**, integrate it into a spree/solidus store using the
[spree_wombat extension][3] and one of the existing Wombat integrations.

[1]: https://github.com/nebulab/cangaroo
[2]: https://github.com/wombat
[3]: https://github.com/spree/spree_wombat
[4]: https://github.com/spree/spree_wombat#push_url

The birth of a Cangaroo

In order to let the creativity to flow, we decided to organize an hackathon
involving all the team.
Nebulab believes in side projects, they help to form the junior members
and grow the seniors, and put them in front of new challenges such as the
exploration of fresh technologies.

**But... what to do?** Perhaps the embryonic idea was already present in the
head of some of us...recently a recurring Slack topic is the future of the
Spree platform, on which, essentially, all our projects are based and whose
support had been declared abandoned by the original core team.
This event resulted in the birth of a community for the development
of a new ecommerce platform, [Solidus](https://solidus.io/), starting from a Spree fork.
The discussions on the [Solidus Slack channel](https://slack.solidus.io/) have
shown the need to quickly search and access the extensions developed for this
new platform.
Then it was a short step. A small webapp, easy to develop in a limited space of time,
a Solidus extensions search tool using GitHub API.
Given that everybody was interested in Javascript frameworks, the choice came down to Ember.js. Being known for a framework that increases developer productivity, we thought it would be great for a 1-day hackaton.

![Coffe Break](https://cdn.sanity.io/images/kqgmf0g2/production/c189632a02839d69d004c0c20f2081ffdcb4ccc5-770x350.jpg?fit=clip)

After a short but intense brain-storming on Ember.js structures and a coffee
break, we started coding, dividing us in four groups.

- Communication with GitHub API
- Search Form
- Interface Design
- Frontend development

Taking inspiration from the [biologic radar used in Metal Gear Solid](https://metalgear.wikia.com/wiki/Soliton_Radar)
, we named it *Soliton* and, once created the repository, the rule was: push on it as often as possible!

Referring to [Ember.js Guides](https://guides.emberjs.com), we've easily built the
frontend and backend application skeleton code while in parallel the style support tools were configured (with [bourbon and neat as usual](https://nebulab.com/blog/neat-a-semantic-approach-to-grid/)).
In the meantime Davide, our designer, was free to imagine and draw the user interface.

![Soliton Interface](https://cdn.sanity.io/images/kqgmf0g2/production/cb4ec13e01d3687ed330949c0d17b925d8df8f4e-770x305.jpg?fit=clip)

A side-project carried out in the informal context of an hackathon day has,
without any doubt, the positive side-effect to strengthen the union of the team,
that by our nature can be distributed anywhere in the world. A great opportunity to
work side by side and having a few laughs!

See y'all the next hackathon!

![Working on Soliton](https://cdn.sanity.io/images/kqgmf0g2/production/8a39d998fb3dd3cca793484759fc652537a5accf-770x408.jpg?fit=clip)

The Soliton Hackathon

Spree or Solidus? Which OSS project Nebulab, as an agency involved in
Ruby on Rails eCommerce development, should invest on? This blog post
tells the story about what's happening inside our agency in choosing
where to put more effort.

## Spree and Nebulab

Nebulab has proudly been one of the first company that adopted Spree. In fact
we are using it since version 0.30. We always did our best contributing
actively to the project and its extensions, attending almost all SpreeConf
around the world and supporting the community via the Spree Mailing List.

We strongly believed in this project that we used for 100% of our eCommerce
customers, often recommending them to migrate to Spree from other platform,
like Magento or custom Ruby on Rails eCommerce applications.

We have also been one the first company that applied to be a
[Spree Solution Partner][spree solution partners]. This partnership allowed us
to give something back to the project and take a lot of contacts with clients
all over the world.

On October 28th Spree announced that [they will no longer
maintain the OSS project](https://spreecommerce.com/blog/future-of-spree-oss).
The main reason is that the Spree company has been acquired by another
bigger company, First Data.

It's easy to imagine our feelings hearing that our favorite OSS project
would have a so drastic change in its maintenance and community management.

Bad news never come alone. **[Wombat][wombat]**, an
integration platform built from Spree company that we were using for some
of our clients, would be discontinued soon. Fortunately, according with one of
our cool customers which was extensively using that service, we developed
[Cangaroo][cangaroo], an Open Source alternative to Wombat, that we are
currently using successfully in production.

## Solidus

Months before this event, a group of developers from
[Bonobos][bonobos], one of the
[biggest online retail store][bonobos ipo] in the United States and
[Stembolt][stembolt], a Canadian web development firm, forked
Spree because they started to diverge from the direction Spree was taking.
They called the project [Solidus][solidus], naming it after an
[old Roman coin][solidus coin] and the
[SOLID principles of Object Oriented Design][solid principles].

Having more activity we naturally started taking a look at this fork,
understanding its principles and its different approach that we started
to appreciate and share.

If you are interested in differences between the two platforms
[this article][spree vs solidus] is a great resource.

Here's a list of stuff that we like about Solidus:

### A Solid Roadmap

Solidus guys decided to put focus on fixing and improving current codebase
instead of adding new features that are probably unnecessary for many stores.

Here you can find the full
[Solidus Future Plans][solidus future plans].

We trust developers involved in the Solidus project, we can see on the
[Solidus GitHub Repository][solidus github] that they are great in what they do
and lately they also have emerged for their attention for security issues.

### Top Priority to Code Integrity

Solidus is trying to get rid of stuff that doesn't look clean like the
improper use of `class_eval`. This is not only a question of code
style but ensure it's easier to customize your stores, your extensions and
to update Solidus from one version to the next one.

But why **class_eval** is not a good practice?

Of course it depends by the situation but in general using class_eval you
are re-opening the general class definition; technically this is not
an inheritance and this means that into the re-opened class you cannot use
`super` to replicate a previously defined method behavior. For the
sake of better understanding this concept, let's make a simplified example:


**Spree::Stock::ShippingRateSorter** is a class defined into the solidus
core that defines how to sort shipping rates.

```ruby
# Solidus Core

# app/models/spree/stock/shipping_rate_sorter.rb
module Spree
  module Stock
    class ShippingRateSorter
      attr_reader :shipping_rates

      def initialize(shipping_rates)
        @shipping_rates = shipping_rates
      end

      def sort
        shipping_rates.sort_by(&:cost)
      end
    end
  end
end
```
Now, in your store or extension, suppose you want to change how to sort
those elements. Specifically we want to reverse the order of shipping rates.
We used to write in our stores something like:

```ruby
# Our App or Extension

# app/models/spree/stock/shipping_rate_sorter_decorator.rb
module Spree
  module Stock
    ShippingRateSorter.class_eval do
      def sort
        shipping_rates.sort_by(&:cost).reverse
      end
    end
  end
end
```

This is not terrible, at least until the default way shipping rates are sorted
changes into core, and our code is no more compliant with it making it a mess
to update solidus to more recent versions.

Often, the solution to this kind of problem is using **super** to inherit the
behavior of core code in order to make our extensions less dependant to that
code.

Solidus is proposing to change this `class_eval` over-usage, moving to a more
clean way to extend stuff.

```ruby
# Our App or Extension

# app/models/spree/stock/custom_shipping_rate_sorter.rb
module Spree
  module Stock
    class CustomShippingRateSorter < ShippingRateSorter
      def sort
        super.reverse
      end
    end
  end
end

# config/initializers/spree.rb
Spree::Config.shipping_rate_sorter_class = Spree::Stock::MyShippingRateSorter
```

Awesome, isn't it?

### Forked from Spree 2.4

Solidus has been forked from Spree 2.4, and now Spree is at 3.0. The main change
between these versions is the introduction of **Twitter Boostrap** into both
frontend and backend. That wasn't a good idea in our opinion for several
reasons:

- updating would mean changing frontend code of all stores we were working on;
- 90% of our clients are not interested in bootstrap themes but a
custom frontend style, so often it would probably be more work to
remove it than to adapt the spree frontend to that specific store needs;
- in our vision the frontend HTML should not include front-end framework class
names but semantic ones that represents what's inside that specific element.

### Active Community

Lot of friends and contributors that we did know on the Spree community have
already joined the Solidus community. In fact, in the
[Solidus Slack channel][solidus slack] there are already 400+ developers
that discuss, support each other and design together the future Solidus moves.

We also love conferences, and we look forward to attend
[Solidus Conf 2016][solidus conf] in Toronto, an opportunity for us
to learn, to better understand the Solidus goals and to meet community members
and clients in person.

## Our choice

Our plan is to start all new stores using Solidus but to stay with Spree for
the majority of those already developed. We think that this is the decision
that makes more sense, also because Spree has new maintainers now and this
should ensure quick response to any security issue that could come out.

Even if Spree seems to be reborn with a
[new core team and roadmap][new spree core team],
we think that there's still a lot to do for Spree to recapture our interest
and we currently feel comfortable with the Solidus approach, which we hope to
contribute to as much as we can.


[bonobos]: https://bonobos.com/
[bonobos ipo]: https://pando.com/2014/07/06/bonobos-raises-another-55-million-and-aims-for-an-ipo-all-in-spite-of-being-ecommerce/
[cangaroo]: https://github.com/nebulab/cangaroo
[new spree core team]: https://spreecommerce.com/blog/spree-roadmap-announcement
[solid principles]: https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
[solidus]: http://solidus.io/
[solidus coin]: https://en.wikipedia.org/wiki/Solidus_(coin)
[solidus conf]: http://conf.solidus.io/
[solidus future plans]: https://github.com/solidusio/solidus/milestones
[solidus slack]: http://slack.solidus.io/
[solidus github]: http://github.com/solidusio/solidus
[spree solution partners]: https://spreecommerce.com/solution_partners
[spree vs solidus]: http://bluestout.com/blog/spree-vs-solidus-ecommerce-platforms/
[stembolt]: https://stembolt.com/
[wombat]: https://github.com/wombat

The Nebulab