Dave Copeland, otherwise known as DaveFron5000 on Twitter. I wrote this book about how to be a good software engineer. I wrote this other book about how to build awesome command line applications in Ruby. And these aren't particularly applicable to our talk, but what we'll learn in this talk will help us build better applications and be better programmers. I hope. So the title of the talk, right? Overcoming our obsession with stringly typed Ruby. So stringly typed is what we're talking about. Does anybody know what I mean by stringly typed? Oh, and you came anyway. So if you've ever heard of Jeff Atwood, otherwise known as Coding Horror on Twitter, he writes his programmers blog. And he's got this great post, it's a few years old. He goes through different types of programmer jargon. And there are these very amusing phrases for things that we do as programmers. And the one that I thought was the most amusing was this one, stringly typed. And so what he says in the blog, he says it's a riff on strongly typed, used to describe an implementation that needlessly relies on strings when programmer and refactor friendly options are available. And we use strings all the time. Input comes as strings. Output needs to be a string. Rails loves strings. Databases love strings. We use them all the time. But it can get us into trouble if we use them when we really shouldn't. So we'll have a motivating example to demonstrate how we can get into trouble. So we'll talk about zip codes. So if you're not from the United States, this is also called a postal code, but basically it's a bunch of numbers that help the post office figure out where a particular piece of mail is supposed to go. It's sort of a pre-sorting thing that they do. And the basics of a zip code is that it's five digits. It's not a number, it looks like a number, but it's always five digits, even if they begin with zero. So like zip codes in Puerto Rico would start with 009. And like I said, it's not to a particular area of the United States as defined by the post office. And you can sort of read into them like the first couple of digits can kind of give you a sense of where in the country it is. And you can see that the numeric value of a post code or a zip code is lower on the East Coast than it is on the West Coast. But generally it's just a meaningless string of numbers that they use. So with that in mind, we're going to look at a very simple application designed to send letters to people. So we have a database of addresses and we have this third party API that we're going to use that's going to allow us to send the letters. So like your account is overdrawn or you're due for a refund or something like that. And basically that service will take care of like printing and folding and stamping and mailing the letters. And we do what programmers do, which is make two systems talk to each other and wrap some service to do something more specific for whatever it is that we need to do. So this is the Ruby API that the third party mailing service is providing us. That's where the implementation isn't there. So we will configure a bunch of letters that we might want to send in their system and those all have IDs. So whenever we want to send a letter, we will find it by the letter ID which gives us back this class that has this method called mail that takes the four parts of an address as strings, a street, city, state, and a zip code. And so calling that will mail that letter to that address. So to build our part of the system we'll make a database of addresses and we'll use strings to store them because that's what the database gives us. It's a pretty reasonable design table. And then we'll have some code of our own. So this bit of code here, its job is to read in address information from the command line and store it into the database. And we can assume for the purposes of this talk that this dollar database thing is some super simplified way of getting data into the database. It's not anything like active record. It's just something simple so that we're not too worried about the database layer for this. And so we can use this bit of code to add stuff into our database. Now to actually send the letters we're gonna make two classes. So the first one's job is to wrap the third party mailing service with something that's a little friendlier for the internals of our system. So our system deals with an address as a hash. So this letter sender is gonna take the letter ID of a letter we'd like to send, a hash of the address to send it and it will handle figuring out from that hash how to call the third party service. The second class that we're gonna need is going to handle getting an address out of the database. Oops, sorry. There it is. So it's going to take the ID of an address and the ID of a letter using the ID of the address that will again use our simple database API to get the address out and then call the letter sender. So this is very simplified, right? But we've separated concerns and this probably has shades of an application that you work on. This is very simplified, but it has all the hallmarks of what we do or integrating with something, we're wrapping this, we're getting things out of the database and everything in here is a string, but it's pretty simple. So let's see it in action. So we'll store an address, 45 South Faroaks Avenue, Beverly Hills, California and the only zip code everybody knows, 90210. Okay, so we've created an address. This is the address of the Peach Pit from 90210, if anybody ever watched that. So let's send the Peach Pit a letter. Okay, we sent letter number 12 to the Peach Pit, everything looks good, no explosions, everything's great. Happy Path works, everything is looking pretty good. Let's send another one. So 1675 East Altadana Drive in Altadana, California. Now this is the address of the house that they used on 90210 to represent where Brendan and Brando Walsh live. This is where that actual house is. So we're gonna send that house a letter, but instead of using the proper zip code for Altadana, California, we're gonna just type Walsh. Database successfully inserted that row, we now have an address that is clearly wrong. Let's send the Walsh as a letter. Okay, when the letter's sent. So that looks good, right? Except that the address is wrong. Walsh is not a zip code, yet our system was totally happy to send a letter to an address that had that as the zip code. So what might go wrong in this case? So if we're lucky, the best case is that our third party mailing service will blow up and tell us that this is a bad zip code and refuse to send this letter. Every other possibility is worse. We'll send, what if it gets sent to the post office? What will they do? Will they return it to us, maybe? Will they trash it, they might? Will they try to send it, sure. And if they do send it somewhere, where will it go? Is there a West Altadana Drive? And they send it there by mistake? Is there a East Altadana Drive in some other town in California where it goes? Who knows? We've given them an invalid address, we've made their job hard, and if this letter was important, it might not get where it needs to go. So clearly there's a bug in our system somewhere. So you could argue that the problem is in reading the input, right? We have this zip code as a string, but not every string is a zip code. So maybe if we restrict our input from being anything that doesn't look like a zip code. Okay, so we could do that. So now when you're adding addresses to the database, we're never gonna allow an invalid zip code. But I could just go into the database and insert an invalid zip code, right? There's nothing stopping me, and this is a real thing that could happen. Someone who, we might need to bulk import data from some other place. Someone who is not a Ruby programmer might need to get data into the database. There might be a need to get data into the database through something other than that cheesy command line thing that we wrote. So this is a real possibility. So we could say, well, maybe our database design was bad. Maybe we should do a better job of designing our database. So we could do something like this. If you're familiar with Postgres or other databases, this is called a check constraint. And this means that the database will refuse to insert anything into the addresses table unless the zip code matches this regular expression. That's darn handy. So that would prevent inserting bad data into the database. But there's nothing stopping me from going into a console and just calling the letter sender directly with an invalid address. And again, this is a reasonable thing that we might want to do. What if it's an emergency and I don't have time to get it into the database? What if someone else sees this class and wants to use it and they expect it to deal with this error case and it obviously doesn't? What if we need to send letters to addresses that aren't in our database and don't have the protections that we just added? All right, so there's a lot of real reasons that we could do that. So we could add a check in letter sender. But then what are we doing? We're like adding zip code checks everywhere. Even though our system that we're looking at, it's pretty small, but in any reasonable system, having to check this everywhere is untenable. I mean, you can't build a maintainable system this way. Because every time you want to add, change, modify, do anything that has to deal with the zip code, you've got to make sure to remember to add a check to make sure that it's correct. And that is not good. What we really need is a better way to deal with this. So if we think about our system, it looks like this. We've got our three classes that we made and they're all pretty small, they're pretty single purpose, they're pretty easy to understand, they're probably pretty easy to test. It feels like we did a really good job designing our application. So why are we having this problem? So I've drawn the parts of the application as blobs instead of the traditional box because to emphasize the point that the problem is, the boundaries between these applications, they're very loose, they're very ill-defined, they're not very strong, and so anything can come and go. We really want only zip codes going around in our code base, but we've done nothing to indicate that. In fact, we're allowing anything as a string to go through our code base. And so these boundaries are bad, which means it's easy to do the wrong thing and easy to create a problem. So what we'd like to, well, specifically, a boundary to be very clear is it's what's coming and going, it's if you think of a method, right? It's what arguments are expected. If I'm calling this method, what am I supposed to pass in? What am I not supposed to pass in? What am I gonna get back? If the answer is you can pass in anything and you'll get back anything, it's really hard to know what this method does. It's really hard to use this method correctly, be really hard to make changes to this method. It's not good. What you really wanna say is I expect a zip code and I will return you an address or whatever the case may be. But that's not what we do. We put strings and hashes everywhere. We use them all the time. Why? Because input is strings. Input from Rails is a hash. When we produce things, it's always in a hash. APIs want hashes, they want JSON objects or whatever the case is. And the problem is that we have these strings with no expectation of what's supposed to be in them. We have these hashes where we have no idea what the keys are supposed to be and so it makes it very hard to understand.  It's that there's a convenience to this. If we wanted to create a system using Java, for example. So Java, yes, you can make a string, you can make a hash, but it is not as easy as it is in Ruby and the APIs around strings and hashes in Java are somewhat cumbersome to use. So you don't tend to create systems in Java based on strings and hashes. Instead, you think really hard and you create special purpose classes for everything before you actually start writing code. In Ruby, though, we don't have to do that. We can start exploring the design of our system, figuring out what classes we need, figuring out what those boundaries are by executing code and strings and hashes let us do that because we don't have to think right upfront what do I need in these strings and hashes. I'm just gonna like just push code around and see if I can get things just kind of working before I think too hard about what's supposed to go in these strings or what's supposed to be in these hashes. The problem is if we leave the system like that, we leave it in this state where it's very hard to understand and very hard to modify. So what we need to do is after we've figured out what the boundaries are between our classes, we need to make use of data types to explain and define explicitly what is supposed to be coming and going. What are the boundaries? So a data type is a set of possible values. So integers is a data type and so there's an infinite number of them, but not every number is an integer. So these are integers, these are not, so that gives you some feel of a data type, right? A string can be anything. A zip code can only be five digits. So the possible values of a zip code are much, much smaller than the possible values of a string. A data type also defines allowed operations. So what can you do with a number? You can add it, multiply it, divide it. You can add strings, right? It'll concatenate them, but you can't divide a string. It doesn't make any sense. The vision is not an allowed operation on a string. Thinking about our zip codes, right? What operations are allowed on zip codes? But anything can be done, so many things can be done to a string. And finally, a data type also affords you to assign meaning to these possible values, right? So if I give you the string 20005, it is meaningless. But if I tell you that that string is a zip code, then you know it means Logan Circle in Washington, D.C. There's meaning to these values. So if you can describe your data as a set of possible values, the allowed operations, and some kind of meaning of those values, then you've said a lot about the system that you're doing. You've said a lot about the boundaries coming and going. A lot more than what you get with just a bunch of strings. So we can compare our implementation using strings to what we would actually like to have happen, right? A string, the possible values, anything. Anything can be a string. Operations, there's a ton. Meaning of a string can be anything, really the meaning is nothing. A zip code, right? It's only five digits. There's only 100,000 possible zip codes. Operations, there's probably none, at least not so far. What they mean, they have a meaning. So we've implemented a system using this thing on the right, left, and we want to use a thing that's on the right. So that's the source of problems. If we could just arrange things differently, our system might be better, right? If we had these firm boundaries, then so these circles would represent where we actually need to deal with the string, but everywhere else in our system can be safe in the knowledge that it's getting a valid zip code. We can reuse those parts of the system. We can add to those parts of the system without having to also add all these stupid checks because then we can say, well, the data type that we want is a zip code and we can be sure that that's coming and going and that makes it a lot easier in this bug that we saw would have not manifested itself in the same way. So, let's make one. You can do it in a lot of ways. I think making a class is the best way, but it's not certainly the only way. So we need to get the tainted potentially invalid string into our class at some point. So the initializer will take a string that we're going to assume is going to contain those five digits of the zip code. But since the string can be anything, we do need to check. So in here, we will check. If the string is not exactly five digits in a row, then we will raise an exception. Otherwise, we're good to go. Just this, just these four lines of code will help us dramatically, right? If we create a zip code with 90210, that is valid, so zip one is assigned, and we can use it. If we try to create the zip code with Walsh, that will explode. Zip two will never be assigned and that means that anywhere in our code when we have a reference to a zip code class, we know that we have a valid zip code. We don't have to check. It's already been checked. It's coming into us as a correctly modeled data type. Obviously Ruby lets you subvert all of this and I'm not gonna talk about that, but the intention here is encoded in our code. Like it's very clear what we're trying to accomplish. We are going to need one operation which is to get out those bytes, right? Because our service later down the line needs a string, we need a way to get that string out. So we will provide this method raw zip code that just returns it. I know that this operation, right, it happens to return our internal representation, but we could represent internally using an array of five characters if we wanted to. Doesn't really matter. This provides that operation of like, what is the raw string of the zip code? So that, if we were to implement our system using that, then we would reduce the places in the system where we would potentially have an invalid zip code and then the internals of our system would be just what we want. Nice firm boundaries that are very clearly defined. So I would say that this thing that we've been through, it's part of the design process, right? We figure out what problem are we trying to solve, and then we just shove our code around trying to figure out how to solve it. What is the code supposed to look like? What classes do I need? Get it to work. And then once you understand what you're trying to do and how you're going to do it, you can define the boundaries that you've created between your classes by using data types and creating a class that matches them. That makes everything easy to understand and is generally good. So we've seen how to make a class. We know generally what that class was trying to accomplish and why we care, but how do we actually let people know? How would I know I'm supposed to pass in a zip code and not a string? How am I supposed to know that I'm getting a zip code back and not some other type of object? So Ruby has no way in the language to do this, right? You can't, in the language, say this variable is supposed to be this type. There's no way to look at a Ruby program and figure that out. You have to run the program and see what happens. And there's no reason to think that running the program twice would have the same results, so we have a little bit of an issue. But we follow a few conventions that make it pretty simple. So if you have a variable named zip underscore code, probably stands for reason. That's supposed to be an instance of the zip code class because our code base contains a class called zip code. That seems reasonable to assume, so that's a convention we can follow. If we need to have multiple zip codes in play, then we can suffix zip underscore code to whatever the variables are. So sender underscore zip underscore code, we can assume is probably an instance of a zip code. Method names would be the same way. If I have a method name that has zip underscore code in it, I can assume it's going to return me an instance of the zip code class. And you can and should document the public methods. That makes it unambiguously clear what is expected, what's coming, what's going, what is the boundary, what class can I do. And if you do that, RDoC will hook it all up and cross-link it and everything if you ever generate and look at RDoC. Here's an example, right? So we've got this geo-locate method, takes zip underscore code as an argument, so we can assume that that's an instance of zip code. But because we have two seconds in our lives to help someone, we're going to write a documentation that makes that clear because this is a public method. Nearest zip code, same deal. Since the name of the method has zip underscore code in it, we can assume we're getting a zip code back. But again, we will take two seconds to write that out because this is a public method and it might be helpful. Our private method center point also takes a zip code clearly, but since it is a private method and no one is going to see it and it is likely to be changed later during refactoring, no real reason to write a document comment there, although you could.  So we talked about a convention for that. We talked about how we can kind of communicate to other developers and to ourselves what the boundaries are. Can we enforce these boundaries, right? Well, we'll talk about whether or not we should, but let's just see what it would look like if we tried to actually enforce these boundaries, right? To actually write our code so that it would not work to misuse the data types. So you can check the type. So isa is a method on every object. It returns true if the object is the same class as the class given or a subclass. So if we made a subclass of zip code, this would still return true. So that would be a way to check. If you didn't want to allow subclasses, you can use instance of. So this will return true if zip underscore code is a zip code, but not if it is a subclass of zip code. So this is a stronger check of the type of the argument. A looser check would be to look for the methods that it supports. Maybe we don't care if it's a zip code, but we want it to respond to the method raw zip code. So respond to is a way to do that. This is, you know, when they talk about duck typing in Ruby, like that's kind of what's going on here. This is called structural typing, which means the type of something has to do with its structure, not its name. So this is a weaker check, but it's a check. For checking return values, you can't easily access the return values of every method like we could with the arguments. So you'd have to do it in a test. So in all of your tests for these methods that return specific data types, you would assert that the result is whatever the class is that you want. And you have to remember to always do this. So that is what it looks like. And if you had to write every single routine like that, it would probably be pretty painful, right? So should we do that? Is there any value in doing that? Some programmers think it is unwise to write code where the types are not checked. That it is a bad idea to allow code to be written where you're not doing these checks all over the place. And that's fine. You could write type checks everywhere if you wanted to. In Ruby, I think that would be pretty painful, and I don't think we need to. And if that's the kind of code you want to write, I mean, there's other languages that are really tailor-made for doing lots of type checks. Ruby is not one of them. And I think that's fine. So then the question is, is checking these types like should we ever bother? Like is there any point to it? I think there's two points to it, two times that it might be useful. If there's some sort of risk involved, which we'll talk about, or if you're doing a big refactor, it can be helpful. So risk, right? Whenever I'm doing this, I kind of ask myself a couple of questions. How often am I expecting to get the wrong type in? Is it something that's gonna be really hard to screw up? Is it really obvious what to do? Or is this really easy to screw up? And everyone's gonna pass the wrong thing in. And then I balance that with what happens if the wrong type does come in? Will there be a exception just generated that is nice and I don't have to bother checking? Or will the medical laser cut off someone's thumb and which case maybe I do want to check? So you do this calculus in your head to try to figure out if you can be helpful by adding a type check. I don't often do it, but I do think about this to when deciding whether or not it's useful to do. A big refactor is another one.  And it can be tricky because it's a big change.  This is called lean on the compiler if you've ever heard of that. This is darn handy, it makes it really easy to do these sorts of refactors in a language like Java that compiles. So obviously we don't have a compiler in Ruby, but we do have a test suite and so we can leverage that with some type checks to kind of fake it out. So we'll change whatever core types we want, add in explicit type checks to our code, anywhere that's using the things that we just changed. We're gonna add those type checks to lots and lots of places because when we run our test suite they will all blow up with nice helpful error messages about our misuse of the data types that we've created. Fix the errors and then we can remove all the explicit type checks because they really don't need to be there.  Adding these explicit type checks can help. But both of these amounts to checking explicitly is not something that you probably are gonna do very often. So the other problem, the world wants a string, right? HTTP is strings, Rails is strings, databases are strings, output is strings, input is strings. So what do we do when we want to live in this world we have nice well-defined data structures but the world wants these dirty strings. So there's two things you can do. First you can adapt some protocols that will turn your data type into a string in a standard way that various parts of the Ruby library expect. You can also create wrappers that will take strings and turn those into your data type and by judiciously using those wrappers in just the right place, you avoid having to convert strings to your data type and back throughout your code. So let's see a few examples, protocols. If anyone has read Confident Ruby by Abdi Grim, if you haven't you should buy it, it's excellent. It contains all kinds of tidbits about Ruby. It's super, super helpful. Chapter 4.2 talks about protocols adopted by the runtime in the standard library for turning objects into simple types like strings. So for example, here's our zip code class. If we were to try to use it in IRB, the string version is this horrible thing with this object text thing, I don't know what that is. Puts does the same deal, string interpolation does the same thing. So what's going on here is that Ruby is using a protocol to turn your object into a string. The default implementation of this protocol is this mess. That's 2S, if you couldn't guess. So we can just alias 2S to our raw zip code method. We can just say, okay, the string representation of our zip code is this raw zip code internals. And now it works, wonderful. But there's a second protocol, and I bet we've all seen this one before. No implicit conversion of zip code into string. Probably seen this with a Boolean, like put S some string plus a Boolean. And at first it used to drive me crazy because it's like, dude, you have 2S, you know how to convert it into a string. But this is actually Ruby doing a type check. Ruby is saying that if you wanna append your non-string object to a string, that's probably wrong. You're probably making a mistake. I'm not gonna let you do that.  That's, I think you're wrong. And you can tell Ruby, no, I am right. I know what I'm doing. I would like this converted to a string. And you do that by implementing 2STER. So 2STER is not implemented by default, which is why we get this exception. So if you implement 2STER, that is sending a very strong message to everyone that like, it is cool to convert me into a string and this is exactly how I'd like you to do it. And, oh geez, and it works. So that is great. These protocols are also useful for web templating languages, like ERB that we're showing here. It will call 2S or 2STER, depending on the templating language to turn your object in. So you don't have to wrap your data structures in these presenters that turn them into strings as long as their string representation is appropriate. For simple types like this, I think it is, for a more complex type, maybe you wouldn't wanna do it this way. So there's some other ones that don't have to do with strings. There's 2A, converts any object into an array. So if you implement this, your object can be used with a splat operator to be turned into elements of an array, which is darn cool. 2Int is like 2STER, but for integers. So if you had like a price or a discount or something like that, this is a good way to go. 2H is added in Ruby 2.0 to turn it into a hash. So those are some protocols to turn your custom data type into a more primitive one that the standard library and other libraries might be expecting. The second one is wrappers. So we're getting strings out of our database as we saw before. And we wanna turn those strings into our zip code data type. So we could add a line of code here to do that, but then you gotta remember to add this line of code everywhere that we called select from. We don't wanna do that. We would like to isolate that inside the database. And so this goofy database handle that we have, like it doesn't have this feature, but we can add this feature by using the power of simple delegator. Does anybody use simple delegator? Okay, this is cool. So, simple delegator, you inherit from simple delegator like we're doing. And you can see here on line six, we're creating an instance of our wrapping database. And so what that's gonna do is it's gonna, any message we send to database is gonna pass it through to the underlying object. So we've created a wrapper around our goofy database handle that will pass all the methods through. But since we're doing that in a class, we can add methods to that and give it better functionality. We can intercept methods. So we'll add a method called convert that is this DSL-ish thing that will tell the database we'd like to convert the zip code column of the addresses table into a zip code class. And it saves it here in a table. So then what we can do is we can override the select from method to basically do the conversion inside. So first thing we have to do is call the original object select from method to have it do the work of selecting from the database and getting those strings back. Simple Delegator gives you a method called underscore underscore get object underscore underscore which I assume was created because no sane person would make a method named that so they can be safe that it will be available. That returns the object that we're wrapping. We then call select from on that object to get the raw results. Then all we need to do is convert those raw results that have strings into a result set that has our data type in it. So convert results will take raw results which is an array of hashes and it will convert each row of that into a hash that contains our data type. And convert row is a little gnarly. So take away from this that this is possible not necessarily how this code works but basically we go through the hash that we're given and if there's a conversion for the table and the column that we've got we do the conversion otherwise we just leave the value alone and at the end we return the converted row. So that's a way you could add wrapping to anything that you want. So this lets you kind of consolidate it into one place where it's needed and not have to do these conversions everywhere. Now I'm guessing you're probably not using a database mapping tool invented for a conference talk but maybe something else like ActiveRecord. So ActiveRecord has this feature. It's called serialize. You give it the name of the column and an optional class that will handle the conversion. By default it does this silly thing with YAML but you don't want to do that. We want to convert it ourselves. So we'll give it our zip code class and then we'll implement two methods on that class. Load and dump. Load takes the string from the database and is expected to return the data type that we want. Dump takes the data type that we have and is expected to return the string representation suitable for putting into the database. Notice we're using the two-ster protocol here. So this code is actually fairly generic. If we had a richer system of types we could generalize this somewhat. And so this is all you need to have ActiveRecord use your custom data types. And what will happen if you do this? Because remember you can't make a zip code if it's invalid. If someone does put invalid data in the database it will blow up the second it is fetched. So this will A tell you what data is bad and where someone was trying to access it. But B, it will prevent an address with an invalid zip code from populating your system and infecting it with this bad data. It absolutely prevents it. Thus allowing the internals of our system to continue to be implemented as if they're getting valid data because we have ensured that that will happen. Sequel, I don't know if anybody uses this. I haven't used it in a very long time but it does support this as well. I have never run this code. This is to demonstrate that it is supported but basically you use a serialization plugin and you register the serializer. So you've got a name of it and then two lambdas. One which is sort of like a dump that we saw before that's expected to get the string. The other is like load that is expected to return the actual object. And then throw a couple of methods in your model and now using Sequel you have all of this goodness as well. So this makes it really easy to use custom data types without having to worry about strings leaking in to your system. So this whole thing was talking about zip codes just because it was very simple and easy but there's lots of other places you could do this with even the simplest things. So email address. We store those as strings all the time. So these two email addresses are the same. They're the same email address but the string representations that we have here are false. So using a string is probably not a good idea.  I mean we've done lower and down case and all this is terrible. What if we had a class data structure, right? The data type of email, these two emails are the same. So the data type can reflect that. Prices, if you're doing e-commerce we have prices everywhere. So what is one third off of $100? It is not that 33.333336 is not a price. Right? Price.new100 discount third. 33.33 is a price. So by using a simple data structure we can enforce the rules of our system. Make sure that prices are always correct. It also forces you to think about stuff like this. Like there's some sort of mathematical operation I'm sure we could do that would have us debate do we round up or do we round down. Well, you should think about that and the price class would be a great place to encode that decision. Enumerated types like states or provinces or status codes or error codes. These are also really great for making data structures because they have a very well defined and obvious set of possible values. Okay, so that is my entire spiel. To take away anything, think about using data types. When you're designing and building your code don't forget to define those boundaries because you have something in mind. You have in mind data that is coming and going. Instead of just letting that data go off somewhere or be in documentation or written in a wiki like put it in code, right? When you make a data structure explicitly in code that's putting your knowledge and your intent in the code so that others can benefit and so that your code is easier to read, write and understand. So thank you, here's a link to the slides if you wanna check them out later, they're online. If you have a crappy consulting job you can come have a great job at my company so talk to me later about that. And that is all I have so thank you.


