Thanks for the feedback guys. I suppose the Pat's second approach and Mikel's approach are similar in that they are using an array and a loop to manage the variations.
The thing that they don't really do is kind of explain the actual formula taken to derive the data, which I feel (perhaps unfoundedly) that they should. Nonetheless, they will ensure that the output of the function is correct. - As far as DB/application logic goes, this is how I see it. Part of the core part of the application I'm writing is calculating tax liabilities so it seems pretty clear cut that it should be part of the application code, managed by git and tested pretty thoroughly. I'm fully aware that the tax rates change from year to year, as well as how tax is applied and that's part of the maintenance cost of the project. The other concern with any DB based approach is that it isn't necessarily a linear function as discussed in the code snippet. There are things such as rebates, concessions and levies that are applied under certain circumstances ie. private health insurance and the medicare levy. I feel like databasifying things like that would be asking for a heavier maintenance burden in 3 years time when they change the rules under which it is applied. Thanks for the input, it's definitely a help being able to get feedback on the many ways to skin a cat. Cheers, Michael On Fri, Sep 2, 2011 at 3:48 PM, Adam Boas <[email protected]> wrote: > Sounds a little like mixing concerns to me. Regardless of how easy it is or > isn't to deploy your code, tax tables aren't really an application logic > concern. Maintaining tax tables in code would probably lead to potential > copy errors and would need to be maintained by people who likely don't > understand them. Having them in a database, and potentially uploadable from > spreadsheet, puts the management of them in the hands of tax people who can > manage and verify their voracity. > > > Adam Boas > m:+61 (0)457 741 117 > e:[email protected] > > > > On 02/09/2011, at 3:32 PM, Ben Hoskings wrote: > > Deploying your app should be easy enough that that doesn't matter. > > You have to change the values somewhere -- if they're stored in the DB, > you're changing them in an admin interface. I'd rather use my editor and > git. :) > > Also, this way, you update the specs along with the rates, which reduces > the chances of cock-ups. > > - Ben > > > > On 02/09/2011, at 3:22 PM, Anthony Richardson wrote: > > Should the tax rates be loaded from a database in your app? > > > With your current solution you will need to rewrite your application and > > tests each year they change the tax rates (often). Not to mention special > > cases like the flood levy. > > > Cheers, > > > Anthony > > > > > On Fri, Sep 2, 2011 at 12:04 PM, Michael Gall <[email protected]> > wrote: > > > Hi guys, > > > I'd love to get some feedback on a spec I'm writing. It's a tax calculator > > for australian taxation rates - nothing too complex just yet, but some of > > the calulation specs feel wrong, but I don't know a better way. > > > Thanks in advance. > > > > describe TaxCalculator do > > describe "low income bracket" { > > before { subject.income = 5000 } > > it { subject.calculate.should == 0 } > > } > > > describe "15c tax bracket" { > > before { subject.income = 10000 } > > it { subject.calculate.should == 4000 * 0.15 } # the tax bracket is 15c > > in the dollar between 6000 and 37000 > > } > > > describe "30c tax bracket" { > > before { subject.income = 50000 } > > it { subject.calculate.should == 6000 * 0 + 31000 * 0.15 + 13000 * 0.30 > > } # the tax bracket is 30c in the dollar between 37000 and 80000 > > } > > end > > > > Cheers, > > > > Michael > > > > > > -- > > Checkout my new website: http://myachinghead.net > > http://wakeless.net > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/rails-oceania?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]. > > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > -- Checkout my new website: http://myachinghead.net http://wakeless.net -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
