If you haven't seen The 15 minute E-Commerce Site CLICK HERE

I'm currently looking for Contract jobs, Contact Me if you are interested. Dave.

Tunnel Vision David Henner Aug 08

1 comment Latest by fdcqyecevb

A company contacted me today and told me they are in stealth mode. After looking at the founder's background he was in stealth mode for FIVE YEARS! If you are in stealth mode for more the 6 months I have my doubts but over a year starts to raise red flags.

Either the idea is too hard to implement or you aren't dedicated or maybe you just aren't as good as you think. I don't know what the problem could be but I'm sure you have excuses. That should signal to change.

Change the idea?

Change your effort (none or more effort)?

Change your career?

Just maybe talking about the idea to others rather than fearing feedback from people might help. I've actually seen more companies hurt because they don't communicate their "brilliant" vs staying in stealth mode.

So please people, get a clue. Even if you have a great idea that is exciting, your idea is too hard or too boring or not a good enough idea from the perspective of another entrepreneur. People are too busy with their own idea to steal your idea. Tunnel vision is why you love your idea and it is also the reason nobody wants to steal your idea.

Security Silence David Henner Dec 21

2 comments Latest by DRH

About a month ago ror_ecommerce had its first security announcement. The fix was super simple and the vulnerability was limited to MySQL. Given that most users of ror_ecommerce use postgres on heroku the scope of the problem should be limited.

That stated my concern is this announcement mostly fell on deaf ears. In fact, I'd bet the only people listening are hackers trying to take advantage of the vulnerability. This has me very concerned. I've found similar issues with OSS that actually list the companies that use their software. This is an announcement to every hacker of what sites use the software and are vulnerable.

I personally gave phone calls out to sites that I knew have ror_ecommerce in production. Luckily they all use postgres so they were never vulnerable. I'm not going to name names, but if you maintain OSS please DO NOT name the companies that use the software unless they personally ask for the advertisement. It is selfish and irresponsible to list these companies.

ROR_ecommerce's Security Fix

As for the specific fix, the commit can be found here:

Commit with fix

For more details on the fix click the link below: (BTW this is an issue with many Rails applications)

More Details

If you have code that looks like this:

@user = User.find_by_perishable_token( params[:id] )

You might want to change the code to look like this:

@user = User.find_by_perishable_token( params[:id].to_s )

On MySQL at the very best you have a bug. Worst case you have a security vulnerability. Happy Coding!

Stripe Commerce && RoR ecommerce 2.0 David Henner Jun 30

Post a comment

Today I am releasing stripe_commerce. This is basically ror_ecommerce forked to use stripe. It also has added functionality of handling subscriptions in the cart.