Am I gonna have to do this forever? Like I'm not gonna live like this. I don't wanna live like this. If this is what it takes to lose weight, screw it. I'm not doing it. I'd love for you to drop whatever it is you're trying to lose 100 pounds, 200 pounds, 30 pounds. Like I'd love that for you, but even more than that, I'd love for you to have that confidence and that empowerment that comes with you knowing yourself in your soul that any time you wanna drop weight, you know that you can. Good morning, my name is Boris. I'm a board certified physician assistant working in medically supervised weight loss and today I'm answering the question, do I have to count calories forever? So if you've seen a lot of my other content, I highly, highly suggest that people really get a handle on their diets and that means counting calories and eventually counting macros, so carbs, protein. I don't personally count fats, I just do carbohydrates and protein, but some people count all three. But at the very least, I think everybody trying to lose weight should spend some period of time at least counting calories and only calories. And actually that kinda gives away my answer of do I have to count calories forever? And the answer really is no, I don't think that you do. What I really think that it is, is it's just another tool in your toolbox that you can use whenever you need it. But in order to develop that tool, it's not something you can just say, oh, I'm going to count calories now and oh, when I wanna lose weight, I'll count calories. It's something that you really have to learn and how to train yourself to do and really get into the habit of doing it every single day for at least a few months. Sorry, there's a cute dog wearing boots. It snowed up here in Syracuse and, you know, everybody's all bundled up in their warm jackets and I guess the doggos are no exception. Freaking love dogs. Anyway, so I just, I don't think it's enough to want to count calories and think that you'll be able to do it. I think that you have to do it every single day consistently with every single meal.  I don't care how big or small the meal is or the drink is, you need to track it. So if you do that for a few months, I think that at least like six months in a row every single day. I mean, if you have a cheat day, if you miss, if you just don't do it one day, it's not like, oh, that's it, gotta start over six months. Like, no, okay, you missed your day, you know, slap on the wrist, whatever, it happens, just go with the next day and do better. Just be nice to yourself, love yourself and just say, okay, I'll do better tomorrow. I'll do better the next day. If you screw up tomorrow too, it's okay, do better the next day. That's all that matters is that you do it consistently. We're human, we all make mistakes. So if you're learning how to count calories and you happen to miss a day, two days a week, it's okay, just get right back up on that horse and just do it right the next time. But my point is, I think that everybody should learn how to count calories, really develop that tool, that skill and put that tool in your toolbox and in order to have that skill ready whenever you need it, whenever you realize, okay, I need to drop five pounds, I've been kind of overdoing it, then you can just pull that tool out of the toolbox and use it and in order to develop that tool, I think that you really should spend a few months, I think at least six, really counting calories and really tracking every single thing you eat for a long time. You can use a spreadsheet, you can use my fitness pal or some other app, the company that I work for, Kudos Weight Loss, we have our own app, whatever app or program you end up going with, as long as you're using it consistently, that's all that matters. I don't really care which one you use. Me personally, I don't even use an app, I use a Google Sheets spreadsheet that I just made for myself and it just totals all my calories, all my carbs, all my protein. I have my own measurements to my own resting metabolic rate in there and so it basically programs the totals in so I can track everything for the day and see if I went over that day. I can track everything for the week and see if I'm supposed to gain or lose a pound that week based on how well I did. So I just made my own spreadsheet. If you want a copy of my spreadsheet, maybe I can throw it up on my website but the thing is like resting metabolic rate is so specific, everybody's is different. My spreadsheet wouldn't work for you and your spreadsheet wouldn't work for me. So it would be more of like a one-on-one thing. Like I'm happy to do it with our weight loss clients and our patients and everything in our practice but as far as making a spreadsheet that works for everybody that's not really possible, it's something you're gonna have to do yourself. And actually come to think of it, I think I'm gonna make a video on how to make your own calorie tracker spreadsheet. And I think the reason that I use the Google Sheets is because it's less glitchy. Like even my fitness pal which is the most popular calorie tracking app that there is, I feel like it's super glitchy. I just find like it goes slow. It doesn't always have the meals that I want and so it just doesn't really work for me personally but I'm also someone who's just really particular about their apps and the way that their programs work.  So that's why I use my spreadsheet. So that's something you could do. Point is unless you have like a notebook pen and paper with you which like nobody does anymore, I think you should have an app or a spreadsheet or something to help you count calories and maybe even protein and carbs on your phone so that you could do it every time you eat something. And I know this is a super, super short video compared to my normal videos. I think it's gonna be probably five minutes or less, maybe even like three minutes, I'm not sure. And I feel like I've been repeating myself a lot here but I've been repeating things that I think are very important and that I just really want to get across and to really stick in your mind because I think this is extremely important. If you can get a handle on counting your calories and only your calories at first, if you can really do that consistently, it's incredibly empowering because you know that if you need to lose weight, you can do it. You can drop weight. It's not this nebulous thing that I talked about in the last video. Weight loss is not this like mysterious, magical, mystical, nebulous thing that it's just like unpredictable and you have no idea what your body's gonna do. Like it's not a perfect science but more or less, if you control the number of calories and you keep them consistent, you're able to lose weight. It is enough of a science where if you do things consistently, they do have predictable, consistent results, okay? So learning how to count your calories and really getting that skill of tracking your calories developed and becoming a really powerful tool in your toolbox is something that I think everybody needs that's trying to lose weight. And the answer is, do I have to do this forever for the rest of my life? No, I really don't think so. And I don't even think you have to be at your goal weight in order to stop tracking every single calorie and every single meal. I think that it's something that you should just know how to do and if you really need to tighten up and you really need to be more serious and more strict, you could do that for a period of time and again, knowing that it's not forever. So for example, let's say you're like me, right? You started at 215 pounds. It got down to like 168 pounds. That was definitely too light. Like my hormones were shutting down, things stopped working.  So that was definitely too light. I just wanted to get really, really lean, snap some photos, just see if I could get that really lean, ripped look and then go back up to a healthy weight because 168 for me was just way too low. So now I'm like 185, much happier, much healthier. My body's functional, my strength is back. Like I feel better, everything is just better. So I'm at a much healthier weight now. I got down much lower. But my point is in order to get that low, in order to get that lean, I really had to develop that toolbox, that skill to be able to track every single calorie and to really be able to know what I'm eating and control what I'm eating whenever I need to. So for instance, not saying this did happen, but okay, maybe it happened a little bit.  I have mashed potatoes and gravy and stuffing and dressing and all the good stuff. And by the way, we took my niece to go see the lights. So of course they were selling hot chocolate and pretzels X, Y and Z. Let's just say I totally go overboard. I gain like 10 pounds over the holidays. I step on the scale after the holidays are over and I go, okay, that was fun, but I really don't want to be this heavy. I'd really like to fit into my clothes a little bit better. So let's say I want to lose five pounds. Having that skill, having that tool in my toolbox empowers me to lose five pounds whenever the heck I want. So let's say I want to lose it after the holidays. Boom, I know what to do. And I know that it'll work because it's worked in the past. And I know that I can do it. That's the biggest thing. I say this over and over again on my channel, what is confidence? Confidence is literally just knowing what you're doing. So confidence just like weight loss, again, isn't this big nebulous thing where you like can't put a finger on it and like sometimes you have it, sometimes you don't like no, confidence is a science too. Confidence in a particular task, in this case, weight loss is literally just a skill that you know you have and that you know you can do reliably and consistently because you've done it before.  And it feels like it's never going to end. And that's when you ask yourself that question, like, am I going to have to do this forever? Like, I'm not going to live like this. I don't want to live like this. If this is what it takes to lose weight, screw it. I'm not doing it.  But once you've done it consistently for a number of months and you know that you can do it, it might not feel great, it might kind of suck, but you know that you can do it, that gives you that confidence.  And that more than anything is what I want for you folks watching me who really want help losing weight and you think that my channel is helpful. That's what I want more for you than anything else. I'd love for you to drop whatever it is you're trying to lose 100 pounds, 200 pounds, 30 pounds. Like I'd love that for you, but even more than that, I'd love for you to have that confidence and that empowerment that comes with you knowing yourself in your soul that anytime you want to drop weight, you know that you can. I'd much rather teach the skill than actually help you lose the weight because the weight can come back. You know that. You know if you go bad for one week, for one month, you can gain almost everything back. You can lose all your progress and then you're back to square one, right? Wrong, you're not back to square one. Your weight is back to square one, but your confidence and your skill set and your ability to lose that weight, that's what stays with you for life and that's what I want for you. And like I said a couple of videos ago, as I get more and more into this weight loss profession, as I see more and more patients, as I hear more and more success stories and I see what works, what doesn't, as I talk to more and more patients and kind of use creativity to develop treatment plans and weight loss plans that work for different people, I'm gonna talk about that more and more and more on this channel. I'm really gonna shift it away from PA school and test taking skills and stuff like that that I was talking about as a grad student and more towards my current passion and what I'm actually working in and like really dedicating my life to at least at this time. And that is medical weight loss, medically supervised weight loss. So that's what this channel is gonna be about. So stay tuned for a lot more amazing content on weight loss, on calorie tracking, on exercise. It's definitely something I'm into as well. And I'll see you in the next video.


