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.

E-commerce Tips 1.0 David Henner Apr 01

8 comments Latest by DRH

I've been looking through many business's code over the past couple years. It appears many very smart developers make the same mistakes over and over again. I continually see some obvious and not-so-obvious mistakes being made. My plan is to start documenting and blogging about the issues I see. So today My goal is to start this series with...

Saving Addresses

Saving an address in an application sounds so easy most people don't put much thought into it. You just need a basic CRUD app right? You guessed it... WRONG!

Lets talk about the easy section of the CRUD actions first, CREATE. Create is almost as simple as it sounds. Add all the validations that you need and you're done.


Next up... DELETE. I'm skipping UPDATE for now. Update is the most complex so I'll leave that for last. If you do this:

## NEVER DO THIS
@address.destroy

you better get ready for 404 errors and nil object errors. Instead you better have code that looks like this:

@address.inactivate!

class Address
  def inactivate!
    self.active = false
    save!
  end
end

and in your User's model you better have something like this:

class User
  has_many :active_addresses, :class_name => 'Address',
             :conditions => ['addresses.active = ?', true]

end

or you could do this:

class Address
  def self.active
    where(['addresses.active = ?', true])
  end
end

What does this buy you? It should be pretty straight forward but now we are not deleting Addresses in the DB. So when a user looks at an old Order an address object isn't nil.


Now comes the difficult beast... UPDATE. The reason this is difficult it that you actually shouldn't ever update an address. Instead you should be creating a new address and inactivating the old address.

In this process validations need to be fooled around with a bit to work the way the end users should see them. So you should be doing something like this:

def update
  @address = current_user.addresses.
                        new(params[:address])


  respond_to do |format|
    if @address.save
      old_shopping_address = current_user.addresses.
                                        find(params[:id])
      old_shopping_address.inactivate!
      format.html { 
           redirect_to(address_url(@address), 
                :notice => 'Updated successfully' ) }
    else
      @form_address = current_user.addresses.
                                   find(params[:id])
      @form_address.attributes = params[:address]
      format.html { render :action => "edit" }
    end
  end
end

Now to make this work all pretty in your view your form needs to use "@address" for the error messages. Then use "@form_address" for the form. Like this:

<% if @address.errors.any? %>
  <div id="error_explanation">
    <%## You might want more Verbiage %> 
    <ul>
      <% @address.errors.full_messages.each do |msg| %>
        <li><%= msg %></li>
      <% end %>
    </ul>
  </div>
<% end %>

<%= form_for(@form_address, 
             :url => address_path(@form_address)) do |f| %>
     <%= render :partial => 'form', :locals => {:f => f} %>
<% end %>

Well I guess I left truly the easiest for last... READ. Just make sure when you display the person's current account information that you only display active addresses.

  @user.active_addresses
    # or
  Address.active.for_user(user)

One more thing. You might think you can create a new inactive record for each order you create (or an address with a specific address_type). I assure you this is a bad idea for several reason.

  • You will generate a lot of records.
  • You have many records in your DB that are basically duplicates
  • When you are trying to look through a users information it gets very difficult figure out what may have changed and when it changed.
  • It hurts performance

That's it for this post. CreditCards, CartItems, Cart vs Order, OrderItems and Returns are all on my to-do list. If I get really motivated this might turn into a book.

Thanks for reading!

ror_ecommerce 1.0 David Henner Feb 15

Post a comment

It's been almost 2 years that I started a project that I thought would take me a few months. At the time I wanted to create an e-commerce project that would be simple for a rails developer to begin an e-commerce project from. I was actually envisioning an SOA architecture. Once I realized the difficulty to get an average developer up and running I abandoned the SOA approach.

Now it's time to call the project 1.0. I actually tagged 1.0.rc some time ago and then Rails 3.2 came out and I needed to upgrade and allow some time to pass before I gave the approval for 1.0.

First I would like to personally thank all the contributors.

  • Dean Perry
  • Denis Peplin
  • João Martins
  • Moses Song
  • Nelson Hernandez
  • Nick Jain
  • Oren Golan
  • Torsten Rüger
  • Vladimir Melnick
  • Yury Velikanau

Contributors mean so much to open source. The project would not be worth the effort without you. It's amazing to get feedback from people and the first pull request was the best Christmas Present.

Now the project is in a state that it can be used as a great platform for e-commerce applications. I have even used rorecommerce for apps that were not e-commerce but had an e-commerce element. Rorecommerce gave me all the authentication and general things I normally add anyways so I found this approach worked great.

New Goals

