• 494 - There are no default states for United states when you don’t load sample data
• 551 - Remove bootstrap restriction in production mode
• 553 - Allow creation of default user through web interface
• 550 - Seed data no longer populated correctly
• 552 - Allow db:admin:create rake task to be run more then once

The most important change is that we have modified the migrations so that they are no longer loading so-called “seed” data (countries, states etc.) Keeping this seed data out of the migrations fixes a whole bunch of problems. You can still create everything from scratch with a single rake task

rake db:bootstrap

By popular demand, the bootstrap task is once again permissable in production mode. For safety reasons it will not drop the existing database in production mode (as it does automatically in development and test modes.)

You can also still build everything from scratch using individual rake tasks. In fact, we’ve created several new rake tasks so you can have fine grain control.

The following two rake tasks build an empty database with the required seed data.

rake db:migrate
rake db:seed

You can create an admin user (or an additional admin user if you already have one) using

rake db:admin:create

You can also load the sample data (assuming you don’t already have it through bootstrap) using

rake db:sample

There is a new rake task which should migrate your existing orders so that they now have shipping and tax charges when applicable. As always, please backup your database before attempting to run the migrations. If you’re running the source you’ll also need to remove the now empty vendor/extensions/tax_calculator directory after your git pull.

This code is very edge so be prepared for a few bumps if you decide to use it. There is at least one known issue and we’ll likely encounter a few more as we go. You may also want to do a search in your custom code for references to tax_amount and ship_amount. These are no longer valid attributes for the order model. If you need the tax or shipping total for something, however, you can do the following:

  @order.tax_charges.sum(:amount)

So now that we can support an arbitrary number of charges, the next task is to support an arbitrary number (and type) of credits. This concept should be relatively easy since a credit is really just the flip side of a charge. Once that is implemented we can finally get to the coupon and discount stuff that we have been planning for a while now.

Paul Callaghan has been improving our documentation while Brian Quinn has been hard at work migrating our issue tracker over to Lighthouse. The move to LH is going to have several benefits for us, including improved integration with GitHub. We’re going to have a slightly more formal issue reporting and resolution process which I’ll explain in more detail later in the week. Unfortunately we were not able to preserve the issue authorship informaiton during the migration. Actually, its preserved but as part of the issue text (Reported by: Sean Schofield.) So you will have to sign up for LH if you don’t already have an account. In theory this lowers the barrier for reporting issues since many Rails developers already have a LH account. They also accept OpenID if you’re into that sort of thing.

Paul Callaghan and I have been working on the new extension directory which we will now be using to keep track of all of the third party extensions people have been writing. We’ve got a bunch of them in there already with many more to be added still. If you have extensions to share please publish on GitHub and add them to our registry. Make sure you follow the instructions in our new online documentation concerning the creation of your own extensions. Special thanks to Juan José Vidal (juanjo) for the original contribution of code in the form of the tension project.

We have also made significant changes to our wiki. Most of the wiki has been ported over to the new Spree Guides. We still have a lot of clean up to do on our wiki but we didn’t want to hold things up over such a small thing. In the next few days we’ll be combing through the wiki and getting it down to just the bare essentials. The idea is that the wiki is going to be for FAQ, troubleshooting and other advice from users. The thinking is that the wiki is still useful even though we have this great online documentation as well. Its a work in progress so we’ll see how this works out in the coming weeks.

If you’re curious about who helped us with the redesign, we hired Erika Greco whose quality of work speaks for itself.

jQuery is currently running using the noconflict() option for the Administration interface only, this should help avoid any issues with Prototype during the transition. We plan in enable noconflict() on the customer facing interface at some point in the future to allow developers to use Prototype if they wish in their site extensions.

We’ve also included the jQuery.alerts plugin that provides richer replacements for the standard javascript alert and confirm methods. We’d suggest that any extension developer should look at including them for things like delete confirmations, see taxonomy.js for example usage.

My departure from End Point is based largely on personal reasons. After speding the last four years working out of my home office, it recently became apparent to me that I needed to make a change. The home work environment has become way too distracting as my son gets older and more demanding of my time. My office also sits in the center of the house so its pretty much impossible to isolate myself from all of the distractions around me. Believe me, if there was a way to make that situation better I feel I would have discovered it by now.

The only reason why I’m bothering to mention this on the Spree home page is because its possible that this departure will raise questions and concerns about the future of the Spree project. Let me start off by saying that I personally remain committed to the long term stability and success of the Spree project. I’ve given a great deal of thought as to how to best move the project forward. I actually think that recent developments are going to accelerate the pace of this project, as opposed to slowing it down. Here are some things to consider:

• Core Team: All members of the core team have permission to commit to the Spree core. Removing myself as the sole gatekeeper to what goes into the project has removed a bottleneck that was starting to effect the project adversely. We’re already starting to see reduced wait times for reviewing and committing code contributions. It also reduces my personal stress considerably. I can go away for a long weekend and the project does not need to come to a halt. The core team consists of four developers (including myself) plus some excellent candidates to be added in the future.

