Hey, everyone. Welcome to Developer Team. My name is Jonathan Cottrell. And in today's episode, I interview Tony Hillerson. Tony is a developer at MapQuest. Tony also wrote seven mobile apps in seven weeks. The book details the process of Tony building seven different mobile apps with seven different frameworks. We talk all about that process in today's episode. Today's episode is sponsored by Rollbar. With Rollbar, you can detect, diagnose, and defeat errors. We'll talk more about what Rollbar has to offer Developer Team listeners later on in today's episode. While you're listening to today's episode, make sure you tweet at Tony Hillerson. That's T Hillerson, T-H-I-L-L-E-R-S-O-N, and let him know how much you appreciate him being on Developer Team. Let's get into the interview. Let's get into the interview with Tony Hillerson. Welcome to the show, Tony. Hey, thanks for having me. This is going to be fun. I'm looking forward to it. I'm really, really interested to talk to you because you are the author of one of my favorite concepts of books, specifically the 7 in 7 series. First, I want you to talk about what inspired you to write the book. So this book, this particular instance, or in the series, the 7 in 7 series is called 7 Mobile Apps in 7 Weeks. And I'm right there with you. I would have never expected to be one of the authors of one of the 7 in 7 books because it's really a, it's the perfect concept, I think, for that type of medium. It's the idea of polyglot, a polyglot program, polyglot programmer. And the format of diving deep into a couple different features over three days is kind of, for anybody who's not familiar with the series, three days spent diving deep into the features of a language or database platform, or in this case, a mobile platform like iOS, Android, React Native. And then seven of those stacked up really lets you do a comparison, of the different technologies involved. And also work at your own pace. And then also have a springboard to go forward and continue on with your investigations after that. So I guess the question was, where did I get the concept from? I think I was already primed to like to see the world and through that lens when thinking about developing, developing a platform. At the same time, bringing together evolution and evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution Also clients wanting to cut down on cost, they thought, by using a cross-platform technology instead. What are the trade-offs there? That experience just kind of, I just wish there was a book for this kind of thing so many times that I finally just kind of wrote it. Yeah, it's like the best kinds of startups are the ones that are created for people who need them themselves. Yeah, exactly. You wrote the book for yourself. You find an itch and you scratch it. Yeah, exactly. It's the same reason I created Developer Tea. So I totally understand that motivation. So we're going to talk about the book more in depth, but let's talk about the concept of the 7 in 7 series. How does it work? How does somebody follow along with the 7 in 7 and get the most out of it? So there's probably different approaches to following along because it's a bit flexible. But the idea is this. You have seven technologies in a search. And you have a certain, I guess, technological theme. For instance, the first book was called 7 Languages in 7 Weeks. And that really sort of broke out in the market. And everybody kind of said, yeah, that's a great idea. And I think that's inspired other people to try to put things into the series. For instance, myself. The idea is you take seven technologies, languages, database technologies, mobile technologies. And you... Say you're going to focus for a week on this technology. And then you're going to move on to the next technology. You know, at whatever pace you'd like. You can cram it into seven weeks total. Or you can spread it out however your schedule dictates. But the week is broken into three days. So it's actually three days instead of seven days in a week. To give you time to do a little bit more of self-study, I think. So you start... You start out generally... You're not taken through... Like, here's how to set the thing up. You're expected to do that as kind of a prerequisite. But you start out investigating some features. And playing around with it a little bit. Whatever makes sense for the type of technology you're dealing with. And then that day finishes out. You've accomplished a few things over the day. And then you are presented with a set of... Like, try these things on your own. Here's some documentation. Here's some information to look into. Here is a couple different challenging steps that you might take as next steps. Of varying levels of challenge. And then you can go on to the next day after that. Yeah. And so I'm looking through the book. And Tony was kind enough to send me kind of an advanced copy here. The pre-edit copy. Which, by the way, it doesn't seem all that pre-edited. Like, it doesn't seem like it hasn't been edited yet. It's very good. It's very close. From what I can tell. But so this is going to be a fantastic book. I'm looking at the different platforms that you're using. And the structure. So I'm going to give something away. Assuming it's okay to give this away. Go for it. So part one, or I guess part zero, day zero, is setting up the API. And this is something that I absolutely love about the way this book is structured. The book is structured to have an API that already takes care of... A lot of the... We'll call it the data and business logic side of things. Okay? So imagine that you already have an application running. A data application. And then you're trying to build a mobile app on top of that. And the reason why I love this is because it doesn't just give you, like, the intro level Hello World kind of stuff for those different native platforms. Instead, it actually shows you how to connect to an API. Which is the stuff that we're actually doing. Right? And so for a lot of beginner tutorials in these different areas, you're going to see applications that are really just the intro level. But with this kind of setup, when you have an API already available to you with various functionality... Really cool, by the way. The little API that you built for this, Tony. But when you have that setup, you can start learning more and deeper functionality that you're... Probably going to actually use in the real world much, much earlier. And so I really like that because it gives you more of an in-depth picture of these seven different platforms on day one. Yeah, you got it. I'm really glad I didn't have to prompt you to say that. That's exactly my thoughts, too. I didn't... So right-sizing the project that we go through for each technology over the week was tough. It was tough to think about without some pre-work done. And I wanted to make it that much more than a toy app without getting into too complex a functionality. And then, obviously, in the time that you have allotted in each week, there's no way to go and say, okay, for this first day, we're going to jump into Rails or something and then build an API so that we actually have something to hit. So I just decided I'm going to do that first. And exactly like you said, that gives us the opportunity to not only play around with code on the client, like we're going to build some views and we're going to see how view hierarchies work and navigation work on these platforms, but we're also going to make some web requests because everybody's got to do that. So I wanted to go through, you know, here are some points that I want to hit on every platform. What is your day going to look like when you're out and developing in this technology afterwards? You're going to have to... You're going to have to pull down data from the web and you're going to have to transform it from JSON into native objects and you're going to have to figure out the right way to pull that down and accomplish all of that and then put it on a screen. So that's kind of... That activity is going to take place on each of the seven platforms. That's so key. I feel like this is something that is underserved in the tutorials and really sometimes even in the platform itself, say for a few days, you're going to have to pull down data from the web. You're going to have to pull down data from the web. You're going to have to pull down data from the web. You're going to have to pull down data from a few of these platforms. The JSON, like pulling down JSON data, doing something with it. I feel like that is the new hello world standard, right? So I really appreciate that you actually built that in as kind of the... This is what we do on day one to learn about this thing. And maybe you want to learn about text output, but really, I mean, you can do a text output thing in about 20 minutes with pretty much any of these things. So I really like that a lot. And not just for 7 and 7, but if you are listening to this episode and you're wanting to learn a language, for example, I would recommend that you have some kind of... A good example of this is the JavaScript MVC, the to-do apps. The MVC to-do or whatever it is that it's called. I can't remember exactly what it's called. I'll include it in the show notes to make sure I get the name right. But the idea is to... Perform these functions and show them in these different platforms and perform the same functional requirements in each scenario. So it goes beyond just how do I get standard output from this thing or how do I write to a web page? How do I do a web request? It goes a little bit further. How do I do a web request and then turn around and do something with that data and then in response do another web request? So it's really interesting to see that. As the setup for learning, I would say it's a good template for learning this stuff. You don't have to just learn about the stuff that Tony has written about in this book in this particular manner. Set this up as a way of learning for yourself and see how it works. Yeah, I think so. And I think those day-to-day problems that you have to solve might vary a bit from... I'm just pulling data out of a database and putting it onto... I'm just pulling data out of a database and putting it onto a database and putting it onto a database or I have to solve some more computer science types problems in my day-to-day job. But there's some core set of those things that you're going to have to do no matter what language it is. You might ask around, I guess. I think that's a good way to come up with that list. What should I do when I'm kicking the tires? Not just write hello world, but what should I do that I'm going to have to do with this technology in my day-to-day job? Am I going to have to... Am I going to have to mangle text? What does it look like to do regex in this technology? What does it look like to make a web request like we've been talking about? Get a list of those things and keep them handy for when you try out a new technology. Yeah, I mean, this is why I recommend going and actually building a project with something when you're trying to learn it. Build very small things with this stuff, but build something that's actually functional, that has a suite of features. So then you can see how... Let's say you have multiple classes, for example, or multiple models in your app or whatever it is. But you don't need an entire structure. You need a few things that interact with each other. You need a few features that impact other features so you can see what is the structure of this code. And then that gives you an idea of what it looks like to continue building features on top of that. Have more than one view, for example. That's a really simple rule of thumb. If you're trying something else, that's like a framework, for example, you need to have more than one view to see what it means to create multiple views in that particular framework. Yep, exactly. And think about separation of concerns, like following an MVC pattern or something like that, instead of where you might end up in a tutorial program, like let's just shove it all in the view controller type thing. And then you're going to get an idea of what the language is like. That's fine. But where is that going to break down? And obviously, that's not going to scale. What are you going to do next? What do people do to solve these kind of problems? Are there patterns out there you can look for and then stretch it a little bit? This is probably one of those problems that's very persistent amongst people who are reading kind of beginner tutorials for MVC frameworks. For example, let's say you use Sinatra, which is not necessarily an MVC framework, but it's a Ruby kind of a micro framework, right? If you read most Sinatra tutorials, they only show that app.rb file. And I've seen a lot of Sinatra apps that are literally just one super long file. And I think the problem is people are missing the point if they do that. And people end up actually doing the wrong thing if they are just looking at that simple tutorial about how to get started. There's that secondary scale, right? Where most applications, most applications, live one scale level up. Now, you don't need to be looking towards scaling to a million users on day 10. That's silly. But you do need to be looking to scaling your code base to make it manageable. And that's really what that level of scale is about, is what you said, Tony, the separation of concerns. You know, a lot of people don't think about that until they're starting to get into that situation where they're trying to scale for the users. And the problem is, you can't respond fast enough if your code is a mess. Yeah, you've got to think about, you know, you know your way around the code base, but what happens when two other people get on here? How are you going to split up the work? How can you have multiple streams of work? Adding features to this, it's, you know, obvious. Obviously, it's going to break if there's just one file. What, what, what, what's next beyond just like, you know, I don't know if you remember, I think it was XKC, they had some, it was a, it was a cartoon. Okay, I want to explain XKCD. I'll assume people know XKCD. But he talked about like writing a program that looked up the answer on Stack Overflow and implemented it as, as like the, the development environment. Like, I want to do this. It looks up on Stack Overflow, influence the code from Stack Overflow, and then you've got what you need. I think it was Stack Overflow influenced or Stack Overflow driven development. Yes, yes, that's the one. Yeah, I mean, when you get something off the web and it took you two seconds to find it or go through the tutorial, you should value it at that rate. You know, you've got to, you've got to go a little bit further. It might be a specific answer that you need to interpret and use your skills as a developer to go beyond, you know, just that quick and easy answer. And Tony, I'll even go one step further. You mentioned that, that, you know, you have to worry about other people coming in that don't know your code base. Well, a similar problem is if you're like me, you work in an agency environment and you switch to a different code base for a period of time and then you return to your own code base and it's like a stranger wrote it, right? What, who wrote this? This is, oh, it's me. It was me. You go to the git blame if you're trying to figure it out. And the problem is, you know, if you haven't documented that code or if you haven't in some way followed, uh, some kind of convention or pattern or something, uh, you're going to be just as lost as an external dev would, would be. So, um, you know, it's really important to think about that stuff, especially if you're working with multiple people and especially if you're working on multiple projects. Yep. And that's part of, that's part of kicking the tires on a new technology. How do I think about organizing? How, how, how would they like me to think about organizing this? How would the creators, or if they have, they, they've given me nothing and do I, am I going to need to apply some reasonable set? So that's, that's one thing I found with, um, I've always played around with the web, web technologies, but never too far onto the, the, the view side in that's, that's been more on the, on, on, on side projects and things like that. So never like production level. So every, you know, everything I've done there has been small and, and easy to say, well, that's okay. I don't need to go too far. And that, but I, I really, it really came through to me, um, doing the web chapter, the mobile web chapter for this book. Um, how there's nobody or there's, there's either nobody to tell you, um, what to do. And you've got to figure it out by yourself because the platform and the technology and the tool don't really, um, give you a good structure for organizing your product or your project. Sorry. Um, and, or there's like a million voices. Just telling you what to do. So you've got to, because everybody's got an opinion on it because there's not really a strong way as opposed to like a Java project. It's going to end up looking like this. If you pick Gradle or something like that. Yeah. You have to, that's one of the things you've got to think about. Um, and, uh, you know, web, you've got to go find out what are people think about organizing or using NPM? What, what sort of, uh, structure that does that sort of impose on my code? Is there a structure that people like to use? Um, are people going to be familiar with this? With this? If I pick a structure and they come in on the project, uh, or are they going to be confused and argue with me about how it's organized or something like that? Yeah, absolutely. I, so, uh, something interesting about what you're saying, and there's probably a developer who's listening right now who says, uh, well, but I don't really, you know, I want to be creative with the way that I, that I code, right? Like, you know, the whole code is poetry idea. That's fine. Um, if that's what you want to do with your code. Uh, but here's the thing. You can be expressive in your code and still have a conventional structure, right? You can be, uh, expressive and maybe even clever sometimes with your code and still have a conventional structure. Don't try to express yourself through, you know, some, some crazy off the wall structure in your code that you came up with over the weekend. It's probably going to end poorly. For you. Um, I know that sounds really strongly opinionated and there's not a lot of times where on the show I'm going to be strongly opinionated, but you're not the only one that's going to write for this particular application if it's successful. So if you care about the success of the application, then write it for all of the people who are going to be working on it, not just for yourself. You can go and express yourself on code pin or you can go and express yourself, you know, on a side project that is entirely meant for, um, the sake of, um, the sake of exploration. But don't go and screw up everybody else's day by, by being creative with the structure of your code. It's not going to be worth it in the long run. You can actually be expressive in the code itself. Uh, and I think you'll find over time that you'll be much happier with code that is not simply expressive, but is also readable by other people that other people appreciate because you're going to be able to do more and do more quickly, um, with code that is simple and not complex. Clever, but instead much easier to extend. Extensible is the idea here. Yeah. Yeah. I mean, creativity always has to happen within a framework that there's constraints, help creativity, and you don't want to be creative with the, with conventions, like conventions that everybody's going to subscribe to, like try to find the conventions, stick with them, be creative with, with the problem solving. Exactly. Yeah. I think, uh, that, that is a pervasive issue. Uh, that, uh, if you figure that out now, it's going to help you in your career in the long run. And this show is primarily targeted towards people who are, who are coding for a career, not for fun and, uh, also coding because they enjoy it. Okay. So if you want to keep the career side of that equation, uh, you have to think about other people. You have to code that in, in such a way that you're thinking about other people. So I keep that in mind as you go forward. I think, yeah, you're not, uh, um, it's not bad to go and see what is everybody else doing when it comes to something like when it comes to something that everybody's going to be doing, like organize, adding to the, adding to the code base follows an organization. I want to know what everybody's doing or the majority of the market or the majority of people are doing so that they're going to feel comfortable in the code base because I want to grow the business and hire people and, and be able to scale the code base, you know? Exactly. Well, and you, you gain economies of scale here. So really simple example, don't rename your package JSON to something special for your company, right? Like, uh, that this is a, a very simple example, dumbed down as far as possible because it's something that I was tempted to do when I was younger. I wanted to say, Oh, this isn't just a normal package JSON. This is my NPM package JSON for this particular type of project. And I'm going to reconfigure and add my own stuff in here and then, you know, hack around and make things my own. And that's, that's not going to give you the economies of scale. Like for example, if you upload it to GitHub and it has a package JSON in it, it's possible that GitHub will link you directly to that package. If it knows that it's a package dot JSON file. If you're not familiar with what I'm talking about, I'll leave a link in the show notes that shows you about, uh, uh, NPM's package. Uh, package model and how NPM handles, uh, dependencies. But you know, that's the kind of thing that isn't really, you're not really gaining a lot of expressive value out of simply renaming a file or a folder. Today's episode is sponsored by roll bar with roll bar. You get the context insights and control you need to find and fix bugs faster. You know, dealing with errors sucks. We've mentioned this on the show before. Of course, roll bar has been, uh, sponsored for a while now, but this is so true. Dealing with errors, digging through logs, trying to figure out what's going wrong, especially if you have bad exception handling in your app. Uh, all of that is very difficult to do. And roll bar fixes this problem for you. Roll bar works with all major languages and frameworks, and you can start tracking production errors and deployments in eight minutes or less. So for example, if you push out a new, uh, version of your software, you can get an alert in slack or you can get it in hip chat, or you can create issues when you have an exception in your application in GitHub or Jira or Asana, all these places that you're already used to using roll bar integrates with those. Some of roll bars, the customers include her Roku Twilio kayak, Instacart, Zen desk, Twitch, and me at whiteboard. So go and check out roll bar. Roll bar has a special offer for you, by the way, and you can get a free copy of the app. You can get 90 days for free. That's 300,000 errors, tracked 90 days for free. It's called the bootstrap plan. Go and check it out. Roll bar.com slash developer T and get a handle on your errors today. That's roll bar.com slash developer T. Thanks again to roll bar for sponsoring developer T. Uh, let's switch gears here. I want to talk to you about, uh, the different platforms that you actually used in the book. And then, uh, maybe about the, the different apps that you used here. First of all, the API was built on rails and Tony, did you build that API? Yes. Uh, it's, I, I'm familiar with rails. It just seemed like the easiest thing. I, I, I didn't expect people to have to get in there and change anything. So I didn't make it to, uh, I didn't agonize too much about that choice, uh, because I don't expect people to have to, uh, change it at all. Although it's completely available and you can play around, as much as you'd like in there. Yeah. It may actually end up being a good jumping off point for people who are creating APIs. Yeah. I hope they don't look at it too closely. I, I, I solved the, I solved the problem of, of giving myself something to call from the web basically. But sure. I, let's see, I think there's a weather endpoint and there that provides weather through Yahoo API. And, and a couple of them are Yahoo APIs. Then a, a financial endpoint, uh, that returns data. There's a, yep. Uh, uh, I don't have to iterate them all, but yeah, I think they might be, there's probably something interesting to find in there. Sure. Yeah, absolutely. And, uh, so, so that first API is set up with rails and then you go on to the seven different platforms and I'm just going to list them all and then we'll go back and talk about the different apps that you build. Um, but the first one is probably the most interesting decision and I think a really important, important statement that you're making here and that is the mobile web. Uh, and, and you built a, a world clock app with the mobile web and then you went on to iOS and chapter three, uh, or I guess it's chapter three, part one, chapter three, and then Android is next. Universal windows platform is next. And you do Ruby motion and Xamarin and finally react native. And that is a wide gamut of, of choices. And, uh, I'm, I'm really, really excited to read through this because, uh, I'm, I'm interested in each of these for different reasons and for different projects. Um, so, so can you give me just a general sense of, of the lay of the land of these different platforms and, uh, you know, what your experience was going through each of these? Yeah. So, uh, when I first kind of had the idea for this book, it was a while ago, a few years ago, I talked about this with the series editor, um, whose name is Bruce Tate, Bruce Tate. He was one of the authors of the original seven, uh, languages in seven weeks. Um, and he felt really strongly that web should be one of the, the, the ones that we cover. Uh, and I didn't know how I felt about that at first, but I think it is a good decision. And here's why I think, um, no matter if you choose to have an app experience for whatever your product is, you should have a good mobile experience. On your website. So that's, that's kind of the message there. And, um, my experience there was, um, it was a lot of fun to get into the responsive design, which I, I had, you know, sort of known about and played with on the, the, on the, the edges of projects where I'd been involved, but not, uh, too much on the, on the view side. Um, so the responsive stuff, and then also what I tried to do was make it, uh, the project, which is, uh, like you mentioned, it's a world clock. Uh, so it's, it's just like a list of basically you, you, you store a list of time zones in the local storage. And those are the time zones, um, uh, turn into clocks on, on the UI. Like I tell you what time it is and whatever that, that, that, uh, time zone was. Um, I tried to make that app as native as possible or much like a native app as, as possible. So there's the, the, the, the favorite icon. I show how that turns into, um, an app looking type thing when you save it to the desktop on Android or iOS and how you can use the, uh, the app manifest to store everything offline so that if you're not connected, it's still, it has access to the local data that you've stored and all the assets are, and, and, and library JavaScript, uh, dependencies are downloaded and available offline. So, um, that, that's, that's kind of the, the, the direction of the app. It's, it's testing how far can we get this towards a, a native app like experience. And yet it's mobile web. That's kind of like a, how to build a modern website, right? Like, yes. Yeah. And that's, that was the other interest or the more, I guess a more, um, uh, succinct description of what was interesting to me about the responsive design. It's the mobile first design. So instead of in the, in the style sheet, uh, um, which I'm, I'm bad at, I'm horrible at that's the stuff. Cause anything it gets, as it gets more visual, I, I get more confused. Um, but, but it's an interesting way to think about it. You apply styles such that it works correctly from mobile and then remove those as the, the capabilities of the, whatever you're running on, um, allow them to, instead of going the other direction. So you don't, you don't make the CSS, uh, work correctly on the desktop and then start, uh, adding things as the screen gets smaller, you work the other direction. And that, that was an interesting little exercise for me to learn about that. Yeah. Yeah. I think, uh, so the, the concept there, if, if whoever is listening to this is unfamiliar with that, uh, the idea here is, is called progressive enhancement and it's where we get that concept of mobile first. Um, the hope is that anyone who visits the site, uh, the website can view it on whatever device they, they're on. So you may have someone viewing it on a very old iPhone or Android, right? Um, or you could have someone viewing it on an iPad pro, or you could have it, have someone viewing it on a small, but relatively capable laptop or a massive desktop computer, right? And there's different capabilities and, uh, screen resolutions that come with each of those, obviously different screen sizes and, uh, there's readability concerns, and there's a whole host of interesting things to think about when it comes to building for, um, basically every device with one code base. Uh, so I'll, I'll leave a couple of links in the show notes to talk a little bit more about progressive enhancement. That's not really what today's show is about, but it certainly is relevant, especially since Tony, you covered this, this idea in a book about native applications. And I love this concept of reframing, uh, reframing the web as a native platform. I think that's, I think that's totally true. Yeah. I, I, I thought about how to organize, by the way, the top level organization, uh, is I, I did the native platforms as I called them first, and then our platform native is, as I called them, I had to come up with a word and then platform. So web is native platform. And I, I kind of did a little bit of mental, little gymnastics there and, and looked at it from a different perspective and thought, you know, the web is pretty native. You're going to find it on every, on every desktop, every mobile phone. It's not what we, not what everybody means when they say native all the time, but it's still there. It's going to be available. Um, so, and again, your, your, your users should experience, have the best experience on your website, no matter what platform, what, what device they're coming from. Yeah, absolutely. Uh, an interesting concept here is the idea that the native viewing device, if you want to call it that for the web is the browser. And so if you're performing, uh, if you're performing remote queries, for example, you're performing a web request. Well, the browser is directly created for that purpose. You don't have to call up a new code base. The browser is natively built to, to do web requests. That's what it's made to do. And so that in that way, it is the most native of all things, uh, when it comes to connecting to the web. And I actually, by the way, built the app, um, such that it's not, it's making us an API request to another endpoint. It's not, uh, and so then we have to, you know, cover cross-platform script scripting and that kind of stuff. So yes, that I, I made it as, as yep, Stan, I made it as Stan. Yeah, you have to add the, I had to add the cores header. Um, I think I actually did that with a little Sinatra app by the way. Um, but I talk about that and that that's, that's, that was the kind of the mindset going into it. Let's make this as standalone as possible, not dynamic HTML at all. Yeah. Yeah. We won't go into cores because it's kind of a nightmare if it's your first time trying to do a Jason call to fully understand what's going on with cores. But, uh, certainly the book goes, goes into a little bit of detail about what a cross origin resource sharing, I think is what that stands for. C O R S. Um, and, and I'll, I'll include a link of the show notes about that as well. But, uh, that's, that's really, really interesting. I love this separation of the, of the two concepts there, the, uh, native platform or official native platforms versus the, the cross platform. So, uh, let's talk about the official native platforms and then, uh, perhaps more interestingly, the cross platform tools. Yeah. Um, okay. So I'll just go down the list. iOS was the next week. Um, I, let's see here. I wanted of course, to make this a hundred percent Swift, no objective C, um, cause that's the new hotness and it's also a pretty cool language. Um, it's the app Apple recommended way, right? Yes. But, but I I'm with them. It's, it's a great language because it's, uh, bringing it's, it's an interesting language. It's bringing functional, um, language. It's got a lot of functional language cred, I think. And, and that is a good way to take your career. Uh, you should be, if you don't understand what's going on there yet, you should try to figure it out. And it's an interesting, you know, it's an interesting mental shift that you have to make if you're coming from a procedural language, uh, and Swift, I, uh, Swift, the iOS was the first one that I did, uh, over a year ago now. And Swift, uh, went through, went through a lot of evolutions and I, I was trying to, uh, on the third day in iOS, I, I build an interest. Uh, it was an interesting sort of exercise in building, uh, a web client or an HTTP client. Um, that was a little bit more, I, I used generics to, um, to make it, to make it, um, so that you can specify what you want the Jason to turn into when you pull it down from an API in terms of a Swift class. Um, by specifying that as a, as a, as a, as a generic to the call that you're, that you make, like go get this web resource. And I want it to be an instance of this object or an array of this object when it, when it's, when it comes out the other side so that it's, it's probably, it's not production ready code and it only implements get, I believe. But, um, the exercise is to kind of show you, um, generics are very important, not, not only in functional languages, but they're very important in functional languages. Type types are very important in functional languages. So here's how we can use them to our advantage. And, and, uh, that's, that's sort of the, the, I guess, I don't know the capstone day, um, uh, bit of the iOS project. And that is that that's a weather application, by the way. It's, so it pulls down data from the Yahoo weather app, uh, or weather API. And you can, uh, check what the weather is like at a certain address, zip code, something like that. Very cool. Yeah. So there's some, there's some, uh, reverse encoding of, of zip codes or whatever that particular API does. Yes. Yes. So I use not only the, the location APIs of iOS platforms so that you can, you could get the weather at your current location and it, it'll turn that into, yeah, that's right. It uses the reverse geo coding APIs on, on iOS to turn that into an address, which you pass into the API. Then it gives you back the weather results there, but you can also type in an address. Very cool. Um, you mentioned, I want to just kind of hover on this, this conversation about Swift for a second. Um, Swift, if you are new to programming, Swift is probably going to be a bit daunting. Um, and I'm not saying that to deter you from using Swift because there are certainly things you can do with Swift, especially, uh, if, if you are somewhat familiar with the concepts of coding, there are so many features in Swift that, that the width of, and when I say width, I mean the number of types of things that you can do with Swift is much broader than the average language. Like for example, with Ruby, you can look at, you know, I, I could list the, the maybe 10 to 15 keywords pretty quickly and, uh, and kind of cover most of what the language can do. Now there are really specific techniques that you can perform with Ruby. Um, but you know, the, the primary base of the language is the, the, the, the, the, the, the, the, the primary building blocks of Ruby are really, it's really not that much, right? And the same could probably be said for JavaScript. And, uh, you know, some of these functional languages, certainly Lisp, for example. Um, but, but with Swift, it's, I, in my opinion, it's much, much broader in terms of the number of things that can, it can do. And the syntax is, is not as intuitive, uh, right away as maybe Ruby would be. So, maybe Ruby would, would be in my opinion. What do you think about that, Tony? I, I think, yeah, I think I agree. I think one of the, the, uh, the reasons for that is that it, it, they're trying a bit, um, not, not, not with the same results, I think, as something like Scala, but they are trying to make a multiple language for people who are, um, coming from different backgrounds to be, to feel somewhat comfortable in. So you're going to find something. I, they explicitly stated some of the inspirations with Ruby. I, the inspirations ruby is an inspiration you know probably for for cleaning up the you know semicolons and stuff like that and then java and c sharp have been have uh some influences there too but also the functional languages and scala i think is one that's listed which is another multi-paradigm language so you can you could write java in scala and you you know that's the old joke you can write java in whatever language you want but that that and that's some of the the uh what i think makes swift a little bit more complex they're trying to make it feel comfortable to a wider audience um but get some of those newer concepts in but they've they've pared back a little bit on some of that stuff as they've evolved the language for instance i think they removed four loops interesting and now you only have four in uh i believe uh in in one of the i'm not sure which version so they're trying to get you towards nudging you towards how they think it should be done and a four loop is definitely like that's that's a procedural concept in a functional language you don't think about that uh it's it's not functional thinking really so they're trying to like push you a little bit away from some of those things as they go on and it's it's interesting to watch the language grow but definitely i agree it is a it's a more complex language yeah certainly i'm doing a lot of studying on javascript and um there's a lot of you know there's a lot of there's a lot of there's a lot of there's a lot of there's a lot of retroactive adding of things to javascript that i think um if javascript were to be designed today would look a little bit more like swift in my opinion um so that so that's just some some food for thought for those of you who are trying to decide what languages or language you want to look into next uh swift is swift is definitely an interesting one and um very powerful certainly i wouldn't say that the the eco-language is not the best way to put it but i think it's a good example of how the ecosystem for swift has evolved uh this is by the way this is kind of a strangely technical deep dive right now it's out of the ordinary for developer t but um i've been thinking about swift quite a bit uh since since it was released i think it's a very interesting opportunity uh but but i'm looking forward to what happens in the open source community with swift now that the if i'm if i'm not mistaken the compiler is open source correct yeah that's it's open source it's open source it's open source it's open source it's open source it's open source uh actually the compiler is i'm not sure i'm not sure how to answer that it because clang is i believe part of the the tool chain so i'm not sure if that's the compiler or what i'm speaking a little out of turn here but the the swift is open source as a language so there's there's already been accepted uh community um pull requests to the language um sure yeah so in other words you could you could take swift and then do like a swift compile to javascript or something like that if you really wanted to yeah i'm not i'm not sure what what things have been contributed but there are contribute contributions going in so that's a really cool move by apple and it's it's definitely something to watch and and that you know the the possibilities are interesting now you can have swift code on the the server side and then there was this announcement who knows how real it is but but there's this rumor that android is considering swift as possibly a first class language on the android platform oh very interesting yeah that is it so that's a perfect segue into uh into the android app that you built it's a currency conversion app thank you so much for listening to today's episode of developer t in the next episode we will dive directly into talking about that currency conversion app that tony made for android thank you so much for listening to today's episode and thank you again to rollbar for sponsoring developer t today with rollbar you can put errors in their place and you can get up and running in just a few minutes with rollbar it's incredibly easy incredibly powerful and i use it you should check it out rollbar.com slash developer t and of course that will get you the bootstrap plan free for 90 days that's 300 000 errors tracked for free thank you so much for listening to today's episode don't forget to tweet at tony that's t hillerson on twitter that link and all of the other links from today's episode can be found in the show notes at spec.fm thanks so much for listening and until next time enjoy your tea