

Insurance on Rails - mrduncan
http://blog.thinkrelevance.com/2009/7/21/insurance-on-rails-2

======
gstar
Somewhat similarly, as a stopgap in '07 I built a Django (well really, Python
and duct tape) Sarbanes-Oxley SOD system over a month or so.

I had to deal with well over a million records, but fundamentally it was a
pretty simple ask, laying a 2d matrix of rules over user and permission
records from 30 different systems. I even hooked it up to SAP and various
AS400s through MQ, print queues and various other things.

It was a total stopgap move - so a whole bunch of vendors bid on the "real"
system, one was selected, and now almost 3 years later and a few million
dollars spent, and the "real" system still isn't working.

"Web 2.0" frameworks have a lot of applications in business, the ORM +
presentation layer tools give you most of the groundwork you need, but as the
article says, the key is in the polish and the business oriented design.

~~~
Retric
If they have been using your system for 3 years, you might want to bid ~500k
for a ~6 months contract to get it to the next level. It might not be _fun_
but you can make crazy money building custom enterprise applications once you
have some credibility.

~~~
gstar
Ha! Indeed!

I would absolutely consider doing that if I had time. I'm kinda all-in on my
own startup at the moment and I'm doing my level best to not be distracted by
contracting.

And oh how right you are about it not being especially fun! You make a good
point about the sort of money that I should chase to do the job properly, too.

Thanks.

------
palehose
Although I don't work with COBOL, I do work at a financial services company
and we have a lot of old software that we are not going to replace with Ruby,
PHP, or any other dynamic language because the precision and accuracy of
decimals and floats in dynamic languages is inadequate. I'm really surprised
that the precision issue gets ignored at the native numeric level within
dynamic languages.

~~~
rleisti
Ruby does have libraries for dealing with real numbers with an arbitrary
precision.

~~~
palehose
I haven't gotten very far with this issue in Ruby, however in PHP there is
also a way to get around the lack of precision by treating numbers as strings
and then using additional libraries to perform the necessary calculations. The
ability to do this in a clear and concise manner and be absolutely certain
that everything is adding up properly is not easy.

From my perspective, the fact that these calculations do not perform correctly
right out of the box using dynamic languages is the problem, and adding
additional libraries is not the solution.

~~~
cschneid
The last project we did with money, we just treated all amounts as integers
storing the number of cents. No accuracy problems w/ whole integers, so 1000
because $10.00. Easy to do math with, and keeps it's accuracy.

Might not work for hard-core financial work, since the number of decimals
might be too deep for that to be efficient. (although there's nothing stopping
you from saying the last 5 digits of every number is the decimal part).

~~~
gnaritas
A better thing to do is to not use raw integers to represent money at all,
create an immutable money object, use integers to represent units and a
currency string (cents/USD) inside the class. Use the money as the primitive
it is, giving it the appropriate numerical operations
added/subtracted/multiplied/allocated. Money is not an integer, or a decimal,
or a double, or any other number, Money is Money and should be represented by
an appropriate abstraction of its own.

~~~
arohner
> A better thing to do is to not use raw integers to represent money at
> all...Money is Money and should be represented by an appropriate abstraction
> of its own.

Good point. This makes me wonder though whether it is _ever_ acceptable to use
primitive math without some kind of units, except maybe in pure math. You are
always counting _something_ , be it dollars, or people, or widgets sold, or
hard drive seeks.

~~~
gnaritas
I would depend on whether adding different units together was an error. 1
dollar + 1 euro should be an error. So raw numbers for pure counting is OK,
but raw numbers for counting units of a specific measure are not OK, an
abstraction should be introduced. If you just willy nilly add feet and meters
you might end up missing your desired orbit and losing a billion dollar
satellite.

~~~
cschneid
I agree, and while the project we were on didn't have strong typing of money,
what I described was the database storage of the numbers. We did very few
calculations, and the system was explicitly USD, so going deep into "proper"
handling of money was just unnecessary.

I really do like using the type system to keep track of units (type system
either in the object oriented sense, or the haskell type system). This is
similar to Joel's old article about using a naming scheme for dirty vs.
sanitized strings for the web. It's all a type system, just his was in a
language that didn't support language-level types.

