Welcome to a relentless pursuit of rest. My name is Derek Pryor. I'm a development director at Thoughtbot. I work out of our Boston office. And I'm super excited to be here, kicking off RailsConf with you all. And I do feel like I won the lottery because I get to go first, and then I get to enjoy the rest of the conference and see all the great talks with you guys without having to worry about this presentation I have to give. My Twitter handle's right up there on the screen, so if you have feedback during this talk or after the talk, you can tweet me there. Meet me in the hallway. Later on in the week, I'll have some Thoughtbot swag to hand out so you can find me later. Give out some cool notebooks and potentially some t-shirts and things like that. So, ostensibly, this is a talk about rest, right? So, what is it? I'm kind of just kidding about that. I'm not gonna recap Roy Fielding's dissertation here. There's been plenty of conference talks on this. In fact, it was alluded to at the opening keynote that this is the 12th RailsConf. And at every single RailsConf, there have been at least one presentation about rest. So, why should this RailsConf be any different? In addition to those conference talks, we also have probably hundreds of blog posts developed by the community. Probably, I don't know, half a dozen books or so and hours of podcast material, some of which I'm responsible for. And a common refrain among a lot of that content is that somehow we're doing rest wrong. And this can be any number of ways that we're doing rest wrong. As programmers, a lot of us tend to love semantic arguments. And rest seems to have plenty of them for us to have. So, we do. Rest is all about the power of HTTP on some level. So, there's plenty of arguments for us to have there. Do you have an API? Do you version that API with a slug in your URL, perhaps? Should you instead be using the accept header and content negotiation? If you were gonna be more restful, maybe. A few years ago now, there was a pull request to Rails to change. Or to add support for the patch verb, because that was more semantically correct than how we were using put. And I remember at the time I had really strong feelings about that one. And I was like, yeah, we really should be using patch. And so now we can, and nothing has changed. And then there was this, hypermedia. It was kind of, I alternately read as like an extension of rest or a rebrand of rest. And it was all about providing additional URLs for clients to use to get more details about your resource. The big idea being that clients shouldn't be building their own URLs, you should provide them for them. And then, whatever this is. I think it has something to do with hypermedia, but to me, it just always sounded like mean Cheerios. Thank you. So, the secret is that none of that stuff really mattered as much as I thought it did. Those really strong feelings I had about patch, like I alluded to, nothing changed when that became a reality. None of those things make me a happier or more productive developer or make my application more successful. Most of us in this room, I'm guessing, work on a single app or maybe an API with a small number of clients that we control because we also write those clients or we work with the people who do, or we have a business agreement with the company that does or something like that. And in those cases, in all cases really, it's consistency that matters. We can make those decisions that I alluded to before and make them consistently and we can move on. The rest of those decisions are rather academic. And that's not to say that you shouldn't care about them at all. You should have opinions and you should discuss them. But I believe that the importance we put on them is outsized to their benefit. So, this is a talk about rest. So, what am I gonna talk about? I wanna talk about how rest makes my code better and my job easier. How it makes my code easier to read, easier to maintain, easier to extend, and how it can ease Rails app growing pains that we all experience. To that end, I'm actually gonna spend a lot of the talk talking about nouns and verbs. In REST parlance, that's resources and actions. So, resources being your domain objects and actions being the things you can do with them. This is the very, very basics of rest and certainly it lacks the marketing appeal of something like hypermedia. But we're gonna use our focus on resources and actions to drive us towards creating more small things.  Those are the antidote to all of the Rails anti-patterns that I encounter on application after application. So, yes, in this talk, we're gonna talk about some common anti-patterns that I do encounter on a regular basis and I'm guessing that you do as well. And we're gonna talk about how restful design helps us to avoid and correct those anti-patterns. So, first I wanna talk about custom actions, right? There's nothing special about the seven default actions that a Rails scaffold controller gives you, right? You've got new and update and create and all those other ones. Fielding certainly didn't bless any set of actions. Maybe it would have been best if he did, but he didn't. But this is a case where strictly following that convention over configuration that David talked about is gonna help us to avoid many of the pitfalls. It's the first step of avoiding a lot of these anti-patterns. Before I get started with that, I just wanna take a quick second to talk about how I get started in a Rails application. So, if I'm coming on to an established Rails application, the very first thing I do is open up routes.rb. Because a good routes file can tell me a lot about your application, right? It can tell me all of the capabilities of your application and do so very succinctly. And it can tell me about the language of your app, not Ruby, but like the business language of your application. What are we actually working with? A bad routes file also tells me a lot about your application. Tells me where I'm gonna find large controllers or which code I may need to read in order to understand what it is your application does. So, I thought we could start with a slice of a routes file that obviously a simplified slice of a routes file that I commonly see in Rails applications. So, here we can see on the first line we have a singular user resource. So, right away, just from experience, that tells me the singular user is likely the current user and we support an edit and update action which is them editing their user record or updating their user record in some manner. Perhaps their user profile, something like that. And then there's these two custom member actions that are just sort of hanging out here. They seem relatively harmless, but I immediately wanna know how to edit password and update password. How do they differ from editing and updating a user? And why are they on the user's controller? So, I immediately wanna dive into that user's controller and see how things, why those choices were made. But before we do that, I wanna take just a quick pause and look at what those routes, those member routes in the middle there would look like if we wrote them out longhand without the use of the resource as helper. So, it looks something like this. And I just wanna focus on the controller mappings there. If we break those out, we have users edit password. Users update password. And there's a pattern there. That pattern is noun, verb, noun. So, that pattern's a dead giveaway that we're missing a resource. And I see this in a lot of applications. And then the resource that we're missing is actually right there in the action name. The resource is passwords. So, we have passwords edit, passwords update. And that pattern is the more familiar noun, verb pattern. We're manipulating a password in these actions. We're not manipulating the user. The fact that user is, the fact that password is ultimately stored in the user's table is inconsequential to the resource that we're dealing with. So, we can fix this in our routes file by creating a password resource, another singular resource. We don't need to create a password model for this to work, as I was saying. And here we've put password in its proper place of prominence here. It is the thing that we're working on. It is the thing we're editing. It is the thing we're updating. And we get to use our conventional edit and update actions. Here's what our passwords controller looks like. All we've done is copy over what used to be edit password and update password into a new controller and call them edit and update, move some views around, updated some helpers so that our tests pass, and we're ready to submit our first PR. And at this point, there tends to be some questions or possible objections that come up. A common one is that this can't be worth another controller, right? And I always wonder what is it that a file costs us? It's very lightweight, right? And ultimately, my response to this is that I've never once, in the many years I've been doing Rails development, regretted extracting a controller. I've never wished my controllers were bigger. I've always wished I had more of them that were smaller. So any chance you can take to create another controller, you're often wise to do so. And it's also often a first step towards larger refactorings, as we'll see throughout this talk. The second objection is more of a realization usually, not so much as an objection is that password isn't a model here, as I talked about. We're so used to there being a one-to-one correlation between active record models and our controllers that it can feel wrong somehow to stray from that. And as we talked about the Rails scaffold generator earlier, and that certainly encourages this one-to-one correlation.  And the books and tutorials written about Rails often reinforce this. When you want to introduce new functionality or change functionality, you just either generate a new scaffold or generate a new controller and a model, something like that. But the key takeaway here is that our controllers do not need to map to active record objects one-to-one. Our controllers can map to a single column on an active record object, or to just a plain old Ruby object that isn't persisted anywhere if that helps us for whatever reason. And this realization was a light bulb moment for me, and in speaking to countless other developers, they professed it also was for them as well. It's often highlighted as the one realization that really improved people's Rails code. Because what it does is it frees us up to build small objects to bridge between our controllers and our models, and lets us not expose the specifics of our model implementation at our controller level. And we can see an example of that in our next anti-pattern. So complex actions, what I'm talking about here is really long controller actions, perhaps calling out to several private methods, something like that. They tend to be very difficult to read, very difficult to test, and resistant to refactoring, because it's hard to break off pieces of them without messing up some other part. But the key thing to realize here is that oftentimes we can rethink complex actions into several smaller actions across several resources. And this is often appropriate to do. The first thing I wanna call out is that nobody comes into work thinking like, I really can't wait to write some controller code today. Right? It's just kind of a thing that happens. We write complex controllers over time. In the beginning, our controller actions are just the way we like them. They're super boring. For example, we may have a controller action that allows users to update the caption on a photo that they've uploaded, and that action might look something like this. You don't need to read every line here, right? You can just kind of get a sense for what it's doing from the shape of it, because you've written a controller like this before probably. And it's boring. It's wonderful how boring this code is. Right? Every one of our controllers. Unfortunately, it seems as if no boring controller like this survives first contact with our users or our product owners if we're not diligent about it. Before long, a new story might come along. Right? This seems pretty harmless. As a user, I want to mark a photo as featured so it's displayed prominently on my profile. So my immediate thought here is, okay, I'm gonna add a featured column on photo, and it's just another column that gets updated just like we had with caption. I don't really need to change much at all. No problem. So we do that and we submit that and the product owner tests it and comes back and says, oh, I forgot to tell you, I should have told you you're only allowed to have one featured photo. Okay, so I guess we have to have a conditional for when you go from something that wasn't featured to something that is featured and we need to find the previously featured photo and update that so it's no longer featured. All right, cool, we can do that. So we submit that and then there's one more thing that comes back and it says, oh, I was able to unfeature my final photo and I really don't want that to happen. We should just pick the first photo to be featured. All right, that seems arbitrary, but these things happen. This is a real feature that I have developed. So, you know, and you might think long and hard. In best case scenario, you come up with a controller action. You update your update controller action to look something like this, which is kind of intentionally hard to read here. It's interestingly shaped, right? And if we zoom in on the new method, that update photo private method we've extracted, there's a lot going on here, right? We've got an active record transaction. We've got a compound conditional. We have an ELSIF, which just the spelling alone in Ruby makes me kind of go, hmm, I probably shouldn't be using this. And it's not bad. That whole thing is not bad by comparison to what you're probably thinking of when I say complex action. But as a spoiler, if you're paying particular attention to the code and the requirements, this is also not correct. And how could it be, right? Business logic like this in controllers and conditionals in controllers like this are often not tested. And as such, have bugs in them. So how did something, so how did a feature that seemed so simple end up putting us here? Which again, probably not as bad as your complex actions, but it fits on a slide. The problem is one of differing perspectives. We wrote our original controller thinking that we were updating attributes on a model where each attribute was of equal importance. The new feature requires us to treat a certain attribute differently, right? We have to kick off a process. One attribute is now more important than the others. And the behavior differs based on which way that attribute changes, whether it's going from false to true or true to false. The dissonance in those perspectives is what results in the complexity we saw. And we can resolve that complexity, resolve that dissonance by getting back to being boring with rest. We'll introduce a featured flag resource to represent flagging and unflagging photos. Our photos controller goes back to what we previously had. It's super boring form that we saw earlier. And we're gonna make sure our new controller is equally boring. And here's how that might end up looking. It's deceptively, it's kind of a deceptively small font here because now it's two actions. But if we zoom in on create, we can see it is almost identical to the boring photos controller we showed before. The finder changed because the parameter changed. And now we're using a service object. If you see here, the add feature flag service object to get the work done. But we maintained that familiar boring shape of our controller action. And the same thing is true of our destroy action. We're using a different service object or object. Sean doesn't like service object. So here's what one of those service objects might look like. So here's our add feature flag service object. So you can see this is also pretty boringly shaped. It's not perfectly factors as I might write it, but it's also not very interesting. All of the complexity in the original controller, or the controller that we showed that have that complexity in it, all of that is now gone, right? The compound conditional, the if else, it's all faded away into the routes, right? Those decisions were all made before our controller code even ran. So as a result, this is also going to be significantly easier to test. I can unit test this or model test or whatever you wanna call this kind of test that you're dependent on the database for, right? I can test this in isolation somehow, and then I can have an overriding feature test and have pretty good confidence that this is correct. The lesson here is that we need to be boring. Your controller should be boring. Your model should be boring. When I first started in Rails, it was common to hear fat model skinny controller, and we don't say that as much anymore because we really want small things everywhere. What we should be saying is boring model, boring controller, boring object. There's something really satisfying in taking code that was complex or perhaps clever and breaking into component pieces that are boring. So as we add complexity to the application, we wanna make sure that the code we're adding is as boring as possible. Now, when I'm reviewing a Rails file or controller actions, I often encounter the third anti-pattern of ambiguous language. So what do I mean by this? How many of us out there have an orders controller with a process action or something similar, right? What does process do? What does it mean to process an order? That would likely depend on who I ask. If I ask somebody who works in the warehouse, what does processing an order mean?  If I ask somebody who manages inventory, maybe they'll tell me it's, no, it's actually dispatching that order to the proper warehouse to be fulfilled from. Or if I ask somebody in finance, I can bet they're gonna tell me it's processing the charge or the credit card charge, collecting the money. This might seem trivial. After all, we're talking about the code, so as long as those involved in the development of the project agree what process means, does any of this matter? Ultimately, having ubiquitous language throughout your application and in the business is what's gonna ensure ease of communication about everybody, among everybody who cares about that system, right? What we wanna do is avoid translating between the business terms and the terms used in the code because that results in confusion and it results in people making the wrong change because the product owner asked for it in the language of the salespeople and you implemented it in the language of the code. So process doesn't tell us anything. To figure out what it means, we have to go source diving. So okay, let's open up this orders controller which I'm sure is very boring. So again, I need to fit stuff onto a slide here. So the real action in the real controller would be a lot harder to decipher than this. But these controllers tend to begin with an indecipherable entanglement of conditional before actions at the top. And those before actions are possibly order dependent. In worst case scenario, which I've seen several times, they mutate some sort of instant state along the way. So we pick our way through all of that and then we drop down into the process action itself and that calls out into several private methods which we have to kind of unwind and those depend on instant state as well. Okay, so we go through all this process and then we discover that what we're actually talking about is shipping and order. Processing and order is equivalent to shipping it. So why didn't we just say so? So let's just say so. We didn't say so because this is awful. This somehow reads worse than process. Where are we putting the ship? I don't know. The problem is we don't need a better verb. What we need is a resource. So let's do that instead. We're not putting a ship, we're creating a shipment. This language works even if you're not ultimately inserting a database row somewhere. You can use create, it's fine. We don't need to change the underlying implementation. So here's what our shipments controller looks like. Now we pull over all the before actions we need, they're no longer conditional, that's kind of nice. And we take the process action and we make that our create action and then we pull over any private method that it needed. Just by pull over, I literally mean copy and paste it. Private methods and all, everything. And then we submit this as a pull request to say we've improved the language of the application. Isn't this great? At this point, we tend to get a little bit more heartfelt in the objection category. Yeah, I just told you I copy and pasted a bunch of code so I did duplicate a lot. We duplicated a lot of the private methods to make it work and some of that private method is just duplicated typing, like the finders and things like that, I'm not gonna worry about that. But some of it may actually be duplicate knowledge that would be nice to have housed somewhere. If breaking out that new controller is what it takes to highlight this, then it's worth it every single time. And I wouldn't rush to go ahead and make those extractions now, like let them sit for a little bit and make sure they make sense. This change stands on its own. As our friend, Sandy Metz likes to say duplication is cheaper than the raw abstraction. So I'm gonna live with this duplication for a little bit and see where it takes me. But this change does stand on its own. And the larger objection is that I didn't actually improve the code here. The ubiquitous language improvement I made, though, is worth a PR and a merge. No one else is gonna have to wonder what process means. We're all gonna be talking about the same thing consistently, as long as we wean all the developers off of saying process. But there's something else of value that this has done for us. I like to call this breathing room, right? It's the best way, the best way I can explain it is to draw a comparison to writing something, writing a blog post, or a paper, or a conference talk, something like that. And you may, in your writing, you may have a sentence wedged into a paragraph somewhere that isn't sitting right with you. It feels important and you want to say it, but it's just not working. So you try to reword it a few different ways, but it's still not great. And then you pull it out into its own paragraph and suddenly you realize the problem was that you had a lot more to say. And you can start to expand on that. And it starts to make more sense in itself and it starts to strengthen the things that are around it as well. That process is akin to going from something like this in our code, right? We've got this tangled mess and we're trying to figure out where this teal string goes. And so we're pulling at it and then we realize, oh, this is a totally separate piece of teal string over here, right? And we're trying to make an improvement on something like this to something more like this. Where we're holding a single piece of thread and we're still not quite sure what to make of it, but we can pull at it and we can see where it goes. So we want to get to this state because that's where we can really start to impact the rest of the application, right? So where do these things often go? State machines. Calling state machines themselves an anti-pattern is harsh, right? State machines happen somewhat naturally in a lot of our work. Orders kind of transition among various states of fulfillment pretty naturally. My problem isn't so much with the idea of a state machine. It's more how they're commonly implemented in Rails applications. They typically are made up of hundreds of lines of DSL tacked onto a model and that DSL expresses all the possible events and transitions and validations and potentially methods that are overridden in various states. And that all gets tucked into our order model for instance because that happens to be home to the state column. And so we just shove it all in there. A sign that I might be in store for something like this would be seeing this in the routes file. When I see this, it's a good indication that I'm in for a large controller backed by a state machine. So I might go ahead and take a look at that order model and try and figure out what's the state machine doing. So here's the beginning of it. So I came here trying to figure out what happens when an order's authorized. So like, okay, here are our events right here at the top, right? Nope, nope, those are transitions. Oh, nope, nope, they're not transitions. They're callbacks for transitions. Okay, all right, but all I care, again, all I care about is authorized. So okay, I see on the third line, that's authorized. Oh, but that's going authorized to captured. Oh, the fifth line is going from pending to authorized. That's what I care. All right, and it authorizes a payment, but it does it after it transitions. I don't know what that means, but and should this class know how to authorize a payment? Right, I don't think so. So here are the various events we support as we scroll down in the state machine. And this one's not so bad. There's less than a handful of them. Great, and yeah, okay, here's our transition. When we authorize, we go from pending to authorized. Another nice thing about this is like, they're very, it's a very linear progression among the states, so it's not too bad. And here's some custom class behavior based on the state. We have different validations based on whatever state the thing happens to be in. And we may actually, as I alluded to earlier, have methods that are overridden or methods that only exist on a certain state. Here's what the whole thing looks like. This certainly isn't a pathological case, but it's also not boring. It's extremely dense. When I'm reading through this code, I'm usually trying to answer a specific question about one particular event. And I'm left much like in our orders controller example to try and piece together the entire thing by going through a thing of callbacks, and then the transitions and the states and all that other stuff. And is this all tested? Probably not, because somebody went, I'm sure they tested it in the state machine. In the state machine term. State machines are magnetic, right? They attract more states and more transitions and more events and more callbacks, and they accumulate conditional logic, which is where our bugs hide. States and transitions that fall out of use are almost never cleaned up, because no one's clear that they're no longer in use anymore. Many of the recent projects I've worked on have 200, 300, 400 line state machine definitions. And this is not uncommon. I don't work on extremely pathological projects all the time. So how is REST thinking going to save us down here all the way in our model? Still this one from my friend, Sean. Pretend for just a moment that update didn't exist. What associated records would you need to create in order to properly reflect the state of your order? Those are the resources you need to care about. So if we did that in our example, we might end up with this, right? We've created resources for authorization, capture or refund or rejection, and we support creating those resources. Thinking resourcefully here gives us that breathing room I alluded to earlier to reconsider the interactions between our controllers and our models. Each of these state transitions can now be encapsulated by an object if we want, and the objects may still well update that state column on order. That's perfectly fine. Or we may actually insert some associated records instead. Also works fine. So in addressing each of these anti-patterns, oh, sorry, let's talk about this one. So what used to be an encoded mess of transitions and events is now just like this boring object here. So this is what it would look like if we extracted that authorization thing into an object or service object or process object or command object, whatever you want to call these things.  And if I want to know what happens when an order is authorized, I open up this file and it tells me. And if we want to change what happens when an order is authorized, this is so lightweight that there's no sunk cost fallacy to overcome. We can throw this away and start again without worrying about losing some sort of context that we didn't understand about authorizing an order. So anything that drives us towards these types of small plain Ruby objects is going to be a win for our Rails application. So in addressing each of these anti-patterns, we've thought about our application from the outside in. We've been preaching outside in, or a lot of us have been preaching outside in development for quite some time. Generally when talking about test-driven development. But outside in development works equally well when designing your domain object interactions. And it results in similarly better design and better code. What we're doing is changing the language of the application from what does this application store and how does it store it, to what is it that this application does at the highest level. And there's still an overriding objection that I often hear to much of the advice in this talk. And some of you in this room may be thinking it. And that's, you know, this is fine for crud apps, but my app's different. My app's a snowflake. It's much more complicated than what you're letting on. This is fine for base camp, but my project's a lot more complicated. Or pretend perhaps maybe I just want to use RPC or whatever, you don't really like REST that much. So what I found in app after app is that in most cases, what's keeping any app from being just a crud app is a lack of imagination. You haven't gone back to rethink the problem from the outside in to identify the resources that you're actually talking about. And you want to be a crud app, believe me. Believe me. Because crud apps are boring, right? And I hope you know by now, when I say boring, I mean that in the most sincerely complimentary way. You want to be a crud app because Rails is really, really good at crud apps. And you've chosen to write or have been stuck with maintaining a Rails application. So when doing that, be boring. Be RESTful. Don't worry about response codes, right? Identify the real resources and use in your application and design your entire system from that perspective from the outside in. Don't worry about the vagaries of your data model or your data store. Any questions? Yeah, so the question was, how would you handle the state machine exam, sorry, the example of a wizard, right? A multi-step process that maybe in the end creates or updates one record. It kind of depends on the specifics of what you're trying to get done, but I did recently do the same type of thing where people were going through this registration wizard and telling us a bunch of information about the facility that they were onboarding. And the way we did that was had them, in step one, they created the shell of the resource. And in step two, we modeled that as associated records, even though ultimately they weren't all associated records. Some things were like an address would then be associated to the thing in the next step. And there may be a state thing at the end that happens to say yes, they've checked all these boxes and the wizard is now complete, but trying as much as possible to think about breaking that up into different resourceful steps. And it is kind of dependent on the on exactly what you're doing in the wizard. So the question was, a common objection is that it's fine to do, it's basically fine to do this here, but you haven't addressed it everywhere else, is that like now we have a different pattern in use in lots of places. It is a common objection, you're right about that. And I mean, we have to be trying to make the application better. And if people can agree that yes, this is better and we should be moving to this, then I think you'd do it, right? And you update the other things as you have need to. But yeah, there does tend to be some pushback about, like, well, now this is a different pattern, we've never had a service object anywhere, now we have a service object, but if that's an improvement and the team can agree that that's an improvement, the option is just stagnating and a thing that you agree is not the optimal solution. So that's the way I would put it. So where I would put, so the question is where did all the complexity that was in the state machine go when I showed the example of the extraction that I had done. And I wouldn't extract it to a controller, what I actually extracted there too and I might have done a poor job of explaining it was that was the service object that controller is gonna use. And I would put all of, as much as I could of that there, right? And there was, if we go back, I don't know how far back that is. Oh, not too far. Okay, so there was this idea of whether or not something's authorizable down in the bottom and that would be like the conditional validations perhaps. And the before transition and after transition stuff, that all just kind of goes away in the middle of this process or call or whatever you wanna call that, the main method of this object here. Because it does the transition of updating the order and then it calls the authorized thing that we were doing in our state machine at that point. So moving that as much as possible into a service object or a collection of objects that work together and testing those individually. And I think this really does kind of encapsulate a lot of what was happening in that state machine and I think it's read significantly easier. I haven't thought about it from that perspective. I think the generators are super useful. And I still use them on occasion like when I need to remember what a vanilla controller looks like. And I don't know that it's a solvable problem if you're gonna generate code. I don't know that like the generator could know exactly what the best thing to do was. Oh, and for the video, the question was, should we update the generators to be more in line with an approach like this somehow? So the question was about alternative action names like reorder if you have a collection of something and you wanna reorder them so that we create a reorder action. And how would I handle that? And yeah, I would typically like going back to our photos example, if you were reordering all of the photos, I might create an album instance, right? And you can update that album instance with an ordering of its component photos or something like that. Or a positions controller like you alluded to in your question, something like that. But there's no reason the collection of objects can't be a resource in and of itself. So yeah, that's how I handle that. So the question is, I'm making a Rails engine, is that what I'm doing? Okay, so I'm making an API for an engine and the action is start the engine. How would I make a nice resource for that? Boy, on the top of my head, I don't know, engine start request, create. And engine update, sure.  Like I think, I'm not trying to say that you should never have a custom action, but I'm saying it should be your default to never have a custom action. And you should agree with your team that like here, a custom action makes sense for me. I just happen to think that answer is almost never, but you may differ slightly. I just hope that you don't differ to the point of creating custom actions in your orders controller all the time, that kind of thing. They're laughing because that's my favorite question. So the question is where do you place these things, and I always ask that question because it's so nice when you open up app and you have like models and you have this and you have that. Wherever. You can put them in app services, app objects, app boring. I don't know, but just pick a thing. I've worked on a project before where we actually broke them down based on the types of things they were. If they were like a command object or if they were a query object, that's a common thing, like app queries. I'll see for like query for complex query objects. Just agree with your team what you wanna do and use a fuzzy finder like control p and vim to find the file anyway, and you're all set. Cool, anything else? All right, thanks everybody.