• Strong Community: We have a very strong open source community here at the Spree project. There’s an active mailing list where users help one another without having to rely exclusively on answers from the core team. That’s the sign of a strong community for sure. The issue tracker is buzzing with activity and we are getting a steady stream of patches (and new translations!)

• New Sponsorship: The Spree project will now be sponsored by Rails Dog (that’s me.) I’ve already invested some money in purchasing the spreecommerce.com domain name. End Point will remain an active partner in the Spree project and they will continue to provide their excelllent hosting services. By taking over sponsorship of the Spree project directly this should help alleviate any concerns that people might have about one single company being too closely tied to the project. Spree is a true open source project. It belongs to all of us and we’re all in this together.

• New Website: The Spree project will soon be sporting a new website. I’m going to be spending a considerable amount of my personal money into making this site a little more polished and attractive. The new documentation effort is going to be part of this process as well. So you shouldn’t be thinking “Oh noze! There goes Spree!” Spree marches on with even more resources and determination than ever before.

• Corporate Support: End Point has indicated to me that they intend to stay very active with the project. We can expect to see even more contributions on the mailing list and in the form of source code from these guys. In addition to my new company, there are many other companies out there indicating they are willing to provide support. The more companies using Spree the better for all of us.

My future plans will be taking me to a small company called Econify which is located in Washington, D.C. The owner of the company is actually a friend of mine from college. The office is located close to home and only two blocks from where my wife works so we’ll be able to commute together. They’re also offering a flexible schedule so I can have some predictable time off to schedule my family stuff around. My new company will be doing Spree consulting if anybody is interested. Just drop me an email at sean@railsdog.com if you’ve got either a project or just need a few hours of consulting time to advise on a project.

Spree continues to gain momentum thanks to all of our hard work together. This month the website topped 10,000 visitors for the first time and we’re closing in on 500 watchers in GitHub. We’ve also received contributions from over 60 different developers. I’ll be taking a long weekend off starting tomorrow but then its back to business. I’ll be using the next two weeks to finish off our shiny new website which we hope to launch on June 15. I look forward to even more progress in the second half of the year.

First, with the latest core changes, screen.Sass is broken down into several components, such as:

...
@import mixins.Sass
@import colors.Sass
@import layout.Sass
@import product_detail.Sass
@import cart.Sass
@import checkout.Sass
...

This improved organization will make it easier to adjust the core code for specific page or component changes. For example, one visitor to the RailsConf Spree Birds of a Feather session discussed how his client requires the single page checkout to be overridden and separated into separate steps. Instead of managing the entire screen.Sass stylesheet, he can simply override the checkout.Sass file for the required changes. This modularization will make it easier to adjust style rules without the fear of conflicting with or breaking other site style rules.

Second, a benefit that comes from the Sass improvements is the move to separate color stylesheet rules from the layout style rules. For example, the colors.Sass file contains the following:

...
!input_border = #BBB
!default_border_color = #DDD
!link_hover_color = #eee
!lighter_text_color = #666
!medium_blue = #2E6AB1
!lightest_blue = #BBDAFD
!light_blue = #E5F2F8
!dark_blue = #162F54
...

These color rules are then used throughout the stylesheets. Below is an example of their implementation:

#header
 :position relative
 :color = !medium_blue
 :clear both
 a
   :color = !medium_blue
   &:hover
     :color = !light_blue

The above Sass yields the following css rules:

#header {
 position: relative;
 color: #2e6ab1;
 clear: both; }
 #header a {
   color: #2e6ab1; }
   #header a:hover {
     color: #e5f2f8; }

The benefit of separating the colors from the layout is that the long term plan is to allow for a much easier way to reskin the site by making minimal changes to layout.Sass and colors.Sass. For example, in the future colors.Sass may contain the following:

...
!input_border = #BBB
!default_border_color = #DDD
!link_color = #ABABAB
!link_hover_color = #EEE
!lighter_text_color = #666
!background_color = #2E6AB1
!accent_color = #BBDAFD
...

A separation of “lipstick” and “layout” will ease the ability to customize the Spree look, which is an essential for every implementation of Spree.

A final benefit with this round of Sass improvements was to take advantage of mixins, which allow you to define a set of CSS attributes and include them in any number of selectors as an inline rule. This goes along with the DRY notion - it’s much easier to manage a single css definition that is applied to many selectors. The mixins also accept arguments and can have a default argument value. Below is an example of a mixin definition with a default value:

= round_corners(!radius = 5px)
 :-moz-border-radius= !radius
 :-webkit-border-radius= !radius

The mixin is used in a selector, such as:

button
 +round_corners(0.3em)
 &.large
   +round_corners

The above example yields the following CSS:

button {
 -moz-border-radius: 0.3em;
 -webkit-border-radius: 0.3em;
}
button.large {
 -moz-border-radius: 4px;
 -webkit-border-radius: 5px;
}

Although at this point the Sass implementation does not introduce new skinning functionality, it certainly gets the Spree project moving in the right direction. Some future improvements include improving the ease of overriding Spree core colors as discussed above, improving the ease of overriding stylesheet rules or complete Sass components, and introducing a mechanism to include extension style rules in order to avoid having to include a separate stylesheet for every extension.

For more information on Compass and Sass, take a look at the Compass & Sass screencast.

There is also an important change to the Spree project in GitHub. The project can now be found at railsdog/spree instead of schof/spree. This shouldn’t impact too many people, since I just renamed my personal account and all of the forks and watchers should be intact. Your GitHub forks will continue to work properly but going forward you will want to clone/pull from the new repository location: git://github.com/railsdog/spree.git If you are tracking the old schof/master repository in GitHub you wil probably need to update your remote references.

For example inside of .git/config if you have a remote reference to schof you would want to change it as follows:

[remote "schof"]
        url = git://github.com/schof/spree.git
        fetch = +refs/heads/*:refs/remotes/schof/*

should be changed to the following

[remote "railsdog"]
        url = git://github.com/railsdog/spree.git
        fetch = +refs/heads/*:refs/remotes/railsdog/*

Please feel free to drop us a line on the Spree mailing list if you have any troubles with the move.

You may be wondering what has prompted this change. In the past several months we have seen an explosion of interest in (and contributions to) the Spree project. We are now in the enviable position of having more contributions then can be handled by a single person. Its important that these contributions be reviewed for code quality and possible implications for the Spree community as a whole. Instead of getting bogged down with delays I’ve decided to enlist the help of these three individuals who are going to help with code review and general project leadership. Each of the new core team members has shown an excellent ability to work together as a member of a team - something that is just as important as a person’s programming ability.

You may also be curious as to what this means for my involvement in the project. I personally plan to remain very active and involved in the Spree e-commerce project. I will still be coding and I’m going to continue answer emails and IRC questions when possible. Most importantly, I will continue to provide oversight of the project and making sure that we are not straying too far from the original vision. I’m personally very excited about this step, as it allows me to offload some of the project maintenance and the entire community reaps the benefit of a faster development and release cycle. We’ve already demonstrated that we can build a pretty sweet commerce platform without a bunch of venture capital. The core team now gives us a solid foundation as we take things to the next level.

Fabio Akita did a lengthy interview with me about Spree on the second day of the conference which he already has posted. I haven’t listened to it yet but it was basically a discussion about the origins of the project and what makes Spree special as a commerce platform. The “Rails Envy” guys were kind enough to mention us during their Rails: A Year of Innovation talk. Carl and Yehuda both mentioned Spree during their talk on The Russian Doll Pattern: Mountable Apps in Rails 3. Mountable apps look extremely promising and they have important implications for projects such as Spree.

One of my main goals at this conference was to learn more about the exciting concept of mountable apps. Yahuda explained that in Rails 3, applications will be able to define “mount points” which define an informal sort of API that can be used to link applications together. In this way, applications such as Spree could be combined with other applications, such as Radiant, and they could even share common aspects such as login or admin panel. The ability to mount several apps together is a confirmed (and nearly completed) feature for Rails 3. The actual implementation of a commmon login and admin menu is being envisioned as a separate project outside of the Rails core. In fact, Yahuda and Carl have already started up a Google Group to discuss such a venture. Feel free to join in the discussion if this is something that interests you (and it should interest you if you are planning on doing a lot of Spree development in the future.)

One exciting announcement during the conference was that End Point is now offering dedicated Spree Hosting. They’re offering highly secure, pre-configured Linux boxes with all of the Spree software and dependencies installed and ready to go. My favorite aspect of this offering is the parallel development environment you get for free with dev camps. Personally I like this kind of service because it saves me the hassle - particularly when it comes to setting up log rotation, dedicated backups, nagios monitoring, etc.

RailsConf tends to provide leading indicators on what technologies will become a big deal in the following year. Last year everyone was talking about Phusion Passenger. This year, there is the same level of buzz (probably even more) surrounding Rack. I’ve recently discovered an excellent guide on this topic on the Rails site. Gregg Pollack also gave a very excellent explanation of Rack during his innovation talk (with video of this talk promised soon on Rails Envy. There was also a lot of talk about metric_fu which is a nice gem that combines a series of code metric modules into a single gem. We’ll be running this on the Spree project soon. I’m sure there’s lots of room for improvement.

RailsConf was a great time and definitely worthwhile. I was glad for the opportunity to get the word out on Spree and spend time with my coworkers. Even better then talking about Spree was listening about what other people were up to. After the conference we all had several exciting new ideas on how to improve Spree. You’ll be hearing more about these new ideas in the coming days.