I want students to think more about writing just for me as their professor, as the talking head, in front of the room, which I ultimately don't think is a very productive form of learning, whether in the humanities, but specifically in the First Nations studies more generally. So getting students to conceive, audience, and move beyond that and to find their own tone of voice, and I think introducing digital projects and open practices into that is fundamental to making that happen. The work that students have done academically is sort of treated as lesser than or is sometimes used as fodder for professor research projects, their way to build up. So thinking about how to hold up student work as academic work and as viable contributions to this in ways that isn't appropriative, I think is a real challenge not just at UBC, but for the academic world more broadly. Students for the most part don't understand their rights. So they don't understand copyright. And so that is a big part of class as well, is that making clear what copyright is, what Creative Commons is, how they can state their rights. I don't think they often, they don't understand how that they can label and mark their work through things like Creative Commons to establish those rights. So while I use open practices and I use digital technologies, we do that through a window of copyright and Creative Commons, so they can understand what the rights are around their words and the way that they get them out there. When you publish, traditionally, anytime you publish, there's there's a feedback, whether it's a peer review or whether it's just people disagreeing with your point of view. But I think open makes that much, much bigger and much more fraught and much more attacking and negative in a lot of ways. So there's different stakes now with publishing and openness widen that. All you need to do to understand how volatile these spaces are, open up a national post article, go to the comment section there and see the racism, the misogyny, the hatred and the vitriol that's viewed out there. So I think the call out culture is a big thing on Twitter and social media is by pointing to people and saying like you are doing this wrong, how dare you anger in there. But part of what I get my students to think about is this calling culture and how we can invite people into the conversation. So finding spaces where you can use calm, compassionate language to point out error, but not in a way that alienates people, but that brings them in and potentially looks at making them allies in this conversation.