My feeling the following are on my near term additions:

  • Admin UI will get more attention
  • Documentation (specifically more
  • details why each model was
  • architected the way it was) Theming
  • capabilities. Mass importing ofproducts / images Create
  • Engines for (Surveys / Blog / ... )

Still further down the road:

  • Point of sale capabilities (maybe merchantOS)
  • Store for developers to sell their own engines.

One last note:

I just added a demo site. This should help people evaluate the project. Take a look... I have not setup authorize.net but you should get a good idea of what's inside the project.

login: test@ror-e.com password: test123

Dave

Justifying TDD/BDD & Technical Debt David Henner Feb 12

Post a comment

Yeah I said a dirty word.

SCHEDULING

So here is the scoop. At some point you will need to give someone a schedule. I still stand with the idea of having Goals not Schedules. Goals are for your team. Unfortunately, Schedules are for Venture Capitalists.

The first rule for scheduling is that the schedules are not made to be met. Schedules are made understanding what needs to be done.

Given the 1st rule, you should not spend a lot of time on schedules. That said if anything you schedule takes longer than a month or two you should still break it up into sections (preferably 2 week sections or less).

What you aren't doing correctly!

The one part of scheduling that people never take into account is maintenance. The day your app goes live you might schedule 25% of your time going toward maintaining production.

My first reaction is 25% is probably too low. Your first few weeks after launch at least 50% of your time concerns maintenance. Even if you don't have bugs your users are responding (hopefully) and if they are responding you should spend some time reacting to their concerns.

Lets say 25% percent is an accurate amount of time devoted toward maintenance. One of the biggest issues is that you now continue to have a constant amount of time devoted toward maintenance for the next year of your schedule. Why is this an issue?

Every time you release a new feature the % of maintenance must go up.

This should not come as a surprise. As you have more features, you have more issues. So to schedule correctly your schedules should look like this:

  • Task-1 ( 2 weeks + 5% maintenance)
  • Task-2 ( 1 weeks + 2% maintenance)
  • Task-3 ( 2 weeks + 0% maintenance)
  • Task-4 ( 4 weeks + 10% maintenance)
  • Task-5 ( 1 weeks + 15% maintenance)

Yes some tasks will not need maintenance. An admin interface will commonly have little maintenance issues.

Lets say another 10 weeks pass. Looking at the above schedule One might think that after 10 weeks you could finish all the tasks. This isn't true because in the beginning 25% of your time is spent on maintenance. Then as you progress your maintenance time grows to 57% of your time.

Pretty soon all of your time will be spent on maintenance. This is when managers say we don't have enough developers. NOTE TO BUSINESS FOLKS => LEARN TO STOP THE CYCLE MAINTENANCE CYCLE.

Developers sometimes label this as technical debt. Unfortunately business folks don't understand technical debt. They do understand schedules not being met. So we need to explain to them in terms that they understand. Unfortunately a gantt chart doesn't measure your schedule very well.

Now it's time to Justify Best Practices?

Give a VC or business guy two or three schedules. Don't focus on the time it takes for each task or even the maintenance. Your first schedule is each task without TDD. It might look like this:

  • Task-1 ( 2 weeks + 5% maintenance)
  • Task-2 ( 1 weeks + 4% maintenance)
  • Task-3 ( 2 weeks + 2% maintenance)
  • Task-4 ( 4 weeks + 12% maintenance)
  • Task-5 ( 1 weeks + 15% maintenance)

Your second schedule is each task with TDD. It might look like this:

  • Task-1 ( 2 weeks + 3% maintenance)
  • Task-2 ( 1 weeks + 2% maintenance)
  • Task-3 ( 2 weeks + 0% maintenance)
  • Task-4 ( 4 weeks + 10% maintenance)
  • Task-5 ( 1 weeks + 10% maintenance)

You notice the reduced maintenance but the reality is maintenance is still rising at a good pace. The third schedule you need to add a task to reduce Technical Debt.

  • Task-1 ( 2 weeks + 3% maintenance)
  • Task-2 ( 1 weeks + 2% maintenance)
  • Task-3 ( 2 weeks + 0% maintenance)
  • Tech-Debt-Task-1 ( 1 weeks - 5% maintenance)
  • Task-4 ( 4 weeks + 10% maintenance)
  • Task-5 ( 1 weeks + 10% maintenance)
  • Tech-Debt-Task-2 ( 1 weeks - 10% maintenance)

Unfortunately you should not work off technical debt until weeks after you create the debt. Scheduling more time up front for tasks just doesn't work. There are a couple reasons for this:

  1. You always have "ah-ha momments" after the project is complete. Sometimes well after the task.
  2. Some of the debt isn't learned until you have more information. (like when you are asked to build something on top of the original code)

