A typical golf scorecard format.

Basic Golf Card

The basic golf card will have holes along the top with distances, pars and handicaps for each hole. Hole handicaps can generally be ignored for basic golf score keeping. The distances can also be ignored for now as distances are more informational and help the player while they are on the course.

Par is important however as it is the baseline that is used to calculate the users score against par.

In the example above there are five tees listed (Gold, Blue, White, Silver, Red). For each of these tees the distance, par and even handicap can be different. So it is important to know which tee you are playing from so that you know which tee to use on the score card.

Scoring a Golf Card
Now that we understand the information that is on the score card we can shift our focus to how to score a golf card.

Steps to Scoring a Golf Card:
1. Write the name for each golfer
• This goes along the left hand cell in the example above (just under the Handicap)

2. As you play write the result of each hole
• The result for each hole goes in the cell that intersects the golfers name and the hole which they scored the result on. If the golfer scores a 5 on the first hole then the scorer would mark a 5 in the cell beside the golfers name.

That is really it and with this basic information you can keep the score on a basic golf card.

Out/In/Total
While keeping the score for each hole is important, it is also important to add up the Out, In and Total correctly.

Out: The total score for the first 9 holes
In: The total score for holes 10 through 18
Total: The total for all 18 holes

Tournament Scoring
Generally during tournaments you will play with one or more player in your group. Each player will have another player keep score for them. So Player A will keep score for Player B and vice versa. Tournaments use this format to reduce the cheating and to add a bit of formality to the process so that scoring is as accurate as possible.

At the end of each round the player is required to sign their scorecard to indicate that the score that the other player has kept for them is indeed accurate.

Note: The signature is signifying that the hole scores are accurate but does not signify that the addition of the scores (Out, In, Total) is correct.

Use of Symbols
Commonly people will use symbols to indicate how a hole score relates to par. A score that is circled represents a below par (e.g. birdie or eagle). A score that has a square around it represents a score that is above par (e.g. a bogie). If a score does not have a symbol then it means that the score is a par. My score cards generally have a lot of squares on them.

Golfingstat.com Scorecard
Given that Golfingstat.com users like stats and need more information to drive the stats they need to capture more on their score cards. The way that we recommend you do that is to use a whole score card for each player. That way you have up to four rows to write information for each hole. Here are the three that I usually capture and how I capture them.

Score – As detailed above.
Putts – Similar to score. Just write the number of putts that you had for this hole. Then total them for Out, In, Total
Fairways – Fairway for each hole will either be a check to indicate a fairway hit, a X to indicate that it is a fairway missed or a – to indicate that it wasn’t an eligible hole (e.g. a par 3). I then usually add the fairways hit for in, out, total.

Golfingstat.com records greens in regulation as well but you do not have to record that on your score card since it is calculated automatically. You record a green in regulation if you had a birdie putt opportunity on the hole. Since you are recording your score and the number of putts we can easily calculate this without you recording it manually.

Golfingstat.com is a website that allows you to track your handicap and other golf stats for free.

The post How To Score a Golf Card appeared first on Golfingstat.com blog.

Stumbled across a VPS host called Digital Ocean, their offerings have 2x the ram of Linode for a quarter of the cost. So instead of hosting off of a single 512mb server I was able to get a 512mb server for an app server and another 512mb server to host the database and only pay half what I was paying before.

Digital Ocean charges by the hour too so I can have a development server that is an image of the production server and can spin it up/down as needed rather than trying to run a development instance on my production server in the limited linode memory.

I think the only downside to this is that Linode gives you up to 4 CPU’s (depends on how busy the server you are on is) where as Digital Ocean only provides a single CPU. For me currently I think memory was my bottleneck so I don’t think being limited on CPU will impact me drastically and if it does then I can still spin up a few more instances and introduce more app servers.

I was worried about how long the migration would take but it was actually only a few hours of work. The worst part was trying to get Bluepill and RVM to play nicely together and start correctly on reboot. Other than that it was pretty smooth sailing…

The post Digital Ocean from Linode appeared first on Golfingstat.com blog.

Putting (2.5 strokes)
33.5 putts per round vs 36 putts per round

