Good afternoon. We have Ellen Goodwin here. She's given a TED talk, which is awesome. So this should be really good.  As a former graphic designer, she's well acquainted with the perils we all face when trying to get things done when we'd rather be doing something else. Please welcome Ellen Goodwin.  Superheroes are tight, they've got caves and they have masks. They fight interesting people. They have superpowers. They have a little conference dedicated to them over the convention center in July. Action heroes, on the other hand, are just mere mortals who have learned to leverage the forces of action, energy, and focus to overcome obstacles, to vanquish their goals, and to achieve their goals. None of us can be superheroes.  And that's what we're going to go through in the next 40 minutes.  I'm Ellen Goodwin. I'm a productivity expert. I'm a trainer and a full-time action hero. I was a graphic designer for 20 years and that's pretty much why I'm an action hero because that put me there and I'll explain that in a minute. I'm the founder of the shift, accountability master line, co-hosts of the Faster, Easier, Better podcast, and oddly enough, the co-founder of the dive bar for the month for here in San Diego. So I was a graphic designer for 20 years and about seven years before the end, I fell into the pit of procrastination. And whether it was just because I was bored or my clients didn't inspire me, I started missing deadlines. I started not doing what I was supposed to do.  They don't. They hate it. So clients weren't happy. I procrastinated more. I lost clients.  And that's when I did a deep dive into procrastination, where it comes from, how we can get rid of it, and it all comes from our brain. And I'll go into that in a little more, just a little while, but it all comes from our brain. So through deep education, training, research, I put together tools and systems that I started to use that brought me back from the brain. My clients, my friends, my family's stalkers going on, they asked me to help them. That's when I became an action hero. So today we're going to learn how you guys can be action heroes. Again, it's that trifecta. Action, energy, and focus. Those are the three things that are going to make you an action hero. So action. Action is the number one thing that we need to do. I'd like someone to yell out and feel free, who is your favorite motion hero? That's perfect. There's no such thing as a motion hero. There's action heroes. People get confused between motion and action. And it's not just people, it's your brain. Your brain cannot tell the difference between motion and action. It sees motion as you having done something. Whoa, look at me, I did something. Motion is a little hamster on the wheel, going around and around and around. Action is moving forward. Like a football game. Motion, a rocking chair. There's a lot of motion going on, but you're not getting anywhere. You have to know the difference between motion and action and move yourself past that. Now, motion is super important. For any of the, is there any web developers in here? Would you start a website without doing some planning, thinking about the architecture, where you want to go? This guy says yes. Just go for it. Oh, just go for it. A blogger, I don't know if there's any bloggers, writers in here. Would you just start? No. You have some planning. Planning is motion. And planning is essential. You have to plan. But here's the thing. It's stuck in that motion, in that planning and never move forward. Let's say I wanted to start working out. I'm going to get in shape. So I go online and I find all these exercises. I find an eating plan. All this stuff. Wow, look at what I did. I didn't do squats. I need to do squats, but I didn't do squats. All I did was plan. I was in motion. Getting on the floor, doing some push-ups, doing something to work those muscles. Do you see the difference between motion and action? We need motion. You do need motion. You need motion of writing a to-do list in the morning, or writing it the night before, which is actually better. You need to do that. You need to plan the website. You need to plan stuff, but you also have to move from motion into action. And the best way to do that is by applying in the sand. And that means you schedule when the motion stops. You have to stop the motion. So, let's say I have a project. Whoa, that's a move. Here's your line in the sand. You have a project that has to be done on Friday. So what I'm going to do is I'm going to plan noon on Monday. All motion stops. Everything else is going to be action. You've got something that has to be done at the end of the day. Give yourself half an hour of motion or an hour if you need that. You don't give your first cup of coffee until the motion stops. Figure out a line in the sand when you go from motion into action. Okay? Now, all action heroes have enemies. What do you think is the enemy of action? Procrastination. Exactly. Procrastination is the definite enemy of action. So, here's our quick... So, quick little biology lesson. Procrastination begins and ends in the brain. Your limbic system, which is right at the top of your spinal column, is your midbrain. You've got some really fun things there. You've got your emotional center there. You've got your reward center. All of those work together to keep you from getting your stuff done.    The limbic system is millions of years old. It's the old part of your brain. So, limbic system fighting the prefrontal cortex. So, everything we're going to go through is how we're going to overcome the limbic system or we work with it. So, we have four types of procrastination that we all deal with. Four types of procrastination that we deal with. We've got low value, low priority. We've got fear-based procrastination, fear of success, fear of failure. We've got distractions, what I like to call shiny squirrels. And we've got procrastination when things are way too far down the road. So, let's look at each one of those. So, the first, low value, low priority procrastination. This is something it's not super exciting but it's got to be done and we don't want to do it. Cleaning, organizing, that all falls under it. I'm sure you guys can think of it. Y'all, something else that you think is low priority that you're not getting is taxes. Taxes are a great example. If we have time at the end, I'll tell you how I did them this year because they are low priority. So, when you've got low priority, low value, what's going on is your limbic system has just named those things. It's just said, taxes are boring. Cleaning is yucky. It's emotional. So, what you have to do is remove the emotion. Those tasks aren't icky. They're not yucky. They're not boring. They just are a thing. You've labeled it. So, the limbic system gets to say no. So, the best thing to do is to externalize whatever it is you need to do and set a timer. You just set a timer for what you're going to work on for how long you're going to work. I talked to somebody yesterday and he's like, well, I want to start. I'm like, well, set a timer for the start then. Set a timer to tell you how long you're going to do that. You just set like 30 minutes. I'm going to work on my taxes for 30 minutes. That's it. Your limbic system can't argue with that. It's just an externalized thing. Even better is if you set the timer for a shorter amount of time than you think it's going to take. Because that way, with an artificial deadline, you don't fall into Parkinson's law. Parkinson's law says that a task expands to fill the time available for it. So, if you give yourself an hour, you're going to take an hour, even if it only takes 15 minutes. So, set that timer for a little bit shorter, externalize it, get it outside of you. Do that low value, low priority procrastination. Okay. The second type, fear-based. Fear-based procrastination. We all fall victim to this. Fear of success, which surprises people. Fear of failure. Fear of getting out of your comfort zone. Fear of not knowing what comes next. I listened to Roy in here yesterday talking about Gutenberg and how people are like, I don't want to do that. So, fear-based procrastination. I'm sure you can all think of something you put off because you're afraid of it. So, when we run into fear-based procrastination, what we need to do is pretend to be a baby. So, we all know of babies. Washington starts to learn to walk, right? They're kind of toddling or toddling around. They fall down. They get up. They fall down. They get up. They look like they just came out the bar at 2 o'clock. They're just everywhere. But never in the history of the whole world has one of those little babies fallen down and say, yeah, I'm good. I am good. I am not getting up. I'm fine. You just leave me here. I'm just fine. Now that baby got up and they kept going. They kept trying. You know what they were taking? Baby steps. Where do you think the name comes from? Baby steps. They were taking that. That's what we do with fear-based procrastination. We need to break down whatever it is you're afraid of. Whatever that task is. Break it down into small, little bits. Baby steps and succeed on each step.  It sees taxes. Oh my God.  It's going to take forever. But if you break it down to small, little bits, it's much, much easier. This year with my taxes, I scheduled 10 days out and I gave myself 15 minutes a day. That was it. 15 minutes. The first day, all I did was print out the tax plan. I succeeded. My brain was happy. I was happy. The next day I did the next thing so when you have fear-based procrastination whoa you're all distracted by that. Whoa. When you have fear-based procrastination act like a baby. Don't fall down. Just keep taking those baby steps. So the third type of procrastination is distractions. Distractions, shiny swirls. We have distractions everywhere. Everywhere. On our phones, our tablets, our computers, our coworkers, our friends, our family, everything. The brain likes to get distracted. The brain loves to get distracted. It loves these new, bright, shiny things. So while I could tell you, oh, here you put this block around your phone and really you should have your phone in the other room and turn it off your computer, the best way that you can overcome distraction when it's procrastination because of distractions is become accountable. You become accountable. Now today is Sunday. Let's all pretend that on Tuesday morning at 8 o'clock you're getting on an airplane and flying to mid-Africa. Random place, but you're going there. Between now or four o'clock when this talks over between 10 and 8 in the morning on Tuesday you've got a lot to get done. You've got to pack. You've got to talk to the dog sitter. You've got to make sure all the work is taken care of. There's a lot of things.  Right? That plane is holding you accountable to getting your stuff done. And that's what you need in real life. Not an airplane, but you need someone or something who holds you accountable. An accountability partner. An accountability buddy. An accountability mastermind. Somebody that knows what you're supposed to be doing so you get your stuff done. Okay? Who can be your accountability partner? You can have a friend. You can have a neighbor. You can have a coworker. You cannot have a spouse or a family member. You can do that. You can join a mastermind group. You can have a friend that you just text and you go, hey, I'm going to do this and I'm going to text you in an hour and it will be done. Find a way to hold yourself accountable. That way you don't fall into that pit of procrastination where you're like, oh yeah, I'm on Netflix. Now, you can take this even further if you want. And you can do what I like to call this. This works great on projects that are going to take a while. It might be 10 days, 2 weeks, a month. It's easy to procrastinate on those. So what you're going to do is, again, you have your tasks. You know when it's supposed to be done so you've got your deadline, your task. You pick someone that's going to be your accountability partner. In my case, I always pick my neighbor. Next, I pick an amount of money I'm willing to give up if I don't get my project done. It has to be something starting at easily 100 bucks. It's got to be like 10 bucks. It's got to be 100 or more. Now here's the part that's important. You're going to pick an organization, a charity, a political party, a religious group that you don't believe in. Yes. You don't get your stuff done. That accountability partner takes your money and gives it to the group that you have decided that you don't like and they are holding you accountable. I worked with an author earlier this year who had three chapters left on her book. So she put 500 bucks up against herself getting it done. If she didn't finish, that money was going to the NRA. Another woman right now who's working on a book, she's got $1,500 up against her finishing. If she doesn't finish, it goes to the KKK. She's going to get that book done. She is going to get that book done. So this is very extreme accountability, but sometimes we need that.  Finally we have things that are too far down the road. Too far down the road. I want to lose 20 pounds. I want to go back to school. I want to write a book. All big things. But what happens is we can't see ourselves down the road. We all fall victim to what is known as hyperbolic discounting. And it's a cognitive bias that says basically the farther we are away from the present day, the harder it is for us to understand ourselves or to do good things for ourselves. This is why when you're on a diet and someone brings donuts and you're like I'm going to have a donut, I'm going to have a donut tomorrow, it never works. We can't see ourselves. That's why if I offered you a dollar today or two dollars next Sunday, you take the dollar today. You can't see yourself down the road. So we procrastinate. Okay, so when we've got this hyperbolic discounting we're dealing with, the best thing we can do is keep it in our present day. Because remember, we can't see ourselves in the present. So the best way to do that is to chart it down in some way. Maybe taking a calendar and putting a check mark every time you do what you're supposed to do. Maybe it's grabbing an app that allows you to keep track of things. There's thousands of those out there. You want to mark it down. Just figure out what works best for you. Don't make it difficult. Just make it so you see yourself every day. Maybe it's a chart on your fridge that you get a check mark when you eat well. Friends of mine had a big, big project that they needed to keep in the present day. And that was that they had huge credit card debt. Now, credit card debt is really hard to keep in the present buys, present day.  So what they did is they made a chart. And the chart started with a really big number up here. A really big number. And a zero at the end.  So they had an idea of how long it was going to take. Then they took this chart and they put it on the living room wall. So they got to see it every single day. So they were friends if they happened to stop buying. But for the first three months, they just beautifully paid the amount of money, they paid it down. But they started seeing this, this is on the wall every day. So they started thinking about it. So they started not going out for coffee as much. Saving money on lunches. Saving money so that they could pay it down faster. And they did. Because they saw it every day. They finished up six months ahead of schedule. And they turned around and made a new chart. And that chart started with zero. And ended with a really big number. And they stayed to buy a house. They made it happen because it was right in front of them. They kept it in their present day bias. So that's what you need to do when things are too far down the road. So action. Remember, you have to move from motion into action. Know what type of procrastination you're dealing with. And it's concrete in its special ways. Okay. Energy. Action heroes need energy. And there's two types of energy that we're going to look at. We're going to look at physical energy and mental energy. Because they're both very, very important. So the first type. Personal energy. Biological prime time. That's what Chris Bailey is another productivity expert. That's what he calls it. It's your chronobiology. How many of you in here are mourning people large as it were? How many of you here are night elves? I'm not surprised. How many are in between?  Yeah. Well, congratulations. No one is better than anyone else. It's just what your energy level is. Now I know a study came out this week saying that night elves can die earlier. Don't listen to them. So we all have different energy levels.  It's how you leverage that energy. Now I get up at five in the morning and that's when I write and I read and everything I do is so easy because that's when I've got my creative energy. For years I would go to the gym first thing in the morning and then I realized wow, I'm wasting all this good creative time. I can go to the gym later. I don't need to be creative at the gym. But now I know how to take that morning time to get my work done. And it's, like I said, it's like butter. Cutting through butter because I have that creative energy. This is my best time. I can do meetings. I can do emails. I can do all that stuff later in the day when I am not so full of creative energy. So it's important for all of us to know when our best energy is and the easiest way to do that is to start charting it down. Super easy way to do this. Take a phone. Take a phone. Set up timers every hour for the time that you're awake. Don't do it at night or they'll screw everything up. But set a timer for every 60 minutes for three days. When that alarm goes off, chart your energy level. Just you can put it on a no-card. You can put it in your phone. Just put it somewhere. It can be as simple as you know, go from 10 to 1. 10. Oh my god. I'm on complete fire. 1. I'm napping. Don't bother me. Do this for three days. You'll get a good idea of where your energy rolls. So are you super energetic then? Get your work done. Do the most valuable work then. When you've got lower energy, do the things that don't need as much energy that aren't so important. So you want to leverage your personal energy. Use think of it. How you can make your work feel like you're cutting through butter. So the other part of our energy is our willpower for self-control. It's our mental energy. And it's essential that we conserve it in order to get stuff done. To be the best we can be. So willpower studies have told us lots of studies. I'm sure you've heard of studies where we only have a certain amount of willpower self-control at any given time. So we need to conserve it like I said. Anytime we have to make decisions we start to use up that willpower. Every decision means another little bit of willpower gets used up. We run into decision fatigue. I'm sure all of you have sat through a meeting in the morning where you're biting your tongue trying not to talk to people that are saying things you don't agree with. You're trying to reserve your judgment and when you get out of that meeting it's a lunchtime and you know you're going to eat really healthy but boy you've got no self-control now. I'm just going to have a hamburger and fries. I'm so frustrated. That is decision fatigue. So we want to guard against decision fatigue. We want to guard against our self-control or willpower being depleted. The best way to do that is with habits.  Habits are just systems. They are just systems for all of us. There is a system that we use to conserve willpower. We use systems in our work, right? You start a website, you've got a system that you do. You start a blog post you've got a system that you do. Habits are just systems that we use. So, how do you do better habits? Super easy. Two super easy ways to build better habits. First, we're going to do habit stacking. Habit stacking is basically just anchoring a new habit on an old habit. So let's say I wanted to start taking more vitamins. I could anchor that habit onto my morning habit of brushing my teeth. Super easy. I have a client that just because it is tax time realized that she should have a better system of tracking expenses because it's been a really bad month and she's been trying to get all those together. So, we're having her track expenses at the end of the day when she does her regular shutdown. She has a shutdown system put it on top of there. Just take five minutes, track expenses. So you take a habit that you already have. Yeah, that is your anchor. Take whatever new habit you want and put it on top of that. It's going to be a lot easier than trying to remember things. So you use what you have already, anchor it, put a new one on top. The next one is micro habits.  You get it to the point that there's no resistance, there's no friction. Going back to the whole idea of, hey, I'm going to get back in shape. Maybe I say, hey, I'm going to do 20 push ups every day. I got some resistance to that. Definitely, I can't lie, I got some resistance. So, with a micro habit I'm going to make it smaller and smaller. Going to get the part where there's no resistance whatsoever and that could be something as small as one push up. I'm going to do one push up a day. The definition of a micro habit is that it is so small that you would be embarrassed to tell your friends what you're doing. So if someone came up to me and said, hey, I heard you get in shape, I'm doing one push up a day. Hey, me. So small. But that's a micro habit with a woman with expenses. She could be tracking one expense a day. That's it. But micro habits have a little bit of magic to them. And that is that they expand. After you get used to doing one push up for a while, hey, you're down there already, why not two? Then three, then five, and eventually you're at the 20. You don't have any resistance that you have to deal with. So you make your micro habit super small so that eventually it expands and you get to where you want to be. You just remove all of the resistance to it. So build habits to keep your willpower and your self-control. Know your personal levels of energy and leverage your day with those as best you can because I know some people work for other people, but use it as much as you can leverage it. All right, now we're on some focus. Whoa, we're not. Now we are. Focus. Focus. Well, if action heroes could have a superpower, focus would be that superpower. Because when you focus really deeply focus, you can actually expand your time. You're not being distracted. You're laser focused on what you need to do. And I'm going to show you some techniques for focusing. But just know that you don't need to focus for eight hours a day no matter what anyone said because your poor brain would explode. If you can put in a good half an hour focus session once a day, then expand it out over weeks to the point where you get two hours. Seriously, two hours of really good deep focus is going to change your life. Focus is amazing. So, who knows what the enemy of focus is? Distraction. Distractions. We can get more specific. Multitasking. Yes. Multitasking. Context shifting. Multitasking is definitely the villain when it comes to focus. So, we have to overcome multitasking. And yes, we can go back to the distractions find a way to block them out. But what we want to know and what we want to do when we're focusing is we want to keep our brain in one room. So just keep your brain in one room.  Alright? Now, I'm sure this has happened to at least one of you because otherwise it would be really embarrassing because it's happening to me. You're on your phone, whether you've got your phone up here, you've got your earbuds in, and you start reading an email when you're scrolling through your phone. At the same time, you're supposed to be talking to someone. And after a little while, you're not sure what they said or what you read. Does this happen to anybody? It's not just me. Come on, show of hands. Okay. Alright. So, if your brain was a house, this is what was going on. Every time you were reading, you were in the living room, which is the part of your brain where you can read. And every time you were talking or listening, you were over in the bedroom. Okay, that's the part of the brain where you can listen. Now, you can't do both things in one room. If you want to read or listen, you have to be in the proper room. So, I'm reading, I want to talk, I have to go physically into the bedroom. And if I want to listen, I sit there, and if I want to talk again, I mean, read again, I go into the living room. I can read in the living room, I can talk in the bedroom, I can't do both in the same room. This is exactly what happens when you focus. You have to pick one room to keep your brain in.  You're using up a little time. It doesn't help for your energy. You're losing self-control. You're not focusing. So, you want to keep yourself in one room. Alright, that's how we focus. So, the best way to focus is with timing. Find a way to time yourself. And really, this is like my favorite timer, right there. So, time yourself. You can use a kitchen timer. You can use the timer on your stove. Use the timer on your phone. It doesn't matter. But what you have to do is you're going to do it with a sting. And that's not the stinger. It's an acronym that you use for whatever timing mechanism you do. If you do Pomodoro's, if you do one of the ones I showed you a little bit. As long as you're setting a timer, do this. You're going to do a sting, which means select one thing to do. You're going to keep your brain in one room. Time yourself. Set a timer, whether it's 25 minutes for the 5 minute break, 40 minutes for the 5 minute break, 10 minutes. Set a timer. Ignore everything. Everything gets ignored except for what you're working on. No breaks. No breaks until that timer goes off. Then give yourself a reward. Whether it's a little bit of food, a little dance party, whatever. If you need to jump back and do it again, then do it. So I mentioned that you've got Pomodoro, which a lot of people know, which is just 25 minutes on, 5 off. It's named after a timer that looks like a tomato. You could just call it a timing method. Pomodoro just sounds more fun. Another one, which is my favorite, is the 10 plus 2 times 5, which is not a math equation. It's a timing device for focus. You work for 10 minutes. Take a 2 minute break. You do this 5 times in an hour. You've knocked out 15 minutes of good focus with a 10 minute break. This works great for things that you want to just do in short bursts. I'll do like a blog post. So I'll just spend the first 10 minutes knocking out ideas. The next 10 minutes, I might write down three sentences for each one. The next one, I might bring it out even more. You don't have to do cereal like that. You could just be doing. I'm doing 10 minutes. Take a break. 10 minutes. Take a break. It works really well if you have a list of what you want to accomplish. So that way, if you get halfway through one of your 10 minutes, you don't waste 5 minutes figuring out what you're going to do. I use a seconds pro for a timing or an integral timer. Both of them freebies. That way I can just set up the timing 10 minutes, 2 minutes, set it up for 5 times. That way I never touch my phone because the bells go off and it tells me when things are. Because if I touch the phone and have to set up the timer, too tempting. Too tempting.  Batching. Batching is another way that we can keep our brain in one room. So batching means that you set your timer and you do like-minded things. So maybe I'm setting a timer for 30 minutes and all I'm doing is reading. But I might read some blog posts. I might read some emails. I might do research. I'm keeping my brain in the reading room. I might do financials. I'm doing invoices. I'm right inside the bills. All I'm doing is financial stuff but I'm keeping my brain in one room. John Lee Dumas who does the Entrepreneur on Fire podcast. He puts out a new podcast every day and he does extreme batching. On the first Monday and Tuesday all he schedules is interviews. 15 interviews Monday, 15 interviews Tuesday. That's all he does. He stays in the same brain room. Gets it all done. He's got 28 days to do other things. That's pretty extreme. Okay. That is focus. Focus is keeping our brain in the same room. He expands time. It makes us an action hero. When we put these three things together action, energy, focus, we become the action heroes of our own life. But here's something that I didn't tell you. When we talk about overcoming obstacles and achieving our goals, it sounds like wow, I'm an action hero. I'm going to have to work really hard. I'm going to be better. I'm going to get a lot more done. Nobody wants to get a lot more done. Nobody wants to oh yeah, I'm going to get more done in my day. What we all want and what you get when you're an action hero is that you are able to get your have-to's done more efficiently and effectively so you can get to your want-to's more easily. Who doesn't want to spend some time with their family? Spend some time with their friends? Spend some time not working. That's what you get to do when you're an action hero.  Thank you and I'm happy to take any questions. Yeah, as you're going through your year, do you ever take time to stop and evaluate some of the habits that you've created? And if so, what are some of the things that you're looking at when you're evaluating those habits? Well, I do check out my habits. Well, I look to see if they're serving me because it's really easy to fall into like, oh yeah, this is what I do, but I need to look at it and know, what am I getting out of it? How is it helping me? Is there another way that would be better? And what I would try if that's the case, I would go, you know what, let me try for two weeks let me try this, because nothing's written in stone. You can always change things. Yes? Someone as your accountability partner. That were accountability partner. So you said, like, you have your neighbor. My neighbor does like, for my long ones, I actually have an accountability partner that we've been partners for seven years and we've never met in real life. He lives in New York. We talk every morning, we met in a coaching program. There was a message board, basically, where people were looking for accountability partners, and that's how we got together. So, you know, finding someone that's not going to make you feel bad, that's why I always say family is just a really bad choice. Is that your husband next to you? Because he had a question in the last question. So you don't want family. You don't want family.  And maybe what can you do to do it better? Sometimes just when you have a short thing to do, it's really easy to just hit a friend up and go, hey, text them. I need this done. I need to do this. And so check in on me in an hour. And I have to tell you whether I got it done or not.  Unless you're really friendly with your co-workers. So, there's all sorts of people. That might be an accountability mastermind because you tend to find people that are more or less at the same level. And usually if you find like a paid one because people have money in the game and they're usually, you know, on the same level, you can look around. You can just, you know, Google masterminds and you can find one that's going to be you can get super specific or develop your own mastermind. Or develop your own mastermind. But you can, you know, you can find it. There's a WordPress accountability group, you know, our mastermind. Absolutely, absolutely. What else can I answer for people? Yes. Seconds Pro. Seconds Pro. Or intervals. And the great thing with those is you can set them up as boxing rounds which is kind of fun. So, when it starts, you get a ding ding ding like a round starting and then when it ends, you got more bells. So, you know, it's entertaining. What else can I answer? Yes. How often are you talking, to meet over to that account? Every weekday. At 8.30. Once a day, we talk. We talk about, yeah, for like 15 minutes, talk about what we're going to do, what we did, what we didn't get done, what we're kind of hoping to do. You sometimes just bounce ideas off of each other. So, yeah, 15 minutes. Just like that. Sort of like a big business. In the morning they have their meeting and they say what they're all going to do, so there's sort of accountability for each other. Absolutely. Absolutely. What? Not too much. You know, I enjoy it. The nice thing is I can use all of it for my own business now. So, I'm not a super surprised no one's asked about the dive bar thing. Oh. Star bar. Star bar. I still wanted to ask about it. I'm here in San Diego. I live in San Diego. Fantastic. You can find us on a meet up. Our next meeting is next Saturday at noon at the turf float. So, normally it's the fourth Wednesday of the month and we go to different dive bars. I've done it for eight years. If you get a chance, I did a TEDx talk about how dive bars can change your life. Other people talk about hey, we're bringing water to the Sahara and I'm like, we're going to dive bars. So, any other questions? Yes. Into those firsts? That can work perfectly. I like to do it when I'm writing and not necessarily do the outlining. But I like it because I know that 10 minutes isn't very long. So, especially if I'm feeling like, whoa, I've got short attention span. 10 minutes I can easily walk through sometimes 25 minutes sounds like, oh, I don't want to sit here that long.  It's my favorite way to do stuff. Yes, it's a great way for them because ADHD, ADD, yeah, super fast. Children too? Children love it, especially when you work with bells. You have to make it fun. You have to make it fun. But 10 minutes is wonderful for kids. Again, you're just working with that limbic system. You're telling me an limbic system, nope. You don't have to work that long. 10 minutes are done. You're out. You can do another 10 minutes, but just that. 10 minutes at a time. Is anyone else? Well, thank you everyone for being here. It's been a pleasure.


