Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode I interview Tony Hilerson. 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 Roe Bar. With Roe Bar you can detect, diagnose and defeat errors. We'll talk more about what Roe Bar has to offer Developer Tea listeners later on in today's episode. While you're listening to today's episode, make sure you tweet at Tony Hilerson. That's T. Hilerson. T-H-I-L-L-E-R-S-O-N and let him know how much you appreciate him being on Developer Tea. Get into the interview with Tony Hilerson. 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 this seven in seven series. First I want you to talk about what inspired you to write the book. So this book, this particular instance of the seven in seven series is called Seven Mobile Apps in Seven Weeks. I'm right there with you. I would have never expected to be one of the authors, one of the seven in seven books because it's really a, it's the perfect concept I think for that type of medium. The idea of Polyglot, Polyglot Programmer and the format of diving deep into a couple of 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 through that lens when thinking about developing a, like some material about comparing technologies and then put that together with me working with multiple mobile projects over the years. Having to answer the question, you know, which platform should we develop for first? How should we think about platform acts compared to the one that we would rather develop on? Usually that was, hey, let's start on iOS and then think about Android after. And then 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 a niche and you scratch it, yeah. 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 and 7 series. How does it work? Does somebody follow along with the 7 and 7 and get the most out of it? So there's probably a different approach is to following along because it's a bit flexible. But the idea is this, you have seven technologies in a certain, I guess, technological theme. For instance, the first book was called Seven Languages in Seven 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, 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, which is actually three days instead of seven days in a week, to give you time to do a little bit of self-study, I think. So you start out generally, you're not taken through, like here's how to set the thing up, you're expected to do that. It's kind of a prerequisite, but you start out investigating some features and playing around it that a little bit, however, 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 to look into. Here is a couple of 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 close from what I can tell. 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, 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. Like I didn't, so right sizing the project that we go through for each technology through over the week was tough to think about without some pre-work done. And I didn't, I wanted to make it that much more than a toy app without getting into two complex of functionality. And then obviously in the time that you have a lot 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's some points that I want to hit on every platform. What is your date? What is your day going to look like when you're out and developing in this technology afterwards, you're going to have to pull down data from the web and you're going to have to transform it from Jason 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. It's so key. I feel like this is something that is underserved in the tutorials and really sometimes even in the platform itself, save for a few of these platforms, the Jason, like pulling down Jason data, doing something with it. I feel like that is the new Hello World standard. 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 you know, maybe you're, maybe you want to learn about a text output, but really, I mean, you can do a text output thing in about 20 minutes with pretty much any of these things, any of these platforms. So I really, I really like that a lot and not just for seven and seven, 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, you know, a good example of this is the JavaScript MVC, the to do apps, MVC to do or whatever it is that it's called. I can't remember exactly what it's called. I'll, I'll include it in the show notes to make sure that you get the name right. But the idea is to perform these functions and show them in these different platforms and perform the same like functional requirements in each scenario. So it goes beyond just how do I get standard output from this thing or how do I, you know, 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, you know, in response, do another web request. So it's really interesting to see that as, 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. Let this up as a way of learning for yourself and see how it works. Yeah, I think so. And I think, you know, those day to day problems that you have to solve might vary a bit from, you know, I'm just pulling data out of a database and putting it onto some sort of view or I have to solve some more computer science types of problems in my day to day job. But there's, there's some core set of those things that you're going to have to do no no matter what language it is, you know, you might ask around, I guess. I think that's a good, that's a good, good way to come up with that list. Like, what should I do when I'm kicking the tires? Not just like right, hello world, but what should I do that I'm going to have to do with this, this technology in my day to day job? Am I going to have to, you know, am I going to have to mangle text? What does it looks like to, to do rejects in, in this technology? What does it look like to make a web request? Like we've been talking about those, 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, you know, let's say you have multiple classes, for example, or multiple models in your, in your app or whatever it is. But you don't need like 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. You know, 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 NPC 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 like, where is it? Where is that going to break down? You know, obviously, no, it'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 NVC frameworks. For example, let's see you, Sinatra, which is not necessarily an NVC 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. People end up actually doing the wrong thing if they are just looking at the simple tutorial about how to get started. There's that secondary scale, right? Where 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 of the 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 obvious. Obviously it's going to break if there's just one file. But what's next beyond just like, you know, I don't know if you remember. I think it was XKCD. They had some, 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 like the development environment. I want to do this, it looks up on Stack Overflow, it wants the code from Stack Overflow and then you've got what you need. I think it was Stack Overflow, 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 have 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 we can use the answer. And Tony, I'll even go one step further. You mentioned that 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. What? So who wrote this? This is always 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 some kind of convention or pattern or something, you're going to be just as lost as an external dev would would be. So 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 kicking the tires on a new technology. How do I think about organizing? How would they like me to think about organizing this? I would the creators. Or if they have given me nothing and am I going to need to apply some reasonable, so that's one thing I found with, I've always played around with the web technologies but never too far under the view side in, that's been more on the on on side projects and things like that. So never like production level. So everything, you know, everything I've done there's been small and easy to say, well, that's okay. I don't need to go too far in that. But I really, it really came through to me doing the web chapter, the mobile web chapter for this book. How there's nobody to, there's, there's either nobody to tell you 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 give you a good structure for organizing your product or your project. Sorry. Or there's like a million voices 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 that's going to end up looking like this, if you pick Gradle or something like that. You have to, that's one of the things you've got to think about. And, you know, web, you've got to go find out what are people think about organizing or using NPM, what sort of structure that does that sort of impose on my code? Is there a structure that people like to use? Are people going to be familiar with this if I pick a structure and they come in on the project? Or are they going to be confused and argue with me about how it's organized or something like that? Yeah, absolutely. So something interesting about what you're saying and there's probably a developer who's listening right now who says, well, but I don't really, you know, I want to be, you know, be creative with the way that I, that I code, right? Like, you know, the whole code is poetry idea. That's fine. If that's what you want to do with your code. But here's the thing. You can be expressive in your code and still have a conventional structure, right? You can be 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. 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 the sake of exploration. But don't go and screw up everybody else's day 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. 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 with code that is simple and not clever, but instead much easier to extend, extensible as the idea here. Yeah, yeah. I mean, creativity always has to happen within a framework. There's constraints, help, creativity, and you don't want to be creative with conventions. Like conventions that everybody is going to subscribe to, like try to find the conventions stick with them, be creative with the problem solving. Exactly. Yeah, I think that is a pervasive issue that 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 coding for a career, not for fun, and also coding because they enjoy it. Okay. So if you want to keep the career side of that equation, you have to think about other people. You have to code that in such a way that you're thinking about other people. So keep that in mind as you go forward. I think, yeah, you're not, 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 organized, adding to the, adding the code base follows an organization. I want to know what everybody's doing or the majority of 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 be able to scale the code base, you know? Exactly. Well, and you gain economies of scale here, so a really simple example, don't rename your package JSON to something special for your company. Right? Like, this is a very simple example, dumb 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 MPM package JSON for this particular type of project. And I'm going to reconfigure and add my own stuff in here and then hack around and make things my own. And 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 on it, it's possible that GitHub will link you directly to that package if it knows that it's a package.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 MPM's package model and how MPM handles dependencies. But 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 Rollbar. With Rollbar, you get the context, insights, and control you need to find and fix bugs faster. Dealing with errors sucks. We've mentioned this on the show before. Of course, Rollbar has been a sponsor 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. All of that is very difficult to do. And Rollbar fixes this problem for you. Rollbar works with all major languages and frameworks. You can start tracking production errors and deployments in eight minutes or less. So for example, if you push out a new version of your software, you can get an alert in Slack or you can get it in HebChat or you can create issues when you have an exception in your application in GitHub or Gira or Asana, all these places that you're already used to using Rollbar integrates with those. Some of Rollbars customers include Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch, and me at Whiteboard. So go and check out Rollbar. Rollbar has a special offer for you, by the way. And 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. Rollbar.com slash Developer Tea. And get a handle on your errors today. Rollbar.com slash Developer Tea. Thanks again to Rollbar for sponsoring Developer Tea. Let's switch gears here. I want to talk to you about the different platforms that you actually used in the book. And then maybe about the different apps that you used here. First of all, the API was built on Rails. And Tony, did you build that API? Yes. It's, I'm familiar with Rails. It just seemed like the easiest thing. I didn't expect people to have to get in there and change anything. So I didn't make it to, I didn't agonize too much about that choice because I don't expect people to have to 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 solved the problem of giving myself something to call from the web basically. But sure. Let's see. I think there's a weather end point and that provides weather through Yahoo API and a couple of them are Yahoo APIs. Then a financial end point that Bertrand stocks. Yeah. There's a, yep. I don't know if they'd rate them all. Yeah, I think they might be, there's probably something interesting to find in there. Sure. Yeah, absolutely. 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. But the first one is probably the most interesting decision and I think a really important statement that you're making here and that is the mobile web. Then you build a world clock app with the mobile web and then you went on to iOS and chapter three 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 choices and I'm really excited to read through this because I'm interested in each of these for different reasons and for different projects. So can you give me just a general sense of the lay of the land of these different platforms and what your experience was going through each of these? Yeah, so 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 whose name is Bruce Tate. He was one of the authors of the original seven languages in seven weeks. And he felt really strongly that web should be one of the ones that we cover. 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 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 kind of the message there. And my experience there was it was a lot of fun to get into the responsive design which I had known about and played with on the edges of projects where I had been involved but not too much on the view side. So the responsive stuff and then also what I tried to do was make it the project which is like you mentioned it's a world clock. So it's just like a list of basically you store a list of time zones in the local storage and those are the time zones turning to clocks on the UI. Like I tell you what time it is and whatever that time zone was. I tried to make that app as native as possible or much like a native app as possible. So there's the favorite icon I show how that turns into an app looking type thing when you save it to the desktop on Android or iOS. And how you can use the app manifest to store everything offline so that if you're not connected it still has access to the local data that you've stored and all the assets are stored and library JavaScript dependencies are downloaded and available offline. So that's kind of the direction of the app. It's testing how far can we get this towards a native app like experience. And yet it's mobile web. That's kind of like a how to build a modern website. Right. I guess. That was the other interest or the more I guess a more succinct description of what was interesting to me about the responsive design. It's the mobile first design. So instead of in the style sheet, which I'm bad at, I'm horrible at that stuff because anything gets more visual I get more confused. But it's an interesting way to think about it. You apply styles such that it works correctly for mobile and then remove those as the capabilities of whatever you're running on allow them to instead of going the other direction. So you don't make the CSS work correctly on the desktop and then start adding things as the screen gets smaller. You work the other direction. And that was an interesting little exercise for me to learn about that. Yeah. I think so the concept there, if whoever is listening to this is unfamiliar with that, the idea here is called progressive enhancement. And it's where we get that concept of mobile first. The hope is that anyone who visits the site, the website, can view it on whatever device they are on. So you may have someone viewing it on a very old iPhone or Android, right? Or you could have someone viewing it on an iPad Pro or you could have someone viewing it on a small but relatively capable laptop or a massive desktop computer, right? And there's different capabilities and screen resolutions that come with each of those. Obviously different screen sizes and there's readability concerns and there's a whole host of interesting things to think about when it comes to building for basically every device with one code base. So I'll leave a couple 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 idea in a book about native applications. And I love this concept of reframing the web as a native platform. I think that's totally true. Yeah, I thought about how to organize, by the way, the top level organization is I did the native platforms as I called them first and then our platform native as I called them, I had to come up with a word and then platform. So web is a great interview native platform. And I kind of did a little bit of mental gymnastics there and looked at it from a different perspective and thought, web is pretty native. You're going to find it on every desktop, every mobile phone. It's not what everybody means when they say native all the time, but it's still there. It's going to be available. So and again, your users should experience, have the best experience on your website no matter what platform, what device they're coming from. Yeah, absolutely. 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, 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 do web requests. That's what it's made to do. It is the most native of all things when it comes to connecting to the web. And I actually, by the way, built the app such that it's making us an API request to another endpoint. It's not. And so then we have to cover cross-platform scripting and that kind of stuff. So yes, I made it as, I made it as, yeah, you have to add the, I had to add the cores header. I think I actually did that with a little Sinatra app, by the way. But I talk about that. And 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. We won't go into cores because it's kind of a nightmare if it's your first time trying to do a JSON call to fully understand what's going on with cores. But certainly the book goes into a little bit of detail about what cross-origin resource sharing, I think is what that stands for. CORS. And, and I'll, I'll include a link in the show notes about that as well. But that's, that's really, really interesting. I love the separation of the, of the two concepts there that native platform or official native platforms versus the, the cross platform. So let's talk about the official native platforms. And then perhaps more interestingly, the cross platform tools. Yeah. Okay. So I'll just go down the list. iOS was the next week. I, let's see. Here I wanted, of course, to make this 100% swift. No objective C because that's the new hotness and it's also a pretty cool language. It's the Apple recommended way, right? Yes. 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. 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 went through a lot of evolutions and I, I was trying to, 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 JSON 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 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's, when it comes at 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 exercises to kind of show you, um, generics are very important, 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's a weather application, by the way, it's, so it'll, it'll pull 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. And 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 the iOS platform so that you can, you can 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 and it gives you back to 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, 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, uh, the, 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, uh, 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 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 list, 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, 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, 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 Baltimore, uh, parallel 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. Ruby is an inspiration, you know, probably for, for cleaning up the, you know, semi-colon and stuff like that. And Java and C-sharp have, have, uh, some influences there too, but also the functional languages in Scala, I think, is one that's listed, which is another multi-paradigm language. So you can, you can write Java in Scala and you, you know, that's the old joke, you can write Java in whatever language you want. But you, 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, get some of those newer concepts in. But they've, they've paired back a little bit on some of that stuff as they've evolved the language. For instance, I think they removed for loop. Oh, 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, they're trying to get you towards nudging you towards how they think, it's, think should be done. And a for 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, 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. Uh, I'm doing a lot of studying on JavaScript and, um, there's a lot of retroactive adding of things to JavaScript that I think, um, if JavaScript were to be designed today, it would look a little bit more like Swift, in my opinion. 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 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 to you, 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. Um, 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, bits, it's, uh, well, actually the compiler is, I'm not sure. I'm not sure how to answer that. I'm not sure if that's the compiler or what I'm speaking a little out of turn here, but the, the, the Swift is open source as a language. So there's, there's already been accepted, uh, community, um, poor quests 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 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, uh, 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 Tea. 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 Tea today with Rollbar. You can put errors in their place. And you can get up and running it just a few minutes with Rollbar. It's incredibly easy and incredibly powerful. And I use it. You should check it out. Rollbar.com slash Developer Tea. 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. Until next time, enjoy your tea.