TDD / BDD / working off Technical debt will never remove the need to hire more developers. But using this technique it is much easier to justify using best practices. You will be able to "scale your developers." You should also point out to the business folks the amount of man hours spent on maintenance / new features / training / management with and without best practices after 6 months & 1 year. This is what your VCs and other business folks understand.

Your next step is to justify not having schedules. I haven't thought of what to do about that yet. Luckily I have been successful at using a few curse words to justify not having schedules. =)

The startup Grind David Henner Jan 30

Post a comment

I am currently in the process of starting my own company. The process is long and has many ups and downs. At the end of the day I feel this process will be more than rewarding. I just can't wait for revenue and profits.

Until then I need to look for part-time contract work. I feel the process of finding part-time contract work should be easy but I must be doing something wrong. In fact two blog posts below I talk about how I tell customers what they need to hear rather than what they want to hear. That prevented me from closing on a part-time contract.

If anyone has needs a part-time developer my rate is $125 / hour. I like working onsite but I'm always up for telecommuting. Part time might mean fly me in for one week out of the month and let me telecommute one day of the week for the rest of the month. If you need help feel free to contact me at drhenner [at] ror-e.com

dave

Gamifying your development process David Henner Jan 30

3 comments Latest by DRH

For years Agile and now lean development processes have been practiced at many companies successfully to create software. I tend to Lean towards "Lean" development mainly because it has not been bastardized. In fact I have found most companies that call themselves Agile have no idea what Agile means.

I find these processes address key problems in development. Unfortunately they don't address many issues I find to be extremely important. The biggest issue being Employee turnover. By this I don't mean just developers changing jobs I mean anyone moving. Developing software should not just be a process it should engage your entire team and be fun.

Let me introduce what I call:

The Gamification Development Process

First there are several goals this process tries to achieve.

  • Communication
  • Better and more open ideas flowing in the office
  • Low employee turnover
  • Motivated workers
  • Idea wins mentality

Let me say, I would like to inherit all the Lean processes and My intention is not to rehash what lean is all about so please read up on "lean Processes" if you don't know what Lean is.

Game Process 1:

Once a month (or every X weeks) a company will break their company down into several competing teams. Marketing, Developers, Creative even the C-Level employees will be broken into teams. Each team should be broken down into a good mix of each skill-set.

Each of these teams will be asked to create something useful for the company. What each team creates (or starts to make) depends entirely on the team. No idea can be vetoed. At the end of the day (or the next day) the teams will pitch their idea/solution to the company.

The winning team wins something. Cash, a vacation day, an iPad... You can really have any prize.


What this process does is first it gives you a set time where ideas at your company flow to the leaders. If you see an idea that can make money for the company you can immediately make that idea the next company project. Also now employees will constantly be thinking, "What can we do to win next month?" Employees will be talking with each other during the month, constantly trying to come up with the next best idea for the company. I can't count the number of times good ideas are brought up at low levels but never addressed to management.

Also your employees are now excited to come to work. If your idea becomes a real project you have:

  • A Sense of ownership
  • Pride
  • Recognition
  • Motivation

You can also more easily see where good ideas are forming in your company. Remember Ideas should win not seniority.

Game Process 2:

Give developers time to ask other employee's "What their biggest pain point is". I remember when I worked at ShoeDazzle. I was given a good amount of flexibility to work on what I wanted. I'm not sure if this was because I didn't listen to management well or because they truly gave me freedom but that is beside the point.

I would approach the DBA and ask, "What are you asked to do repeatedly that I can automate?" The first time I asked the DBA his response was, "I've never had a developer in 15 years ask me that!" He rattled off about 5 of his biggest pain points. Three of his pains I finished in less than an hour and it freed up at least a day every week for him to do other things.

If you ask your developers to take a day every couple weeks to help automate different people's jobs the reward will be handsome. Make this part of your culture.


This process first makes developers more approachable. If your employees are talking to your developers, your problems can be automated. It also makes the daily grind just a little more easy to deal with. People get bored with their jobs because many times they are doing the same mundane things over and over. If these mundane things eventually go away, employees are happier and happy employees don't leave.