Presenting Argyle R. Mackey, commissioner of the Immigration and Naturalization Service, United States Department of Justice. Patient service of the United States Department of Justice was responsible for the detention and supervision of all civilian alien enemies. These aliens were detained in service facilities, maintained in the western part of the United States. Those who were married and whose families were dependent upon them for support presented a special problem. This was resolved by establishing a family facility at Crystal City, Texas, 110 miles southwest of San Antonio. It was important, of course, that normal living conditions prevailed, and to that end, those detained were expected to do most of the work in connection with the operation of the facility. The cooperation of the detainees for the most part was excellent, and the long and valuable experience gained through the years by the men and women of the Immigration and Naturalization Service in dealing with aliens of all nationalities made possible the efficient functioning of the program. The filming of the Crystal City facility, which you are about to see, shows how men, women and children, detainees of World War II, lived, worked and played under traditional American standards of decent and humane freedom. Here is a party of women and children arriving in Crystal City, following their voluntary decision to join husbands and fathers in detention. Practically all the children and many women were American-born. Incoming parties were greeted by a detainee welcoming committee and band music. New arrivals in their baggage were examined by inspectors and matrons. Money and valuables were placed in the facility safe and detainees given receipts. Following the admission procedure, they were fed in the central mess. They were then escorted to quarters, which had been assigned in advance of their arrival. The sun shines practically every day in the year with a cool breeze from the gulf in the evening. Originally it was a migratory labor camp of approximately 100 housing units, utility and recreation buildings. To provide for a population of 3,600, we added more than 500 housing units, school buildings, a hospital, administrative and maintenance buildings. We tripled the number of streets and extended electric and sewage facilities. This is the perimeter over which arm guards kept a 24-hour watch. At night the illumination from the lights along the top of this fence was visible almost to the Mexican border. Both groups cultivated flowers with great pride. Seeds were purchased by them with their own money. They also paid for and built the screen porch as you see. For such items, which were considered morale builders, they could draw on their personal funds. Each housing unit was furnished with running water, an ice box, beds and linen, chairs, and some with toilet facilities. Community showers and the trains were located throughout the area. People who had to be isolated for medical purposes were placed in cottages like this, which were equipped with modern conveniences. There were about 50 of these in the area. This is one of the community bath houses. This is the way the houses appeared before the detainees made homes out of them. There are the central administration buildings. One of the most important facility functions was internal security. This unit supervised repatriation movements, investigations, releases and paroles, allocated housing. Another important office was supply and procurement, which supervised the purchase and rationing of foodstuffs and other supplies, the general store, canteen, labor. Foodstuffs were checked into the supply warehouse and then rationed according to a formula based upon the normal needs and size of the family. Detainees were issued plastic money each month with which they could purchase these foodstuffs in the facility store. The system was economical and practical as it was based upon the dietary customs of each group. Here is the mail truck being checked in. Mail is closely tied in with morale and within the restrictions imposed for security purposes, few limitations were placed upon the number of letters which could be sent or received. Mail was delivered to the internal security office where it was examined by German, Spanish and Japanese sensors, the daily milk delivery. At one time there were 1600 minor children in detention. 2500 quarts of milk were required each day. Daily ice delivery, a very important matter in a climate which often reaches 120 degrees. Chores such as the delivery of milk and ice, police duty, the maintenance of good sanitation and hygiene were rotated. Every man had to take his turn. This is the 80-bed hospital which we built. Those are mesquite trees, familiar to all Texans you see around it. A Japanese gardener by profession was responsible for beautifying the grounds. There are the public health medical officer and head nurse. Ills were often imaginary, traceable to detention, the fence, the loss of freedom. As many as 60 patients were treated daily in the clinic, Japanese and German girls who were trained by the public health nurses as aides were faithful and dependable helpers. Young America, about 250 Americans were born in this hospital. This is the operating room. There were five detainee doctors in the facility, two of whom were Japanese women. This is the office's mess. The culinary staff was entirely Japanese. Many couldn't speak English and knew nothing of American cookery, so the dietician had quite a time at first. But you can see she really went out, while the food was excellent. These are school teachers, nurses, members of the administrative staff, and security officers who lived at the station or in the neighborhood. Crystal City is an extremely isolated spot and good food was good for morale. The farm was located outside the enclosed area. Here is a supervisor, a native Texan who taught the detainees how to employ scientific methods to the soil. The Germans did not like farming, so this work was performed by the Japanese, many of whom were successful west coast truck farmers before detention. Those are radishes. The Japanese boil and serve them as a vegetable. About 50% of the fresh vegetables used in the facility were produced on this farm. This is the machine shop. The Germans preferred this type of manual work and produced from wood, which we furnished, practically all of the beds, tables, chairs, and other articles of furniture used in the facility. The Germans did practically all of the repair work on the transport. Most of the equipment was pre-war and it required constant repair. Operating a laundry for approximately 4,000 people and the hospital is a big job.  Here is the sewing project. Generally speaking, the German women declined to work outside the home. So the Japanese women took over community projects such as this. They made sheets, pillows, mattresses, aprons, children's clothing, hospital uniforms. The Yets, which were a very scarce item during the war, were made from outing flannel. Here are some of them being cut. And here they are, ready for distribution to the hospital. There are a few samples of clothing from the sewing project. This is the tailor shop. Peruvian Japanese tailors made alterations and repairs for the detainees. For which we permitted them to charge a small fee. In the clothing store, we provided a very restricted variety of low-cost articles of essential clothing. Plastic camp money with which they could purchase these articles was issued to them in accordance with the size and needs of the family. Each family had an annual ration card which was punched as purchases were made. There were only a few looms available in the weaving project, but they were very popular. Another section of the farm. It pays to be safe, but inoculation always hurts. This was another of the facility projects which helped to keep down costs. Wrestling frequently was conducted with considerable ceremony and formality. As upon this occasion, Japanese would rather wrestle or watch wrestling than any other sport. Now we see the children also enjoying the past time. There is an 11th century sport, jousting minus the horses, which the Japanese enjoyed very much. Detainees exchanging the latest rumors and making calls. This is the German recreation center. There was a small cafe in this building called Waterland where they enjoyed music furnished by their own orchestra. The kindergarten was at one end of this building. Here are some children at play under the direction of a detainee teacher. Here is the American Grammar and High School, which was accredited by the Texas State Board of Education. Many graduates from this high school went on to college following their release from detention. The Japanese required their children to attend the American school in the morning and the Japanese school in the afternoon. There is the Japanese school. Directly in back of those children is the Japanese Recreation Center. Carefully selected movies were shown each week in the two recreation halls. This swimming pool was originally an irrigation tank for the farm. Seepage of water in the vicinity of the tank caused mud holes and unsanitary conditions. So it was necessary to wall it in with concrete. This was done by the detainees at a cost to the government of about $2,500. This tank was not only of vital importance to the farm for irrigation purposes and essential to hygiene and sanitation, but it helped greatly to relieve the monotony of detention for teenagers and adults. And as you see, it was particularly beneficial to the children.


