 OK, can everyone hear me OK? Great. So hi, I'm Anton, Anton McConville. I'm a developer advocate with IBM BlueMix, which means I spend most of my time developing applications that showcase our product, or working with clients to help onboard them onto it. Underneath the covers, I'm a sort of experienced developer. I've got apps in the iTunes store. I've had a career that's spanned UX and development, and I lead a tech team at IBM. So we're going to get busy with some code during this talk. And so the talk is going to be in sort of four little parts. We've got half an hour, and we could spend a good two hours working on Swift and learning it properly. So we're just going to be skimming the surface. But I'm just going to talk about why Swift makes sense with Cloud Foundry and on the cloud, show the basic structure of working with a Swift project. We're going to do some seed of the pants coding and for 10 or 15 minutes, just working through a simple example and hopefully deploying that to BlueMix. And then we're going to look at some future steps. So just to sort of set the scene a little bit, Swift is a pretty young language, a quick show of hands who's coded with Swift in the crowd. Just a few of you. And how many of you are mobile developers in general? OK. So it was born in 2010. It really just became public in June 2014. So it's super young, and it's evolving really rapidly. It's pretty immature. The first sort of public release of the language came in September 2014. And then the second release came in September 2015, and they're working at the moment on release three. And then the big announcement at the end of last year was Open Swift, where we had a version of Swift that runs on Linux. And that's the big enabler for getting it on the cloud, so it can run on things like Cloud Foundry. So caveat there, it's data mature. It's December 2015 when it started to go open. But the other sort of the flip side of that is now is the time to start paying attention to it because there's so much momentum behind it. IBM have a team of open source developers contributing to the app or the big team. So let's look at sort of step back a little bit and look at why Swift makes sense. Hopefully many of you are familiar with this model. This is like day one computer science. Computers only do three things, input, process, and output. And the lines used to be pretty clear where those things happened. 2016, they still only do those three things, input, process, and output. But what's really dramatically changed is the number of wires that you can input information. So multimedia, social media, wearable devices, internet of things from factories, that sort of stuff. Location awareness, the number of targets that we can output has really radically changed as well. So we're at the sort of tipping point where more applications are being appreciated on mobile devices than they are on the desktop. But we're also targeting things like haptic communication, touch, navigation, awareness, and some of the same things that are input. So wearable devices, speech, that sort of stuff. The only way to make sense of this whole sort of environment is to process it in the cloud because of the volume of data that's available and the variety of sources and targets for that data to connect it all. Obviously we need a cloud and I'm preaching to the choir here because you're at a cloud conference. We also can process the information differently as well. IBM has this thing called Watson. Lots of the other cloud companies have got artificially intelligent software. So we no longer need to think of data as just numbers. We can look at it through natural language as well. So that's the sort of environment we're working in. And Swift really plays well in this environment because it's been designed to run on mobile devices to interact with social media, to interact with haptics, to interact with multimedia, and all of the things in the picture. It's kind of a really convenient language for doing a lot of this work. There's no easier way of capturing your voice data than on a mobile device, right? Because you've got a microphone right there. It's much harder to do that through the web. So this is from Apple's website, where they say Swift is a modern programming language that is safe, fast, and interactive, and it's their baby, so they're very unlikely to say it's unsafe, slow, and a bugger to work with. But it is, I mean, certainly compared with Objective-C, it's much more fun to work with. The syntax is more familiar to things like Python or Go or even JavaScript. It takes much more influence from that, but it's built on the solid foundations of Objective-C as well and the rich history that it has and it can offer. If you want to play around and experience Swift while I'm talking, you can go to this website and there's an interactive sandbox where you can actually program and run it if you want to get your fingers dirty with it. So what are the other advantages to Swift? Well, the clear, obvious advantages, it works full stack. So many of us probably come from the enterprise where we're used to using Java or .NET on the server side, and then we have JavaScript, HTML on the client side. The days of writing Java on the client side are, I think, falling behind us, at least, and then working with mobile technology as well. So you get a mismatch of languages. And teams were certainly in my experience from the enterprise. Teams have been split up into front end and server teams. But then you get people like me. I've had experience in both sides. And the context switch when you're working on a mobile app and then switching back to a different language on the server, it's taxing and time consuming, and there's formatting issues to go through. It's just not as convenient. One of the most beautiful things for me about Cloud Foundry was working with Node and being able to choose where to run the JavaScript code, whether that be on the server or the client, and actually moving it back and forward and experimenting and not having that context switch and being able to deliver JSON objects really simply and easily from the server to the client. And it's almost seamless. You start to lose the boundaries a bit more. So the idea of using Swift full stack, coding on the server, coding on a Raspberry Pi, whatever. And then building your front end piece with Swift as well, it's really attractive. It sort of opens up the opportunities a bit more. It's compiled. So again, with things like Node, which isn't compiled, you just load it up to the server and let it loose. So it's more prone to failing, where you don't have that type checking, that stronger type checking at compile time. So compiling gives you that advantage as well of a more of a safety check ahead of time. And getting back to those sort of Java developers on the server side, what I've noticed from them is they're slower to adopt JavaScript and Node because it isn't type checked. It's less of a familiar way of working for them. And future friendly. So again, looking at that picture that I showed a few minutes ago, thinking of the future. You've got wearable devices from Apple. You've got their laptops, their phones. God knows their car. They're all gonna be running with Swift. So people have already written great libraries, even in that short time frame from the last couple of years for working with Swift on the phone. It's booming sort of area. It's a growing, it's a rapidly growing language. So it's kind of future friendly. It's very modern. So that's sort of the background on why Swift makes sense in the cloud. So working with Swift, what does it take to work with it? So if you wanna get started, the place to go is Swift.org. So you can just take a quick look at that. It's got details about Swift. You can download the latest releases. If you're a Linux developer, you can get a Linux version of it. You can get the latest version of Xcode to work with it on your Mac from the command line as well. It's got getting started walkthrough, which is really good. This is how I learned. I'm not part of any Swift development team. I'm a consumer. So learning hopefully like most of you. And then what I wanted to do today was be kind of authentic about it and show you the reality of where it's at. So this is your starting point. Swift.org is where you go to get set up. And just mentioning that compatibility. So it's compatible on Linux, compatible on OSX obviously. So the fun thing is it's gonna be running on Raspberry Pi soon enough. It's early days still on Linux. So a lot of the foundational libraries that come with Swift on OSX are currently being ported to Linux. So that's a very bare minimum at the moment. But like I'm saying, now's the time to start paying attention. Now's the time to really, if you're interested at all in Swift and the future of programming with it, now's the time to really get engaged with it because I promise you by the end of the year you're gonna see a lot more vibrancy even on the Linux platform. It's moving so quickly. So one of the things I introduced with open Swift was package manager. And like many other programming languages, like Node for instance, it's your way of organizing things into modules. It's your way of relating dependencies to the code. So this is what makes it possible to take Swift program and deploy it to the cloud. You've got an organized way of packaging it. So just getting into that, a package consists of a Swift source file and the manifest file. The main manifest file is called package.swift. We also use manifest.yaml when we're deploying to the cloud foundry. Hopefully we'll see that in a second. And then it has one or more targets where you specify the product. So this is what the package file looks like. So it's a Swift file itself. You're importing the package description. And then you just give it a name and list the dependencies on there and you can give it a GitHub or a Git dependency and it'll take care of downloading that for you as part of the installation. The structure of it looks a little like this. So you have a project folder. Inside there you have another folder called sources where you keep your Swift files and your package.swift file. So it's not rocket science there for the structure of it. And then for building, Swift build. So you go into your folder and type Swift build and it will create a .build folder within which there's a debug folder and these artifacts. And to run it, you type .build slash debug server. So we're gonna just quickly make a really quick hello world program. You guys let me know if you can see this shell. Can you read it? No? Okay. Let me see what I can do. Let me know when you can read it because I won't be able to read it. Okay. Okay, so I'm just gonna make a quick folder called summit and CD into it. I'm just gonna touch package file just to create it. It's gonna be an empty one for a second and make sources folder. Gonna CD into the sources folder and then I'm not gonna use an editor just to prove to you it's not any sort of magic that's happening with Xcode. I'm just doing it from the command line which is probably dumb because I'm not gonna get any syntax checking or anything but we're gonna keep it simple. So all we're gonna do here is just do a hello world. Okay, so we should be able to go back up again. This is just reflecting what I just showed you that the packaging and we can do Swift build and we've linked it. So now we can type build, debug. What do we call this folder, summit? And you see hello world. So that's your basic Swift program. So we're gonna try and do something a little bit more complicated in the second and then deploy that. So just getting back to the slides for just a second. So Copa America, any soccer fans in the crowd? Anyone looking forward to this? One person, so there are two of us in here. Copa America is a big soccer tournament from South America. It's 100 years old and for the first time ever it's being played in the United States this year and I think next week. I'm a big soccer fan. You can hear from my accent. Although I live in Canada. I'm not originally from North America and I was really just fascinated by where all of the players came from. I was interested in plotting them on a map. So I've been building up this set of data and I thought it might be a fun set of data to work with to show you a quick app. So what we're gonna do is we're gonna plot the Argentina team on a map view on the iPhone and we're gonna serve that from Swift on Bluemix. All being well. I was just to cheat a little bit. So this is what we're gonna build hopefully. Just to cheat a little bit, I'm gonna take a pre-made Hello World app that runs on Bluemix already. So this is your starting point. I keep reinforcing that it's very, very early days with Swift. So serving Swift from Bluemix, from Cloud Foundry on Bluemix requires just a socket connection at the moment. That's what this Hello World app is built using. So I'm just gonna go to GitHub. All of this stuff is available on GitHub by the way and I'll put all of my workshop on GitHub and if you follow me on Twitter, I'll tweet out or just look me up on Twitter, I'll tweet out where the coordinates of it are. So again, we'll just create a folder or we'll just clone it. So we'll start off with the Hello World app and in here, it's gonna look pretty familiar to what I've been talking about already. We've got a package file, we've got a manifest, we've got our sources folder in there. Let's take a look in the sources folder at the demand program. And so this has got a bit more Swift going on in it. So you can see it's importing. This bit at the beginning is either figuring out if it's on Darwin on OSX or if it's on Linux. So it's grabbing different versions of the foundation depending on what's there. It's creating just a socket on there and then it's looking at the environment variables and my system. So please don't be taking any photographs when I wanna start running it. But you can see this is building up some hits to him out to show that. It's got an environment variables, this line here. So line 46, so it's got an environment variables and then building up a little hits to him out to show it. And we've got a little socket server down here at the bottom, which thankfully I'm not writing from scratch today. So let's go back up and we'll build up. So Swift build again. And you can see in here, it's already showing deprecations. This is one of the things that you'll notice if you're working with Swift, how quickly it changes. This thing is deprecate, like lightning. And it's a nuisance if you're programming an iPhone app at times but it's also healthy and they're evolving the language pretty well. But it's one of those things you gotta be ready for working with it because it's so changeable. So if we run this, you can see it's starting. It says server is listening on port, 9080. So a little hard to see, can I? So you can see here it's just going through the environment variables in my system and printing them out on screen. So we built a little Swift app and this will deploy to Bluemix or to whatever Clive foundry host that you're using as long as it supports the Swift build pack. So what we're gonna do here is we're just gonna take a JSON file. So I've got one called copa, I think copa JSON and put it right there. And then we're gonna edit the men file. And it's not gonna be a crazy program. All we're gonna do is serve this JSON data from the Swift backend. So I'm just gonna get rid of this bit where it puts together the environment variables. So let's see, maybe, okay. And this time round, rather than do that, we're gonna just read from the file system. So I'm just taking, just getting the path to the file system there to that file. And then reading that into an NS data object. So that's a native object for iOS, usually. And then for the response body, what I'm gonna do is just encode that data. So in the real world, you'd be getting your data from some other source. A lot of this data I actually mined script from Wikipedia. So ideally you'd use Swift for doing that kind of thing. There are some good libraries already for doing things like screen scraping with Swift. So it's kind of risky for me doing this here just right in the raw file. But I wanted to give you that sort of simplistic authenticity of doing it in just in a VI session. So that should be enough to get us our string and encode it. The other thing we're gonna do here is the content type is now just gonna be application and JSON. And so fingers crossed that should build. Oh, okay. So I've got an error saying it should be var instead of let for response body. Okay. Do I have, I must have two of them. Yeah, here we go. Phew, it built. Okay, so now if I try and run that, so when I refresh the page this time, we've got our JSON data showing up there. These are the Argentina footballers that we wanna see. We've got latitude and longitude in there. So that's pretty cool. What would be even cooler if we got that onto the cloud? So what I'm gonna do is for the sake of speed is take one that I take a manifest file that I built earlier. And it's, we've called it Swift CF Summit here. So if I just quickly go to Bluemix, I did deploy this earlier and then deleted it. So we've got the spinning wheel of death here on Bluemix, but it should be fine. It's just, I think I closed my laptop while I was still doing it. So there we go. It's not there. So if I do a CF push, I've already logged in and everything so it should find my endpoint. It's using the manifest file there. One of the things in the manifest file is that it's got a Swift build pack on there. So as it's starting to upload, we'll leave it to upload and I'll get back just to, actually what I'm gonna do is pretend that it's gonna upload and go into the, into Xcode and show you this little app. See if I can find this. I keep moving these things around. Can you read this okay? Okay, good stuff. This isn't a very sophisticated program at all. It's just one view, a map view. And so we've got view controller Swift here and we've got the beach ball of death recovered. So in this view what I'm doing is I'm setting an initial location which is around Argentina centering the map on that location. And then I'm taking that data source. So I've actually programmed it already. So it's just taking Swift CF summit.mybloomix.net. So that's that JSON data that we just put together. And then parsing through, finding an Argentina item, getting the latitude and longitude and just plotting it on the map. So if we've deployed, it's still starting the app there. I'm just gonna let it do that and multitask back in here and we'll look at that in a second. So I'm just a little bit worried about running out of time. So future steps. Katera is a web framework that's been developed by the IBM team. So if you're familiar with Node, it's like Express except for Swift. And that's coming along. Keep your ear to the ground. It's gonna be some big announcements on that. And during the summer, probably around the developer conference timeframe for Apple. So that's, I'm looking forward to that coming so that I don't have to use sockets anymore. I can build proper web apps. Swift 3 is coming along. There's some new evolution steps in there. Windows is a curious one. So there's talk of Swift appearing in all kinds of platforms. This was a link that I saw. The other day I was putting the slides together. So Microsoft also working on a Swift compiler of red. Google are considering it for Android. It's another rumor. I don't know if these are malicious rumors coming from Apple or what. But I keep hearing these things. Blue Mix and Swift. From this web address, you can see how they relate to each other. I have to show you IBM's really deeply entrenched in Swift and believing in it for its future. There's a whole bunch of open Swift packages as well. Linked in there. And then this workshop is there as well. That's all of the slides. I just wanna see if we can get this app running and show you that. So we're apparently running. So if you go back to Blue Mix and I refresh here. So you can see, oh, I've got two of them somehow. Oh, one of them's gone. It's good. So if we view the app, we can see it's running in the cloud now, that same code that I just programmed. If we start up the simulator, hopefully it's starting. We should see, there we go. So it's consumed the data and it's plotting the pins on the map. So 100% Swift server and client. And that's all I've got for you. I can take questions. Thanks very much for listening. Argentina. Youself. Any other questions? Yeah, the package manager that I was showing you is works very similarly. If you go to swift.org, you can read about it more in detail there. I had to skim through it, but definitely, yeah. Yeah, I can't quite hear you for Swift. There are a bunch of them. They're being pretty diligent with this one. And trying to get it using, and trying to port as much of the native foundation stuff as possible. A lot of the other frameworks have cheated to Polyfill while the Linux equivalent is being made. So I would put my money on this one. I'm being patient and waiting to use the KaiTuro one. Yeah, so I mean, I'd be lying if I told you that I'm a language expert. I'm like a shameless consumer of these things. I'm a front-end developer and a designer and that's, but from what I've seen, I would prefer using Swift to Java for sure. It's not as verbose. It's not, you don't necessarily need as many files, you know, headers and footers and things like that. It's single file. It's lightweight. It's very script-like, so it's strong that way. It's a good language that way. It's type, it's strongly typed as well. So better, if you like strongly typed languages, better obviously than Node, but it gives you the familiarity of using like a scripting kind of tone on the server. So there are the language sort of strengths as I see them. And then the value of it is that you've got that huge ecosystem that Apple are building and all those amazing libraries and APIs that go along with it from whatever service you want. You can start to consume those easily. You've got ready-made APIs on there for using them. Yeah. Which has that definition word. Yes. I would love an answer to that question too. But I'm tolerant enough. I mean, it was sort of awkward at times programming on the client side for that. But the benefits, far right strip, the drawbacks certainly compared to programming with Objective C in the past. So it's one of those worlds, right? It's one of those things. But I've heard a lot of people compare it to go. Anything else? If he's brand new, I would say it's probably a good idea to start with Swift and start learning it. To start, and I would say probably on the client, like start building, if you've got a Mac, start building iPhone apps with it. It's fun and you get an instant gratification. You've seen this little program. It's hardly any lines of code in it. And you can run it in your phone. So it's a fun way. And then he'll be able to graduate really easily into running stuff in the server. So for the server side Swift, you need to use that sort of package management. I haven't capped up with how that works on the client side. On the client side, you typically build with Xcode, takes care of all that stuff for you and packaging it up. I imagine they're probably gonna align. I would go to Swift.org and read about the future for it. Okay, thanks again, guys. Have a safe trip home. Thanks.