You always read that improving your putting can drastically lower your score. In this comparison the 5 handicapper putts on average 2.5 putts less a round than the 20 handicapper. While I am sure everyone would like to shave 2 or 3 strokes off their round but this isn’t a massive difference.

Iron Play and Chipping (17.3 strokes)
To get a sense of the importance of iron play we are going to look the holes where drivers do not factor in (Par 3’s). Our 5 handicapper averages 3.4 strokes per par 3 while our 20 handicapper averages 4.5 strokes per par 3. If we take that average and apply it to a whole round (18 holes) that is 61.2 for the 5 handicapper and 81 for the 20 handicapper. Now we take the putts off of this and it becomes 27.7 and 45 respectivly. This is a difference of 17.3 strokes.

This also explains the large difference in greens in regulation (50.45% vs 12.5%). If you hit better approach shots you will hit more greens in regulation.

Driving (1.8 strokes)
To assess driving we are going to look at par 4s then take away the expected number of iron strokes and putting strokes (par3 averages).  The 5 handicapper averages 4.45 on par 4s and the 20 handicapper averages 5.65 on par 4s. The average over 18 holes for the 5 handicapper is 61.2, while the average over 18 holes for the 20 handicapper is 101.7. If we take the iron strokes from “Iron Play and Chipping” out of this we end up with 18.9 for the 5 handicapper and 20.7 for the 20 handicapper. This means that driving only accounts for roughly 1.8 of the strokes per round.

Driving clearly has an impact on iron play and chipping stats as well. If a player hits a long and accurate drive then more often than not they will have a shorter iron with a good lie for their approach shot.

Interestingly even though there was not a large difference in the par 4 stats (with par 3 taken out) there was a slight difference in the fairway %.  The 5 handicapper hit 64.1% of fairways while the 20 handicapper hit 47.25% of fairways.

So to recap it appears that iron play and chipping is the biggest difference between a 20 handicapper and a 5 handicapper.

Links:
Golf Handicap Tracker
5 handicapper (my dad)
20 handicapper  (me)

The post 5 Handicap vs. 20 Handicap appeared first on Golfingstat.com blog.

This is the logic we use at GolfingStat.com to calculate your golf handicap. It adheres to the USGA rules and although it is not sanctioned by the USGA it will give you a handicap which matches your USGA handicap.

Go ahead and sign up for GolfingStat.com and begin tracking your golf handicap.

The post Golf Handicap Calculation appeared first on Golfingstat.com blog.

Given that a big part of GolfingStats is Stats here are some Week #1 GolfingStats Stats:

Number of Users Created: 23
Number of Rounds Created: 40
Number of Courses Created: 31

Average User Handicap: 18.9
Average Round Score: 89.1
Average Putts Per Round: 35.2
Average Fairway %: 36.8%
Average GIR: 26.5

My handicap after one round this season is 25.1. So I am 6.2 behind the average…I now have a goal!

In terms of future features I have some big plans…

1. Predictions: Click on a round that someone else has played and see what GolfingStat.com thinks you would shoot on that same course/tee. Also want to have some fun predictions (e.g. How would you shoot from the tips @ Augusta?)

2. Friends Tab:
a) Invite Friends: GolfingStat is great! Not enough people know about it though. You should be able to invite your Facebook friends.
b) Linking Friends: You have friends on GolfingStat.com so you should be able to see how they are playing.
c) Notifications: Be the first to know when a friend posts a new round, so that you can talk some trash or congratulate them

The post Week #1 of Tracking Golf Stats appeared first on Golfingstat.com blog.

My plan is to generate traffic by using a free $100 in Google Adsense.

Not sure if my numbers make sense but here is what I am thinking…

I know that people will be more likely to adopt a score tracking tool earlier in the season because they are more enthusiastic about the sport in the early months. I also know if they start using a tool earlier in the season they are less likely to dump it and pick up another tool. So I need to get as many visit as possible in the first 30 days or so after launch otherwise the value of a visit will be significantly lower.