In this video we will explore how the inert pair effect influences the type of bonding in group 14 elements. To be more specific we will see how inert pair effect favours the formation of ionic bonding in heavier elements like lead. Now we know that inert pair effect describes the reluctance or the inertness of the ns electrons to participate in bonding and this happens because of the poor shielding effect of the intervening d and f orbitals and it becomes more pronounced as we go down the group. That means it's going to be more significant for lead. Inert pair effect also describes why lead is more stable in the plus 2 oxidation state whereas all of the other group 14 elements are more stable in the group oxidation state which is plus 4. Now the question is do you think that the inert pair effect can play a role in dictating the type of bonding as well? Well indirectly may be yes because depending on the oxidation states we know we can predict the type of bonding right? For example all of the elements of the group 14 in the higher plus 4 oxidation state would prefer covalent bonding whereas the lead which is more stable in plus 2 oxidation state would prefer anic bonding. Now that would be correct because based on Fajans rule we know that lower valencies always prefer the formation of ionic bonds whereas higher valencies which in this case is plus 4 would prefer the formation of covalent bonds right? But suppose we didn't know about Fajans rule. Is there a way to substantiate this preference in bonding using the inert pair effect? Well that's what we're going to try in this video. Okay so to figure out the answer to this let's consider two elements of group 14. One is lead and one is carbon that is one in which inert pair effect is acting and carbon in which no such thing is going on. Alright so let's look at carbon first in detail. So you see carbon has four valence electrons in 2s and 2p orbitals. Now because it is small size of carbon and its high ionization enthalpy carbon will not want to give away all of these four electrons you know carbon will not form C4 plus ions it's extremely unstable and the ionization is required to form this is also extremely high so what does it do? It would rather prefer to share these four electrons. Now for that one of the 2s electrons will get excited or promoted to the empty 2p orbital and this gives us four unpaired electrons which can hybridize and combine with other unpaired electrons to form four covalent bonds. So here we have the example of methane CH4. Because the 2s and 2p orbitals are closed in energy it is easy to excite the 2s electron into the empty 2p orbital and notice that energy required for this promotion is more than compensated by the energy released when forming the two extra covalent bonds. Now can we do something similar in the case of lead you know excite the 6s electron and form covalent bonds like this? So pause the video here and think about it for a moment okay? Okay let's see. In heavier elements like lead the inert perifet comes into play so what happens here is that the valence 6s and 6p electrons get drawn closer towards the nucleus that is they experience greater effective nuclear charge due to the poor shielding effect of the F and D orbitals. Now this affects the valence s electrons more than the p electrons that is 6s experiences more nuclear charge so because of this the energy difference between 6s and 6p is larger than we would normally expect and it's definitely larger than the energy difference between the 2s and 2p orbitals of carbon. So that means promoting the 6s electron would require more energy and even if we somehow excite the 6s electron to the empty 6p orbital the resulting covalent bond formed does not release enough energy to compensate or may not compensate for the energy required for this promotion. Unlike in the case of carbon where the bonds formed are strong enough to encourage the promotion of the 2s electron. Now why are these bonds not as strong as the carbon bonds? Obviously look at the size right lead is a much bigger atom and as the atomic size increases atoms form longer and weaker bonds and this decreases their bond energy. Thus as carbon form stronger bonds than lead it is worth exciting or promoting this 2s electron to the 2p orbital as compared to exciting the 6s electron to the empty 6p orbital. So what happens is instead lead would rather let go of the 2p electrons easily and form pb 2 plus ions. Now this formation of pb 2 plus is also favored by the low ionization enthalpy.  Now because the s electrons would rather prefer to remain paired they are reluctant you know to participate in any kind of bonding be it ionic or covalent. Now remember folks this does not mean that lead forms only ionic compounds. No here we are simply talking about the role of inert pair effect in understanding why lead refers to form ionic bonds over covalent bonds. For example pb Cl4 is a covalent compound whereas pb Cl2 is considered to be predominantly ionic in nature. So here lead is in plus 4 oxidation state and here lead is in plus 2 oxidation state right and we know that because of inert pair effect lead is more stable in plus 2 oxidation state and because of that at room temperature pb Cl4 easily decomposes to form pb Cl2 and chlorine gas and in this process it acts as an oxidizing agent. So let's learn more about that in the next video.


