Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
good morning thanks for coming two promises in Ruby super excited to be here sharing what i think is some pretty cool code my name is dinshaw I've been doing Ruby since about two thousand two thousand oh sorry building website since about two thousand
found Ruby via rails in 2006 and I now work at constant contact in one of our new york offices in tribeca and we have been recently trying to automate the publishing of ads to various ad distribution services and these services tend to have pretty complex
domains and they expose them by a restful services so what this means for us is that we've had to manage these really long sequential workflows so will create one object on the remote service and then we get an ID back and we use that to create the next
one we do that like five times then we have to send all the IDS back to associate them with each other and we started off coding this top-down and it quickly just got ugly and coming from a object-oriented world you don't really want to look at a bunch
of just top-down methods and then we tried to make it a little cooler and we were using a state machine to try and manage the workflow and if any of you have tried to use state machine to manage workflow it almost immediately gets unmanageable and you find
yourself bouncing around between the callbacks that you've defined in your state machine and the actual code you're running and you don't know where to handle exceptions and nothing really makes sense so we started looking for something that was
a little more along the lines of how we thought about a problem to express it in code and a friend of mine suggested looking at javascript promises so I took a look and it looked really cool and I did a very superficial and implementation in Ruby and we used
it for a little while and then this talk got accepted so I went back to look at promises again realize that I had completely missed the point of promises in Ruby so took a little bit of a deeper dive and it turns out that it's just a really cool pattern
and watching it happen in Ruby is really cool too so we're going to do a lot of code we're going to go through the code that we're currently using so the slides if you want to follow on there's some links to peripheral reading and stuff github
com / gin sha i also just tweeted both the slides and the code base so that's at tal friends so if you at some point decide that it's interesting enough you actually do want to see the code feel free to find me to take a look and that and the code
is actually down there in the footer as well so what are promises oh really all right well I'll fix that but try the tweet try checking at tall friend and that should work and if not I apologize I'll get it for you afterwards so what are promises where
did they come from I'm quoting here promises are trying to provide direct correspondence between synchronous and asynchronous functions and that's a quote by dominic denticola who you could argue is the modern father of promises at least in javascript
the first link here is a presentation that he gives called callbacks promises and co routines where he talks about the origins being from jewel and E which are languages for managing distributed systems so they are heavily into concurrency and then he talks
about just the application and the value and where it came from you're missing the point of promises is a blog post that he wrote because it in the beginning when when languages were starting to adopt the promise pattern there were some disparate implementations
because people were kind of taking part of the part of this back and implementing that and there were a lot of differences in the implementation so he tries to in this blog post he really does a great job of clarifying the truly core concepts and then a lot
of that work and a lot of community contributions culminated in the promises 8 plus specification and if you it's a quick paper to read and you'll see if you look at the contributors you'll see a lot of names that um you're probably pretty
familiar with from the Ruby community in the JavaScript community so what is a promise we'll start with the problem that promises was trying to address so we've all you've written any JavaScript you've probably done something like this we're
assuming a couple things here that get cat is a function that is going out over the wire it's making an HTTP call getting some representation of a cat and then because we're not sure how long that's going to take but we want to be able to decide
what to do afterwards we pass it in a function and we have access to an error or the cat depending on what happens we check for the air if we get the air we handle the get cat error otherwise we proceed and then we do this again for the cat pics and it's
a pretty manageable it's a pretty readable solution anyway like all of us get what's going on here when we look at this but it doesn't look anything like the way we think about this problem in our heads so wouldn't it be nice if we could have
some way to express what we're actually thinking here which is like I want to get a cat I want to get the capex and i'm going to show you the cat pic and the rest of it could be argued as sort of implementation details so promises attempts to solve
this problem so this is working promise code if if you had an implementation there's a couple of assumptions being made here but I'll get into but we're saying get cat and get cat should return a promise one of the contractual obligations of a
promise is that it the return value will respond to them so in this case it's probably returning a promise that responds to this then method and a promise is either in in one of three states it begins its life in a pending state and then it becomes either
fulfilled or reject it and if it is fulfilled it will follow the success path through all the subsequent vens that are chained on to it and the success path is the left-hand argument of the been here so if get cat works it will then get cat fix it will then
show cat pics and if at any point one of these operation fails due to an exception being raised or just because whoever's program that has decided that that is a no longer fulfilled case then it will switch and it will start following the air pass or the
right-hand side of these arguments get cat error and get cat pics era so what does this look like in Ruby so here is a tried example of what we were dealing with in Ruby we had just a these huge methods with like 15 functions that we had to do that all returned
an ID and we had to pass it in the next one and all had happened sequentially you can see what's going on here at three lines it's not horrible but imagine it at 15 or 20 lines and then what if you wanted the whole thing to be run in the background
so it adds another level of obscurity to handling errors and deciding what you want to do and then what if you wanted some of these things to be happening concurrently but waiting for one or two or more things to happen then this this pattern just is completely
not applicable so you need something a little more powerful so what would the promise pattern look like in Ruby it would look exactly the same as it does in JavaScript because the promises specification is just that it's a specification it's not a
coding library so you can do it in any language and if you play by the rules it's going to look the same one thing to note here so so the assumptions that we're making in this code is line one is a get cat function which is presumably getting a cat
[ ... ]
Nota: se han omitido las otras 3.769 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.