I asked him actually, my brother and I both asked him, we were like, would you ever go get tested? And he just smiled at me and he was like, no. I'm like, okay. I'm still working on it with my dad. He's kind of, he's open with it at this point, but it's not got any like drive to go get a diagnosis.  He doesn't really have any issues. So it's understandable, I guess. That makes sense.


Michael Bly and I'm here today to talk to you about cross-origin resource sharing and why something that's really simple to implement, really simple to use both on the Ruby and the browser side, can actually have some pretty important ramifications for web app development. So a little bit of background on me, I am the co-founder and CEO of DivShot. DivShot is an interface builder for web applications. So basically we're letting you drag and drop build using Twitter Bootstrap components for now, what we're going to expand beyond that and sort of the difference from every other drag and drop tool you've ever seen is that our prime directive and our focus is on exporting clean code so you can actually, you know, use it. You may have also seen some of my work, I'm also a fellow at Intridia, I've worked on open source projects there for the last five years including Omni-Auth and Grape and yeah, it's a Ruby consultancy, fantastic people. So that's a little bit of background on me. And if you'd like to follow along with the slides, they are just, it's HTML so you can go follow mbligh.github.com slash course talk. Feel free. All right, so cross-origin resource sharing. What this basically is, if you're not familiar, actually let's do a quick poll to get this out of the way. Who's familiar with what cross-origin resource sharing is already? Okay, a good number of you. Who has used cross-origin resource sharing in either a side project or something, production, whatever? Okay, good to know. So for those of you who aren't familiar with it, cross-origin resource sharing is effectively cross-domain Ajax. So everyone's familiar with using XML HTTP requests in the browser in order to request resources from the server without having to refresh the page. Well, cross-origin resource sharing lets you do that same thing but rather than being restricted to the same domain that the page loads on, which has been the traditional browser security case, now you're able to request from other domains as long as on the server side they're implementing this protocol. So you might be familiar with JSONP as well where basically you make a request to a remote endpoint that wraps it in a callback function that is then executed as JavaScript on your side and JSONP is effectively a hack way to do cross-domain Ajax. It only works for get requests. You don't really have any kind of error tracking, error reporting, custom headers. There's lots of things you can't do with JSONP that you can do with cores. And like all good things, cores doesn't work that great in IE less than 10. There is an IE equivalent of the cores called X domain request. There are also some various restrictions on how that works as opposed to the full cores standard. I'm not going to get into that now, but if you're building something that's for IE 8 and 9, there are a lot of things that I'm going to talk about that you'll be able to do, some that you won't, so dig into that a little bit more. So what is important about cores? Why does this cross-domain Ajax actually matter when it comes to building web applications? What it allows us to do really for the first time is we can build an application that effectively implements service-oriented architecture on the browser side. So there's actually been a lot of talk about SOA at RubyConf today, and I think that's because more and more as we mature, as our applications get larger, you realize that having this big monolithic application just becomes more and more unwieldy, whether that's because your tests are taking longer and longer to run, whether that's because you have completely unrelated code and just everything's getting out of control. The more you can break your app apart, the more you can turn it into small modules, small independent things that work together to give you the whole package, the better off you are. So to sort of go over the, oh, and the other thing that I'm going to go to in a little while is that if you build a public API for your application and you allow those developers to use cores, that can do some really amazing things, and that's one of the things that I'd say if there's going to be a takeaway of go do this, if you have a public API for your application, figure out how you can make it work with cores because there's some really awesome things, but we'll get back to that in a little bit. So what is cores? Cores is basically just a protocol where browsers and servers have agreed on a set of headers that basically tell you whether or not a given domain is allowed to make AJAX request to it. So basically how this works is if you're doing a GET request, and it's just a vanilla GET request, you don't have any custom headers you need to send or anything like that, your browser will just send that GET request over to the server, and the server has the option to respond with an access control allow origin header. And the access control allow origin header basically just says whether or not the origin domain, so if I'm on app.myapp.com and I'm making a request to API.myapp.com, then API.myapp.com has the opportunity to either approve or deny that origin of app.myapp.com for this request. So basically in the response headers, there will be access control allow origin, and that can be a star, which just means any domain can make a request at any time, or that will be a specific origin. So if it's a specific origin, that's either something that's going to be just statically added to your server somewhere in that I'm only ever going to allow requests from this one, or you could dynamically compute what that's going to be and send back a domain if it matches some whitelist or some other specification. So that's how it works for a GET request. For a post or put or delete, or if you need to send custom headers, then what happens is it sends an options pre-flight request. So what the browser does is it says, okay, you're trying to make an Ajax request across domains and it's not a vanilla GET request. I need to know more than just if this is allowed, because posting data to the server could be dangerous in certain scenarios, and the entire reason that browsers weren't allowed to do this before and the entire reason that cores exist as a standard is to basically protect servers from cross-domain site attacks. So, you know, cross-site, you know, that's sort of along similar principles as cross-site forgery protection and things like that, by not allowing Ajax to go across domains, you enable better security by default. So if you're making any request other than a vanilla GET request, then this options pre-flight request is sent first. So the browser, before it actually sends the post or whatever you're trying to do, it'll send an options request that's basically saying, you know, hey, server, I want to make this request. Is that okay? And the server will then respond with these various headers, one of which is the access control allow origin, which I already talked about a little bit. Another is access control allow methods, and this can be comma separated. So if I have the same endpoint and it can respond to GET, POST, PUT, DELETE, then I would add all of those to the access control allow methods in that options pre-flight request. There's access control expose headers and allow headers.  There are some basic headers that are that it's always allowed to see, but if you have any kind of custom headers that you're implementing things like that, maybe you're sending an API rate limit along as a header, you would need to add that to the expose headers. There's also the allowed headers, which is this, these are the headers that the browser is allowed to send to the server. So by the same token, if I don't specify certain headers that I'm expecting, then the browser is actually going to strip those headers off of the XML HTTP request before it's sent. So the server never actually sees that unless it gets the okay. And again, this is all done for security sake. And this brings us back to SOA in the browser. So this is sort of the really generic idea of what is SOA. You know, in a traditional application, you might have a monolithic, say it's a Rails app, doesn't really matter what it is. And that incorporates all of the different aspects of your application. You know, if you have authentication, user messaging, and activity feed, profiles, you know, a public API that developers can access. If that's all in a monolithic application, then, you know, that's a single point that the browser is communicating with. And that may be a request response cycle, or that may be through Ajax, you know, something more responsive like that. But either way, basically, you're just communicating with one endpoint. If you take the service-oriented approach, then you take each of these components of your application. So your authentication, your API, your messaging system. And you break those out into independent services. And by independent services, that means, I mean, it can mean a variety of things. That can mean basically that they're logically separate even if they're on the same server. So you're just basically separating all that logic, these existed different endpoints, or they can be, you know, entirely different languages, entirely different run times, different server infrastructure, different everything. And what this does is it gives you a ton of flexibility. So the advantage of the advantages of a service-oriented approach is that you have scalability that works better because each of these individual service parts can be scaled independently because, theoretically, they can all be on different infrastructure. So if I have an application and 90% of my requests have to do with user messaging and only 10% have to do with everything else, it would be really nice if I could, rather than scaling up this, you know, giant monolithic app that maybe has a big memory footprint, has a long startup time, what if I could just scale up the messaging part and have 10 times as many messaging servers running as I have everything else? So that's the basic idea behind the scalability of a service-oriented design. Reusability, which I completely misspelled. Reusability is also important because as you build these as independent services, you might come across, say, you're building another application that can actually utilize the same service. These services can kind of take on a life of its own. If you're familiar with Heroku add-ons, in a lot of ways, once you start building with a service- oriented approach, it's almost like you're creating your own add-ons for your application that do a specific purpose that you need. And if you have another application that has that same need down the road, then you're able to reuse that service without a lot of work, without stripping out a bunch of code. Again, flexibility. This just allows you, you know, maybe I have parts of my application that are very non-concurrent real-time focused, and so I feel like Node.js is a better fit for that part of the app. But for my main application and my API, I just want to use Ruby because I've already got code in there, and it's really simple and everything like that. So it allows you to implement things in different architectures without sort of sacrificing or coming up with complex schemes. Fault tolerance. So if I have part of my site go down, if I have built a service-oriented architecture that's performing well, it's potential that I only have a partial outage of my site rather than it taking down the entire thing. And clean boundaries is just saying that because these services are built independently, they're able to communicate independently, which means that there's always a clean separation of responsibilities in your code. So it forces you to make harder and more important architectural decisions earlier. You have to really think about your app in terms of these modules and these services rather than just, you know, oh, I'm going to slap some code in and we'll clean it up later. So it kind of forces better coding practices, a little more architectural thinking on you upfront, which also is a bit of a disadvantage. There is a bit of initial complexity to a service-oriented approach because now you're not just building one app. You're not just using sort of the standard path. You're building many applications. You have to figure out how and when they need to communicate with each other, how and when they need to communicate with the browser or whatever your central control point is. So there is a little bit more complexity with a service-oriented architecture. Cross-service communication can be tricky. You know, if I have a user's table on one server but I have another service that needs to know some of that user information, it can be a little bit tricky to figure out, you know, do I pull that over and cache it for a while? Do I, you know, make a request each time to that service? So figuring out the boundaries of when and how much they should communicate with each other can be tricky. And the other thing is that there's not really, at least in the Ruby world, and I'm not familiar with one that I think is particularly great. There's not, there's not sort of a framework that's like, that's built from the ground up to let's make service-oriented apps, you know, this is an easy way to do it. There's lots of sort of tutorials. There's some books out there that describe how to do it. But there's nothing that's as easy as, you know, Rails G controller, user's controller that's out there. So those are some of the disadvantages. But if you're building something that's more than a toy application, that you're expecting to spend months or even years maintaining, those disadvantages are really worth the pain to get to the point where you're thinking architecturally, you get that scalability and that modularity.  So, you know, if you're familiar with Rack, all Rails apps are Rack apps, all Sinatra apps are Rack apps. And so what you can actually do is in your Rackup file, you can just run a Rack Cascade of all of your applications. So say you just have, you know, a folder for each application. And what Rack Cascade does is if it encounters a 404, so it says resource not found, then it just falls through and tries to call the next application until something returns a non-404 response, or it returns a 404 response if it can't find one. So that can sort of be a cheat, where you're breaking it out into these individual services, but they're still all running in the same stack while you're sort of spinning things up. And my recommendation, if you're going service-oriented, would be to keep things lightweight. You know, I'm a huge fan of Sinatra. It's something that you can just get in so quickly, do a little bit of work, you know, everything's so clear. You know, sort of a plug for my own library, but I also built Grape, which is a stressful API framework. And these apps tend to be a little bit easier to break apart than Rails apps. Now, that's not to say that there's not likely to be a place and a case for Rails in your sort of service-oriented architecture, because you're probably going to end up having maybe a core application that runs a lot of your logic, but not some of these services, and that might make sense as a Rails app. And I'm sure that people that you may have seen, you know, there's the possibility of doing sort of one file Rails apps and breaking that apart even more. But personally, I prefer things like Sinatra. So as far as implementing cores in Ruby, it's actually dead simple because there's a gem for everything, so use the rack cores gem. So in your gem file, you just add rack-cores, and then it's a rack middleware. So in your rackup file, in an initializer for Rails, you just use rack cores.  You can pass multiple arguments if you need to to that one, and then you can specify resources. And on each resource, in addition to just specifying the path, you can also specify methods, which is going to give you that access control allow methods. You can supply headers, expose. So this is just a shorthand way to automatically handle those options pre-flight requests as a rack middleware.  So when I talked about if you have a public API looking to implement in cores, part of the reason is because it's really, really easy. So let's dig in a little bit. I built just a really simple service-oriented in the browser example so that we can go through both a few of the sort of principles of what's going on and a few of the challenges you'll run into. So here is my application. It's very simple, obviously. And first thing I need to do is I need to sign in. So now it's come back here and it asks for a status. So hello, oops, hello RubyConf. This is not my laptop and it shows. So I hit update, it shows up over there, and that's all this application does. So this is obviously very basic. This is not something that needs to be built in a service-oriented manner, but it was built in a service-oriented manner so that I could show you a few of the things that you might wanna do. We're just gonna go through the code on GitHub a little bit. So the first thing, and this is one of the things that even though it's not terribly important, I think is just really cool about what you can do with cores and that is that the app itself is just static HTML. There's no server anything going on. When you land on this page, that's just static HTML. So I could serve that using Apache. I could serve that by just dumping everything onto Amazon Cloud front and now I have it on a CDN. So that gives you just a real simple power, I think, to be able to serve your application that can do all of these amazing things as just static HTML and not even worry about the server side for your core application. So that's sort of the first thing. And if you look, basically we just have a basic HTML and all of the logic takes place in application.js. Oops. So taking a quick look at this. The first thing that I'm doing here, and this is a terrible hack that you'd wanna do better in a real application, but we need to know the different services that we're talking to. So in this case, I've built two services. I've built an authentication server, yes?  Let me, is that better? All right, cool. So I've built two services for this. I've built an authentication service and I've built a stream service, which is what allows me to publish and read from that stream you saw. So basically right now I'm just setting up that these are the hosts of those services that I'm going to access. So you need some way to do that usually, but this is a bad way because I'm using conditional logic and hard coded things, so don't do that. The next thing I'm doing here is I'm setting an Ajax pre-filter, so the authentication scheme that I'm using is loosely based on OAuth2 type things in that we just have a bearer token that's generated and that bearer token is given to the browser and then stored locally on the browser so that it can make subsequent requests to the stream service, excuse me, using that token. So what I'm actually doing here is I'm using JQuery, I'm using an Ajax pre-filter on JQuery to say, if I have a token, then I'm going to try to make authenticated requests when I do Ajax requests, so I'm going to add an authorization, I'm gonna add an authorization header to my request that sends along this bearer token. So the next thing that we can look at is what happens when the app launches and what happens here is that if you look at the OAuth2 specification, the way that you can send a bearer token to a client-side application, so something where you can't trust the code, you can't have things like client secrets because the end user can just inspect the code and pull it out if they need to. So the way that that's dealt with, at least somewhat, is by passing the token in the location hash. So because it's passed in the location hash, if you're not aware of this, anything after the pound sign in the URL is never actually sent to the server. So you want this token to be obfuscated at least to a degree, and by sending it in a location hash, that's not actually sent to the server when the request is made, so you have a little bit more security there. So all I'm doing is I'm checking if there's a token when in the location hash, when we launch the application, and if there is, then I'm going to verify and make sure that that's a valid token. Otherwise, we need, otherwise we already have a token, so I'm going to try and attempt to fetch the stream of updates. And now I think it'd probably be a good time to move over to our authentication app. So that was our static HTML browser app. Now our authentication app is just a one file signature app that I wrote, and here we're just setting up Redis, that's not a big deal. So the first thing you can see is all we're doing is if you go to the root of this, then we're going to authenticate using Twitter OmniAuth, and that's just because that was the simplest thing to implement. So then we go through the normal OmniAuth process if you're familiar with that, but basically it's going out, making the OAuth request, coming back, and fetching user ID, user information. So that's what's happening in this callback phase is we're just saving some user information, and then we're going to generate that access token that I talked about. So if you look at this regenerate token method, all we're doing is we're generating a URL safe token, and we are saving that in Redis, so that, excuse me, we can look it up later. And then like I said, we redirect back to the app host and include in the hash the bearer token that we just had. So that's really most of what there is to this application. The only other thing that we're doing is we have a Verify method where we're basically just checking to see if a token that's passed is associated with the user, and if it is, we're returning information about that user. And we'll get to that in just a second. Sorry about the coughing. So moving on to our stream application. This again is just a one line Sinatra application. But this can show you how you can sort of use services that talk to each other in general. So what we're doing here is we have an authenticate method. So if you go down here, I can either post to my activity stream or I can get activities from my stream. And what happens before any of that happens is I authenticate based on the token, the bearer token is posted in, is passed in. And so here what happens is I'm actually making an HTTP request to that auth server, to that Verify endpoint that I just talked about. And I'm saying, hey, I just got this token, but I'm not the auth server, I'm the stream server, so can you tell me if it's okay? And if the auth server says, yep, that's a valid token, then the stream server can go ahead and complete the request and associate things with that token and that user ID. Otherwise it will send back an unauthorized message. So this is a way that services both talk to the browser or talk to the sort of central controller, but can also talk to each other when necessary. And so if we go back to, I'm not gonna spend too much longer going through this, the code is on GitHub, but just to go through sort of how the posting works, we'll go back to application.js, you can see the Verify token happens at the beginning when we log in just to make sure that the token that we have stored is valid and then we have fetch stream and post activity. These are both just simple. And I guess that's something that I didn't mention that I definitely should. All of these requests, all of these cores requests, you do just like normal AJAX requests. So on the browser side, you don't have to do anything different. It will automatically do the options preflighting and everything like that for you. So if you're using jQuery, if you're using whatever, just do a normal XNL HTTP request and it'll go through. So long as the server is sending those appropriate headers. So we can get activities, we can post activities and then we're just updating the interface. So I mean that's pretty much it. But what you can see is that this is really pretty simple to do. And again, I really feel like it's something powerful where I have this application that's just static HTML. And I'm talking to this authentication service. But what if I had a separate application but I'm using the same user base? Well, now that application can also talk to the authentication service. And I have this stream service and maybe I have an email notification service that reads from the stream service to be able to push notifications. So once you start breaking things apart and modularizing them, then you're able to just do a lot more sort of reusing your code and thinking about things in terms of passing messages rather than just having this monolithic idea. And once you can do that in the browser, then you just have the power to load. If I have a messaging part, if you imagine something like Facebook where you have messaging up here and a user stream here and you have a photos application and all of these things, the browser can now coordinate all of those requests. They can all go to different services on different servers built with whatever the best architecture is for that. And it all just comes together nicely. So that's why I think that Cores is particularly powerful for sort of this browser based service oriented architecture approach. So I think that I just went through all of that. So we're gonna go ahead and move on and talk about public APIs that use Cores and why that's awesome. And that is probably my favorite animated GIF ever. So what's so awesome about it? First of all, it lowers the barrier to entry. So if I build an application and I allow a public Cores API, that means that the only thing that someone needs to do to be able to build an app that leverages my API is have a text editor and a browser. They don't need to run a server. They can do this locally. They can run this from file colon slash slash. So this just opens up a whole new ability to build these super lightweight apps that do a lot more than you'd expect they'd be able to. It allows you to do mashups without servers. So if you imagine all of these mashup applications where it's let's take Flickr data and mash it up with Google Maps data. Traditionally that was done by you create a server side application that accesses both of those APIs. It somehow mashes that data together and then displays it down to the browser in a way that's consumable. But if I use Cores and I just build a web page that makes Cores requests out to the Flickr servers. It makes Cores requests out to the Google Maps servers. Now I can do all of that processing on the client side. So I'm able to create powerful applications that combine multiple services that do all kinds of things without ever needing to build some kind of custom server architecture. And that's also important because when you think about things like Chrome extensions when you think about sort of simple downloadable deployable HTML that's a really powerful paradigm. Services can become public APIs. And what I mean by that is that you may build a service and at first you're using it internally but over time there may be a greater use case for it than just your own internal use. So you're actually able to expose that service to the public without doing a lot of additional work. And finally it has the same burden on you. So the same requests are being made to your servers. The only difference is that you're sending these headers back but it's much less of a burden on your developer users who are building things with your API. So this is just something that I really like a lot. So as an example of something that I've built that's sort of this Cores public API, DivShot Alloy. So in building DivShot we needed the ability to have people edit CSS for their pages but I don't like editing CSS. I haven't done plain CSS in like four years. So I wanted people to be able to use their favorite CSS preprocessor. The problem with that is that there's multiple and there's valid reasons for using all of them. So I wanted to support SAS, I wanted to support less, I wanted to support stylus. And so I built Alloy as a service to allow us to do this for DivShot but then I realized that I had built a service that was really general purpose and useful. So here's an example of it in DivShot. So I'm in my application, I have this, I'm gonna give it a class, let's say super class. Now I'm going to edit some stylus. So here's how we can utilize it in DivShot and that's great, it allows me to do custom CSS on pages which is a feature that lots of people wanted and now I was able to implement it. But what it also allowed us to do is release it as an open source public API so that anyone can use this. So if you go to divshot.com slash Alloy you can have this web API for preprocessing CSS. So whether I'm using stylus, it just compiles. I also built these book marklets that will actually let you click the book marklet and then click a text area and then if you've written sass or stylus in that text area it will just convert the content of that into CSS. So if you're using a website like Tumblr where it gives you the ability to have custom CSS but you don't really wanna write just CSS, you wanna use a preprocessor, you can now use this book marklet instead. And these were use cases that came up because I built it in this service oriented way because I built Alloy as a separate service rather than as part of a monolith. And so I think that it's just a really powerful paradigm to allow you to think about things that way. And famous examples. The GitHub API is 100% supporting of Cores which is amazing and you can see some really awesome examples of that. Things that are just hosted as static HTML on GitHub that give you ways to browse your issues, browse everything on GitHub in some kind of intuitive or new novel fashion and that's because GitHub added this Cores support. In the last few months, Amazon added Cores support to S3 and that's a huge thing because now what you're able to do by leveraging S3 and Cores, you can actually trigger file uploads that are uploading, whether it's a 20K JPEG or a 200 meg movie, you can offload all of that work onto Amazon servers and it never even has to touch yours because by using Cores, the request goes straight to Amazon so the file goes straight to Amazon and all you have to do is be able to deal with the response which is gonna be a URL of where it ended up being stored. So that's an example of what I talked about where it takes the burden off of your users and doesn't add any burden to you because either way, this file is gonna get uploaded to S3 but in this case, it was only uploaded to S3 rather than uploaded to my server which then got uploaded to S3. You know, one thing to think about when you're implementing this on a public API is how to handle authentication. Like I said, in the browser, you can't count on any kind of secret so if you have a client secret, something like that, you can't count on that being kept but you still wanna be able to identify applications so that you can remove bad actors, things like that and GitHub solution for that is that they only allow Cores requests from domains of registered OAuth applications. So if I register an OAuth application that is embli.github.com, now I can actually make Cores requests to the GitHub API from embli.github.com because I registered that application and I thought that that was a clever way to solve this problem. It still lets you identify an application so it just looks at the origin of the request and says, oh, this is coming from embli.github.com so this is Michael's fancy GitHub API application. So I just wanted to mention that as a good way to possibly handle authentication if you do build this into a public API. So now you know what you can do with Cores today and it really is a simple technology that just has a lot of applications and the question that I wanna ask because I've only just started diving into this, I think there's a whole wealth of things that you can do that I haven't even thought of yet so I wanna know what will you do with Cores tomorrow. So that's everything, I'm happy to take any questions you have and come talk to me afterwards or tomorrow or whatever but thanks for your time. Yeah. In the GitHub example, how is that any more secure? Wouldn't you still have to put the mic in the team? So it actually is less secure, I mean it sort of is less secure and there's nothing to be done about that so the reason that identifying applications is important is because if you're able to identify the application then you're able to sort of say, if this is just someone that I don't know that's just created an application maybe that gets a certain permission level whereas if it's on our own servers that gets a higher permission level because we know that it's from a trusted source so it just gives you the ability to identify but anything that's in the browser like that is sort of inherently less secure because it can be introspective at any time. But as everyone found out when the Twitter Android keys were leaked and everything like that just because it's on a different platform doesn't mean it's necessarily more secure so, yeah. How do you do graceful degradation for Internet Explorer? That is something that I don't worry about myself because DiffShot is a tool for developers and it was something that I wanted to research for the talk but wasn't able to find sort of a quick solution for so I can't answer that 100%. I know that there are some sort of shims out there and some libraries to massage, cross-domain XMLHGTB requests into that X domain object but I can't tell you sort of the best way to do it. Yeah. Why UI, which I use in my office has a module on the next ER which lets you use a native request or flash request just by configuration. Right. So you can have it work with ID. Yeah, so that's true. So sort of the way that people were doing cross-domain requests before is that flash allows you to do it as long as you have a, I think it's domain policy.xml file, something like that on the server that allows you to do it. So there's can be like a flash fallback similar to how there's a flash fallback for WebSockets, server-side events, things like that. Yeah. And you found a paradigm for integration testing with that kind of thing, right? So for integration testing, what's interesting is that because this is just standard XML HTTP requests, you can use any of the, like I can't recall them offhand, but there are various libraries for basically mocking out XML HTTP requests. And you can use those same things from the browser side. And then on the server side, that would vary depending on how you're building it. So if it's a Sinatra application, you can just use RackTest to hit it. If it's in Node.js, you'd use Jasmine or whatever you use for Node.js. But I mean, basically you test each of those independently and then you can sort of stub out the boundaries as long as you agree on a communication protocol, if that makes sense. Yeah. Can you use Chorus to authenticate for other connections like the WebSocket, for instance? That is a good question. I'm not 100% sure off the top of my head, but I believe so. Anybody else? Yeah. Okay. When you go back to do things allow top-of-the-range policy cover with the asterisk or are you always stress-as-high? With a lot of examples of asterisks, that seems like it's very important. So in my opinion, the asterisk is okay if you're talking about usually something that's like a read-only API or some kind of transient data or something like that. For anything where you're doing any kind of real authentication, something like that, then yeah, I think it's a much better policy to have specific domains that you're allowing based on however you want to whitelist that. Anybody else? So what about concerns on exploiting these? I just can't imagine like the OS in a storage, every browser running attacks everywhere. So I mean, as far as concerns, it's really no less secure than any other kinds of cookie-based session storage or things like that. Inherently, there are risks when you put data into the client. But what you can do is mitigate those risks. So in the little example application that I showed, every time it loads up the application, it verifies those tokens. You can expire those tokens say every 10 minutes or something like that and require them to be refreshed. And then you sort of minimize this window where if I forget to log out, someone can come back in, use my token and exploit that to hit the API and do all sorts of bad things. So I mean, there are definitely things that you need to watch out for. But I think in general, it's not really less secure than other ways of communicating with the backend so long as you're sort of cognizant of what you're doing and you're aware that you need to make sure that nothing that you consider to be truly secret is ever shown to the browser. All right, I think that's everything. Thank you.