to think Tech on Jay Fidel, which is the movies we can learn from series, where we review movies with the idea of trying to learn from them. And the title of this episode is, Why Do We Like Masters of the Air? I was just playing on Apple TV so much. It's a great air war series. And for this discussion we have, I'm not sure to say judge or captain. He's a retired judge, chief judge of Second Circuit, Jack Lear federal. He's also a Navy reserve captain. Welcome to the show, Jack Lear. Hi Jay, glad to be here. I thought of you while I watched this, you know, it was really a fabulous series. And I wonder if you could sort of introduce the depth and scope of the series to us so we can find out what we can learn from it. I'll be happy to. I have some notes here I can refer to. Masters of the Air is, one of the reasons I like it a lot is it's a true story. And it's based on a book written by a man named Donald Miller. I'm working my way through it right now. And it's just chock full of all kinds of information and history and background. But basically it's about the strategic air campaign by the United States Army Air Force conducted from England against Germany during World War II. And that was conducted by what was called the Eighth Air Force. There was a 15th Air Force, which was down in North Africa later in Italy, which attacked from the south. But the Eighth Air Force was located in England in East Anglia, which is in the northeast of northeast of London. And there were a whole bunch of bases there. And they were staffed by Americans who came from the United States. They flew over there in B-17s and also B-24s. Those were the first heavy bombers, I think maybe almost any place, but certainly in America. The heavy bombers, the first one was a B-17 and then the B-24 came along. And they were long range. At the time they were developed, people thought that fighters would be obsolete because they thought bombers were so fast and they had so many guns. B-17s had 10, 50 caliber machine guns on it. And the thinkers at the time thought that if they flew close enough that no fighter, any fighter who came close would get blown out of the air. Now then it didn't work out in real life. But and they go into that in the series. Now the series is nine episodes where the fifth episode is on Friday. So I watched the first four. Number three is the Regensburg raid, which I'll mention, which got some great flying in it. I saw an interview with the people who made it, including Tom Hanks. And he really emphasizes authenticity, is the way he puts it. And he did the Band of Brothers and he did the Pacific. So if you get a scent, if you like those, you're going to like this one. And anyway, the 8th Air Force got over to England on June 8, 1942, which was pretty soon after the Japanese attack Pearl Harbor. Just to give you some perspective, the Battle of Midway was on June 4, 1942. So these folks were over there very early on. Now they didn't have very many bombers at the time. That was a problem. And they weren't able to fly their first missions until June of 43. 43 was the worst period because they didn't have fighter cover that could take, could escort the bombers all the way to their targets in Belgium and France and Germany. They started out bombing the, excuse me, the U-boat pens along the French coast. And then they went further in. And the idea behind strategic bombing, this was developed by Billy Mitchell, the general in the 30s. You may remember the court marshal of Billy Mitchell. He was court marshal because he came up with this idea that battleships and these other war machines were going to be obsolete because the bombers would win wars. And that was his thesis. And there were other thinkers at the time that believed in that. And that was the reason we, you know, that idea sold. And so we invested in these bombers. We went to have very many of them at the start. And then we built thousands of them, B-24s and B-17s during the war. Once we cranked up the assembly lines and we, you know, used a good old American ingenuity. The idea of strategic bombing was to destroy the ability of the Germans to make war. There was two views on it. One was the British view, which was espoused by the head of the British, or the RAF bomber command. That was bomber Harris, a famous guy. And he believed, they tried flying during the daylight to bomb German targets, but they were shredded by the German fighters in the flak. So they switched over to night bombing. And they believed they couldn't, because they were inaccurate, they decided to bomb large metropolitan areas. And the idea was to kill the workers who worked in the factories and to destroy their housing so that there would be lots of refugees and basically terror bombing. The US view was we could use strategic bombing. We could bomb specific war-making industries. And the reason we could do that is because we had the Northern bomb site, which was a bomb site developed in America. And it was pretty good. It was very accurate when it was tested in the clear skies over Nevada in a non-mortem situation. The problem with it is, as it turned out, it wasn't very useful. It was useful, but it wasn't as accurate as people had hoped because of the bad weather in Europe. But nevertheless, our view was it was not moral to do area bombing when we could do specific bombing of ball bearing factories and fighter plane factories and tank factories and things like that. So that was the American view of strategic bombing. And we were going to do it in the daylight so we could use the Northern bomb site to accurately destroy those targets. So the British would bomb at night and the Americans would bomb during the day. And this is the story of those bombers in the 8th Air Force. Now, this particular group that's emphasized in the movie is called the Bloody Hundredth. It was a hundredth bombardment group, which was one of a number of them. And it was located at a place called Thorpe's Abbot. It was first mission June 25, 1943. It was referred to as the Bloody Hundredth. Not because it lost more than anybody else, but it had several missions that it went on where they had huge losses. And so it got that nickname. And I guess Airmen didn't want to be assigned to that particular group. Let's see. The story kind of evolves around two personalities. One is Captain John Egan. And another is Gail Cleveland called Buck, I guess is his nickname. Before I go further, one other factor which is really interesting. The 8th Air Force during World War II, all these bombers that are bombing Germany, which I've described, they lost 26,000 young men killed. That's 30% more than the United States Marine Corps lost in all of World War II, which is a pretty amazing figure. So that was it. It was effective, but it was very costly effort. And those were all young men 18, 19, 20, maybe 25, the oldest. One person whose name comes up in, I think it's episode five, who I want to describe as named Rosie Rosenthal became a pilot of the Hundredth. And he's a very interesting guy. You can see an interview of him on YouTube. He was a young man who went to law school just from an ordinary family in New York. And he was working as a young lawyer when Pearl Harbor was bombed. And he said he went right down and he signed up in the Air Corps, became a B-17 pilot. He arrived pretty early on over there. In those days, when they first arrived, the crews had to fly 25 missions in order to be sent home. And then they would do training and things like that. But the survival rate for 25 missions in 1943 was very low. In fact, it was like zero. Their casualties were that bad because they didn't have that fighter cover, which I mentioned. But Rosenthal, not only did he fly 25, he flew 25 more. He re-upped, and then he flew two more after that. So he flew a total of 52 missions from the time he went over there until the end of World War II. And at the end, he was trained to fly B-29s against Japan. And then he got out of the military. He went back to his law firm, but he didn't feel like he had sort of wrapped up his experience with the war or done enough. So he volunteered as a lawyer to go to the Nuremberg Tribunal that prosecuted all the Nazi war criminals. The main one is that he worked as a prosecutor on the Nuremberg War Tribunal. He met his wife on the boat over, and this had an interesting story about that. But he was quite a guy. And he's a very soft-spoken, unversusposing guy. A great interview. But anyway, that's the kind of person who was involved in this. And we can be proud of those people. Okay, that's about most of what I wrote down. Oh, a couple of the things. The B-17, they thought it would outrun the fighters, but actually it only cruised at 170 miles an hour, which is pretty slow. And in the beginning, the Spitfires would escort for a while, but they had to turn back. Then the P-47s could go a little further than P-38s. Finally, the Americans got the P-51 Mustangs. And those planes could fly all the way to Berlin with the bombers. And initially, they used them to protect the bombers, so they would stick with the bombers and fly over them back and forth. And then about halfway through, Jimmy Doolittle of the Doolittle Raiders, the guy who bombed Tokyo, he was made the commander. And he changed the approach. He said, fighters are there to destroy the Luftwaffe, because they wanted to destroy the German Air Force, the Luftwaffe before D-Day, because they wanted air superiority. So he said, go ahead of the bombers and strafe the airfields. And when the fighters come up, destroy as many as you can. And when you're on your way back, do the same thing. And that worked. Although the bomber boys kind of felt like they were bait sometimes to bring the fighters up. But it worked. It destroyed most of the German Air Force. So on D-Day, there was like two German fighter planes that came across the beaches. And that was it. So all of that air power actually worked. Although there are people who debate whether it was effective or not. But I don't see how you can conclude that it was not effective. It was super costly. But that's war. Any questions? One thing I noticed was that this was the first effort to actually attack the Germans in Germany in Europe. It was long before D-Day. It was long before we had any force into Europe. And it was the longest running game in the war.  One of the reasons Stalin was anxious for us to create a second front because he was losing millions of people on the Eastern Front. And we were able to demonstrate some effort through the use of the bomber force. The other thing that struck me is that these planes, the ones that did get back, and as you said, a lot of them never got back. And there were roughly 10 crew members for each plane. And they lost an enormous number of people because they lost an enormous number of crew members. And we hear stories about how some of them parachuted out. But a lot of them didn't parachute out. They went down with the aircraft and they were killed. Here's a factoid on that. A group, like the 100th bomb group, had about 48 planes depending upon the situation. During the war, they lost 229 planes. Through the maps, 10 per plane. And they would be hurt in all kinds of ways. I remember one scene where the gunner was in a pod that was breached by flak and it was open to the air. And they were flying at 25,000 feet and it's really cold at 25,000 feet. And he continued to shoot his gun, but he was sitting on a piece of steel which got cold. And we got back. He had frostbite in his rear, in his backside.  There's so many ways you could be killed. So many ways you could be injured. And I don't know if we've ever seen a movie or a series like this where you saw the way they operated within the plane. You saw the way they operated in the machine gun turrets. You saw them being exposed to all that flak. I haven't seen anything like that. I've seen a lot of war movies we all have, but not like that. And I thought, go ahead. Tom Hanks said that he was asked how many B-17s did you use in the movie? He said none. There are very few of them left in the world now. I think there are a few that go to air shows, but they built a couple of models that they said they could even taxi with. And then they built one for interiors that said they had to make it larger than the actual B-17 because it's so small in order to do the filming. And the other thing is, as you mentioned, it got very cold. And that's because the B-17s were not pressurized. We don't even think about that today. Can you imagine flying in a Boeing 737 at 25,000 or 30,000 feet and the windows are open? That's basically what they were doing. In the beginning, they didn't have electrified suits, which they got later, but apparently they were not very reliable. So frostbite was a big issue, which I hadn't known before. Yeah. What fascinated me, well, with two things. One is that we thought these planes either came back whole or didn't come back. But in fact, a lot of them came back in pieces. And you saw in this movie how the flak would tear away parts of the plane and they would live back with all the fuselage missing and all these control surfaces essentially destroyed. And somehow they would get back. And when they landed, it was up to the ground crew to patch it back up and to make it airworthy again. But some of those shots and some of those planes, with the skin torn off and pieces missing, that was new. They said you could take a screwdriver and punch it through the skin. But the B-17s had the reputation of being the most reliable, more reliable than the B-24s. I'm not sure what the truth was there, but the B-17s apparently were maybe over-engineers, since they were the first four-engine bomber. But they took tremendous beating. Their pictures of them flying back with half the tail missing, big chunks out of the wing. It's amazing. And what struck me, and I begin with the notion that Tom Hanks is a major patriot. I've seen interviews of him. And he cares deeply about this and the greatest generation. And so for Spielberg, remember Spielberg and Schindler's List and so many other movies, the two of them are great patriots. And they've made other movies like this. And what I would like to review with you is Greyhound, which is the story of an American destroyer, captain of whom, of which was Tom Hanks again. And this was a statement of the greatest generation. And these guys are trying to tell us something. They're trying to introduce us to the greatest generation. They're trying to let us see what the challenges were, the risks, and how these guys stood up in the face of lethal fire and lethal threats. And the Greyhound is another example of that. But in the case of Masters of the Sky, these guys, every time they went up, including that guy, Rosenthal, they were not very likely to come back. The probabilities, the risks were way against them. And a lot of them died. And so you wondered why they did that. Why didn't they run kicking and screaming back home? Why didn't they try hard to get out of the service when they knew that it was so dangerous? And while you watch the series, you have to examine that. You have to look at what really motivated these guys to stay there and do it day after day after day and see their buddies kill. And why was that? I mean, it's never answered except in the implication. But to me, they did it because of pure unadulterated patriotism. They were working for the free world. They were working for the country. They were working for families back home. They were, in fact, and you see them as the greatest generation. You agree, Shackley? Yeah, Rosenthal says that straight out, he just says he joined because what was going on was wrong and it had to be stopped. And I mean, he didn't know about the Holocaust at the time, but he just felt that the aggression that was going on and the destruction and the harm to humans was unacceptable. And he was willing to go on a state 52 missions. That's incredible. Took that risk.  The other thing I'll just mention that Miller brings down in his book, as he said, they would come back from these missions and they would lose maybe nine fortresses, 90 people, and they would go in and they wouldn't not have any funerals. They would just go in to the place that they were staying.  And that would be it. And then other people would come in and other planes and that's just the way it was. There was no recognition really of the people that were lost in a formal way. I didn't realize that. Oh, you're compared with an infantry experience where you lose your buddy. You're very close to your buddy.  And these guys all knew each other. They were in a circle community in those airfields and they knew all of the players. And when you lost another bomber crew, you felt it. And how do you handle that when you're losing dozens and dozens of dozens of them every single day? You can imagine the stress and you can imagine, you know, how they were burying their grief every day because they had to go out the next day. But I wanted to ask you some questions. So they went for the U-boat pens and they had a couple of tries on that. It didn't work the first time. They never made that mission. Do you remember one or two episodes? But later they got better at it. And every day, you would see the commander telling them where they were supposed to go, giving them a map and a red line about this is where we're going to fly and this is how we're going to come back and these are the obstacles and so forth. But there was one day, and Shackly, I must say that I did not understand what was going on. There was one day when he dropped the map down in front of them and he said, incidentally, this is different because you are going to fly to Africa. And it was a diversionary maneuver, I think. And the Nazis were going to chase you for a while and then you're going to be out of range and then you're going to go to Africa, which is a very long way for a flying fortress to go in those days. And it wasn't easy to get to Africa. What was going on? What was the strategy? Well, the plan was there were three groups, as I understand it. And the first group was the hundreds and they were going to go to Regensburg and then they were going to go on down to Africa and they were supposed to drive. At that point, at that time, we didn't have P-51 so there was lots of German fighters. And the fighters would come up and then when they'd get over the target, then there would be the anti-aircraft that they'd have to deal with. And then when they got through the anti-aircraft, then the fighters could come back. But there was two other groups that were supposed to go pretty quickly. And the idea was that it would spread the fighter defense thin because there would be a diversionary attack at the same time. So the Germans wouldn't know which one would be able to concentrate their effort. But what happened is the following two groups weren't able to take off on time because of weather. And so the hundreds was out there and all of the German fighters concentrated on them. And so they had huge losses and then they turned south instead of coming back to England just as well because they had to go through all those fighters again. And they flew over the Alps and all the way to North Africa. I don't know how many actually made it, but it's pretty dramatic in the episode four. It's a good episode to watch. Yeah, it was a failed strategy in the sense that the timing was bad. They were supposed to be out of harm's way, but they weren't. And they were right in the middle of it. Yeah. Another thing that comes up is the, when they would, they, in due little, I guess it was, no, it was Curtis LeMay who came up with this. Curtis LeMay who later became chief of the Air Force. Remember that? Yeah. And he's the guy who conducted the fire bombing in the Japanese cities with the B-29s later. But he used to go on the missions to see how it was running. And he, he changed their approach. Instead of each bomber using the northern bomb site to site the target themselves, he could see that they were getting, they're all over the place. So he said, no, we're going to have a lead bomber and lead bombardier and a lead navigator. You just follow him. And when you see the lead bomber drop their bombs, you drop your bombs. And also, he changed the procedure so that when they got close to the, to the target, about the time the fighters would, would, would leave and the plaque would start, the bombardier would take over the control of the airplane, I guess, through the northern bomb site. And they'd have to fly straight and level over the target to make the bombing effective, which made them super targets. And so the, the plaque ate them up, which were these 88 millimeter high velocity cannons that the Germans had, which were, were pretty amazing cannons. And they were all, they were, I guess, maybe not initially, but later on they were, they were radar directed. So the radar would direct the firing of the, of the, of the plaque. And I guess they could move, if the bombers moved a little bit, there was enough elapsed time from the time the cannon fired until the, the charge got up and exploded. And so there was possible to do a little bit of avoidance, but not much. I never understood why they flew in these very tight formations, because if they had all these gunners and all the turrets shooting at the fighters, wouldn't they be shooting at each other? You know, they've never explicitly, I haven't seen anything, anybody explicitly address that, but it seems like it's true because they flew in these box, they call them boxes for planes. And now the idea was to cover each other. But those, but if you, if you see how fast those fighters came through, I mean, you know, the, the speed fighters going 300 miles an hour and the bombers going 170 miles an hour. And the ability to sight and hit something must have been almost impossible. But the other thing that's interesting is that, you know, later on, I talked about this, but the Germans developed the ME-262, the first operational jet fighter. And that fighter eventually was used against the bombers. And it had four 30 millimeter cannons in the nose. Can you imagine what that would do to a, to a B-17? It's just incredible. And me standing for Messerschmitt. Right. Yeah. They were pretty advanced in their fighter engineering for sure. And, and yes, at the end of the war, they did have jets, didn't they? But that takes me to something I was going to ask you about. You know, this was all a, as you said, we, we had, we had to get our act together and, and we had to get our assembly lines working. But the, you know, the technology might have been over-engineered in some ways and other ways. It was all kind of experimental. And wars tend to improve technology. We learned from the technology experiences we've had in the wars. And after the war, the U.S. had jet fighters. And after the war, the U.S. developed an Air Force, perhaps under Curtis LeMay. You know, that was second to none. We understood air power. We understood air superiority. And we learned that here in, you know, in this movie. But it struck me that a lot of the gear that they were using was so different than what we had today. And it was, it was an engineering learning experience. The oxygen, you know, the windows, the turrets, the machine guns, all of that was like less than perfected. The skin of the plane, as you said, you could put a screwdriver through it. It was like the Model A for it. Easy to repair, kept on going. But it was old technology. And that's what we had here. And these guys were subjected to technology that would not necessarily protect them. They didn't have the kinds of things that our military aircraft have today. Not by far. They didn't have good radio communications. They didn't have systems. They didn't even have their communications between the members of the crew. That's so good. The control of the aircraft was not so good. So I think the movie brings that out, doesn't it? And you get the feeling that there was a lot of technology that we didn't have then. And now we take for granted. Well, just a few years before this happened, airplanes were made out of fabric, you know, and they had biplanes. I mean, that was only a few years before World War II started. And B-17 came into existence. I mean, a metal-skinned aircraft was very new in the 1930s. I think the spirit of St. Louis was metal-skinned. But it was one of the very first. And so, yeah, all these technologies are very new. Now we're going on to drones. You know, that's an interesting thing is, you know, instead of spending, what, $300 million on an F-35, I have a feeling that that era is going to end pretty soon. And we're going to be using something else. It's probably going to be drones of one sort or another. Yeah. And drones or missiles way cheaper than fighter planes can take out an aircraft carrier. I've seen a number of YouTube videos on that exact point. And so we have to figure out how to deal with those drones and relatively inexpensive missiles. And we haven't quite done that yet. So it's changing under us, you know, what's happening in the Middle East is teaching us so much about air superiority. It's different. In fact, ocean superiority. You could have an attack on a multi-trillion dollar aircraft carrier, and you wouldn't necessarily be able to stop it. We do not rule the seas in the way we used to, especially with the Chinese who have developed the Navy that has more ships than we do. So, you know, it's that whole thing about you have to keep your eye on the ball. And I really wonder, Shackley, maybe not in the course of the time span covered by masters of the sky. But during the war, there had to be somebody back home working on new technology and improving the, what'd you say, the B-17, maybe into the B-24, maybe into the B-29. We were changing the technology. We were learning from every experience to make it better. Isn't that why they had multiple models? Yeah. Well, the B-29 came along very shortly after that, and it had remotely controlled gun turrets. Somebody could sit inside and direct all the guns, all the 50-caliber guns at one time, and it was pressurized. So they didn't have to worry about the cold, and they could fly it in a B-29. It could fly over 30,000 feet. It wasn't effective at that height than over Japan, apparently, but the other. And I think that it was actually more expensive program or second to the atomic bomb program. It was a huge program because they knew that they needed, that the B-17s and the B-24s weren't going to do it, that they would have to have the long range of bombers, at least in the beginning, to defeat Japan. Although Curtis LeMay's idea was didn't need to drop the atomic bombs because at the end of the air war in Europe, he would bring all those bombers from Europe over to the Pacific and use them to bomb Japan. And he thought he could end the war that way, but would have been less destructive? I don't know. Well, you know, I don't remember, but my sense of it is that the Japanese did not specialize in bombers. They had fighter planes, but they didn't necessarily have bombers. So we probably had an advantage over them. Yeah, the Japanese and the Germans and the Russians never developed strategic bombers. The British and the Americans did, and the British built pretty good ones, the one they called, I forgot the name of it, but it had force fit by our engines in it, so it carried a lot of bombs. It was very, very effective. So the whole thing here is, aside from the fact that it's a statement of patriotism, the special patriotism of the greatest generation, which touched me deeply, and I'm sure which Spielberg and Tom Hanks had in mind. Aside from that, technology wins war, and you have to be quick. You have to learn from every technology and make it better. And air superiority, which certainly has changed from those days till now, is still in place, but the equipment in the air is different. I'm not sure how I feel about the Navy and the oceans. There's probably a lot of changes in technology there too, and we should explore that with the Greyhound movie. But all in all, what do you take away from this? What do you take away from this series? Why was it so good for you? Well, I forget. Victor Davis Hansen, I think, says that once a democracy is aroused, it's unbeatable because of the dynamics that's inherent in the culture and the economic system. And I think that World War II proved that. I mean, we were building a B-24 bomber every day or every hour. It was just amazing. Thousands of them were being built, and we were training hundreds and thousands of pilots. That's one of the things that the Germans and the Japanese, is they couldn't train new pilots. They didn't have the oil eventually. They just didn't have the system to do it, whereas we put it in place very fast. I mean, there wasn't eight there, of course, in 1941. They created it. And then suddenly, at the end of the war, they were sending out 1,000 bombers to bomb Germany and 1,000 fighters to escort them. I mean, incredible. Well, I think you've touched on a very important point. The whole country came together to do this. It was Rosie de Riveter and thousands and tens of thousands just like her. And it was a national community that got behind this. And everyone was in favor of that kind of response. You want to arouse a democracy. We are the democracy, and we are aroused. And I also, now go ahead. I was going to say England did the same thing. I mean, even England turned out a huge number of bombers and fighters, and they didn't have the numbers, the people that we had. But they mobilized their entire society. It's interesting that Germans, Hitler never mobilized women into the military. There were some nurses and some auxiliaries, I guess, but he never mobilized them like Rosie de Riveter, like you were saying. And I don't think the Japanese did either, whereas we did. And the British certainly did. Yeah. That was different. It was different. You know, levels of misogyny come to mind, cultural misogyny, if you will. The other thing is, this movie does, of course, show you how they lived. And one of the reviews I saw in the movies, it made clear that slogging in the mud was not nearly as good as being a pilot, a bomber pilot. Chances of survival were actually better in the infantry, but your quality of life wasn't so good.  And the base was filled with English people who were helping, right down to the children, helping them and standing by and caring about them, right down to the dogs in that town and that community. And so, again, as you said, the British really supported this effort. Of course, they were, as a country, they were at greater risk than we were, so they really cared because you had those bus bombs going into London at the same time, so forth. Go ahead. I'll tell you a funny story about the relationship between the British and the Americans during the war. My former father-in-law was a British Army officer, he was in the Signals, and he landed on D-Day plus three and then was with the British Army all the way through into Germany. And he said the only time he was really scared was a drunken GI, stuck a 45 pistol in his face and wanted something from him. Well, you know, they did cover that point in one scene, I recall, where there was this not-so-friendly, friendly competition between the American pilots and the British pilots, and you thought it was going to be a real slugfest, but it wasn't because at the end of the day, they cared about each other and they were on the same team. But, you know, we've seen and heard about that for a long time about how there was this rivalry going on. It was a small point in the movie, but it was something that covered, and that leaves me to say that the whole interaction between the pilots and the local community and the British Air Force was in there, it was in the movie, it was handled. And so, you know, somebody who wrote this up did a lot of research, Spielberg and his friends, or Tom Hanks and his friends, they looked at every single detail. And for that, it made the movie special, it made the movie beyond any movie you've seen about this part of the war. Do you agree? Yes, and I recommend the book as well. The book is a very good read, easy read, and it has lots of great detail in it. He blends this whole story together really nicely. Yeah, but the book isn't entirely true, right? Yeah, parts of it are true, parts of it are true, but not all of it. Well, I think it's mostly true, as far as I can see. Yeah. A lot of history in the background, the kind of stuff I was talking about earlier, I got all that from the book mostly. I think you're right, the book was largely true. The movie took liberties. Yes. Yeah. Which is just movie making, you know? You mentioned before, I began to show that there was an issue about the coloration, the color correction in the movie. What was your thought about that? It seems too colored, I guess is the way I put it. The color seemed to, I don't know, too dense, I guess would be the way I put it. The color, looking at you right now, the color is perfect, but if you look at that movie, the coloration is different than what you see right now. You don't think it was intentional? Oh, I think it was intentional. I think it creates a kind of mood, but it's definitely not like a video where it's really sharp. And I thought, well, maybe it has to do with the fact that they use a lot of CGI for the flying scenes or something. I don't know. It's worth saying. It's just like this reminds me of the movie Golda. And the movie Golda, they had all these battle scenes, but the movie didn't create the battle scenes. They got them out of an archive. And the same thing here, I think CGI or maybe an archive or even animation helped them tell the story. And as you say, they had mock-ups of the planes. And it wasn't actually taken in the air. Well, if you look at the Pacific or Band of Brothers, it's a different coloration. So all in all, wrapping around everything that you've seen, I don't think I've seen as many episodes as you have. What rating would you give this is against your own knowledge of the subject, your own experience in the service? And ultimately, your historical impressions and movie making? How would you give this on a scale of one to ten? I give it a ten. I don't think you could do it much better. My thing about the color is just kind of nitpicking. The story itself, I think, is real. And they've done a great job of creating the mood and picking up what it must have been like to do that. And that's important. I think if you liked this, it would be worth watching 12 o'clock high with Gregory Peck, which is a version of this, which used real B-17s because it was long ago. And Jimmy Stewart? Wasn't Jimmy Stewart in the Air Force? I think he was. He was a general in the Air Force. He flew 25 missions in B-24s in World War II. And he made movies about it later, and that was with real planes also. I'll tell you my reaction, and I'll tell you why. I would also give it a 10 or better, but why? It's purely political for me. What I mean is, we talk about how the youngest generation, generation that are now coming to voting age and so forth, and we'll control the ballot box in the years to come, that they don't know about civics. And perhaps more importantly, they don't know about American history. It isn't taught. And they haven't read the books we talk about. They haven't seen the movies we talk about. They haven't ideated over the guys who were in the greatest generation who were there flying in the masters of the sky, or the Navy, or the infantry. They weren't there. They don't understand. They don't understand that the government is an extension of us. We are the government. We are the military. And the military and the government is us. It's all together. And I think the average education around the country doesn't allow for that. It doesn't investigate that. So anybody who makes a movie like this, especially a very watchable, thrilling, dramatic movie and also factual, you know, is doing a great service to the country and that generation by making people aware of what it was like then. And I felt a sense of patriotism throughout the whole movie. That's what I loved about it. And I want everyone to know. Absolutely. I totally agree. It's an excellent movie. And it just brings back to you how horrible war is. I mean, millions of people. How many people died in World War II? 50 million, 60 million? Incredible. And the thing is, it reminds me that there has to be deterrence or this sort of thing just gets repeated. And it's been repeated in other places in the world a number of times since this time. And we don't seem to, perhaps by seeing movies like this, we'll remember that and we'll think about it. Yeah, but to flip side, just a touch on it is that these guys among other motivations were motivated by the atrocities. They didn't know about the camps. I agree. But they knew the Nazis were doing atrocities. And they knew there was a good side and a bad side to this war. And they were on the good side. And that motivated them to deal with the problem. And so the other side of it, and then we could spend another show doing in a domination of this, is that although war is terrible, sometimes it's necessary. And every one of those guys in those airplanes were committed because they felt it was necessary to achieve the right goal. And it's hard to deal with, especially now, with what's going on in the Middle East. But I think you could make a case for the fact that when somebody, a nation state, goes rogue, there may be no other way to stop. Yeah, well, I feel the same way about Russia attacking Ukraine. I mean, what's the difference between that and Hitler going into the Sudeten land and Czechoslovakia? And that that history. Amen. I totally agree. Well, thank you, Shackly. Captain Judge Shackly-Refetto joining us for a discussion of this great series on Netflix. Thank you so much, Shackly. Take care, J. I'll talk to you soon. Bye.