This is 100% production ready. A simple flag in config/settings/*.rb will allow you to go from a "signup period" to "Pre-Orders" to take full orders.

Generally you can follow ror_ecommerce's documentation. Added features include:

  • Each variant can have their own specific
  • Return process works in development with stripe's sandbox
  • Subscription can be purchased in the cart with normal products
  • UI works well with a responsive design for mobile
  • Software switch for "Signup Period", "PreOrders", & "Orders"

I am asking for a $250/year fee for production use of this software. I am using the honor system. I spent many hours getting this software working and trust this is a minimal price. Feel free modify the code for your own use but leave the license and please honor the fee.


RoR ecommerce 2.0

With the new release of rails 4.0, ror_ecommerce has moved to 2.0. The biggest update is the use of strong parameters. Many small changes were made to get this working with Rails 4. Please see the previous blog post for more details.

ror ecommerce 2.0.0.beta1 (Rails 4 upgrade) David Henner May 08

1 comment Latest by Tam Vo

Today ror_ecommerce's rail4 branch has been tagged as 2.0.0.beta1. All deprecation warning have been resolved and all test pass. This release will now have ruby 2.0 be the supported ruby version and the project has been upgraded to rails 4.

I'm guessing people will want to hear about the pain points to upgrading a large project to rails 4. So the remaining of teh post will highlight my findings.

Strong Parameters

I had originally thought the upgrade would be much more smooth to simply add the protected_attributes gem. It appears to just be the same functionality as rails 3 right? WELL, not exactly. The problem has to do with the gems in your project. You can expect maintainers of gems to support rails4 (and have rails 4 branches of the gems). You can not expect them to support the protected_attributes gem. Hence the guy maintaining protected_attributes either have to cover a bunch of "one off" issues or there are going to be cases where things just won't be supported.

Instead of looking into every gem that has issues working with protected_attributes, upgrading to use strong parameters is an option that should be best long term and in this case for the short term.

I had originally thought the admin area could be ignored but it appears passing raw parameters blows up. So the main task was to edit every controller with a create or update action. In most cases I created a prvate method called allowed_params like the following:

def update
  @address = 


def allowed_params
  params.require(:address).permit(:first_name, :last_name...)

I had two gotchas. First nested forms were not always working. I don't know the exact issue but luckily this only effected forms in the admin area. Given that it was just the admin my work-around was to use:


def allowed_params

Yes I did try the examples for nested forms but that didn't work out of the box in my case.

The second Gotchas was forgetting about my custom setters. For example a Purchase order form has a "receive_po" field that the receive_po method handles. I had to remember all teh use cases where forms used custom setters and put those params within the permitted params.

This was/is tedious work but generally the process was pretty quick.

GEM Upgrades

Some gems that needed to be upgraded were compass, database_cleaner, friendly_id, sass-rails and ZenTest.

 gem 'compass-rails', :git => 'git://', :branch => 'rails4'

 gem 'database_cleaner', :git => ''

 gem "friendly_id", :git => "", :branch => 'rails4'

 gem 'sass-rails',   '~> 4.0.0.beta1'

 gem "ZenTest", '4.9.1'    

Deprecation Warnings

Wow I can not explain the number of deprecation warning I had at first. Most were straight forward to address.

First it was obvious authlogic and awesome_nested_set had issues. Luckily I found two pull requests that addressed the issues. I simply added the following to my gem file:

gem 'awesome_nested_set', :git => "", :branch => 'rails4'

gem 'authlogic', :git => '', :branch => 'fix_deprecated_with_scope'

These solutions looked simple enough and will probably be added to the gems soon enough.

Next up were Deprecation Warnings internal to the ror_ecommerce app. Luckily these were pretty straight forward to address. I need to give credit to the rails core team for explaining the solution to the issues within the warning log. Just following those instruction was pretty straight forward.

One warning I didn't expect had to do with a reg-ex I had.

 The provided regular expression is using multiline anchors (^ or $), which may present a security risk. Did you mean to use \A and \z, or forgot to add the :multiline => true option?

This is a security threat having to do with using a reg-ex that allows multiple lines in a field and hence add "something bad" like javascript. Very interesting... I'm glad to see the rails team protecting me from myself. Thanks. To read more take a look at this article:


The upgrade process did take some time but was pretty straight forward. I recommend upgrading to any app in production within a month of the final rails 4 release. This was not the same headache that upgrading from Rails 2 to Rails 3 was.

Also the forced security model with strong parameters might make beginners have a larger learning curve but it REALLY is great for enforcing security. I was not a believer until I started applying the upgrade.

GREAT job to everyone that contributed to Rails 4!

Open Source Thank You David Henner Apr 22

2 comments Latest by DRH

I love writing open source code. The Ruby community is great because its open source community. It gives me the ability to write code without a deadline. It also allows me to write on a codebase I generally like. Sure there will always be pain points in any code base. After two years you should always look back and say,

Why did I do that?

All being said, sometimes it feels very un-appreciated. Yesterday, I had a request to fix a feature that is optional and honestly not used by many people. (If people are using it they fixed the issue with one line of code) So anyway, I get the request and the email comes across as... YOU BETTER FIX THIS OR ELSE!

My first thought was... Well I bet you can guess. I then stopped and gathered myself. At the end of the day this person probably was under a deadline and didn't know what to do. Instead of looking into the problem, they probably got frustrated and sent an email.

The fix was simple and I completed in less than 10 minutes. Verifying the fix setting up the environment took much longer than the fix itself. All this being said, next time you ask someone to fix a problem, try to put yourself in their shoes.

If it is open source code the person may have never been paid to write the code. The person you are requesting to do work is probably very busy. Your wording should be appreciative. Also after the fix, say thank you. It really does mean a lot. I've been guilty of this but I sincerely try my best.

All being said, I love feedback on my projects. Even if it does point out a bug. The way you word things does mean all the difference.

RoR ecommerce progress report David Henner Feb 04

Post a comment

Its been about two year since ror_ecommerce has been open sourced. Since then I've had the joy of helping and getting help from many developers and business folks. Luckily the biggest near-term challenge is determining when we call ror_ecommerce 2.0. Given that the software changes in small pieces no single change will be large enough to label as 2.0. Adding a major amount of documentation might actually be the trigger more than just software itself.

Currently, the software is solidifying and instead of feature building the focus is on cleaning older code up. Fortunately many of the models have 50 or 60 lines of documentation before you start diving into real code. Unfortunately that documentation is not picked up by the YARDocs. I've found having the docs live in the code is most likely the best way to document everything. However the goal is to eventually have a documentation page much like stripe's documents. It won't be easy to maintain but the payoff for developers will most certainly be worth it.

The current things on the top of the ToDo list include:

  • Documentation
  • Referrals
  • Reports
  • Cleaning up the code
  • Making a multi-tenant version of ror-e

Don't forget to check out the demo.

  • Username =
  • Password = test123

I'd love to hear some feedback about features and the direction of the project. I can't guarantee we will work on your specific "wish" but ask and you might be surprised.