Playing around with Googles Adwords tools I figure $0.30 is a good Cost Per Click for me. This will give me about 350 visits on keywords that I think are good for my site and will use up my $100 in about 37 days.

Assuming 10% of the people who visit my landing page will sign up leaves me with about 35 users from the Adwords Campaign (Cost to acquire a user is about $2.85 per user). Assuming 25% of them actually use my product and post a round a month to Facebook and each user has about 200 Facebook friends that means I will get ~1750 open graph impressions from users posting round. Of those impressions assuming 1% of viewers click through and 50% of those sign up that means I will get 8.75 new users from Facebook open graph impressions.

This of course does not take into account any organic search, which hopefully will supplement my user growth from Adwords and reduce me user acquisition cost.

This should all happen in the first 60 days. Since I am targeting a launch of June 1st I will check back in on August 1st and report how close/far off I was with my assumptions.

The post Planning the GolfingStat.com Launch appeared first on Golfingstat.com blog.

Here is an outline of the analysis which went into my decision…

Bootstrap – Pro’s

• Save ~40 hours of css pain
• Output is better than I could produce (being honest with myself)
• Quicker wins (Can start crossing off pages as being complete and I will feel better about the positive momentum)
• Scaffolding was built using the blueprint framework (based on my experience completing the Rails Tutorial book examples)  and a lot of my divs use the “span-x” classes to specify widths so moving to Bootstrap is pretty easy
• Cross-browser compatible out of the box

Bootstrap – Con’s

• Looks like every other site released in the last year
• Spending time customizing which probably could be used writing CSS from scratch
• To do properly requires me to enable the Rails asset pipleine which requires me to read/understand the Rails asset pipeline

In the end the fact that I could save a weeks worth of work and have a better product won out and going with Bootstrap was clearly the best choice for my particular project.

Adding Bootstrap to my Rails app was pretty straight forward. I followed the Twitter Bootstrap Basics Railscast and choose to use the ‘twitter-bootstrap-rails’ gem. If it is good enough for Ryan Bates then it is probably good enough for me. The only issue I had following the directions was that Ryan’s instructions have ‘twitter-bootstrap-rails’ in the assets section of the Gemfile as follows:

group :assets do
gem 'twitter-bootstrap-rails'
end

Which was giving me errors because Rails wasn’t able to find the Twitter code. Instead of having the ‘twitter-bootstrap-rails’ gem in the assets group I moved it into the main section of the Gemfile and my problems went away.

Next post will have my first screenshot of the site.

The post Finished Scaffolding, Going with Twitter Bootstrap appeared first on Golfingstat.com blog.

So I figured I would give them a try and play around with their product on my development environment and maybe it would surface some problems. Step one for installing their monitoring was creating an account on NewRelic.com. To my delight they were offering a free copy of The Lean Startup as a reward for signing up. The rest of the install was dead simple (install a gem, copy a yaml file to the server and make a few tweaks to the yaml file) the whole process only about 5 minutes from signup to the first data from my application showing up on the reports.

I will touch a bit on their reporting in a bit but before I get into that I just wanted to mention how they do free trial right. A lot of these free trials require you to put in a credit card and unless you remember to cancel they will bill you or at the very least shutdown your account. New Relic doesn’t do anything sleezy like that, instead they gracefully move you from the full featured professional version to the lite (free) version after your 14 day trial ends. They also take the time for a member of their sales team to reach out to you (I am sure the motive is to qualify you as a lead but still it gives the trial a personal touch) and ask you about your planned usage. Just for replying to their email they extended my free trial by 3 months.

On to their features…Since I am still in development mode I don’t really care about the server monitoring portion of their offering. I am more interested in their application monitoring. I love the web transactions features as they can show your controllers by average response time and you can then dive into the controller and see what is slowing things down.

So based on the controller average response time I can see that my RoundsController#update is taking 135ms more than any of my other controllers on the list.

The performance breakdown for that action looks like this:

Compared to my TeesController#update (which runs at 55.8ms):

I am obviously doing something really expensive in the controller which I need to take a look at. I also might be able to optimize by reducing the calls to Hole#find as I am calling this 18 times and it is probably a lot quicker to get all the holes in a collection and just iterate through the collection. At this point I am not too worried about it though as this stuff might solve itself in pre-production. Just interesting to see where I might have potential problems.