This builds:

  • Communication
  • Motivation (it's so much easier to work at a place with less tedious tasks.
  • Feeling that you actually helped someone directly
  • Less employee turn-over

Game Process 3:

Stop making schedules. Goals are fine, Schedule kill. You miss a schedule and everyone gets disappointed. When I say everyone I mean C-level all the way down to the garbage man. Goals serve the same purpose but the feeling of a deadline kills moral. Sure you need to see results but don't you think 90% of your employees try to hit their goal.

So what is the difference between a Goal and a schedule.

  • Verbiage (If you don't think this is a big deal it is)
  • A goal does not have a MS project gantt chart.
  • A goal does not take days of meetings to estimate when it will be done. (Spend your time working not scheduling)

Yes I do understand things need to get completed but first management needs to come up with ideas well in advance of a completed date. Management should be starting projects for Christmas in July. The project should have an on/off switch and should be turned on for Christmas. The project should not be complete at Christmas. Completing a project in the nick of time kills quality and increases stress levels. It also puts a stop on Game Process 1 & 2.

Game Process 4:

Reward your employees. Analog Devices had an idea of a spot award. Any employee can give another employee a spot award. Lets say I automate my DBA's workflow. The DBA can elect to give a reward to me out of his spot award allowance. Management gives the award or even increase the award amount if it was worth it. Several Companies have processes like this. The award normally isn't large. The good news, it doesn't need to be large.

Game Process 5:

Sales people are commonly paid a commission of sales. Even when the sale actually required a developers time. Some projects should have a financial reward. For example, if a projects goal is to increase conversion rate by X% you should be able to quantify that conversion rate (extra customers) into Revenue. The whole development team should see a small % of that revenue go back into their pockets.

The project should pay the entire team not just the project leader. This promotes people within the team to contribute and help out even if they are not working on the project itself. It is also unique to your company. Developers will strive for a more robust better solution if it helps their bank account. Do you want your developer to say "OK" when they know of a better way to do things? Trust me it happens all the time.

Also the reward should be good but not 50% of the developers pay check. Also feel free to say the reward is for extra revenue for the first month of the project. Having the reward go on forever can easily make the team content. This is not the goal. The goal is to motivate and increase quality.

Sounds like you will be paying a lot of Money

So you are reading this and thinking, WOW this is going to cost a lot of money. Maybe not.

First, many of these awards are a direct result of more profit. You might be paying more but as the saying goes. I'd rather 10% of a million dollars than 50% of a thousand dollars.

Second, All of these processes reduce employee turn-over. Employee turn-over is one of the worst things that can happen to a company.

Third, If the rewards are thought out the profit gains will outweigh the rewards.

4th, Productivity will surely increase.

Last, you don't need to incorporate all these tools. even a couple of these processes will help your company in more ways than one.


My goal is to continue blogging about "The Gamification Development Process". Feel free to add comments. Also every great idea needs an acronym...

The Gamification Development Process.... GDP

Until next time....

Does Ethics pay off? David Henner Jan 25

1 comment Latest by Romy

Developers have seen this a thousand times.

Senario

You are asked to rescue a project. The business owner has an application that has no quality.

  • The methods are 100 lines long
  • There are no tests
  • No documentation
  • Every other page has some big issue
  • The data schema just doesn't work

The Solution

The developer tells the business owner the truth. The business owner says "That isn't acceptable. Can we just fix the last few errors."

If your answer is

Yes

You are probably not telling the truth. Thus I would call you unethical. But congrats you got the job. Unfortuately the months pass and the application is a bear to maintain. If you leave before "the shit hits the fan" you are very lucky.

If your answer is

No

The business owner says to themselves. "I need to find a developer that can make my app work." They are guaranteed to find some maverick to take on the task. 99 times out of a 100 the business owner is unhappy with the application. A long time passes and eventually the business guy gets so mad they just start over with a new application.

The cycle repeats...

My Question

If developers have seen this a 1000 times, why haven't business owners seen this at least a couple times? Also, why do developers give in to telling business folks the answer they want to hear? Stand on your two feet and tell the truth. The Truth might hurt and it might not land you a job, but WHO CARES!

The number of jobs out there are high. Be ethical and just tell the truth.

Estimates

On a similar note. Business people have no idea of the sense of time it takes to get things done. I have always been good at estimating. That said if you are a business owner and ask a developer how long something will take. If the answer isn't "I don't know," The developer is just giving you a line. Fact is you as the business owner will always change requirements. As a developer you never know what will change or how much it will change.

So please business owner... Stop asking the wrong question.

Good Questions

  • What is the best way to get the project on track
    • There are no un-acceptable answers to this question
  • What are the consequences of keeping the current application vs starting over.

  • Get a second opinion from a highly recommended developer. Pay the developer for the opinion and tell him they are not getting the job. The answer might change if they are trying to land a job.

Also remember starting over doesn't mean starting from scratch. It means take bits and pieces from the original app. Most developers will say refactor to make you happy. At the end of the day they say refactor because they know you will freak out by saying re-write. Trust me developers know many times that a re-write will take less time than a refactoring job.

Good Luck.