We''re looking at big IBM hardware running AIX as a potential deployment platform for the big credit card processing Rails and Ruby stuff that my team is currently building. I was wondering if anyone else is running on AIX or knows if Ruby is well-supported on this platform. I googled the subject, but http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/3daaf60b012c1921 is the only thing I found -- it''s not 100% confidence inspiring. It seems like more people out there are running Ruby on Solaris, but the client is indicating that they''d rather host our stuff on the IBM servers rather than Fujitsu. Any advice is appreciated. Thanks, Obie
I have come across an issue that might currently be an obstacle for usage of rails in certain applications, for example finance applications. The problem of floating point is that it rounds in a way that you cannot control. Just think of a web shop where you buy stuff and the sum you have to buy is like 1 cent off the sum that you would get with a calculator. So sometimes it is a requirement to have control about how rounding is done. Off course, types like Rational or Ruby''s BigDecimal can help. But the standard way to work with this is to have something like Java''s BigDecimal, which is basically an integer with a power of 10 for scaling. Since the name "BigDecimal" is already occupied for longer floating point numbers, this would need another name. So I started a rubyforge project long-decimal with file name longdecimal.rb and class name LongDecimal for this. It seems not too hard to do this, but it might still take a few days to complete, because I can only work like an hour or so in the evening on it. In case this thing (or some other project going for the same goal) achieves a status of being useful, it might be considered a good idea to allow ActiveRecord to use this, because it matches the common numeric types of the database more closely. Any comments about this? Best regards Karl
If I was using Rails to write financial apps, which by their nature tend to be business-critical, I''d be doing my money calculations within database functions rather than Rails/Ruby code. Databases have been doing money calcs for years, and the best practices for the various database products are now widely known. Regardless of which database you''re using, a Google search will turn up stored function code that does money calculations correctly and accurately for your product. If you try doing this in Rails, you might run into a world of trouble if you make a mistake. Is your Ruby code going to work with *every* type of database out there, or is there some gotcha in e.g. MySQL or Firebird that''s going to bite at some point? Is it worth the risk? My 2c... Dave M. On 09/02/06, Karl Brodowsky <listen@brodowsky.com> wrote:> I have come across an issue that might currently be an obstacle > for usage of rails in certain applications, for example finance > applications. > > The problem of floating point is that it rounds in a way that you > cannot control. Just think of a web shop where you buy stuff and > the sum you have to buy is like 1 cent off the sum that you would > get with a calculator. So sometimes it is a requirement to have control > about how rounding is done. Off course, types like Rational or > Ruby''s BigDecimal can help. But the standard way to work with > this is to have something like Java''s BigDecimal, which is basically > an integer with a power of 10 for scaling. Since the name > "BigDecimal" is already occupied for longer floating point numbers, > this would need another name. So I started a rubyforge project > long-decimal with file name longdecimal.rb and class name LongDecimal > for this. It seems not too hard to do this, but it might still > take a few days to complete, because I can only work like an hour > or so in the evening on it. > > In case this thing (or some other project going for the same > goal) achieves a status of being useful, it might be considered > a good idea to allow ActiveRecord to use this, because it > matches the common numeric types of the database more closely. > > Any comments about this? > > Best regards > > Karl > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Check out the money gem: gem install money Works perfectly with composed_of. -- -- Tom Mornini On Feb 9, 2006, at 1:32 AM, Karl Brodowsky wrote:> I have come across an issue that might currently be an obstacle > for usage of rails in certain applications, for example finance > applications. > > The problem of floating point is that it rounds in a way that you > cannot control. Just think of a web shop where you buy stuff and > the sum you have to buy is like 1 cent off the sum that you would > get with a calculator. So sometimes it is a requirement to have > control > about how rounding is done. Off course, types like Rational or > Ruby''s BigDecimal can help. But the standard way to work with > this is to have something like Java''s BigDecimal, which is basically > an integer with a power of 10 for scaling. Since the name > "BigDecimal" is already occupied for longer floating point numbers, > this would need another name. So I started a rubyforge project > long-decimal with file name longdecimal.rb and class name LongDecimal > for this. It seems not too hard to do this, but it might still > take a few days to complete, because I can only work like an hour > or so in the evening on it. > > In case this thing (or some other project going for the same > goal) achieves a status of being useful, it might be considered > a good idea to allow ActiveRecord to use this, because it > matches the common numeric types of the database more closely. > > Any comments about this? > > Best regards > > Karl > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
> If I was using Rails to write financial apps, which by their nature > tend to be business-critical, I''d be doing my money calculations > within database functions rather than Rails/Ruby code.There are many answers possible. Let''s say you do standard calculations. They can be done with existing tools, no need to do them in Ruby. But now let''s assume we want to do a web shop with something special, which is not around. Then this needs to be done for the specific web shop (or finance application or whatever, something requiring the kind of accuracy needed for finance apps). The java-guys would most likely do it in java, not in PL/SQL. Would the ruby-guys automatically go for PL/SQL (or whatever the DB has to offer for stored procedures)? I''d say yes, if the PL/SQL is there and easily integrated. That would by the DRY-principle in a way... But if it isn''t there?> If you try doing this in Rails, you might run into a world of trouble > if you make a mistake. Is your Ruby code going to work with *every* > type of database out there, or is there some gotcha in e.g. MySQL or > Firebird that''s going to bite at some point? Is it worth the risk?I do not believe so much in DB-independence. So it would be Oracle or PostgreSQL. And a big big migration, if this changes. Yes, mySQL would probably be possible as well, also DB2. I do not really know firebird well enough to tell (only firefox and thunderbird ;-) ) Don''t get me wrong, rails supports great DB-indepence and this is appreciated very much. But the actual application usually takes some advantage of DB-specific stuff, so it throws away the DB-independence that rails would have provided. Which is ok for an app that is only installed a couple of times in the world. Best regards, Karl
Tom Mornini wrote:> Check out the money gem: > > gem install money > > Works perfectly with composed_of.Yes, that is really cool and useful and actually working today! I am not sure, if it really goes far enough to cover everything. Just to give you some points: - there are other numbers to deal with, which do not belong to currencies - the smallest unit of currencies does not follow the same pattern as with EUR or USD - sometimes it is necessary to increase the precision to more digits for a certain calculation - there are like half a dozen different rounding rules for division to choose from So I think that there might still be some justification to have this LongDecimal going. Best regards, Karl
Don''t start something new. If Money is not complete or satisfactory, patch away! We don''t need TWO money objects! -- -- Tom Mornini On Feb 9, 2006, at 3:01 AM, Karl Brodowsky wrote:> Tom Mornini wrote: >> Check out the money gem: >> gem install money >> Works perfectly with composed_of. > > Yes, that is really cool and useful and actually working today! > I am not sure, if it really goes far enough to cover everything. > Just to give you some points: > - there are other numbers to deal with, which do not belong to > currencies > - the smallest unit of currencies does not follow the same pattern > as with EUR or USD > - sometimes it is necessary to increase the precision to more > digits for a certain calculation > - there are like half a dozen different rounding rules for division > to choose from > So I think that there might still be some justification to have > this LongDecimal going.
I''ve successfully compiled and installed Ruby 1.8.3 on AIX, I have not tried 1.8.4 yet... I had to do a lot of fiddling with it to get it to compile, but that was on AIX 5.1... I have heard that it compiles just fine on AIX 5.3. -Will On 2/9/06, Obie Fernandez <obiefernandez@gmail.com> wrote:> We''re looking at big IBM hardware running AIX as a potential > deployment platform for the big credit card processing Rails and Ruby > stuff that my team is currently building. I was wondering if anyone > else is running on AIX or knows if Ruby is well-supported on this > platform. > > I googled the subject, but > http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/3daaf60b012c1921 > is the only thing I found -- it''s not 100% confidence inspiring. > > It seems like more people out there are running Ruby on Solaris, but > the client is indicating that they''d rather host our stuff on the IBM > servers rather than Fujitsu. > > Any advice is appreciated. > > Thanks, > Obie > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
There won''t be two money classes. There could be another numeric type, like the BigDecimal of Java, but named LongDecimal, because BigDecimal is already occupied for something different in Ruby. This numeric type could be used for money instead of Integer, when it is finished. This could make the money class better. But it could also be used for other stuff, not directly related with money. Tom Mornini wrote: > Don''t start something new. > If Money is not complete or satisfactory, patch away! > We don''t need TWO money objects! So I do not see a duplication. Best regards, Karl
On Feb 10, 2006, at 12:52 AM, Karl Brodowsky wrote:> Tom Mornini wrote: > > > Don''t start something new. > > If Money is not complete or satisfactory, patch away! > > We don''t need TWO money objects! > > This numeric type could be used for money instead of Integer, > when it is finished. This could make the money class better. > But it could also be used for other stuff, not directly related > with money. > > So I do not see a duplication.Well...not directly. :-) My point is that if you have specialized knowledge of handling money in applications more accurately than the money gem does currently, then by all means apply that knowledge to the Ruby and Rails world. If you think that a new class will help money, then please create the class AND patch money to use it (or work with Money''s authors), and let the world know that money is better than ever *in addition to* letting the world know that this other class exists for general use. But *please* do not release the the gem as an alternative, as that will just dilute the uniformity of Rails based money handling. Mark my words as I paraphrase one of the least recognized geniuses of all times: We must all hang together, or assuredly we shall all hang separately. You see, Benjamin Franklin understood the meaning of Ruby on Rails over 200 years ago. :-) -- -- Tom Mornini
On Fri, Feb 10, 2006 at 10:10:07AM -0800, Tom Mornini wrote: [...]> Mark my words as I paraphrase one of the least recognized > geniuses of all times: > > We must all hang together, or assuredly we shall all hang > separately. > > You see, Benjamin Franklin understood the meaning of Ruby on > Rails over 200 years ago. :-)I agree wholeheartedly. This is also a substantial advantage of ruby over perl. Having two (or in the case of perl, sometimes ten) ways to do something where one good way would suffice only leads to confusion. -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.everylastounce.com ] [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki [ http://del.icio.us/fields ] ............. Links
Tom Mornini wrote:> My point is that if you have specialized knowledge of handling > money in applications more accurately than the money gem does > currently, then by all means apply that knowledge to the Ruby > and Rails world.I will see if I can help improve "money".> If you think that a new class will help money, then please > create the class AND patch money to use it (or work with > Money''s authors), and let the world know that money is better > than ever *in addition to* letting the world know that this > other class exists for general use. But *please* do not release > the the gem as an alternative, as that will just dilute the > uniformity of Rails based money handling.I agree with you. I think if we can persue this path, the outcome would be pretty much identical to what I would consider if there were no preexisting "money"-library and it would have to be written from scratch. Best regards, Karl