Spree Commerce

Try It Now

Spree 1.0.0.rc1 is Now Available

Posted on December 23, 2011 by Sean Schofield

We’re happy to announce Spree 1.0.0.rc1 is finally available! We’ve been working like crazy in order to meet our self-imposed deadline of “before Christmas.” Unfortunately in our drive to get the RC ready we did not have time to write a lot of explanatory posts and documentation. We’ll catch up in the next couple of weeks now that the major coding part is over.

One of the major changes in this release is related to taxation. You can see some of the recent taxation work on Github and look forward to completely revised documentation in the new year.

We have also started work on the 1.0.0 release notes. They’re still a work in progress but you may find some useful information in the edge guides. We still have some work to do in January but we’re on schedule to release 1.0.0 in time for SpreeConf.

Why you should use Spree

Posted on December 12, 2011 by Ryan Bigg

Hello friends!

Today I want to let you know that we’re currently working very hard towards the 1.0 release, which’ll be out Soon&tm;. While that’s coming, I thought I’d write a blog post to let you know what
makes Spree just so great to use for your e-commerce platform.

Our helpful community

With Spree being built on Ruby on Rails, the syntax and organization of the project is exceptionally clean. To compliment this exceptional design, we have freely available guides which explain Spree in an easy-to-understand way, contributed by valuable members in the community.

For 1.0, we’ll be updating these guides and filling them out with even more useful information. If there’s something else you’d like to see documented here, just shoot me an email (ryan@spreecommerce.com). Better still, why not follow the steps in the Contributing to the Documentation section of the Contributing to Spree guide?

If you’re looking for more help that isn’t quite guides material, we also have helfpul people on the spree-user mailing list.

One more thing: We’ve also been receiving a lot of code from our users through GitHub. We use GitHub because it provides the community an easy way to provide fixes for Spree and we’re able to
review these extremely efficiently and merge them into our codebase. If you want to submit a fix for Spree yourself, we’ve also got a section for that in the Contributing to Spree guide also.

We’re fanatical about testing

When we’re merging in these changes from other people, we look for code quality and test coverage. If these two things aren’t up to scratch, then we’ll help people in those regards. For
testing, we use the best Ruby testing framework, called RSpec. We also use Capybara and selenium-webdriver. With these tools, we’re able to write end-to-end tests for Spree.

In the unlikely case of a bug, we will write a regression test for it, ensure that the test fails and then write the code to fix the bug and make the test pass. Take for example this commit where a regression test for issue
#774
was written, and then this commit was what fixed it. Without these regression tests, a bug
may re-appear. If we accidentally introduce a regression, there’s a high probability it’ll be caught by one of these tests and not released to the public.

We’re also massive, massive fans of Travis CI. When we push Spree’s code to GitHub, a notification is sent to Travis which triggers a new build to run. This
new build will run all the tests for Spree, ensuring that everything is working properly. When the tests are finished running, we’re notified in our Campfire channel and our IRC server. If
the tests fail, there’s one more notification that goes out: an email to me that says “The build was broken”.


Oops!


When this happens, it’s my job to bring the build back to green, because a broken
build means a broken product, which is something we, and not you, should have to deal with.


A build listing from Travis


You can see this system in full effect in the above image. I committed broken code and it broke build 316. While I was fixing
this, two other commits came through from other people and their builds failed due to the break that was introduced. The break was then fixed it with the commit that triggered build 319. We will do our best to ensure that this build is always green, because that’ll mean that we are giving you the best
product possible.

We want to help you

Finally, we want to be the easiest-to-use e-commerce platform out there. If there’s any questions or suggestions you’ve got for it, please don’t hesitate to ask them on the spree-user mailing list. We want you to actually enjoy using Spree and not hate it.

Why? Because we can.

Full Time Designer Position

Posted on December 12, 2011 by Sean Schofield

We’re currently looking to fill a brand new full-time designer position here at Spree. The ideal candidate would work on site here in the Washington, D.C. area but we’re also open to a remote position. Looking for someone full time but would also consider a contract position if you can provide at least 30 hrs. per week.

This position will be responsible for continuous improvement of the website, overhauling the online demo and creating several new Spree themes. We’re also looking to overhaul the admin interface for Spree and we have a general ongoing need for various design jobs that come up from time to time.

Please send a resume to jobs@spreecommerce.com if you’re interested. Please provide some examples of your work along with the salary range (or hourly rate) that you’re looking for.

Spree Preferences Refactored

Posted on December 08, 2011 by cmar

We have refactored Spree Preferences to improve performance and simplify
code for applicaitons and extensions. The previous interfaces have been
maintained so no code changes should be required. The underlying classes
have been completely rewritten.

The new underlying classes are much simpiler and approach preference
storage with the concept that preferences are read much more often
they are written. We use Rails caching to maintain key/value pairs
in memory for fast access. Changes are persisted to the database and
loaded during initalization to pre-populate the cache.

There is a new utility class Spree::Preferences::Configuration for
extensions to create their own namespaced preferences.


<p>MyExt::Configuration &lt; Spree::Preferences::Configuration<br />
  preference :show_ads, :boolean, :default =&gt; true<br />
end</p>
<p><span class="caps">MYEXT</span>::<span class="caps">CONFIG</span> = MyExt::Configuration.new<br />
<span class="caps">MYEXT</span>::<span class="caps">CONFIG</span>.show_ads = false</p>

The above preference will share the same cache and database table as the
Spree General Configuration. It will be keyed as
/myext/configuration/show_ads.

We continue to store preferences for model instances. You can define
a preference for your model. Each instance will use the default value
unless a new value is set. The instance specific preference will be
immediately persisted to the database and keyed with the id
(/user/email_notification/18).


<p>class User &lt; ActiveRecord::Base<br />
  preference :email_notifications, :boolean, :default =&gt; true<br />
  preference :favorite_food, :string, :default =&gt; &#8216;beer&#8217;<br />
end</p>
<p>user = User.create</p>
<ol>
	<li>reading<br />
user.prefers_email_notifications? # =&gt; true<br />
user.preferred_favorite_food # =&gt; &#8216;beer&#8217;<br />
user.get_preference :favorite_food #= &#8216;beer&#8217;</li>
</ol>
<ol>
	<li>writing<br />
user.prefers_email_notifications = false<br />
user.preferred_favorite_food = &#8216;meatloaf&#8217;<br />
user.set_preference :favorite_food, &#8216;meatloaf&#8217;</li>
</ol>
<ol>
	<li>definition<br />
user.preferred_favorite_food_default # =&gt; &#8216;beer&#8217;<br />
user.preferred_favorite_food_type # =&gt; :string</li>
</ol>

We have included a migration that will convert your previous preferences
to the new format.