Live from Las Vegas, it's theCUBE! Covering AWS re-invent 2019. Brought to you by Amazon Web Services and Intel, along with its ecosystem partners. Welcome back to Vegas. It's theCUBE live from AWS re-invent 19. Lisa Martin here with John Walls, and John we've been hanging out with about 65,000 folks or so. Just our best friends. But we talked about this just a little bit ago, but I really am impressed again with the kind of this continued energy and focus. And you know it's going to go well beyond the show, but three days of back to back to back, great presentations, great programming, obviously the show floor is still jam-packed. So really good show, hats off to AWS. Absolutely, you're right. The energy has not wavered one bit. And oftentimes by day three, that can be a challenge. So there's so much excitement. Not out here. Not in Vegas. John and I are pleased to welcome a couple of guests to theCUBE. To my left we've got Jen Doyle, the VP of operations from OneStrategy, and Ricardo Madan, VP of technology, products and services. How about that? From tech systems, I got two thumbs up. All right, good. He gave me carte blanche on how to pronounce that by the way. So guys, OneStrategy and tech systems. Jen, let's start with you. Give our audience an understanding of OneStrategy, what you guys are, what you deliver. Yeah, so we are a AWS born in the cloud, dedicated partner for Amazon Web Services. We are a premier consulting partner who focuses exclusively on delivering to our customers high quality AWS expertise. And across industries? Yeah, so because we're exclusively in the AWS, it's across industries and pretty agnostics for customer size and scale. So we have that unique capability to really dive deep on being the experts on the AWS when our customers are the experts of their own business. Awesome, and tech systems? So tech systems, global services, we are a full stack technology consulting, professional services, GSI global system integrator. And we really pay attention to that term full stack because we cover every facet of the software systems, operation, dev life cycle, but increasingly in the last couple of years, what has been the heart and soul of our ecosystem of competencies and practices and capabilities has been cloud. And even more so has been AWS, which is one of the reasons that we're super excited about coming together with one strategy. Well cloud, obviously it's not a thing, it's the thing, right? So we've kind of moved that past that. When people come to you or clients come to you and they want to understand about this cloud experience, especially if they're native cloud, right? They're not a legacy, not bringing stuff over, but they want to launch. What's kind of the checklist, the preliminary, that elementary look that you do to assess what their needs are, what their, why I guess what their opportunities are and kind of how you get them to start thinking about exactly what they want to get done. Cause I assume it's a big shoulder hunch and a lot of questions about where do we go from here? So how do you get them to, I guess orient them toward that conversation and that discussion? Yeah, so a lot of the way, good place to start is just to really understand their business. Right now it's no longer just a IT side of the house kind of discussion, it's a whole business. And so our first step is really to dive deep and understand their business goals, their culture and what their actual end goal is going to be. And so we have a really great program that we partner with AWS called the AWS Well-Architected Review Program which we were really fortunate to be one of the top initial partners selected for the beta program a few years ago and then a launch partner for them when they went public last year to really dive deep and be able to figure out exactly what are they doing, what do they want to be doing and how to get there both on scale vertically and horizontally, how does cost save and how to really make sure when they're doing it, they're doing it in a secure fashion. And where are those conversations happening? Are they happening at the IT level or is it really up, as Andy Jassy was talking about Tuesday, these types of transformations have to come from the executive senior level. Are you having those conversations with the heads of business? Yeah, we've really been seeing that kind of transformation and it's been phenomenal where that change in culture is no longer just the IT side of the house, it is senior leadership. Like Andy Jassy said, it's now a holistic business approach where you need that alignment in the senior leadership down and that inclusivity in that kind of part and a lot of our conversations, you're getting everybody really buying in to the AWS cloud initiatives that are going on and Rick, keep me honest, I know on your side as well, tech is experiencing a lot of that same thing. Indeed, and the way to kind of, I guess, divide and conquer the vectors from where we lean in to handle those conversations and prioritize the needs and even deal with the different audiences, Lisa, like you're talking about, because like enterprise IT owners and business owners, ultimately they care about making the business better but they're approaching it from different lenses and in AWS language, there's a methodology and a mindset called working backwards and it really is the process of beginning with those goals, those business goals that Jen talked about and framing them up just super tight. Before we talk about how many lines of code or how many servers are going to be provisioned, we don't want to even get into that until we've got that really good fluent understanding of the quantified needs and how to really kind of celebrate what that is and then work backwards from there, because it's such an all-encompassing conversation, especially with enterprises that are nascent to the cloud, they've only dipped their toe in the water kind of like what Andy was talking about during his keynote a couple days ago. Our specific methodology, underworking backwards, we break it up into two pieces. One is called Think Big and one is called Act Now. And Act Now starting from there is usually for the folks and that's like the technology solution, they're fluent enough, they're lucid enough and what their business is going to get out of cloud and out of a migration and out of native development, all that good stuff that we can kind of go right surgically into hey, how do we just make you better based on our combined expertise and our experience? Think Big is a little bit more involved kind of to where the question was going because you're thinking about OCM, organizational change management and how does that culture really instantiate itself to move fast and be agile and think in a lean way and repurpose lots of skills and lots of roles that kind of go extinct after a while. So how do we take all this great talent inside an organization and upskill them and next gen them to really operate inside of this new cloud ecosystem? So, excuse me, you're talking about really organizationally this leadership culture change or shift, if you will taking ownership of it from the very top. How do you characterize maybe what that mindset looks like today as opposed to maybe four or five years ago? It's so easy to put it over, let's just throw it over the IT guys and developers and we're going to focus on our marketing and our sales and we're going to do that. You know, the C-suite is there, right? They're much more present in these kind of discussions. You have to have it, do you not? To drive that kind of fundamental change. For sure. I think a lot of it has to do with the accessibility that AWS cloud is really bringing to the industry where it's now in such a easily integrating way into your entire business. It's C level, as you say, down to the interns can have that same accessibility using that toolbox that AWS allows for them to really jump in hands first and start making things right away. You can be spinning up instances within seconds. It's so simple. For people at all levels of knowledge, it's not just the 20 years of IT that can be the only ones to understand what's going on anymore. What are some of the barriers that AWS and cloud have removed that five, 10 years ago, customers were concerned with ABC that now those barriers have been mitigated. There might be new barriers, but what are some of the evolution that you've seen AWS really sort of fuel? So that we could even think back to some of what John, you were talking about, the kind of erstwhile mindset was a very big iron one. You didn't really look at technology and IT as anything more than a utility. Now it's a competitive advantage. Now you have to, that's why you have this whole concept of being a digital native and digital transformation, all these big words that they get so much airtime, but that's really been an acceptance and an adoption that technology has gotten to the point where we are moving quicker, better, faster as a function of celebrating CX customer experience and enhancing it and using technology to really make organizations move quicker, move faster, adopt new features into whatever their product set is, whether it's online or whether it's packaged, whatever. So I think those barriers that AWS has really kind of bubbled up to the surface and then sifted off has been that integration into the business and that's been a transformation that no other company has really enabled outside of AWS. For years, think about like Gartner and Forrester and IDC, they would talk about the number one objective for IT is to be aligned with the business, but always in like a subservient role. Now it's more of a foot forward and a leadership role that you see inside of these organizations. That used to be all those of the IT guys. Yeah, that's right. Hey, those are the IT guys, right? I mean, the whole thing's safe. If you look forward then, when you sit down with whomever and you're trying to walk them through their process and get them to evaluate, look what their needs aren't so and so forth, what's the biggest hurdle you got to get over with them? You know, with somebody to say, you've got to be totally present. This is what your IT offering should be. You should be cloud or whether you're hybrid, multi, whatever you might be, but you got to be cloud. What's the big challenge there you think to really get somebody to jump into that deep end? Honestly, I would really say it's the culture change. Right now, it's been such a huge digital transformation. You can't deny that, but the culture transformation that's going along with that has really been phenomenal. And that's a lot of the people who are at that point of starting their cloud journey are starting to realize they have to change the way that they look at everything. It has, you've mentioned several times, it's not just the technical side anymore, it is the business side and that's the big cultural shift of getting over that. There's a lot of technical debt in there with all the on-prem and different areas that people have invested in. And honestly, right now, the day of lift and shift is kind of going away. It's all of the new cloud benefits like serverless and containers is really going to be revolutionary, but that education and enablement really needs to be more prevalent in everybody's vocabulary and not just the IT guy who can tell you about it. It needs to be the C level, the enablers, the stakeholders in the middle that really understand what's going on. So can you talk to us about one strategy in tech systems coming together? Tell us a little bit about that, what you're doing together and how you might be an enabler of that cultural transformation that is absolutely linchpin. So there's that enabler and that accelerator to kind of that change and not to overuse the word accelerator, but that's just kind of one vector that we can talk about a little bit. And it's really what we're encouraging our customers to look at because they've got a broad choice of SIs, of system integrators like us, but if you're not coming to the table with real depth of expertise, depth of expertise that can help mute a lot of the complexity that we're alluding to because even though we've got so many benefits and so much growth happening inside the AWS world, there's 175 services today. There have been 2,500 feature updates releases across that portfolio just this year alone. There's five to 10 new announcements a day. And then outside of the AWS stack, you've got hundreds and hundreds of other members of the DevOps tool chain that get bolted into that. So the way that we're kind of getting customers to overcome some of that reticence is by muting a lot of that, simplifying it and coming to the table with real accelerators where we've invested collectively hundreds of thousands of lines of code that we've built and put together for AWS proprietary tools for better adoption, whether it's database freedom and getting like kickstarted off of your legacy oppressed database environments and into the purpose built platforms inside of AWS, whether it's microservices, libraries and frameworks that we built for customers to help them start to decompose some of those big expensive, high technical debt applications that Jen was talking about into microservices to containerize, to make them run faster in the cloud. So that's where we're leaning in from not just with the expertise and the combined resume of hundreds of awesome engagements that we've moved customers to the cloud in and hundreds and hundreds of terabytes that we've moved but it's doing it in a way where the customer knows that they've got a real leader here with them side by side in the journey and it doesn't happen in one or two conversations. I mean, this is going on across many different settings and demos and think big sessions like we were talking about. So it takes some time. Yeah, I mean, I think the combined family of tech systems in one strategy will really be phenomenal for our customers. 48% of the market right now is using AWS cloud and to keep up with that scale of innovation and growth just to be able to do that, businesses need AWS experts and that's who we are. It's in our name. We have one focus, one strategy and that's AWS. We are developed based on the same agile lean leadership principles that AWS has with the several competencies that we have such as our data and analytics, machine learning, DevOps, migration. We have a proven track record of not only being the AWS experts but being able to be agile and grow with that same speed that AWS ours to keep up with the training our teams on that expertise. And I think with tech systems, global footprint and ability to find these amazing talent combined with our skillset we will be able to create a larger geographical footprint to deliver to our customers in a way that they will not only see our ability to deliver what they're doing but exceed their expectations. I imagine the amount of engagements that you're going to have after an event like this, three days, you mentioned they're up to 175 services that AWS is delivering. The volume of announcements, it's incredibly challenging to keep up with it. Plus there's 2,500 sessions that customers can't go to that many. So I imagine there's going to be a lot of leaning on one strategy and tech systems to say help us deconstruct this and digest all the opportunities here. So you guys are, I'm sure going to be very busy after this event, but we thank you. Joining John and me today and telling us what you guys are doing individually and now collectively together. We appreciate it. Thank you Lisa. Thank you John. Oh, our pleasure. For John Walsh, we're out Vegas baby. This has been theCUBE. This is the end of our third day of continuous coverage of lots of stuff going on with AWS re-event. John, it's been a blast hosting a few segments with you. As always. Nice job. See you next time. Thanks for having me. All right, I will see you next time. Thanks for watching.


