029 iPhreaks Show – Continuous Integration Integration for iOS with Kevin Munc

00:00
Download MP3

Panel Kevin Munc (twitter github blog) Jaim Zuber (twitter Sharp Five Software) Rod Schmidt (twitter github infiniteNIL) Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up) Discussion 00:27 - Custom Integration for iOS 02:58 - Jenkins CI 05:49 - Running Unit Tests from the Command Line 08:10 - Custom Integration (CI) 15:46 - Report Tools GCover Cobertura PlistBuddy 19:19 - Distribution TestFlight 21:50 - Continuous Deployment 24:47 - Travis CI 25:15 - Cloud Options for Setting up CI Hosted CI MacMiniColo TeamCity 27:22 - UI Automation 29:18 - XCUnit Specta Picks Host Xcode Server in a data center (Rod) NSScreencast (Rod) Intro to OCHamcrest (Jaim) Switch Your Control Key (Jaim) Gcovr User Guide (Jaim) Sketch (Kevin) Pixa (Kevin) Next Week Building Hardware for iPhones with Joel Stewart Transcript CHUCK: Hey everybody and welcome to Episode 29 of the iPhreaks Show. This week on our panel, we have Jaim Zuber. JAIM: Hello from Minneapolis! CHUCK: Rod Schmidt. ROD: Hello from Salt Lake. CHUCK: I'm Charles Max Wood from devchat.tv. We’ve got a special guest, and that is Kevin Munc. KEVIN: Hello from Memphis, Ohio. CHUCK: So we brought you on today to talk about continuous integration for iOS. Now, if I remember right, didn’t they add some kind of continuous integration thing to xcode? KEVIN: Yes. There is the bots now with the server, so you can avoid Jenkins if you want to. CHUCK: [Chuckles] KEVIN: It’s still got some limitations. And I think going through the pain with Jenkins ends up giving you more flexibility at this point in time, but it’s a really good sign that Apple is putting some effort and attention on quality and continuous integration. CHUCK: Right. But that's not what you were talking about; you're talking about people using Jenkins? KEVIN: Yeah, that’s where most of my experience is from. I've been doing continuous integration in other platforms for a long time; CruiseControl back in the day, and Jenkins for iOS stuff. JAIM: It’s pretty much the standard that people have been doing Jenkins for a while, would like to get into the bots, but they are not quite ready for primetime is what I'm hearing. Have you played enough around the bots to know that they are not quite ready? KEVIN: Somewhat. And I do sort of run into trouble at different points in time, just trying to know where the configuration options are, especially if I'm trying to back out… I’d like to do some blogging on it, do some speaking on it. So, I'm trying to get more familiar with it because that’s something that is in my wheelhouse here. But yeah, I'm definitely trying to go back and redo some things. And I run in to these issues that I didn’t run into the first time. And then trying to do things like… I usually in my continuous integration setup, there's the basic stuff where you does a build, do the tests, run and pass, and maybe some other stack analysis and reports. I usually try and add other things like have a ping to see if the APIs are healthy or not, and things like that. I haven’t figured out how to time that sort of thing into the new bot stuff. It seems it’s focused on the bare essentials at this point. And so, it’s kind of a lot to expect, I guess. ROD: Do you have to have a separate machine to use bots? KEVIN: No, I've been fiddling with it right on my laptop that I can do my normal development on. You need to get the server app from the app store, and I think you get promo code through the dev portal, so you know to buy it. And then I just run it locally. It has a lot of options on it and then at bottom is the xcode stuff. CHUCK: Nice. So let’s harp back over to Jenkins real quick. So you set up Jenkins on… do you have to run it on a Mac? Like a Mac Mini or something? Or can you run Jenkins on a Linux machine and still do the CI stuff? KEVIN: No. You have to have a Mac.

Transcript

