RoR-e

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.

production support David Henner Jan 12

Post a comment

Six Months ago I volunteered to be production support at my current job as a ruby developer. At first this appeared to be a great idea. The site had bugs that needed to be fixed quickly. I demanded quality more than anyone else so fixing these issues didn't bother me.

The problem with this role was three-fold.

  1. Other Ruby Developers weren't responsible for their own mistakes.
  2. Developers started making the same mistakes over and over. (they didn't feel the pain of making a mistake)
  3. Developers didn't learn.

Not taking responsibility supports laziness and causes developers not to worry about anything except the happy path. If you are blessed to work at a place where people demand quality, you are truly blessed. Also the role of production support isn't required in that environment.

I'm going to keep this post short. The moral: If you are a manager and you are thinking about creating a position for production support, THINK TWICE. Some work-places having this position will work out fine. Know your employees because what looks like a good idea might bite you in the butt.


ror_ecommerce, ruby on rails ecommerce done right

Tests and Docs makes better ruby code David Henner Dec 28

16 comments Latest by Mark Wilden

OK it might appear to be obvious that writing tests will make your code base more robust. Likewise writing documentation will allow people to read your code better. I haven't heard many people discuss the side benefits of writing tests and docs.

If you Follow TDD/BDD in it's purest form, congrats. My brain doesn't work that way. I follow something I call Demo Driven Design. I'm not sure if DDD is a good acronym though, LOL.

Here is the concept. I'm given a project. I normally think of one feature in the project that I can complete in 4 hours or less. Then I start writing code. (no tests) After the feature is complete, I will have normally re-written several of the methods in the feature several times.

  def price
    self.variant.price
  end

  def total
    self.price * self.quantity
  end

Had I been writing tests the whole time I would have had rewritten the tests several times also. This at least doubles my effort for no extra benefits. I'm not sure about you but writing tests can take much longer than writing code. I hate wasting time so pure TDD frustrates me. (I lose momentum)

Now after a few hours I have code that I like. Now it's time to comment the code out.

  #def price
  #  self.variant.price
  #end

  #def total
  #  self.price * self.quantity
  #end

Now I write my tests.

  before(:each) do
    @cart_item = Factory(:five_dollar_cart_item)
    @cart_item.item_type_id = ItemType::SHOPPING_CART_ID
  end
  context " price" do
    it 'should have a price of the variant' do
      @cart_item.price.should == 5.0
    end
  end

  context " total" do
    it 'should have a total price of 2 times 5 dollars' do
      @cart_item.stubs(:quantity).returns(2)
      @cart_item.total.should == 10.0
    end
  end

The tests should fail. Then I un-comment the methods and they should pass. This process saves me a lot of time and saves me the frustration of re-writing test.

Testing code... biggest benefit is my code quality on day one improves (not catching future issues)


Documentation

So now the tests are complete. I don't write documentation. If I write the documentation immediately I lose focus on the overall project. Losing momentum is one of the worst things for any project. Especially when you have deadlines. The key here though, don't get lazy and never write documentation. After you reach an ending point now comes the tedious task of documentation.

Writing Docs can be much more rewarding if you also re-write some of the code as you go. How many times have you looked at your code after a day or week or year and said. Damn I should have done XYZ? Well now it's a few days (maybe weeks) later. You now have the benefit of hind-sight. Plus the code is still fresh enough so you don't have to re-remember what you did.

  # Call this method if you need  
  # the price of an item before taxes
  #
  # @param [none]
  # @return [Float] price of the variant in the cart times quantity
  def total
    self.price * self.quantity
  end

I always find myself catching small things. (like OOPS this should be a private method) You also have an opportunity to catch big mistakes.

This doesn't interrupt momentum and when I test / document like this my greatest benefit is my code quality goes up. I know having a great test suite has benefits of catching mistakes in the future. I find the biggest benefit is my code quality on day one improves.

I've had all my unit tests for ror_ecommerce for months. I'm currently creating YARD docs for all of the methods in the models.

I can say the code quality has been dramatically improved through both testing and documenting.


ror_ecommerce, ruby on rails ecommerce done right

ror_ecommerce vs spree (The best Ruby e-commerce solution) David Henner Dec 20

20 comments Latest by raul

All the time people ask me...

'How does ror_ecommerce compare with spree?'

To be honest I am probably a bit biased. Assuming everyone knows that I will be biased I will try to be as open minded as possible.

I feel spree is great solution for small sized businesses that wants to get an e-commerce website up fast. It's documentation is pretty good and will definitely save you time to market.

Ror_ecommerce will also save you time to market. What ror_ecommerce lacks in documentation it gains in coding style. After all it looks and feels like a normal Rails app. There isn't a learning curve for developers because things behave as most developers would expect. (winner RORe)

The next difference is performance. ror_ecommerce doesn't have many queries compared to spree. The version of spree I am familiar with had hundred's of queries on many pages. If you plan on scaling large, this can kill performance. (winner RORe)

If you are planning on going public with your site one day you better have an accounting piece in your application. ror_ecommerce has a double entry accounting system built in out of the box. This could potentially save you months of development if you want to go public one day. (winner RORe)

Spree's front end is potentially ready for production on day one. Again for small shops this is an advantage for spree. ror_ecommerce does not try to add much front end work at this time. This is a disadvantage for a small shop that just wants to get something out the door. For a shop that wants to scale large ror_ecommerce this is exactly what you want. Let me explain...

Lets say ror_ecommerce had a bunch of CSS and html in your way from the beginning. There is a good chance you will not remove the CSS, instead you will re-write parts of the CSS and some will stay around even after it should have been deleted. Thus very slightly hurting performance and cluttering up your code. That being said, I see advantages to having a completed front end. (winner Spree)

The Cart is one of the best features in ror_ecommerce. If a user puts something in their cart and removes it. There is just a flag set for that item. So now a marketing team has access to all the information people are putting into their cart. Also a user can save items for later and have items in their cart that are "wish list" items. In spree there isn't a cart at all. Spree starts with an order. This means spree can't have appropriate validations at the model level. Spree had to introduce validations at the controller / programmers discretion. Not only is this buggy but it breaks MVC. In addition there are many abandoned records in spree, thus bloating the orders table. (HUGE WINNER RORe)

Order_item (list_item in spree) prices are broken down individually in rorecommerce. This allows you to process returns without complexity. Also ror_ecommerce never deletes lineitem records. Deleting items on exchanges in spree means you lose history. Thus it is impossible to complete returns accurately 100% of the time. (winner RORe)

Purchase Orders are in ror_ecommerce out of the box. This may be a bit overkill for small shops it is still a great thing to have. Spree does not have purchase orders. (winner RORe)

Internationalization is currently being built out in ror_ecommerce. Spree's Internationalization is pretty good. (winner Spree)

Security, ror_ecommerce out of the box gives you a config file for all secure data and ignores the config file in git. This follows best practices. Spree holds much of the configuration information in the database and also has a column in the DB for credit_card.number. Although, they don't recommend using the number field it's only one bug from a lawsuit. (winner RORe)

Spree clones credit cards and address for every order. This bloats these tables and give no advantage. Instead ror_ecommerce adds new records only when you add a record. When you edit one of these records in ror_ecommerce it inactivates the old record and creates a new record. This improves performance for ror_ecommerce. (winner RORe)

Finally coding style in ror_ecommerce uses many namespaces to allow every action to have one responsibility. This allows easy navigation and clean code. Spree creates many non-CRUD actions and uses resource controller. Resource_controller does to much automatically for you out of the box. This is not a good thing. It hurts performance. (eg. queries for an object without an include thus creating N+1 conditions) It makes the code much less readable. (sometimes you don't see and code it's all magic and when you do over-ride resource controller the code gets very confusing very quickly). ror_ecommerce on the other hand uses standard RESTful controllers. It's very readable and most of the logic is in the models. (WINNER RORe)

You can make a judgement for yourself. You know my opinion.


Follow Up:

RoR ecommerce now has documented over 95% of the methods in the models. With the added YARDocs ror_ecommerce has one more big benefit.


Follow Up 2 (one year later):

After talking with many developers I have found that Spree might have a lot of documentation but figuring out what is out-dated and what works for what version of spree is an impossible task. I don't know how spree can fix this. They did hire Ryan Biggs full time for helping and he is great but he might just have an impossible task.