Hi, everyone. Happy Thursday. Joe for jaspyscasebreaks.com coming at you with 2019-2020 Panini Chronicles Basketball Fat Pack Edition, Value Pack, Fat Pack, goes by many different names. This is random team number 93 with a chance to win six mixer spots. That's something that we're going to do at the end of the break. As always, we're going to do the break itself first. So for these folks right here, good luck. Thank you for getting in. It could be some surprises in this pack, too. 11 times for the names and teams. Six and a five. One, two, eight, nine, six and a five. There we go. 11. We got Michael all the way down to Jason. Six and a five. 11 times for the teams. And 11 in final time. After 11, we've got the Sixers down to the Sacramento Kings. Now no trades in these little filler breaks or mini breaks. And always keep an eye out for these filler breaks, too. Your break may be full, but there may be one or two little extra things we might have to do to give away the final set of spots or something like that. So always look out for that on jaspyscasebreaks.com. There's the first half of the list right here. Got Brenton with the gris. And we've got Jonathan with the pelicans. See what happens there. All right. So there's your list right there. Let's get all that on one screen. Let's sort it by column B. Let's print. Let's rip. Let's see what we got. There's the value pack right there. I guess the score and bronze parallel. That's kind of what we're looking for here. There's the final print out. I think we just have to do two more of these. And then a handful of spots straight up on jaspyscasebreaks.com. And then we're in Brakesville. I'm out of bio. He's been looking pretty good. There's a Kobe White Threads card. Nice. He's pretty good. Ooh, and a nice Luca Dodgecic scorecard here, which is apparently exclusive to this particular set of packs. So that's going to be Dallas. That'll be for Nancy with the Luca Dodgecic. There's the bronze. Kevin Porter Jr. also exclusive to this set. And Kobe White. Hopefully he'll have a nice season next year. He had a good season this year. Got Anthony Davis. We'll see him in action tonight. And Cameron Johnson, another bronze card in that essentials design for the Suns. That's going to be for David Ross. And the Suns. And the Bulls, by the way, is going to be for Adam Levy. You had the Bulls right there. We'll get that Kobe White. All right. Nice. So the whole point of this, of course, is to grab all the names here, put them in here, and re-randomize them, and give away six mixer spots. And that basketball mixer, that's on Jasper'scasebricks.com. So top six after seven. Top six after seven. One, two, three, four, five, six, and seven in final time. After seven. Now, first off from number seven down to 30. Thank you. I appreciate you getting in. Listen, there'll be a couple more opportunities if you want to try again on Jasper'scasebricks.com. We'll get them next time. Congrats to the top six. Adam, Jason, Joseph, Brenton, Amaris, and Sean. There you go. The six of you are in the NBA mixer. You just got yourself a mixer spot for a fraction of the price. And there you have it. I'm Joe for Jasper'scasebricks.com. We'll see you next time for the next break. Bye-bye.