CHUCK: Hey everybody and welcome to Episode 29 of the iPhreaks Show. This week on our panel, we have Jaim Zuber. JAIM: Hello from Minneapolis! CHUCK: Rod Schmidt. ROD: Hello from Salt Lake. CHUCK: I'm Charles Max Wood from devchat.tv. We’ve got a special guest, and that is Kevin Munc. KEVIN: Hello from Memphis, Ohio. CHUCK: So we brought you on today to talk about continuous integration for iOS. Now, if I remember right, didn’t they add some kind of continuous integration thing to xcode? KEVIN: Yes. There is the bots now with the server, so you can avoid Jenkins if you want to. CHUCK: [Chuckles] KEVIN: It’s still got some limitations. And I think going through the pain with Jenkins ends up giving you more flexibility at this point in time, but it’s a really good sign that Apple is putting some effort and attention on quality and continuous integration. CHUCK: Right. But that's not what you were talking about; you're talking about people using Jenkins? KEVIN: Yeah, that’s where most of my experience is from. I've been doing continuous integration in other platforms for a long time; CruiseControl back in the day, and Jenkins for iOS stuff. JAIM: It’s pretty much the standard that people have been doing Jenkins for a while, would like to get into the bots, but they are not quite ready for primetime is what I'm hearing. Have you played enough around the bots to know that they are not quite ready? KEVIN: Somewhat. And I do sort of run into trouble at different points in time, just trying to know where the configuration options are, especially if I'm trying to back out… I’d like to do some blogging on it, do some speaking on it. So, I'm trying to get more familiar with it because that’s something that is in my wheelhouse here. But yeah, I'm definitely trying to go back and redo some things. And I run in to these issues that I didn’t run into the first time. And then trying to do things like… I usually in my continuous integration setup, there's the basic stuff where you does a build, do the tests, run and pass, and maybe some other stack analysis and reports. I usually try and add other things like have a ping to see if the APIs are healthy or not, and things like that. I haven’t figured out how to time that sort of thing into the new bot stuff. It seems it’s focused on the bare essentials at this point. And so, it’s kind of a lot to expect, I guess. ROD: Do you have to have a separate machine to use bots? KEVIN: No, I've been fiddling with it right on my laptop that I can do my normal development on. You need to get the server app from the app store, and I think you get promo code through the dev portal, so you know to buy it. And then I just run it locally. It has a lot of options on it and then at bottom is the xcode stuff. CHUCK: Nice. So let’s harp back over to Jenkins real quick. So you set up Jenkins on… do you have to run it on a Mac? Like a Mac Mini or something? Or can you run Jenkins on a Linux machine and still do the CI stuff? KEVIN: No. You have to have a Mac. You have to have all the xcode tools, install the command line tools and everything. And you can get started with it right on your own, if you would just have a single development machine, you can set it up on there and get it configured and copy jobs out to somewhere else if you want it. If your team has Jenkins and you use for other platforms, and it’s running on Linux box or something, you should be able to slave the instances together, so that the results of the Mac platform Jenkins can be integrated into an overall CI scheme. But yeah, when I go to Jenkins website to download, I recommend getting the long term support version; because it’s not as much churn, with the number of updates it gets, the more stable I found. But then just installing that, there's native installers and there's also just a java war file, which is the option that I tend to go with. I was a Java developer back in the day and still feel fairly comfortable running it that way. Just ‘java-jar jenkins.war’ and it runs. CHUCK: Do you have to allocate a certain amount of memory to it? I know I've had that problem with Jenkins before, where I didn’t give it enough memory and so, it would crap out. KEVIN: I've run into that in the past. I guess I'm not running it as hard these days with the iOS projects I'm running. But yeah, certainly in the past I have had to add more command line options to get it to not fail out because of lack of memory. CHUCK: And then you are running your unit test, I presume, so can you just run those from the command line? Because that is typically where I've seen Jenkins work is there's some command that you give it and then it collects all the output and gets the return code from the process. KEVIN: Yeah, so when I use Jenkins, what I try to do is make everything scriptable, so they can run outside of Jenkins in the command line. I only rely on plugins here and there, as much as I can. So in a lot of ways, Jenkins is sort of just the scheduler and integrator. So in the past, I've been using xcode build command a lot in my scripts. I started finally looking where the Facebook xc tool to get some nicer output and options. But the xcode build command, along with the occasionally run and some of the others, gives me what I need. You can have it run the test, not run the test, tell it to run different SDKs and so on. So yeah, my first step usually is getting it to the command line, and then I use that command in Jenkins. JAIM: So you’re able to run your tests how from the command line? This was the problem with xcode 4 with the Jenkins setup; at least with the team I was working with, we had a trouble of getting the test running with application bundle, you know, the old application tests. Is this working better? KEVIN: Yeah, it is better but is still painful. There’s definitely some hoops to run through to run at different times. And I see the change with every version of xcode that comes out somewhat, which is why tools like the xctools are so much nicer, because they help buffer a lot on that. In the past, I had to go into do the fixes where you are editing some of the scripts that are underneath xcode, so that it has a test host or at least it has the test host. And then things will run; the simulator will kick off, if you are running UI kit stuff on your test. And then on that topic too, if you are having things where they are hitting a simulator, I found the path of least resistance is to have, once you get into Jenkins just a single… I forgot the term now, but a single thread, single job, so you are not having to test suites, trying to hit at the same time and it will both be in the simulator at the same time, because you will for sure get a failure with one. JAIM: It sounds like so much fun. I wonder why CI hasn’t caught on in the Mac world, you know? [Laughter] KEVIN: It’s not as easy as it was back in my job in the Ruby days, that’s for sure. But it’s slowly getting better. Certainly a lot of smart people are trying to make it better, and more and more test tools and frameworks are showing up and getting more mature. JAIM: People are fighting the good fight, but it’s like we are hacking through weeds and stuff to do things that Ruby, Java had been doing for years. KEVIN: Yeah, definitely. That’s why I'm hopeful with the whole bots thing in xcode 5 having test navigator, and hoping that does a language and get the attention and grows into something that’s even much easier and lowers the barrier to just getting going. Like you said, a lot of people know they should be testing an iOS, but there's still a lot of pain. And even myself, every time every project doesn’t always get the attention it should because it’s painful. And then you can a lot of time when things don’t work right, but I keep [unintelligible] away. ROD: I was wondering if maybe we should back up. I don’t know if a lot of our listeners know what continuous integrations is. Maybe we should explain what it is and why you would want to do it? CHUCK: Yeah, you integrate all the time. It’s a Mac term integration. JAIM: [Chuckles] I was told there would be no calculus. CHUCK: [Chuckles] We lied. Kevin, you are the expert. Do you wanna explain it to us? KEVIN: Yeah, sure. So basically, I mean for me, it comes back in the early days of agile with the extreme programing stuff, Ethos was around, code reviews are good, tests are good, integration is good, let’s do them all the time. Then it’s like you said, it’s continuously integrating, so the pain that it tries to solve is the big bang integration layer. There's always, if you are not doing continuous integration, there are points where things come together. And I'm working over here and somebody is working over there and it doesn’t work together, or something has crept in or a bug has reappeared. Continuous integration is a term for basically, there's servers, tools, you run that will give you feedback more quickly for a shorter time frame of what went wrong, so you can have a better idea what things do, be able to see sort of a health trend in your app. And really, once you are on a project with continuous integration and getting that feedback and you get used to that, you really do miss it when it goes away. So continuous integration is just having those sort of health checks primarily build and test at the core, all the time where getting everybody’s code together and making sure that things aren’t having issues. CHUCK: Yeah, my experience has been that when you have several developers on a team is really where it shines because I may make some changes in the repository, and then I push my changes up and I forget to pull your changes down and check them against mine before I do that. And so when I merge it into git or subversion or whatever, then the continuous integration server will pull down the merged copy and it will run all the tests, it will run the builds, it will do everything else that you tell it to and it will give you that feedback. I haven’t seen it as valuable when it is just me working on things, other than giving my client warm fuzzies that everything is green, where they can see it. But with multiple people on the team, it really does pay off because you kind of have on objective system that tells you whether or not you are right or wrong. JAIM: Oh yeah, it’s a real benefit. I mean, how many products have we been on where you get 90% done with the project and you are actually only halfway, done because the last ten percent takes forever? CHUCK: Isn’t that all of them? JAIM: Well, I mean, if you get in there and if you have kind of unit test setup, your continuous integration, things getting feedback when things break and  you are integrating things, I don’t run into that nearly as much. I think you can kind of figure out where the pain points are as you go, so you can fix them. So for me at least, it’s made kind of the last phase of kind of a project, it’s a lot easy to deal with. If you don’t have a month of integrated things and fixing bugs, because you’ve been writing the tests and you’ve been integrating the entire time. KEVIN: Yeah, I think because it’s continuing… if there is a problem, and there certainly of course will still be problems, but you’ve probably got one cause in there, because it’s only been a certain amount of time. Whereas if you wait to do integration, you may have a handful multitude of causes and things to deal with all at once. ROD: So when you are starting a new project, do you use continuous integration right out of the gate or at the beginning is it more trouble than is worth, because you are just getting started and you are walking over every body and what not? KEVIN: If you are on a team of developers, I think in the beginning is kind of the best time to get it going, because you are not under as much time pressure as you might be later, and there's less going on with the project to weigh down the setup. And certainly, I recommend just getting the basic thing setup where it’s pointing at the repository and able to check out the code, and then able to build the project. Like that baseline at least I recommend getting done early and you can add on later. Now, that’s when I'm the only one on the project. I do sometimes delay or test less if I'm the only one around. CHUCK: I have to say that I'm generally on the same opinion; at the beginning is where your creating all your habits for the project, and so by having it in place, you are doing two things, and one is that you are putting that check in place to remind people to run their tests and do the builds and do all of the other things that they have to do that are right. And the other thing is it gets them into the habit of looking at the CI. And those two habits are things that really, really pay off as you move ahead. And so the other thing is then you have that check as you are making kind of the foundational decisions of your project. ROD: Right. But I would think at the beginning, you haven’t had all your interfaces APIs defined completely, and seems like you might have a lot of build there at the beginning. CHUCK: Yeah, but at the same time it kind of gives you a target to go for. So at least you're solving your build errors; at least you are making sure that the unit test passed; at least you are making sure that all these other things are going in in the right way. ROD: So there is no, ‘break the build’ penalties at the beginning. [Chuckles] CHUCK: Why not. ROD: Some things do that. I haven’t had the pleasure of working on a team that uses continuous integration. I've been on my own for so long. CHUCK: Yeah, I like the public shaming route. And it can be anything from, “Dude, you broke the build.” Just much humiliation all the way up to, I've seen teams that make people wear funny hats and do stupid dances and things when they break the build. KEVIN: Yeah, you can have a lot of fun with that. CHUCK: Yup. So, how does continuous integration generally fit in to your workflow, Kevin? KEVIN: It’s kind of funny. Lately, I've been the only one of the project, at least at the beginning. So for me, it has been less urgent but like I said, I still like to set up Jenkins in the beginning, and get at least things running as APIs start showing up, I´ll start setting up a watch jobs for those. And once I'm there, then I just sort of go ahead with the project. Later on, as we get further, if I haven’t already start adding in some jobs that will try and look at code coverage or stack analysis of the code, look for duplicate code, things like that. Actually puling in at times some of the tools from my Java days like CPD from the PMD project to copy paste detector, that will look for blocks of code within certain thresholds that are effectively the same, so you can look for refactoring opportunities of things. And I try to make some time for that. I like when my xcode projects have no build warnings. And I treat the CI server reports kind of the same way; I like to get as clean as possible with what I do. So once you set up and there it’s nice having it humming along and giving reports when things go awry, but I also like looking at it with things are good and seeing what I could improve. JAIM: Let’s talk a little bit about kind of the report tools that you use. I try doing this with kind of code coverage, LLVM’s got their code coverage generator and it seem broken to have been broken at some point, like I always find it will work at one point and then stop working right by the time I wanted to use it. How do you get your test coverage? KEVIN: The tool I ended up with, because  it’s sort of changed over time, there's Python script called GCover that uses the GCove output to produce reports. And you have to turn on some things in your build settings for making sure the debugging information is there, and some other flags so that it have something to tie back to the source with. But again, with multiple loops you can get there and get a halfway decent report and HTML report in Jenkins that you can step through. The GCover if I remember correctly, it turns that into an xml format. That then the Cobertura plugin, it is a  tool from the Java world, can turn it into HTML reports so you can see in you classes, what was exercised by your tests. JAIM: Oh very cool. So this all works for Objective-C and it works great? KEVIN: Yeah. CHUCK: Do you try and get 100% test coverage? KEVIN: No. [Chuckles] CHUCK: [Chuckles] KEVIN: I used to, back many years ago. In fact there's even tool that very briefly was in the Java world where you extended it as your base test class. I think it’s called Hansel or Gretel, I can't remember which. And it will fail your test if it wasn’t 100% covered. It’s was pretty ruthless and brutal. Now, I try and test sort of the key points, the key features, the key functions, and try and stay on mostly the public API things in a sense that I guess the way that I tend to think about it is, I wanna at least cover the happy path and then I stretch out into exception paths, where I'm needing to make sure that things are handled well. JAIM: So if you are doing a universal app, do you ever run two tests for iPad and iPhone? KEVIN: Usually not at the unit level, but when I use UI automation -- which isn’t every time -- I do have separate scripts for those. And when you’re doing that, one of the big lessons I learned is that I attempted that if you are running these on your development machine, the simulator will sort of by default, launch back into whatever mode in an iPad simulator or iPhone simulator that you last ran into in the xcode, which if you are trying to run your iPad… it was iPhone the last time and now you are trying to run the iPad UI automation script, that’s not going to work out the way you want it to. So one of the tools that just come in handy that I discovered as part of this problem and have used in other places is a little command called P List Buddy, and it lets you edit right to and from a script to p list. And being able to do lets you set what simulator mode you want to run. So I'm able to switch programmatically in the scripts before the different types, so when I'm doing a universal app and I've got UI automations tests, that’s how you can control when you want which kind. ROD: How do you guys handle distribution for like beta tests and stuff? Are you doing that every built or do you have configure a special setup to do distributions? How do you handle that for like testflight or something? KEVIN: Yeah, I usually make a separate job in Jenkins just for that, so I can sort of push button, do a deployment And I was doing that with TestFlight for the last couple of projects for that. But then now, I switched to hockey, and now I haven’t integrated that in, but it seems like it will be able to be automated the same kind of way. Because with TestFlight, there's basically a, we call it the curl request, you can send up your da and dzim zip and get that all up there. JAIM: Can I do a manual test press this button and send them to TestFlight? KEVIN: Yeah, from the CI server. JAIM: Okay. I've also seen it where you can do a tag, like a git repository. So if you set this tag, you can set up your CI server to notice that and fire up the build and upload it, so you don’t have to… I've been doing it with Team City. I'm sure you could do it with Jenkins but… KEVIN: I like that idea. I wouldn’t wanna do it every successful build or even necessarily on an [unintelligible] schedule. JAIM: Yeah, it was something where you explicitly set a tag with your commit, and source control would recognize that and fire it off, so it’s not happening after every build. KEVIN: Yeah, that’s great. I always tag my builds that go through TestFlight or Hockey anyway. So that would fit right in. ROD: So then you have a manual job to release to the app store probably too? KEVIN: I've always handled the app store stuff manually. JAIM: Would that work? I’d be afraid… CHUCK: [Chuckles] JAIM: I have the fear, “They’d know. They’d know.” Rejection. KEVIN: It’s just a different versioning profile. CHUCK: Well, depending on how involved your process is for getting stuff ready for the store, I mean, running a script versus whatever, or doing it by hand, I don’t think it really matters as long as it is done right. KEVIN: There are things that go along though with the screenshots and app descriptions and all that stuff. CHUCK: Yeah, I guess that’s true. KEVIN: But if you already have that set up, then you are good to go. JAIM: So what we wanna do is send it to the app store after every checking. It’s like a extreme delivery. CHUCK: [Chuckles] There you go. KEVIN: Well I've been hearing this word -- and I'm not sure that it is – ‘continuous deployment’. Does anyone know what that is? CHUCK: So, I see this with web apps more often than not. And typically, what the discussion there is assuming your test passed the continuous integration stuff, where it runs all the tests and everything else, then it will actually automatically deploy your application to the server. And so, I'm assuming that you could do the same thing with your iOS apps. If it passes all the tests, then it goes up to iTunes. KEVIN: It’s not really working because you got to wait two weeks to Apple approve it anyway. CHUCK: Right. So in that case, it seems to make more sense to wait until you have all of the pieces in that you want in the next release and then push it out. KEVIN: Yeah. CHUCK: But yeah, that’s typically what I'm seeing. So you could something like that if you had a custom web backend or something that you are working on. KEVIN: Are a lot of people doing that these days? CHUCK: Some of the bigger companies seem to be doing it. I think Square is doing it. And these are just companies that I've talked to. I think Etsy is doing it. In fact, I think they made kind of a big deal about it . There are several companies out there that do that kind of thing; It’s like the test passed, it’s all good, and then pushes out. I wouldn’t be surprised if GitHub or some of these others do it too. But yeah, it’s just another step in your continuous integration that does a deployment push. JAIM: So Kevin, you are an independent developer, right? KEVIN: Yup. I've been in it for about a year and a half now I guess. I was doing contracting work through other companies before that. JAIM: So if you go to a client and you wanna setup CI, how do you make that sale to the client? How do you give it to them that this is kind of the right way to do things? This is going to be more effective in the long run. What's your thought for that? KEVIN: Well I guess it varies depending on the client and if they already bought in to CI or not. In different times, some clients have already have continuous integration, but not any macs of their own  to run Jenkins on. And so I've just set it up on my own, and kind of grant them access to see things or just tell them about it, depending on how interested they are. In other projects, they’ve been very bought into the whole thing and then they actually set it up on their own with Travis CI for example on one of the recent projects -- since Travis now supports the building for Mac platforms. If they are hesitant or think it’s something that are just going to cost them money and not give them much value, then if I'm on a team, I’m still going to set it up on my own. If it’s just me, I´ll probably just do testing and maybe not set up CI for that project. It kind of depends. If I do it on my own, it’s on my own time for my own peace of mind. JAIM: You talked about Travis, how does Travis relate? KEVIN: It’s like an alternative to Jenkins or the new bot stuff. And there are many others out there which Travis CI has some cool features around. You have a Travis config file that your projects and register the project with Travis, and then it will integrate with your GitHub and run for you from there based on that configuration file. JAIM: Okay. So I'm working on a project right now and we’d like to setup CI, but it’s kind of a startup; there's no real office. Are there any cloud options for setting these kind of stuff? KEVIN: There are some out there. I haven’t used them myself, but I know there's… I'm going to forget the names and I think some of them actually that like a year ago, I've listed out at one point. I think some of them have actually gone under since then -- which is unfortunate. I know there are some like hosted CI, like hosted-CI.com I think was the one, or some for those dedicated to that. And then the other option, if you are trying to do cloud, like setup Jenkins on your own sort of in the cloud for a distributed team, then have easier access to I think your best options are things like MacMiniColo, where you can have a Mini that’s available out there and then you can administer it any way you want. So it’s the same set up you would do on a local  machine or the iMac in your house, just on the cloud. JAIM: Okay. I hadn’t heard of that. That’s cool. CHUCK: Does Team City do iOS builds? KEVIN: Yeah, you can kick off iOS builds from Team City. CHUCK: I mean, that’s another option. JAIM: Yeah, they do good stuff. I've used Team City. I liked it. ROD: I thought I saw something from MacMiniColo that was specifically targeted at burning bots, but like I don’t know where that went. Then they have a new service available. CHUCK: So, have you guys done much with the bots? With the CI features in xcode? ROD: I haven’t. I though you have to have a different machine. So I got to go download server and give it a shot. JAIM: I haven’t too. I've just heard all the horror stories from people that have been playing with it, so they don’t work. CHUCK: [Chuckles] JAIM: So I don’t need to be like the early adaptor in this kind of stuff. I´ll go for something that kind of works, then I start playing with it. CHUCK: Yeah, get a tutorial out there. JAIM: It’s just a thumbs up that the documentation is correct and that actually it works. I can go from there, you know. CHUCK: Yeah, that makes sense. It sounds really interesting and I definitely liked the idea of being able to run stuff from my machine. Now, is it designed to actually exercise the UI, or does it just do unit tests like stuff? Like some of these other systems do. I haven’t really even looked into what it is. KEVIN: You know, in the little bit of playing I've done, I've only been doing just unit test with UI, you know? From what I believe, I've heard is that there's problem with trying to get UI automation running on it and a lot of the other things I think are having trouble getting hooked in properly. People are changing some of their code management to try and get it to work, where if they are using [] or some modules, they are [unintelligible] that stuff in, so it’s out there and not causing issues. But as far as getting UI testing out there, I haven’t heard if anyone is using [unintelligible] or Frank, or any of those out there for that. JAIM: Yeah, my previous client did some work with just using the creating JavaScript scripts to run the UI automation stuff. And the kick off kind of smoke test with the checkings and builds. So, it is possible. And there are definitely quirks; it would just crash for no reason, like the build and it was just kind of a simulator hanging or whatever, but it’s possible. KEVIN: Okay, the bot stuff. JAIM: Not of the bot, this is just we kick off UI automation, just through Jenkins. CHUCK: All right, yeah we should get Jonathan Penn to come on and talk about UI automation. Because it looks pretty cool when he came and presented it with the Salt Lake CocoaHeads, but I think it would be an interesting session to have here and just see how we can automate some of that stuff. KEVIN: Yeah, I will definitely tune in for that one. CHUCK: All right. Well, are there any other aspects of CI or your workflow in general and how this fits in that you wanna go over before we get in to the picks? KEVIN: Not really. I mean, with the bot stuff along without the new stuff  is that xc test framework sort of rebranded OC unit. So if you are using the official xunit test framework in xcode, where you just create a new test target and new test class and go to the orthodox Apple route with it, now, there's a new prefix for things. From what I can tell, not different at this point, but I'm hoping it’s setting the stage for some more nice stuff. I'm trying to use the more XCUnit stuff in my current project, because I tried using Specta recently, and I think I just had horrible timing because I was with the new xcode and I don’t think it’s had as much time to get up to speed with the bot stuff and everything. So xc test is the new, official, Apple way of writing unit tests. And it’s not BDD style; it’s very Xunit style, but it’s pretty easy to grasp. So if you are looking where to start, it may not be the prettiest or the most hit, but it should get the job done for you. JAIM: Yeah, and if you got the old send text cases, they pretty much map over one to one at this point like you were saying, so you don’t have to change your logic too much. [unintelligible] KEVIN: [Chuckles] Right. JAIM: It will mess up your project, but it will convert the test for you. You just got to fix your project afterwards if you run the conversion. KEVIN: Yeah, just xcode will attempt to convert things for you and make sure you are synced up and have a clean source code repository before you attempt it. CHUCK: All right, well I'm just going to throw my weight behind setting up a CI machine. I've seen this pay off on a lot of teams in a lot of ways. I've set it up on at least 2 or 3 other teams that I worked on. And overall, it’s really nice to have that one place where you can say, “Okay, it either works or it doesn’t.” So it works on my machine, isn’t an excuse anymore, it really does come down to, “Okay it works there, that’s the canonical place, it builds properly, it does what it’s supposed to do, here are the static analysis tools that tell us how good our code is,” and gives you that kind of collaboration point. And it’s also a really easy way, as I said before for clients or product people to look up there and just get a quick idea of what the status is -- it’s broken, it’s not -- and where you are at. So anyway, I really like it and I've used Jenkins in the past and there things I like about it and things I don’t. Most of the things I don’t like about it basically boil down to the UI; I think the UI is hideous. But it is a great tool for getting that stuff together. And you can put a dashboard up somewhere where you can just see it running. So go check it out and if people have questions or run into problems trying to set it up, is there a way that they can reach out to you, Kevin? KEVIN: yeah, that would be great. I'm ‘muncman’ pretty much everywhere – Gmail, twitter, or whatever. So yeah, go ahead and ping me. CHUCK: All right, well let’s go ahead and do the picks then. Rod, what are your picks? ROD: All right, I found that service that I was talking about. It’s called Xcode Server Hosting. So MacMiniColo will provide you with a Mac Mini xcode server and mavericks installed on it, so you can do your continuous integration with bots and everything for just a $79/month. So it seems like a pretty good deal. And my other pick, I just wanna pick Ben’s NSScreencast again. Always comes in handy even if you are not a beginner for reference materials, like get up to speed with rest kit. He's got three great videos  up there on rest kit. So that was nice. NSScreencast. That’s it. CHUCK: Awesome. Jaim, what are your picks? JAIM: Okay, along the lines of what we are talking today, I've been playing with OCHamcrest. It is kind of a replacement for xct test, the kind of the built in social language that you have to write your tests,  because doing ‘XCT’ before every assertion is hard to type and kind of annoying to read. But is OCHamcrest is based off the Hamcrest project. If you come from Java background, you know about it. It’s really cool, kind of a clean way to write your assertions and pretty powerful at matching, so you can do things like, “Make sure there is a class of this type in an array,” which is harder to do with kind of the base assertions. So some really cool stuff like that. Another thing I wanna pick, I got a chance to listen to some of the older episodes that I missed. Chuck, you were talking about Emacs, but I think it’s a little dangerous to recommend Emacs without telling people to their caps lock key to control, because if you do like CTRL+A, CTRL+W, CTRL+Y and all that stuff hundreds of times a day, you are going to screw up your hand. So switch your caps lock to CTRL and your fingers will love you for it. So those are my picks. CHUCK: All right. I've had kind of a crazy morning and I didn’t have the chance to get picks together and so I'm going to past this week. Kevin, what are your picks? KEVIN: My picks, it was hard picking picks that hadn’t been picked before. So lately, I've been dealing with a lot of UI macs from designers. I've had to sort of design asset based picks. The first is Sketch by Bohemian coding and it’s interface tool, designed tool… it’s kind of in a way as the Adobe’s Illustrator in the past and its companion iPad or iPhone app called Sketch Mirror, and it lets you see your designs on your phone in a nice mirrored way. Same with some of the stuff like xscope and live, but with the nice design tool on the desktop side. The other one that’s for me is called Pixa. It’s a graphic asset management tool, and it’s been handy for me, instead of going through Dropbox folder, looking for what I need, it’s helping me find the images I need much quicker. Basically they are pointed at this Dropbox folder where the designers are putting things and I can look at things based on all sorts of attributes; including color, like I'm looking for a yellow icon and I can tap one tag on the side and see all the yellow images that it knows about. Those are my picks. CHUCK: All right. Thanks for coming, Kevin. I really appreciate you taking the time to come out and talk to us about this. KEVIN: Sure, thanks for having me. JAIM: Keep fighting the  good fight! CHUCK: Yup. All right, are you going to be speaking or traveling anywhere, where people can come and see you? KEVIN: Actually, [unintelligible] is I'm going to be talking about that at Code Mash in January in Sandusky, Ohio. CHUCK: Well, there you go. So if you wanna see Kevin speak, go to Code Mash in Ohio or you can reach out to him in the ways that he mentioned before. And with that, we'll wrap up the show. We'll catch you all next week!

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.