 I've also started going into front-end. We work for a lot of companies, a lot of large enterprises, which is great because I'm like, sort of, they do pay their bills. And it also gives us a lot of opportunities to experiment with new technologies. So we try to do things all the time as new projects are coming up for these large companies. And I do believe that culture is the best thing that a company needs to be focusing on. And we have a great culture that manifests in excellent products and client satisfaction. So Swift, how many people here have written Swift? I'm an engineer right now. TVOS also, when the write project comes along. And I love it. I want you guys to love it. So think of your two favorite programming languages and pretend that they had a baby. That baby is Swift. It doesn't even matter what two programming languages you want to pick. Your favorite languages are C and Ruby. It's like, oh honey, you're all performance? My expressiveness? I see it. Go and Java? Your object? And your structs? List and 4chan? Seriously, that's ours? It doesn't look like it, like us. It's ours. It's gonna be, it's, it's compiler's so slow. It's ours and we love it. Which actually also explains why I love Swift so I just get whatever Apple gives us. It's not called center. It's ours and we love it. Swift is actually what we call a multi-paradigm language. So it has optical-oriented components. It has functional components. It has a perfect component. It has generic components. And instead of calling it a multi-paradigm, I like to think about it as being a primal language. It lets you choose the tool that you want that's best for the job in theory. It has some rough edges too. Also, like these, we're gonna judge it by curve. It's only two years old, it's adorable. It'll grow into itself. It's also open source. And they made Apple open source this last December, which I think is amazing. And the first thing I thought was amazing was like, man, Apple is not exactly known for transparency. And yet they're gonna open up this programming language and let everyone contribute to it. But then I started to think that's actually a really bad thing to be happy with from Apple. It's like I had two kids and my wife takes them out of the park and then when it starts acting out there, it's like, you are a terrible mother. But I just like take my kids out of the front yard and be around the porch all the way to each other. It's like some neighbors are sobbing. Thank you for spending time with your kids. You are a wonderful father. So it's not just about, we can't judge Apple on the curve. But one thing that is actually, I think, sincerely lawful is how they open source it. So not only does Swift and all of the components to build Swift.com GitHub like all of you as well, but they opened it up, the evolution of the language itself as an open source process called Swift Evolution, you have GitHub, Apple, Swift Evolution, and there's a Swift Evolution mailing list. And anyone who sees something with the language that they want to change, or they'd like to add a new feature, or they think the API could be improved, anyone can propose this, go to the mailing list, you'll talk directly to the core developers participating in some elements, you'll talk to the community, community advocates, and they'll say, this is what I think it should be, and you'll put together a proposal, I can send it out, and then the community will discuss it. And if it is being a good feature, it'll actually get built. And this is actually Swift 3, just got released officially with Xcode 8, just like two days ago. And if you go to the release notes on Swift.org site, you can look through all the API changes that happened. We're a lot together, like two days to break the project. But you can see that like more than half of them came from the community. So that little community involved can change the actual language itself, I think it is lawful. It's also very hackable. Everything's up there on GitHub, everyone can just play with it. And if something's a little bit hackable, we're going to hack it a little bit. A lot of hackable, a lot of hackable, a lot. So it was all my source. I, of course, made it run for Mac OS, iOS, TOS, WatchOS, whatever, NextOS, and they also promised it would have Linux support. And it did on day one. But then a few people got to go and said, well, wouldn't it be great if Swift ran on Android? Maybe it should run through DSD. My favorite one just came out a few months ago, PlayStation 4. And then there's an operating system by the new upcoming underdog or developer mindshare that everyone's rooting for. Microsoft does. It's not actually a joke, I think it's true. Okay, so why do we want to share code between platforms? And I don't think this is a silly question, actually. I think this is the service we looked at in great depth. It's two parts. Why should we do it all? Is this the jet fuel that we should be living on a tarmac? And actually, if I were to say right now, for a lot of projects, I think it is. I don't think that this is production, I don't think Swift's building is production ready. I don't think shared code is the actual ultimate goal and client satisfaction is the ultimate goal. But let's consider, okay, what do we want to share code for? And the best thing is, why would you ever want to learn the language? Why would you choose the best tool for the job and you can do it in JavaScript? And of course, our project in the making. But I do think, as Brian spoke yesterday, in the opening keynote, it is helpful to learn one thing at a time. So I work in Swift, I work with mobile developers, a few U.S. developers, and all we do all day long are interact with server APIs. And most mobile developers that I've encountered don't have a background in web development. They wanted to program their app and get rich. They have no idea how servers work. Not at all, I mean, I'm with the metal, but it is nice that they can learn a little bit about how APIs themselves are actually built so they understand that they don't include content header in the server experience. So I think it's a good reason for that, so that's what Sandy and I guys have done. So that, and I love a little Swift. So I want all the server developers here to try developing a little server project in Swift. One more thing at a time, I think that's valuable. Our use case at Willow Tree is we do build mostly mobile apps. And so every app we build, we usually build two of. We build an Android app and an iOS app. And that's a lot of duplication. And the fun thing about the duplication is that as the tiniest communication looks to be achieved, things don't work perfect. This communication is in perfect process. And we'll have something like client API changes. And the iOS app, well, it always works perfectly and the Android app will break. You really have both break and they break differently and that's a fun conversation to have with the client. Another use case, the one that I've been exploring a little bit in a few minutes in code, is sharing code between the server and the client. This is the time where we're also usually creating a lot of duplication. We have these models and it's business logic that we invest all this time in and then we have to rebuild it. We're gonna have client-side validation and we can build it again. We're sending these models down the wire and we have two copies of them everywhere. Back to JavaScript, they have solutions for those of these things already. Just do a hyper-app, an ISO workbook on that. Okay, well, my share's swift and this is just personal for me because I love it but it also is because my other main alternative to that work right now is simple swaths. Not what I always put my time doing. But the other reasons that I started my career in web development in 2004 with JCDE and Oracle had its first day of my first job. They didn't have a product for me to work on so they handed me an Oracle tone of like 900 pages and said here, read this. And then a few years later, I discovered the spring, the uprising of web frameworks. I'm sorry, we're gonna send them in PHP and Django and Python and then Rails and Ruby and that really, it really stuck with me. It started nerve and the ethos of making the program are happy really made my job better, made my life better. I think that makes, what does this do? How many is it delightful when I have to sacrifice any of the power? Okay, so we're gonna switch it on the server. So you got the JVN, Microsoft Stack, interpreter languages, binary languages, type languages, interpreter languages. I think Swift fits most closely with Go. And my prediction is that switch on the server will succeed to some capacity and you might share it's long to steal are the disaffected Ruby and Python programmers who went to Go for speed and performance but who will eventually abandon Go to get back to a richer modeling language, richer set of tools, generics. So to go to programmatic, but they're pragmatic in different ways. Go is like, it's like a grandparents tool belt. It's like really big leather and it's like been worn enough that it just feels just right. It's a medium-sized loader, it's not cracking it's not that like lead, plumb, you know, like the person who's your kid you just want to pluck, you chalk everywhere. Where as Swift is like a hipster tool belt right out of four times and it's got that accelerator finder. It's still a little bit of a game in front of it but you're wearing a sweaty tool belt. It's a little weird. But no, the modeling support Swift, it is newer. It is based on some academic research that has not really needed into most mainstream programming languages. I worked out some industry and they say like seriously, that's what you were working on you were there like 20 years ago. And Swift gets closer. Couple of features that I think are absolutely amazing. Enums with associative types because there are some types that allow you to, I'll show an example of the same code, but they allow you to really model that or conditions, they can be in this state or this state, but while you're in those states, you have that data. An example, we always find we have users and maybe users in different plans, right? Like a basic plan where they have this set of features and this set of data and a advanced plan or a premium plan where they have a different set of data. And what we often do is we model that as like, okay, well this user that the column is just empty and in our object teeter that's just gonna be null. And so Swift principles, let's get around all that to where we model our types more closely to the common domain. It's like what's a strong type of system versus a weak type of system. I think the official answer I'm gonna repeat is that there is no official answer. But the one that I've been experimenting with the, I recently started is a strong type of system is a system in which your types are constrained more closely to the values that they then possibly contain. I'll show a concrete example of this too. But if you think about something in Ruby, Ruby is tight. It's just a type in the end unit. You can sign anything anywhere. You can do the same thing in Swift. We have a literal any. You can sign anything to it. But you can also constrain it more closely. Say you have a function that takes an int and you're going to divide something by that. Obviously there's one value that's not gonna work and divide by zero. And so if you just take an int in that's what's called partial function it's only going to crash and you divide by zero. But we can use the types system in itself to protect us from that. We can have a non-zero int type and only allow that type to be instantiated if the value of the underlying int is not zero. And now we accept that function, that type as a parameter to our function. Now with a total function, we succeed for all possible values that can come into that function. That's stronger type. It's more strongly type. It's constraining out of the two of the 64 possible values to two of the 64 minus one. Just type in that method. So anyway, frameworks. What would a web development language be without web development frameworks? And our bunch, I'm not really going to talk about them specifically. I'm gonna use one to show you some of these examples. But the first one that date U is made by a startup called Perfectly Solved, which is sort of an awkward name for a company. But they had the perfect web framework on GitHub. The next one is not quite a startup, but IBM has put an offering out there also with the source called Kitora. And they take a slightly different approach and break everything up to ability models, which is great for reproducibility. And then the third one that I'll mention is one of the little bit of demonstration that is called Vapor. I think it's sort of like a community darling. It's a lot closer to Rails, a lot closer to Django. Well, I think those two are very, very far apart. It's a lot closer to Rails. So now, let's look at a little bit of code. To the screen, I actually knew it, or to just like, it's a little bit closer. I think this stuff is really fun. And so if you can see, seriously, cool. Okay, so we are going to have three different projects that we're going to make. We're going to make them because I was worried with the launch and pilot times that it would be really awkward here. And I made a list of jokes to tell, but I'm actually a little bit of a joker. So we're going to start with our model tier. And I made this one a library. And so if you can see that at all, package, switch, sources, and tests. This library was created with a sort of package manager. So a package manager like, like Crystal also mentioned yesterday with Sharks is a decentralized package manager. Everything's going to be controlled by Git. It'll go and fetch your library that you asked it to and go ahead and build it, fetch its dependencies, and try to resolve the whole dependency graph for it. So in the simplest case, our package is just a package of code with a description of what the name is. So those should be your code. So we've got this model tier here. And one interesting thing about Swift right now, so we have this public start talk here, separate models that does have access control. It's just like your favorite language with all five modifiers, right? Your language you work with has open, public, internal, and private. That's not confusing. There's a can of Swift 3. It might be a little overlooked there. Swift has a rich set of, rich set of value types. And so the interesting value types and reference types are value types are copied around everywhere, so nice and slow, not really. And then reference types are storing a pointer, passing the pointer around, and then the other one down. I think that's what's modified. But Swift's value types, it's super, super rich. They have struct and similar to Go, I guess you can attach the behavior directly to the struct as well. Structs are value types. Swift implements copy on right for all its value types. So passing these things around are actually really, really, really cheap. If you don't ever change it, it's actually passing by referencing the logic of your copy of the data around it. And we have an initializer. So here's an interesting line. If you look at just that line too, public let's speaker string, this says a lot. Oh, we're building up, it shows all the talks. Here it goes. So we have public let's speaker string. So we're requiring how open the data is, it's public, and let. So Swift lets everything be either variable or constant. So anytime you see let, this is a constant value. Once it's set, it can never be changed. One of the ways that Swift adds a lot of C key to what you're writing, it should program easier reason about it. And then you notice it's string. And this string can never be milled. String, or in Swift, introduced what they call optionals. Other things we call the meeting type. Meeting it has a value, maybe it doesn't. And language constructs actually check this. And we know right now that since it's a string type, it will always be a string, never be milled, but language compiler won't let us do that. So we have an initializer. And then if we want to pull this data out, because we're gonna be working with this in JSON to communicate back from the client to the server, we're gonna have a simple little huge variable called data, which is gonna put us in a dictionary of strings to strings. And I wrote this because it's terrible, but it's really interesting because we do this thing all the time, but back to the strongly typed and the loosely typed aspect, our data is a dictionary of strings to strings. But a string with the tightest height that can describe these things, it might make sense for the title of the top. It might be the universe of all possible strings. I don't know what I'm able to think of, but it doesn't make sense for title, like we have, we know we don't get the title of the speaker and so on. So we'll introduce you to the language feature. We know it can only be one of a few things, so we're gonna use an enum. And so now we have this enum here, also introducing another language feature, extensions, types in the Swift are pseudo open. You can add a behavior to them. And then whether it's a language type, project, cyber, or protocol, that ends up being a very powerful feature. But we have enum and it's actually gonna be a strict idea. So anytime we need to use this as a string, we can't. But we also know now that we can only be a title of the speaker or a slide. Okay, go just a little bit further. We do at a certain point need to use strings to strings because the standard library on iOS where we're gonna serialize this in JSON doesn't know about our custom type, it actually wants strings. So we are just gonna take ours and use a little bit of, don't really wanna say functional program, but we will use reduced function to build a dictionary out of those keys. And then since we wanna reconstitute this model with that, we'll do the exact same thing. And once you use more language features, guard and the guard to let syntax. So guard is syntactic sugar to codify early returns. Don't know how many people love the early return practice, but it's goal is to avoid pyramid enum as you're checking all your conditionals. And what guard will do is it actually mandates that if you fail your guard statement, you have to exit the scope. So if we have a title, if we have a speaker, if we have a slug, then we will actually initialize our type. And if we don't return nil, it's a failable initializer. This is the mechanism by which we can use types to constrain values for what we want. If we were to do a non-zero event, we would create a failable initializer so that if the value was zero, it wouldn't succeed. Then we wanna do just a little bit of validation for this demo. And so we have another kind of validity. And this one's a little bit different because we have what's called associated values. And this is fascinating because in the valid case, it's just valid, cool, good job. But in the invalid case, we're gonna attach some data to that. So only when we're invalid and when we are, we must include a string and some data like this. And this is a very simple example. You can get arbitrary, complex as you're abstract. So we'll just do a quick little validation and our title skewer of the 10 characters will return that it's invalid with a message so that we can present to the user. And otherwise we're gonna return that it is valid. That's the server code. So this is vapor. And I'm not actually saying to use vapor, although I think it might be familiar to you if you use one of the other modern interview language frameworks. But you absolutely don't have to. I'm personally hoping that the Swift community sort of settles more in the go-of-line of tighter micro frameworks and just using the standard libraries as possible. So vapor is, I think it's code running in the clouds and such water vapor. And the metaphor extends to droplets which is what they use to run their code. I didn't make these names. But so we'll look at our talks as a resource. This is some helpful APIs that create a RESTful API. And we'll set up a talks controller. All right, so we're importing our library now on line three. So we actually have access to our underlying model that we just wrote. We're just gonna do a few pieces of the controller of what a full RESTful API would be. We're just gonna get an index and then we're gonna be able to post and create a new item. And we're gonna be able to retrieve one the language that vapor uses as index store and show. So there's a bunch here and we're not gonna worry about all of it. But on index, we're gonna retrieve all of our talks and we're gonna run them as JSON. On store, we're gonna pull the JSON out of their request body and make sure that we can create a node. That's that guard led or a talk. Guard led talk from this node nodes. You don't need to worry about its vapor's internals or how they pancake out of that and forth. But the key thing here is that if we don't get it, we're gonna immediately have to be allowed this and we'll return an error response. And then we'll validate it because we can't trust a client ever. So we're gonna validate it and then as long as that happens, here is where we potentially state it to a data source. But for this panel, we're just gonna return with it. So to make all of this happen, we need to extend talk a little bit. And this is where the extensibility of types really comes in handy. So when you try to request a resource, you do something like, your root URL slash the resource name, slash resource ID or a slug. And so Vapor does this with a string initializable protocol. They say, hey, can you give me an item if I give you a string, string initializable? And it's an optional and available initializer because, well, if you don't have that item, you can get a data store. And so we'll implement this. I have a list of all talks, talk data, just a whole big way that we deal with. And we'll just look for the first one where the slug might seem to have come out awesome. And then to communicate between the different data types of Vapor expects, we know that we have this talk that can do, that has the data we want it to go. It doesn't, Vapor doesn't know how to work with it because it's talking about the protocols internally and it's a system that it knows about. So we'll extend it, we'll know the example, JSONer, for example, implement how we can create a talk on a node, how we can make a node. And with that, we can use our string to string dictionary to get to take advantage of the code that we're sharing multiple places. And then if you want to return those responses, we can make sure we're responsible, reasonable, because with Swift, most things are genericized out, but we have to be very particular about that. It's not like go where interfaces are explicitly satisfied. We have to specifically declare that they satisfy these protocols. This part would be hard to see, but we'll go back to the code in a second. So we're gonna now make an app of this. Actually, before that, build a server and make sure that works. So, first of all, I'm just gonna turn on that, so I think it's time for my first joke. How many automatres did it take to change a light bulb? One, four, two, one, four, two. All right, we're gonna load the build. So I set up a simple app to demonstrate this. So we're gonna have a table view controller. This is the interface that you probably know right from like every app ever, which is gonna show a bunch of cells the data. And then we're gonna have another screen to add one, which has just had some text input, title, speaker, slogging, so they're not a data server, sorry, the curly index of it. You can see all of our data comes back nicely. So, we want to build our table view controller, and this code is imperfect at best, but I think it shows a little bit of the language and it's enough to get diagram right on for the screen. So we're just gonna do a get to our talks. And we're gonna get a bunch of data back. And so this, if line 20, let's ask you a URL session, share a task with URL. And what follows is a closure. Swift has functions as first class citizens in the language and it also has syntactic sugar for what's called trion closure. If the last parameter throughout function is a closure, you can just pass that at the end, which lets you create rigid APIs that look like control flow from the language. So, the closure will call back the data response area. We're just gonna make sure that everything's on the door. We're gonna make sure we don't have air. We're gonna make sure that our response is an HTTP or our response, I've never seen this in an old library. I don't know how on earth it wouldn't be, but it's as strong as that language, so we're gonna have access to that there. So it's a little bit we're gonna do it. We're gonna make sure our status code is appropriate. We're gonna make sure we have data. So what data equal data? It's a type you're gonna see a lot in Swift and the data on the right is an optional data. That's a data question mark. So it's a mean, maybe we have data and maybe we don't. So if the guard led syntax, if led works well, we'll say, hey, if you have a value, let's pull it out. If you don't, I'm gonna bail out of this entirely. So let valuable data, data on the left is not optional and succeeds, data on the right is optional and we're checking it. And then we're gonna use the API to pull JSON object out. And then we're gonna make sure that the JSON object is the type you expect, which in this case is an array of dictionaries or JSON objects. And then, down a little bit further, we're just gonna take our talks and we have this array of dictionaries and we're gonna flat map them and we're gonna to transform them with our map function, which is gonna take every value in that array and map it to a value of a view type. We're gonna transform it from a dictionary of string to string into our talk. And since it's purely functional, but since it does have first-class functional support, we're just gonna pass in our initializer. We're gonna have to write a code to actually do this or just pass in the initializer to take that dictionary and render out it from the talk. We'll set those to our talks and then we will just reload our table to make sure that the user is updated with the data. Sweet, so that actually, that actually the first talk of my curl and the second hit talk is our application running. So we are using the server now to communicate this model that an entirely different library that is used also by the client to consume this data. And then the last thing I'll show is if you want to create a new one. And so this is another common task when you have clients in servers is you want to use your experience with a client to get as good as possible so that when they do something bad, like putting anything at all, that they get this feedback immediately when we don't have to go around and check the server. So we can see that title is too short. This is client-side validation using shared validation logic that the server is also doing. And then when we make our title long enough to pass our server or client-side validation that we're sharing this code with and then went to the server, asked the server-side validation as well since they can't trust us and then finally we added to the data store and respond. If, okay, back to right next steps. If you guys enjoy any of this, I do encourage you to learn more about Swift. The best resource for learning about Swift is Apple's programming language guide for Swift and some of the best written programming language documentation I've ever read. And then the two talks that you want to watch, you like watching videos, the two things that you really want to get into to get a feel for how strong Swift can be are both from WWDC last summer. The first one is called protocol running programming where Apple dies into the real differences between Swift and other programming languages. It's also known as the Krusty talk, which you'll see because they have a character that they named Krusty as the old triangle programmer who actually does everything right. And then the other one you want to do is building better maps with value types, which is Apple talking about the value types system value types are going to be the enums, the structs, the tuples as opposed to a reference to Swift or classes, thank you guys. Yeah, so the question is, if I'm going to paraphrase like, is it different than using JavaScript in a way? Yeah, no, I just like something better. No, it's for this. So this is nowhere near production ready on any other platform and I would not do this in the near future. But I do think it will be and I think it'll be a better option than JavaScript everywhere, or a better option than Java everywhere, or I could also do this. Any other questions? All right, thank you guys.