Ah, I have to get out of bed at six o'clock. No, you get to get out of bed at six o'clock. Do you know why? Because 150,000 people will die today. Today, we're gonna be talking about how to shift your words just a little teeny tiny bit. I'm talking like the smallest shift in the world and how that shift can completely change the way that you see and view the world but then also the way that you feel about the things that you do as well. And before I dive into it and tell you what the actual word is because why would I want to give it to you right away? Let me go ahead and lay the groundwork and the foundation so you realize why this is so important. So I'm gonna give you an example of how simple, just a simple change of words can really change the way that you see things, the way that you act, the way that you feel and the way that you view everything around you as well. And I'm gonna give you this example.  They can literally change the state that you are in. And so right now you might just be in a normal, chill state, nothing really crazy but just think if someone comes up to you and they say, hey, I love you, how would that make you feel by just someone saying that? Now what if someone comes up to you and says, hey, you look really amazing today? How would that make you feel? How would it make you feel if they say, hey, your shirt looks really great with your eyes? How would that make you feel? What if they come up to you and say, man, you look so pretty today. You look so handsome today. How would that make you feel? Think about that for a second. What if they come up to you and say, hey, I love your haircut. I love the way that you did your hair today. How does that make you feel? Simply just by the words of the someone's using when they come up to you. Hey, if you're enjoying this video, do me a favor and hit that like button down below. It helps with the YouTube algorithm so that more people can see this message because it helps us get it out organically. So hit that like button and I appreciate you. Words can make you feel amazing, can't they? If they're said to you the right way. Now let's flip it on its head. What if someone comes up and says, I hate you and they say it in a really loud screaming way.   You treat people like trash. I've never respected you. You've never respected me. You'll never be good enough. Someone comes up to you and says those types of things. How would that make you feel? Now you could brush it off and be like, whatever, right? But how'd that actually make you feel? Think about that for a second. Because the words that you use and the words that other people use around you, if you're not careful, can really change the state that you're in. They can make you feel amazing or they can make you feel absolutely terrible. So words are extremely, extremely powerful and you have to think about this and really understand how powerful words actually are.  They could say a derogatory word. How could that word could literally, you'd be having an amazing day. Someone could cut you off or you could accidentally cut someone off and they come in, they flip you the bird and then they call you something that's extremely derogatory and it could change the state of your day just by a couple simple words. Isn't that true? So words are extremely powerful. Just think about how much those words can completely change your state.  How much do you pay attention to them? See, when I talk to somebody, and I learned this from being a coach for years and years and years and years, is to listen to somebody but to really, really intently listen to every single word that they use. And the reason why is because especially when someone's on a stream of conscious and they're just speaking, what happens is they use words and phrases that they're not necessarily paying attention to but they'll give you little seeds. They'll drop little hints of what's actually going on in their mind and you can see how they view the world or how that's holding them back. And so I always say that if you listen intently enough it's kind of like getting a little bit of a window into someone's subconscious.  I want you to think of the things that you get to do. Right, think of the things that you get to do. Right, just think of one thing that you get to do. What is that thing? Have it in your mind real quick and I want you to really think about that. Think about that thing. What is something that you get to do? What is it? And when you think about that thing that you get to do How does that make you feel when you think about that thing that you get to do? How does it make you feel? Does it make you feel amazing? Does it make you feel loved? Does it make you feel happy? Does it make you feel grateful? How does it make you feel to think of that thing that you get to do? How do you feel doing that thing? That thing that you get to do? How do you feel when you get to do it? Roddy, how do you feel right now just thinking about that thing that you get to do? Think of another thing. Think of things that you get to do. Just really try hard with me here. What are some things that you get to do? How do you feel right now in this moment thinking about those? How do you feel when you get to do those things? Okay, now let me ask you this question. What's something that you have to do? What is something that you have to do? Think of that, think of one thing. Bring it up into your mind. What is that one thing that you have to do? What is it?  How do you feel when you do that thing you have to do?  How do you feel thinking about those things that you have to do? Oh man, later on I have to do this. What, how do you feel just thinking about, not even actually doing it right now, but how do you feel thinking about the thing that you have to do later on today? How do you feel? Now let me tell you something. Notice, I use two different words, get to do and have to do. Get and have to do. And all too often, I hear people say, I have to do this. And I can tell by the tone of their voice that they're not excited about it. And here's the thing, I don't think that anybody should do anything in this world that they don't love. Now do people do stuff they don't love? Absolutely. But here's the thing, if you craft your life around enough things and really start to think about the things that you're doing, if you start to craft it around what you love to do, then you get to do things. Now I understand, some of you guys are listening to me and you're like, Rob, but I have to do these things. I have to pay the bills. Of course, I'm not talking about not doing those things. What I'm gonna talk with you right now is about flipping the way that you view the things that you have to do. So let me give you an example. Lots of people say, oh, later on today I have to work out. Okay, is it that you have to work out? Or is it that you get to work out? Imagine if you just switched the way that you said it. So let me explain and let me go deeper into it. I have to work out today is a phrase of like, I don't want to frickin' work out today, but I'm gonna have to push myself to do it. All right, and just think about the mentality of having to do that, having to work out, versus I get to work out today. And let me explain why I say that.  They're quadriplegic. They can't work out at all. They can't go in and do bicep curls.  They can't go play basketball. For them, if they got to work out, their phrase that they would say to themselves is I get to work out today. Now think about how the shift happens in your brain of I have to work out versus I get to work out. There's a shift, isn't it? And it's only one word difference you flip have to get. So you should never have to do something, but you should always get to do something. I have to work out today. Think about all the people that would love to be able to be in your shoes, to do the workout that you quote unquote have to do. No, you get to work out today. You get to walk into the gym because there's so many people that would love to walk into that gym, that would love to walk on the treadmill. They would love to be able to hold on to a basketball and throw it or be able to do some bicep curls, but they can't. So you get to work out. Now you have to work out. I have to get out of bed at six o'clock. No, you get to get out of bed at six o'clock. Do you know why? 150,000 people will die today.  You get to get out of bed every single morning. Not you have to get out of bed every single morning. Think about how the thought of just, I have to get up versus I get to get up can change your perception of the entire day.  Of course. You don't have to get out of bed. You get to get out of bed. You were blessed enough to be able to get out of bed today. Simple shift, right? I have to go to work. You have to go to work. Even if you hate your job, you get to go to work. Cause there's so many people that are unemployed right now. 35 million, 30 million people I think are unemployed right now. They would love to be able to take a job that you're going to that you quote unquote have to go to. No, you don't have to go to that job. You can stay home. Now you wouldn't be able to pay your bills but you don't have to do anything. No, no, no. You get to go to that job. I have to go grocery shopping today. Really? You have to or you get to. You get to go to the grocery store and be able to buy food. Do you mean people aren't going to eat today? It's not that you have to do it. You get to go to the grocery store. You get to be able to afford a meal for you and your family. Think about how this, it's a small shift but think about how this could change the way that you start to view the world. Not I have to do this thing. I get to do this thing. Think about how that little shift could completely change the way that you see the world around you. Right? I have to fill up my gas. Or you get to fill up your gas. Do you mean people love to have your car? Do you mean people love to not have to ride a bike or walk or take the bus anymore? No, you get to fill up your car. I have to feed my children. No, no, no. You get to feed your children. Do you mean people have lost children in their lives? You get to feed them. You don't have to do anything in this world. You could literally stay in bed all day, every day if you wanted to. Now, let's be real.  That's your choice. Life is full of choices. You can make whatever choice you want but it's never that you have to do something. It's that you get to do something. There are so many people that would trade places with you like that, if they could. Don't ever tell me or tell someone else or even tell yourself more than anyone else. Don't ever tell yourself that you have to do something.  Don't blame anybody else. You get to do these things so that's the beautiful thing. You get to go to this job. Even if you hate your job with a passion, I get it. I have hated my jobs with a passion before as well. But hey, it's at least feeding you for now, right? You don't have to stay there forever. Once again, you don't have to stay there. You can leave if you want to. It's up to you. That's your choice. Everything in this world is a choice. That's the beautiful thing about it. But you don't have to go there. You get to go there. And guess what?  But you've made the decision to go there. Nobody else has. And this is really the shift where you start to realize when you stop saying, I have to do things, you realize that nobody is in control of you. The only one that's in control of you is you. And you at this point in time have to look at your life and go, I've made all the decisions to get me to where I am. I can't blame it on the president. I can't blame it on the government. I can't blame it on my parents. I can't blame it on my past. I can't blame it on my spouse that did XYZ. I can't blame it on this person or the car crashed or that accident or this person. No, once you take full 100% ownership of every single action that happens in your life and everything that you do, that's when most people think that's scary to think that it's all on my shoulders. No, that's so empowering because it shows you that from this moment on, you're in control of every single, actually you've always been in control of every single action, but now I know every single action is an action that I have chosen to take, not that I have to take, but I have chosen to take it. Even if it's not the one that I want at this moment, I have chosen to take it and I get to take it because guess what? As I said, you know, there's a lot of people that wish that they could work out. It's not that you have to work out. There's a lot of people that wish that they were still alive, but they died. There's a lot of people that have to go to or that don't have a job. You get to go to work. There's a lot of people that aren't able to feed their family. You get to be able to feed your family. There's a lot of people that aren't able to take a car to go fill up because they don't have one. You have a car. There's a lot of people that aren't able to feed their children. You get to feed your children. So take that switch. And next time you notice yourself saying, I have to do this, become very self-aware. Take yourself outside of yourself and look at your current circumstance and say, no, no, no.  And I have to say, I get to do this. What's beautiful about this is if you start saying, I get to do things, your perception of them flip. And you start to do things with more happiness, with more joy, with more peace. Once again, when I said just a few minutes ago, think of all the things that you get to do and how that makes you feel. Think about how you felt when I said that. Oh, I get to see my children. I get to drop them off. I get to be a parent. I get to be a spouse. I get to be a mentor. Whatever it is that you get to do. And then when I said, think of things that you have to do, you're like, oh, oh my God. There's so many things I have to do that I just don't want to do. Right? There's so many things. But think about if you switched them. If everything that you felt that you had to do, imagine if you could feel better about all of those things by just flipping the words that you use. Because once again, as I started this episode, that's why I had to start this episode talking about how powerful words are. The words that you use are so powerful. Make sure that you're using the words that are empowering to you and not disempowering. Because you never have to do anything, but you get to do everything that you're doing. And I guarantee you that there's so many people in this world that would trade places for you in an instant if they had the opportunity to.  Hey, thanks so much for watching this video. If you want to learn even more about mastering your mind, click right here and watch this video as well. If you believe that the world is going to s***, you will see all of the ways that the world is going to s***.