I hope that golfingstat is successful enough that I can justify spending money on application/server monitoring, if I am lucky enough to make some money on this thing then there is no question that I will choose to use New Relic. Their product is great and as I mentioned above their customer service is excellent.

The post New Relic is Pretty Awesome appeared first on Golfingstat.com blog.

All files in the “/config/initializers” directory are loaded with your app so this is the right place to put these kind of things. I can’t think of a good reason not to apply this function to all number types so I am extending the Numeric class and adding a trim_to_digits(digits) method that looks like this:

class Numeric
     def trim_to_digits(digits)
         m = 10 * digit
         return (self * m).to_i / m.to_f
     end
end

Now I open a console to ensure that it is working correctly and get the following output:

ubuntu-vm:~/golfingstat$ rails c
Loading development environment (Rails 3.2.0)
1.9.2-p290 :001 > 3.45433.trim_to_digits(2)
=> 3.45

Hopefully this little tip will help you become more DRY!

The post Extending Ruby Classes appeared first on Golfingstat.com blog.

Project Process

1. Build a site map / flow
This is important for me because it allowed me to quantify the number of pages that will need to be built. I ended up at ~25 pages.

2. Estimate Page Complexity
Once I had my 25 pages I applied a complexity to each page. (e.g. My landing page has very little logic on it so it is a low complexity page. The stats page is going to have a lot of controls and will require some complex SQL so I marked that page as high complexity.) Once I knew what pages I was building and the complexity of each page I looked at the remaining tasks (Wireframes, Scaffolding, Fleshing Out, Designing/Applying Design) and estimated the amount of effort for each task for a low, medium and high complexity page.

I ended up with the following table:

Project Estimates

As I am completing tasks I am going back to my estimation sheet and adjusting the estimates based on the actual time so as the project progresses my estimates also get more accurate and hopefully future project estimates will be more accurate as I can lift my original estimates right from the estimates from this project.

For my 25 page project I ended up estimating it at ~65 days of work. Since I am not working on this full-time and really only have a few hours a day (or even less some days) it will take me significantly longer than 65 days to finish this. I am hoping to have a minimal viable product release that I can get friends to start testing in like 2 months (just in time for golf season) and have a polished public release by June or July.

3. Complete Wireframes
For the wireframes I am just doing pencil sketches of how I want to lay things out. This is important because it helps me identify the necessary components for the next step (scaffolding). The focus here is identifying components not making it look pretty.

4. Complete Light / Scaffolding Pages
What I am doing on this step is getting a really minimal page that has the components from my wireframes built. I am not worried about validation or making sure that my queries are super efficient or the look of the page. I am just trying to get a working page that has the functionality from my wireframes. I am not sure if this is a typical approach for rails developers but for me I just really need to see progress and given that I am only working a few hours a day here and there on the project I can’t realistically knock out a full fleshed out page in a single sitting so completing a light page in one sitting then fleshing it out in another setting seems to be more workable for me. During this step I am also creating basic tests (i.e. does the page load successfully, does a record get created during create, deleted during destroy, etc).

5. Flesh Out Scaffolding Pages
During this step I am making sure I have full test coverage for the controllers and models and that my code is good. Since I would have done the scaffolding for all my pages before jumping into the fleshing out stage I will have lessons learned that I can apply to my original scaffolding pages. I am also filling in any features which I didn’t apply in the scaffolding stage and am tightening up the attr_accessible, attr_accessor in the models and validations on the model layer and presentation layer (e.g. javascript in the views).

6a. Design Site
The site looks like shit at this point but it works perfectly! So I am going to spend some time in illustrator, photoshop and cranking out html/css to come up with a design that I can apply across the site.

6b. Apply Design to Fleshed Out Pages
Once I have the psd’s, html and css it should be pretty quick to go through the site and change all my views to use the design.

So that is it…my plan/approach for Golfingstat.com.

The post How I Planned / Estimated My Ruby on Rails Project appeared first on Golfingstat.com blog.