RubyConf 2015

Buenas prácticas para manejar transacciones económicas en aplicaciones Ruby

Federico Soria  · 

Presentación

Vídeo

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

- Hi everyone, you're at the talk of Mo Money Mo Problems with Ruby. This is not Tender Love talk, that's somewhere else. My name is Federico, you can find me at Twitter @fedesoria. I'm a Ruby developer from Mexico, I know there's some from here, I come from Monterey, and so on.

I've been doing Ruby for about eight, nine years. This is my sixth Ruby talk, Ruby conference. But, as I say, long-time listener, first time caller. So, my first talk I gave here. I work at Pay By Group in San Francisco, I'm the CTO and the reason why I'm giving this talk is relevant to the startup that I work on, Pay By Group for the past three years.

Let me give you a little bit of background of what we do. Basically, we're a checkout option. So as you're going through a shopping cart or something, you'll see this button that says split the cost with payment group, you click on it, put down the e-mails and it splits the bill.

Although we do sort of like a Kickstart model. At the time when the entire group gets together, then we charge all the cards. So as you can see, that brings sort of a little bit more of a complexity that you usually get when you do regular transactions 'cause we have to do For example we have groups of 200 people, so we have to do 200 transactions in terms of milliseconds at the same time.

And what happens when you have card failures and all that? So it's very relevant. So, again, Mo Money Mo Problems with Ruby, you might've been expecting something a little bit like this, but I'm actually gonna pull a Puff Daddy, 2PDD thing, so we're gonna change the talk to Do's and Dont's with Money.

So to get started, let's talk about money and databases. A lot of people probably know about this already, but there's this big issue when you try to do this. I remember talking to a couple developers, it's like, oh, it's because Java Script sucks. That's why you're gonna get an error.

Actually, no, that's pretty much every language. The problem is not inherited from the language or even framework or anything like that. But it's this thing called a float. It's very useful but not for everything. Assume I read from the definition at Wikipedia.

The formulaic representation which approximates a real number so as to support a trade-off between range and precision. Emphasis on approximates. So the problem with floats is it has kind of inherited of how computers work. So everything gets stored in bits, right? First bit says, is this a negative or a positive number? A couple more bits say, what's the exponent? And the rest of the bits will say the fraction.

So following that notation, when you wanna store one third in the database, it's actually impossible. But computers are smart for us, so they'll try to represent what one third is but that's why you get this kind of problems in which you get this number. So don't use floats for money, please.

This is a thing that you'll find out when you're starting your own startup or programming that uses money. Just don't ever use it 'cause you'll come up with like your numbers at the end of all your operations. Do use integer, integer, sorry. There's an inherited sort of cool thing about integers which is you cannot store decimals on it but it works really well with money 'cause, you know, just store everything in cents.

And then it does a lotta things for you 'cause, you know, you cannot hop a. 1 cent in your database, so it forces you to do the right thing. Also, most payment processors will ask you to pass everything in cents because it's almost I'm actually surprised this is still not a rule.

And the reason why it's not a rule is because we have this thing. A BigDecimal, has anyone used BigDecimal before in Ruby? Okay, it's awesome because basically what it does and the database in the background that if it's not a database that supports BigDecimal, it just stores everything as an integer and when you fetch it, it will convert it into a BigDecimal, sort of like a float or a double.

[ ... ]

Nota: se han omitido las otras 1.874 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.