Welcome to another edition of HeyDT. HeyDT is a series of videos I do where I respond to viewer questions and comments. These questions and comments typically come from comments on my videos on YouTube and on Odyssey. Sometimes these questions and comments come through email or from responses I get on Mastadon or sometimes from Reddit. And the very first question I want to address is, HeyDT, why do you promote GNU slash Linux distributions that do not follow GNU's free system distribution guidelines like Ubuntu, Manjaro, and others? So what he is saying is that most of your mainstream GNU slash Linux distributions, pretty much all the ones you guys know about Ubuntu, Manjaro, Arch, Debian, Fedora, all of that stuff, all of those technically are non-free GNU slash Linux distributions because in the Linux kernel there are binary blobs, there's proprietary bits to the kernel, there's proprietary firmware, and the reason those proprietary bits are in those Linux distributions is because without those, those Linux distributions won't run on most hardware. That's just the fact. I would love to do nothing but promote 100% free as in freedom GNU slash Linux distributions, things like GNU, Geeks, Parabola, Triscoll, but the problem is I give those distributions coverage on the channel, but I can't strictly talk about those distributions. For one, I can't even run those distributions on some of my equipment because I need proprietary drivers, for instance, to run on some of my machines. So if I can't even get those things to work, why would I spend all of my time promoting those distributions to you guys? I want to promote the GNU slash Linux distributions that will work on pretty much any hardware known to man. That's why I talk about things like Ubuntu and Manjaro, which he mentioned, and many other GNU slash Linux distributions. You also have to keep in mind that I'm trying to get people away from the 100% proprietary operating system. I'm talking about Windows, macOS, Chrome OS. I'm trying to get those people away from those 100% non-free operating systems over to things like Ubuntu, Manjaro, Fedora, Archdebian, which are 99.99% free. There's just a small little bit of proprietaryness built into those operating systems just because it has to be in some cases because certain hardware only has proprietary drivers. There's no free driver option for some things. That's why they have to include some proprietary bits. I wish those proprietary bits didn't have to be there, but still, is it better to run something like Ubuntu or Manjaro rather than Windows or macOS?  And the second question is, hey, DT, I made a comment and that comment is gone. Did it go to spam or did you actually delete it? I did not write anything that would warrant deletion. Okay, so I get thousands of these kinds of questions and it's weird. I would assume by now most people know how YouTube works as far as there are algorithms out there searching for spam comments, essentially. I can tell you right now, if you post a comment and it actually includes a link like 99 times out of 100, your message is going to be automatically filtered. It's going to trigger that spam filter and it's going to be gone. That's not me doing anything. I get literally hundreds, maybe thousands of comments a day on my videos. I don't read them. I read a few. When I post something, I may hang out for a few minutes right after I post a new video and read some of the first few comments. I don't read everything. I don't have time to moderate my comments. If I actually had to moderate my comments, I would never actually make video content. So no, I'm not sitting there moderating the comments. I don't care what you guys write. But again, I don't have to moderate the comments because honestly, YouTube does a pretty good job of filtering out the garbage. So anything that includes links is going to go away immediately. I don't have to worry about it. Also, you guys, if you use certain kinds of language, you guys know the kinds of language you probably shouldn't be posting in comments. YouTube is immediately going to catch that stuff. Also, if you're mean or hateful to other people in the comments, typically they report your comments. So, you know, you're mean to somebody else in the comment section. They report your comment to YouTube. YouTube immediately takes that comment down. Nobody actually reviews it, but, you know, YouTube is just going to get rid of it because they don't want to deal with potentially any tricky issues. So no, I don't actually delete comments. It's very rare. I actually have to moderate anything. Occasionally, I will see something that I have to get rid of. Like if it's something somebody is making some kind of threat, like a threat of violence against somebody. You know, I see that. I've got to take that down immediately because what that person is doing is way out of bounds. But rarely do I go out of my way to delete comments.   I don't care. I'm not worried about what people say in the comments. But you guys need to know that some of what you're doing is triggering the YouTube algorithm. Also, never ever copy and paste the same message. You know, like some people will post the same thing two or three different times in a comment thread and YouTube will immediately just filter all of those out as spam. The next question is Haiti. Do you prefer upstream configs or cooked configs? He's talking about like config files for tiling window managers. Do I prefer the raw basic config file as from upstream or do I want something that's already been customized by the Linux distribution? So he's talking about like with Arco Linux, you know, if I install Arco Xmonad or Arco Awesome, you know, they're going to have their own customized versions of those particular window managers. Do I prefer that? Or do I prefer just the vanilla awesome window manager config to hack on? Well, this question is going to be different depending on the person for somebody that's already used these window managers. Then it really doesn't matter because you're always going to have your own config. It doesn't matter what you start with.  So that's my case. I have my own config files for all the window managers that I actually use, so I don't need anybody else's. So it doesn't matter if they ship with a vanilla version of awesome window manager, for example, or if they ship a highly customized awesome window manager, that doesn't matter either because I'm not using either one of those. I'm going to go grab my awesome window manager config from my GitLab. And you know, so that's people that have already used these tiling window managers. If you've never used a tiling window manager, which one would you prefer? You would prefer somebody to actually configure it a little bit for you so you can actually see what the window manager could become because if you start with a very vanilla basic config, it can be overwhelming to the new tiling window manager user. And the next question I want to read, man, this is a perfect example of I obviously don't delete negative comments. Hey, DT, you seem to make a lot of mistakes in your videos. How much do you really know about Linux? Well, I would say maybe not much, but there's that old saying, fake it till you make it. The next question is, hey, DT, you say FreeBSD is a Unix-like operating system. That is wrong. FreeBSD is Unix. And I've addressed this before, but I'm going to address it one more time here is that Unix is a trademarked name for something to be called Unix. Officially, it actually has to be Unix. It can't be FreeBSD. It can't be one of the various Linux distributions. Even many of the Unix operating systems out there, they can't really call themselves Unix because, again, it's a trademark name, but it really doesn't matter. The people that get upset about this, you guys quit worrying about lineage because it doesn't matter if BSD is a Unix-like operating system rather than actual Unix. It doesn't matter if Linux is a Unix-like operating system and not actually Unix. It doesn't matter because you know what? They're better than Unix. The BSD operating systems and the Linux operating systems are better than Unix ever was. Unix is an operating system. Everybody's trying to grab a hold of some kind of history because Unix was this great operating system back in the 70s and 80s. No, it wasn't. Our operating systems now, whether you're running FreeBSD, whether you're running Linux, your operating system now is 10 times better than those Unix operating systems ever were. And you know what really makes those operating systems much better than those old Unix operating systems is that FreeBSD and all of your Linux operating systems are free. They're licensed under free licenses where Unix actually was proprietary. Why are you guys trying to attach yourselves to a proprietary operating system? And the next question is, hey, DT, I see you've started using anime and meme thumbnails. It's a little more interesting and should attract more views, but I'm curious. Do you like them? Man, I get these questions all the time that I know this person has no idea who I am. He's commenting to me, but he thinks I'm somebody else. I have made almost 1,000 videos, almost 1,000 thumbnails, and of those 1,000 thumbnails, I've made exactly one thumbnail that off the top of my head. I know I added some anime to, because it actually was a topic about another YouTuber that does anime related content. But one thumbnail out of 1,000 had anime in it, and that thumbnail, that video, I made that over a year ago. It was not even recent. So I don't think this guy is actually talking to me. I don't want to be one of these people that get upset, but I really don't like being stereotyped. I don't like being confused. I know all of us Linux YouTubers look alike. I know that. I mean, I watch some of the other Linux content on YouTube, and I know almost all of us are middle-aged, bald, white, got some facial hair. You know, we're kind of nerds. I get it. It's easy to confuse us. But it's still, I do get a little angry when I get comments from people that are obviously watching somebody else's content and then commenting to me about it. Moving on. Hey, DT, what are your thoughts on compiling software from source? Do you recommend it? I don't recommend it. I don't discourage people from doing it. Sometimes you just have to compile software from source. If you want a piece of software that is not available in your Linux distribution's core repositories and there's no snaps or flatpacks or app images of it, then your only option is to build it from source. So at the end of the day, you do what you have to do. Is it better to compile your software from source than just grabbing a pre-built binary from your Linux distribution's core repositories? No. So, no, for me, it's all about getting the software that you need on your system. It doesn't matter how you get it. I don't recommend compiling software from source, but I mean, sometimes you have to do that. Me personally, I don't go out of my way to compile software. If I can get a pre-built binary, I'm always going to grab that. It's one of the reasons why I run Arch Linux, Arch-based Linux distributions for the most part rather than source-based distributions. That's why I don't run Gen2. That's why I don't run GNU Geeks, you know, things like that is because I don't like building all of my software from source because it takes a lot of time. The next question is, hey, DT, I have a question. How do you get menus for shutdown, restart, and log out on window managers? I was using Rofi before, but i3 doesn't seem to play well with Rofi. Any suggestions? I don't know why he's saying i3 and Rofi don't play well. Rofi or Dmenu is another good option. They aren't dependent on the window manager. They work regardless of whatever window manager or desktop environment you use. I don't know what he's talking about there, but if you want a good menu for shutdown, restart, log out, all the session stuff, there are a couple of packages out there that are easy to get on most Linux distributions. One I used to use a long time ago was oblogout, and it was meant to be used with Openbox since the name oblogout. It was just a simple program that when it ran, big icons popped up on the screen for shutdown, log out, restart, and things like that. I think there's another one for i3 called i3 log out. There's a couple of these things out there. You could also do what I've done. I just wrote a simple script for Dmenu, so I have a script where when I launch it, Dmenu appears and it asks me, do I want to shutdown, restart, log out, and if I click yes, boom, I'm done. And the final question is actually a comment, and I believe this comment was on one of my videos responding to about the toxic Linux community and certain organizations and projects and foundations within the free and open source software communities that are toxic in nature and kind of divisive. And he writes, hey, DT, that's funny to me because people like you discourage convenience in favor of obscure software minimalism by endlessly memeing the bloated software and distribution supremacy. EG, don't use baboon2, install gen2, and then wonder why the Linux community is so divisive. Okay, so there's a lot to digest here. Again, much like one of the earlier comments, I don't know if this guy actually watches my content. Like, literally, I have never, ever told anyone, don't use a boon2. I don't know where he gets that. I use a boon2. I have most of my web servers, you know, web hosting, typically if they offer a boon2 LTS servers, that's what I use. I've actually like a boon2. I'm a big fan of a boon2. I have never anywhere in like the nearly 1000 videos I've made have ever said, don't use a boon2. I don't know where he got that from. And then earlier we talked about compiling software and I said I don't really personally like it. That's why I don't run source based distributions. So I've obviously never told you guys to go in and install gen2. So who's this guy responding to? Now, have I talked about minimalism, you know, trying to be more minimal and trying to avoid bloat? Yes, but how is that divisive? I'm not saying you have to do that. I'm saying that's what I do, but I don't know. It's weird. It's weird the things that people take personally and really it's comments like this. This comment really has nothing to do with me. This comment really is a reflection on the person that actually wrote that comment. And you can tell that this person has some issues in their life that at some point they're going to have to work out. Now, before I go, I need to think a few special people. I need to think the producers of this episode. I'm talking about Absi, Dallas, Gabe, Lou, Mitchell, Alan, Akami, Archbishop, David, the other David, Dylan, Gregory, Lewis, Paul, Polytech, Scott, Steven, Sven, Weston, Willie. They are the producers of this episode of Haiti without these guys. This episode, it wouldn't have been possible. The show is also brought to you by each and every one of these ladies and gentlemen as well. All these names you're seeing on the screen right now. These are all my supporters over on Patreon because the DistroTube channel is sponsored by you guys, the community. I don't have any corporate sponsors. It's just me and you guys. If you'd like to help me out, look for DistroTube over on Patreon. All right, guys. Peace.


So my wife and I finally bought our very first home as a full-time doctor. Now as you go through medical school and residency, you just don't have an income to be able to pay for a down payment for a home. But as you become a full-time physician, there are several options that you can use to actually buy your first home just like we did. Number one is paying for a home conventionally, which is usually paying about 20 to 25 percent down of a down payment and then having a mortgage over 30 years. But number two, and this is the option that we took, is using a physician loan or a medical provider loan. Banks know that usually people in the healthcare field have a stable job, they have an income. And for me as an attending, I not only had all the money that my wife and I had saved over residency, but also all the income that we had to show over my first year of being hospitalized. And so we use this to obtain a physician loan, which basically required a little bit less down in the 20 percent, meaning that I could keep some cash in my bank in case I had some emergencies, but also have a very similar, if not actually better interest rates than all the conventional loans that are out there in the first place. Now if you enjoy that behind the scenes of my life as a full-time physician and you like to see my journey into cardiology fellowship as well as becoming a cardiologist, hit that like, subscribe, and follow for more content just like this.