What's up guys, this episode is a little bit different, but it's a little primer on the next episode that I'm going to put out, which is on state machines. What is a state machine?
A diagram for a state machine looks something like this, you have an object or something, and you're trying to keep track of where it is, and what you can do with it at that point in time, so imagine that you have your cellphone, it's turned off by default, you would start in this state. The circles are the states, and then the arrows are transitions, and the transitions get invoked by an event, so if you were to press the "Power" button on your cellphone, the phone will go from the "Power off" state to "Power on", and if you were to press that button again, then it would transition your phone to "Power off", now that's a super simple example, and actually, your cellphone has different functionality these days, because you can hold the power button down, and that will actually be the thing that asks you if you want to turn your phone off, so that button now really doesn't do that, it's more of a power button for the screen itself, not the device, but it has some functionality that you can use to keep track of that. Really, state machines are designed just so you can keep track of what is going on since the beginning, and where can we go with this object now that we have it.
Here's another one, imagine you're trying to put in change into the vending machines so that you can get a soda, well if you start with no change in the machine, you're going to start here, and you can put in five cents, and you can put in five more, and you can keep doing that until you get to 55 cents, and then, once it hits 55 cents it knows: Ok, the next thing we need to do is dispense a soda, and then reset the machine back to zero cents, so this is something that's really interesting. You can actually put in all these other options, that's why this one is very complicated, because you can put in all nickels, you can put in some nickels, some dimes, some quarters, you can try to put in all quarters, and this ends up getting very very complicated pretty quickly, because what if you put in a dollar in quarters, then it has to figure out how to give you 45 cents back in change, as well as dispense and reset the state, and that is a complicated system. While a vending machine seems very simple, there's a whole lot of complexity that is handled by basically drawing out a state matching so that you can know for sure that you're never going to end up where the user put in a dollar and you ended up giving them like a dollar back in change and a soda at the same time, you never want that to happen, you want your machine to always work correctly so these state machines are designed to help you say: Look, if you put in 20 cents, here are your options, you could give us another nickel, a quarter, a dime, and we will handle that accordingly, so state machines are this idea that allow you to keep track of the world, and what is happening right now, and what can happen in the future.
I have another example here on payments: Imagine you are checking out on a website, there are several different states that your payment can be in, so it could be "pending", it could be "processing", it could be "finished", "failed" or "refunded". This process is more linear than some of the other ones, like "Power on", "Power off" is like a look that goes along forever, but in this case, you kind of start with a "pending" state, and you work your way up to the "processing", maybe someone starts an order, and it's always pending, and they never actually check out, so it never begins to process, you could totally just stay in that pending state. There's also "processing" state, which is like those few seconds where we're talking to the credit card company saying: Hey, does this credit card look valid, do they have the correct balance, can we actually charge them for this, and then once processing is finished, there's two options: It could have been successful, but it could also have failed, and if it failed, we're probably done, we probably want to leave it there and force the user to start over or something. But if it's finished, there's a few other things we could do, we could refund the payment in full, we could do a partial refund, maybe we could do multiple refunds, and that's a system that could be complicated in and of it's own because if you want to do partial refunds, well then you could refund like a penny a thousand times or something like that, and it should still be valid and you should still be able to refund up into the total amount. But as soon as you've refunded to the total amount, then you should be done, and that refunding should no longer be allowed, and that is the kind of complexity that state machines help you diagram out and organize and keep track of, so this is an idea that is very very common in software because it really helps us keep track of the world, and so I'm going to explain how to add this in the next episode into ruby on rails applications. There are a few ruby gems out there, such as the state_machine gem which I maintain my own fork of, because there's been some maintenance issues with it, and then there's also another one called aasm that has been maintained a lot more in the past few months than the original state_machine gem, so we're going to take a look at this, I'm already familiar with state_machine, but I want to play with aasm, and it's really very similar to the other one, so really, I don't think you can go wrong with either one, you can actually more or less take all this code and jump between the two without any troubles, so that is up to you, I think we're going to take a look at this one, it works with ruby, ActiveRecord, Mongoid and MongoMapper which is fantastic, so you can use this with our without rails, and I really like that approach for gem design. That is all for this episode, hope you enjoyed it, hope you learned about state machines and be sure to watch the next episode so that we can put this into a rails application. Peace
Transcript written by Miguel
Join 29,763+ developers who get early access to new screencasts, articles, guides, updates, and more.