Well, they were in the wilderness and they were taken by the gods. We also have God sightings, as you can see. This is the map, the God sighting map. And the God sighting is where you have seen God in your life. So you take a footprint and then you write on the footprint where you have seen God and you would write something there and we would stick them all the way and follow the map and see how the journey of the Israelites faith grew as they went through the wilderness. So this is the God sighting chart. The parents just did it today. We have the tribe of Joseph. They had the longest train because there were so many. Then we have the tribe of Asha. We have the tribe of Dan. The tribe of Isaac. The tribe of Judah. The tribe of God. And this was our test. We have the children learning about prayer and how to pray. One of the days that stood out for them was on Wednesday when we were talking about intercessory prayer. We talked about how we can intercede for others, especially those who do not know Jesus and those who have not yet received salvation. But when we pray on their behalf, God knows in their spirit and works in their situation and God brings victory in their life. Thank you very much for joining us in the wilderness escape where God guides and provides us. Welcome to Moses tent. Could we send this side over here? Our great God had our cry while we were in Egypt and he was so determined to rescue us from the labor and the hardship we underwent in Egypt. So the Lord told me to call the tribe of Dan together. You with your animals and your young ones. You have not come with animals today. And God told me to give you some instructions that we slaughter. We slaughter a weak animal. Which is very few, isn't it? Yes. Then what do we do with the blood? So to clarify this, this time when you are attending another station prayer we slaughter an animal here. If you slaughter an animal, blood will come out.   So that tonight, midnight, when the angel of death will pass over any dog that will be having a red paint what will happen to the first born is that the first born son will be spared and even of your animals will be spared.   I'm not asking you to do it. I'm asking you to do what you have done. If you are in Egypt, that's when I talk to you. While you are away, we roasted the lamb. So please follow me into the room with your clothes on, with your backpack, with everything, with your stuff. So that when the angel passes and we are signal to go from Egypt, we are ready to march.  The food is right here. Yes, we picked and live in bread after painting the dog posts. We are picking and live in bread. The reason why it's dark intentionally on one day was the recreation of the Passover feast. So the recreation of the Passover feast and the night where the Israelites had to eat the feast of their living bread, which you've just eaten and paint their dog posts, which you've just painted. I want someone to tell me, did God know where the Israelites lived? Yes. Then why did He ask them to paint their dog posts? Yes, Meli. To check if they are okay. To check if they are okay. Yes, so it was not God did know where the Israelites were parents. It's that He wanted us to be very obedient, including the feast of their Passover. They had very specific instructions about the type of bread, how to roast the meat, the type of herbs and all that. But how it applies to us is we have to obey God. It's everything that we do. So every day they would come here. We had a Bible point, a Bible verse, a lesson for the day that we put on around the tent. Now, unfortunately, after they ate the Passover, Pharaoh said, it is enough. I've had it. You people, it needs to go. You need to go and worship the God that you want to worship. So please, can you get out to me? A month ago, I don't know where Moses had gone to. I don't know if he had gone back to Egypt. He didn't even know. We are so confused. I feel like he has gone to Egypt, right? He had abandoned us. And that's why I'm not just in this body. Should we worship this metal over here? No! Now, God called me up the mountain and gave me ten rules. He called them ten commandments, which will guide us on a sweet journey in this world. When I came down from the mountain, I felt almost worshiping this circle. And one of the commandments was the rules saying, we should not do that. So I got down and dropped the commandments down and actually dropped all of them. Now to our parents. That's the snob of both of you. This is where we are taking back in time with the Israelites. In our journey to the wilderness, this is the wilderness escape, and we have made some tambourines there. We were making tambourines as we sang with Miriam after they crossed the Red Sea. And then we made some sandals to remember that God gives us what we need because the sandals of the Israelites did not wear out for 40 years when they were in the wilderness. And then we made some rope to remind us that God gives us the strength that we need. The same way that Moses, when he raised up his hand when the Israelites were fighting the Amalekites, he was able to prevail. When he got tired, Aaron and Hur held up his hands to give him strength. And then we went to win Benjamin to remember the story of the Passover. They were told to pack everything because God was going to serve them. So we made some mats. And then finally, Abigaz sand art tent, you've just seen what we made. We made the sand art because God wants to inscribe his commandment in your hearts and hearts. Thank you. Bye. Balloon bursting. That is what we are going to do with them right now so that you also see what they are doing. I'm going to ask you parents to join them in the line. They will be so interested in seeing you also participating with them. When you are a crocodile, you will be eaten. You will be eaten. We are not a crocodile, you will be eaten. Yes. Amen. Amen. When God has yourself, yes, ma'am. The devil is a monster. The devil is a crocodile. Passionate, honest and something I like about myself. I like my skin tone. My skin tone. I don't know whether that's a party. And I love honesty. I just, I love my family. Just love my family. One thing I love myself about myself is who my mind Christ. There was one time in my life I found myself battling between life and death. I found myself being grilled to a theater to have my arm amputated. But here I live today because of God. That's what's up God. We thank you so much for VBS 2022. Thank you for all the lessons we've learned about prayer. I pray, oh Father, that the lessons they have learned they will take root in their young hearts and that they will implement them at home. Help them even as they go home to unwind and remember all these lessons, Lord, when your Holy Spirit continue teaching them even as they continue to grow in their journey of faith. We pray that you'll continue to be with us. May your Lord give them favor in their families as they continue to pray and share this message with their friends. We ask these things in Jesus' name. Amen.