Check out and sign up for iOS Remote Conf! April 13-15th, 2016.

 

01:22 - Dominic Jodoin Introduction

01:46 - Emma Trimble Introduction

02:03 - Travis CI Background and Origin

06:27 - Travis CI vs Other CI Solutions

10:44 - Travis and Open Source

14:47 - iOS and Travis CI

16:04 - Testing and The Backend

21:17 - CocoaPods

22:41 - Support

24:53 - Pricing and Cost

27:33 - GitHub Integration

29:27 - Setup and Tool Support

Picks

Smoked Gouda Cheese (Jaim)
Smooch (Dominic)
Making voice calls in Slack (Emma)
The Most Important Object In Computer Graphics History Is This Teapot (Andrew)
Big John's Cajun Cheese (Andrew)
2016 Chocolate and Cheese Festival @ The Natural History Museum of Utah (Andrew)

 

Hey everybody and welcome to episode 145 of the iPhreak Show. This week on our panel we have Andrew Madsen.

Hello from Salt Lake City.

Jaim Zuber.

Hello.

I’m Charles Max Wood from DevChat.tv. Quick shout out, iOS Remote Conf. Go check it out. We’re going to have an awesome online conference.

We have two special guests this week. We have Dominic Jodoin— I don’t know if I said that right.

It says Jodoin.

Oh, awesome— and Emma Trimble.

Hello.

Do the two of you want to introduce yourselves?

Sure. I’ll start. So, hi everybody, my name is Dominic Jodoin. I am a customer support engineer for Travis CI. Before that I was a software developer for, close to 15 years. I spent three last year with my software developer career doing mostly iPhone and Android development. I am living in beautiful Montreal, Canada.

Hello, I’m Emma Trimble. I am part of the build infrastructure engineering team at Travis CI. I am coming from chilly Pittsburgh, Pennsylvania.

[Chuckles] Awesome. So we are going to be talking about Travis CI. I want to talk a little bit about the origin. I remember, when it came out, the big deal was put your open source projects on Travis CI. It’s all free and awesome. After a while, it seems that it’s gone on to become something that you can also— for your private repositories and things like that— hook it up so that it will run— you can pay to have it run against your other projects.

Yeah. It’s right. We provide free support for open source projects right now and paid for private projects on GitHub.

Let’s step back a little bit cause in iOS world, Mac world, to do some integration is some pipe dream or a myth like Luke Skywalker. So what are we talking about, Travis CI?

You can build and test your iOS projects on TravisCI. We provide to do this real— okay— I don’t know if we can tell them real but it’s actually virtual machine running on Mac OS on Apple hardware but on the Mac OS— OS for sure. Basically you can do pretty much all that you are doing, little [inaudible] but in the cloud.

Yeah. We run OS X, VMs on— in the [inaudible] pair cluster on Mac hardware, super hardware and Mac pros and server hardware has been discontinued for some time. At this point, we’re working at moving to those and just automatically run your builds or compile your project or run your tests against the simulator on there for nested virtualization and iPhone simulator inside of the VM.

For those who are listening which I— I don’t know how many— but for those who are listening that don’t know what CI or continuous integration is at all. Could you just do— just a really basic intro to what CI is?

Sure. The basic of Continuous Integration is to have every change in the code tested automatically so that you can get quick feedback about this specific change. This helps in software development where you can spot bugs right away rather than waiting for the software to be deployed in production where you don’t want your users to find bugs. So the way it works on Travis CI is that we’re hooked with GitHub and we receive a Web hook every time you do a commit in your repositories. When we received this commit on Travis CI, we check out your code. You provide the steps you want to execute. Automatically to either compile and test your projects. We run that script on our VMs and we send you back notifications saying if you’re built as passed or as failed. So that’s really the basic of it. So testing, as fast as possible, every little change you made in your code so that you know right away if it’s right or wrong.

One of the—

Yeah [crosstalk]

—that I’ve seen with this though is that it also contests your built. For example, if usually you’ll build your iOS app on your Mac, on the machine your developing on but I’ve also seen it where you run that as part of your Continuous Integration. What that does is then, any problems in compilation also will show up in the Continuous Integration and make that available so that people can see, “Hey look whatever you did, they broke the build. Not just the built in the test but also in its ability to shift it all.”

Yeah.

Yeah.

Definitely—

Yeah [crosstalk].

— one of the well-known problems that, “Oh, where’s the iBox,” cause you dragged in something from the file system and it hard coated the path on your machine which wouldn’t exist anywhere else. But you provide a set of build server and “Okay. He has no idea what user home Jaim is.” It crashes, sends you an email so your teammates, don’t download it, and say, “Hey you broke the build.” Then they go back [inaudible] or some iBox like, “No, it doesn’t.” So this is nice way to have a clean environment that everyone agrees you need to keep running.

That is exactly what I was doing say as part of the explanation is that they all works on my box conundrum [chuckles]. Trying to avoid any of that in the future and make sure that we have a

standardized built platform every time that you’re build runs.

I think we’ve made the case for Continuous Integration. I’ve seen people do other things with it but for the most part, this is what we see. So how is Travis CI different form some of the other Continuous Integration solutions out there?

From my point of view, it’s hard to tell because I don’t have that much knowledge about their infrastructures. I know CircleCI does support iOS projects. So it’s hard to tell for other CI from my side, unfortunately.

One thing that is noticeable about it though is a lot of companies tend to want to rule their own CI environment with Jenkins or something along those lines. Before, I did that for a time at the job that I was at prior to Travis and it’s really frustrating. That’s a lot of [chuckles] it’s a lot of small things. It’s definitely when one of your options is to relate yourself. We try to make sure that we take care of all the hard work and that’s one of the nice things about hosted CI products in general. I guess though—.

Yeah [crosstalk]. I’m going to say it little less diplomatically than you did because I’ve used Jenkins at a past job as well—.

—and the past job that I worked at similar to most iOS developers. We weren’t using Java which is what Jenkins is written in. So whenever we ran into an issue, it was a royal pain because it’s like, “Oh well I don’t understand the Java Runtime environment. I don’t understand some of the gotchas in Java code.” I mean sure I can look at the code and reason about what it does but that’s not my area of expertise. I’m tracking down bugs as a real pain. The other thing is that my experience was with Ruby. So there had to be some bridge, be it jRuby or it spoon up a different process with Ruby or whatever in order to run it.

Anyway it just had issues because I had to fix all those issues myself. A lot of companies think, “Okay well— Jenkins or something else is— it’s cheaper because we’re not paying for service,” but by the time I rolled on my time into it, in order to make it what the company, that I worked for, wanted it to be, it would have been cheaper for them to pay for a service like this and use it. That’s not to say that can’t be done and that it doesn’t make sense for anybody. But at the same time it was a royal pain in the neck. It would run into memory bottlenecks and it’s like, ”Oh okay. So what I have to is I have to go edit the start script and tell it to start with more memory and blah, blah, blah.” Okay now it means more memory but the machine doesn’t actually have the memory so now it’s swapping and it’s slow, and yeah.

Anyway, my experience has been with Jenkins and similar is that it’s never exactly what you want. You’re going to spend a lot of time customizing it to what you want. In a lot of cases, it’s written in a language that just isn’t your core competency. So it’s easier and cheaper to call support on a product like Travis CI or CircleCI which is the one I use and say, “Hey this is what I want.” How do I do it and have them say, “Okay. Configure it like this like this, add this config files”, tell us what versions you’re using of this and this. Then it’s done.

Absolutely.

I’ve been on teams that have integrated Jenkins successfully for iOS projects but they’ve had dedicated teams and people that, that’s what they did. They kept the cost thing going. Then I’m sure, Emma would attest that it’s a lot of typing and stuff. It’s not the core of what you do. So yeah if— I’ll [inaudible] that stuff and especially for smaller shops when you don’t want to have someone messing around with Jenkins as part of their job

That’s very larger shops that can afford to have a specialized team run it. That makes sense [crosstalk].

You guys are making me feel bit because I’m not on a large team and I’m the one that maintains our Jenkins set up. To be honest, it is a bit of pain especially a pain to get set up, although, I don’t want to exaggerate it. It works pretty well. But the thing that I really like Travis CI for that I think gets into its history is that, I maintain a couple open source projects. I think it’s really valuable that somebody submits a pull request immediately before I ever even look at it. Travis has run a new build with that pull request and tells me if test’s passed or if anything broke, weeds out that bad pull request really quickly and it also makes me feel a little more confident that one has coming in that’s good.

I’d like to know a little bit about how— so Travis really has a big part of open source or is really involved with open source. I’d like to know a little bit about that. Why is it, that open source is important to Travis?

I think it’s— maybe Dominic can comment a little bit more about— it’s been founding core concepts or core priority of Travis, at least from what I’ve seen to really be nice to the open source community. The Travis product itself is— I think it’s 90% open source itself to some extent. We get the same support from other people, other folks submitting a PR to our project. Then naturally, the test run on Travis. It’s a nice thing in general for everyone to have— it’s somewhat of a GitHub like model of try to— main ideal of company is to provide that support for the open source community.

So if I have an open source project and I want to get a set up to Travis CI, what do I need to do?

it’s fairly easy. I can explain a little bit the process. So you type in your browser the url travis-ci.org and you sign in. There’s a big, if I remember well, a green button that says sign in with GitHub. Once you’re signed in, we will automatically synchronize your account on Travis CI with your account on GitHub and we will show your repositories that you have over ride GitHub. Now, you can just enable that project that you want to use on Travis CI.

The next step, it’s basically to push a new commit. We have some intelligence where we try to find the type of project you are activating with us. So we’ll try to detect if it’s Ruby, Node.js etc. When we do that detection, we try to run some basic CI steps. For example, if you have a Gemfile, we’re going to execute bundle in the insolation step. Afterward, if you have a .reg file, we’re going to run a reg test for the testing step. So that’s basically it. And if you want more fine grain control on what your build does on your project, you have the option and it’s something on the command is to create your own .travis.YAML files where you can specify anything you like in those steps like we have what we call the build libscycles— lifecycles sorry. For those steps, you can execute the command you wish— any command you wish.

Okay. YAML is the Ruby like configuration file, right?

Correct. Yup, basically just a quick notice that every step or command is basically what you would execute on a console— I mean in the terminal on your home machines so it’s not a specific language that you need to learn.

Okay. What are some examples of commands? Does it build on a box if you have a say, library or application?

It should for projects that are respecting the standard way to configure and run and test like let’s say a Ruby project. But most of the time it’s the most important step of your build with, I would say, is like the install step where you can install your dependencies. Afterward, there is the script— what we call the script step where you compile, if required, your project. Afterward you test it.

We have also the deploy step where if you want, you can go the next level which is after Continuous Integration which is continuous deployment where you would deploy every commit you make to your project. So in that deploy section, you can specify where you want to deploy your software or application.

So in the iOS world, how does deploy orbit Travis CI?

Right now, we don’t have type integration with the iTune connect service for example. For other deployment provider, we support for example Heroku or AWS. We have some special support where it’s really easy to configure the deployment to those thing provider. But most of the time all it works right now in iOS is that you issue a command like you write the command in your .travis.YAML file; the same as you would do on the command line on your local machine. Most of our customers, I would say, are probably currently using fastlane which I think provides an easy way to upload your iOS apps.

Okay. So are the best lane tools installed with Travis CI?

Yes. They are.

Okay.

We’ve been talking about little bit more integration around the fastlane program. But we’re still [inaudible]. No word on that yet but the iOS version of Travis is one of the newer languages that we support but we’re working hard to make it better every day.

One thing about Travis and well, I guess Continuous Integration, in general but particularly Travis that I think is cool is if you— for some reasons you could test your app or test your code on multiple versions of the OS or multiple— make sure it builds in multiple versions of XCode or something like that. That’s pretty easy to set up with Travis. So I’m curious to know a little bit about how that— what you guys have to do on the back end to make that that all works? You better have lots of different versions of the OS10 and XCode, all installed in different virtual machines, I guess. Is that kind of a pain?

A little bit. This is my area of specialty. We have a large number of different images and keeping them up to date is challenging at the moment. We’re working on automating our image built pipeline right now to make sure that say, a new version of fastlane comes out, we can make sure that whatever image gets used for— the image is determined specifically by XCode version at the moment. So we have 7.3 beta and 7.2 and 7.1 but they are— once they’re made, they’re made. So when say again a new version of fastlane or CocoaPods or something along those lines. So tool that a lot of people use very commonly is that we need to update those manually.

We’re working on automating the image built process to the point where we can make sure that they get updated automatically every that, say, a new XCode version comes out or whatever. But yeah, right now it’s an effort to make sure that we have clean VM images that then and we have an application that organizes those images for – used by our workers. So, you say in the end, it ends up essentially the same request as what is put in your Travis YAML, gets sent all the way through. So for instance, you say, “I want the Objective-C or Swift image for with the XCode 7.2.” That pretty much that seem value gets passed to our image organization tool. Then, we can use that same tool to test our own images in coding to make sure that everything of it— there’s nothing really terribly wrong with the image before we deploy it to production. Then, promote very easily using that API organization in front of the image names and classifications on our end.

Sounds to me like you are handling a lot of hard stuff that if you had to set it up yourself, you would not have fun with it.

Yeah. I think we have a good 25, I think build images that are very— in variously pointed to for different reasons or whatever. Some of them are just build images that have been superseded by a newer one but haven’t been removed yet just in case if the newer one has major issue. But we try to follow a dev test— staging and production promotions atmosphere and make sure that the images that we come up or that come out for production use are reliable and up to date.

Yeah. That’s definitely a solid value ad, being able to have the different versions that your dependents use whether it’s XCode or CocoaPods. Cause whenever XCode comes out of something new— a new version, you’d just ask, “Should we update it?”

Is the built server updated? What about CocoaPods? CocoaPods is a beta release and doesn’t work with the old versions. So you keep doing quite a bit of a dance. So having that taken care of by people who are actually testing it and work through the chords— that’s valuable.

Yeah.

So what— we talked about XCode, CocoaPods. What other type of parameters do you have in the VMs that you support like what would trigger a new version?

Right now, it’s mostly driven by whatever is most needed. In the future, it would be nice to have a new image anytime that I knew. So fastlane, XCode, CocoaPods, there are a couple of other applications that we depend on for that. But we try to update them every couple of weeks at the moment depending on usage of the images and what not. It’s tough right now cause we’re trying to alienate the process but also, trying to maintain the current thing. So it’s very— right now its support driven in a way.

So if I call up and say, “Why don’t I have XCode 12 yet?” You’re going to make it happen?

Yeah. Well yeah. Generally, XCode versions are the number one thing I saw yesterday. There’s a new beta version of 7.3 that’s released. So probably in the next couple of days that our 7.3 beta image will be upgraded to, I think it’s beta 5 now.

Okay. So you’ve got the Xcode beta for versions. So if your team is up on those— those are available? That’s cool.

Yeah. There are a few others but those are the big ones that we try to get proactively.

So I have a question. How, if you’re doing say CocoaPods, how does Travis CI know to run that stuff? Is it in the YAML file? How is it set up?

So as I mentioned before, we try to came up with some default steps for the different languages that we support. So in the case, like the two main steps as I said were the install— installation step. That is called install in the YAML file and the script test step.

So for iOS projects, we said like, “That pod install is the default installation step for this kind of project.” So under the hood, even if you don’t specify and install a section in your Mac YAML file, we will execute pod install at the root of your repository which ordinarily is where your bug file is located.

Okay. So if you’re on a team that just puts all your CocoaPod files into search control and commits it that way, you would want to turn that soft— is that correct?

Yes, that’s correct. So you can do this by overriding the install section and do your own— or just— you can specify true to say just override the install step on your build.

Okay.

Do you have any support now for that— some of the new Swift— open source Swift stuff? Now that people are developing libraries that are not necessarily – well, particularly libraries but soon maybe web apps and things like that, that are not necessarily iOS or Mac projects but are written in Swift. Have you started rolling that out or do you have plans for that? Things like the Swift build system, Swift package manager, that kind of thing?

Right now, we have plans on doing that. We also intend on rolling out Swift for Linux builds as well since they’re releasing Swift Linux which is cool. But right now, I think that the only Swift related tools that we have are on the same OSX images that you would run your iOS or iOS builds against. But we’re actively looking at making sure that we more wholly support Swift in the upcoming months.

Cool. That would be valuable to me and I think a lot of other people.

Absolutely.

How is it that you decide which platforms and tools to support? Do you have some sort of process where people can ask for something that you already have or how does that work?

The first step maybe to learn and ask for— to support a new language. For example, Ruby for— to contact us support at travisci.com. Else, there’s also the possibility of adding it yourself. Since we are open source, I know there are some languages— for example, if I’m not wrong, Elixir. It was— the support was provided by the community. So that’s something we can look into. Of course, as a first step, contacting us; we can give pointers on where to start to do so.

Some folks also open up GitHub issues about it or sometimes we try to keep public updates going on in our TravisCI, GitHub issues. But again very, very much community driven. If it’s something that everybody wants or that a large number of people wants, then we’ll often look into it. Swift is super new but people are very excited about it. It’s getting attraction in a lot of ways. So it’s definitely on our radar.

So TravisCI as far as cost, it’s free for open source project. Is that correct?

Correct. Yes—

Okay [crosstalk]. What if I have a private repository that I want to use this with?

So we have three plans to start with. The difference— the main difference in the plans is the number of concurrent builds that you can run at any time. So the basic plan is for two concurrent build and it’s priced at 129 a month. You have the option to pay annually. If it’s the case, we’re going to give you one month for free. The next build is the five build plan. We also have— we have the ten build plans and if you require more, we can give you a quote on iron plans.

Now, this work on all repositories for a single user, for organizations? How does that work?

Either one of those. Most people use organizations in that case but same plans abide for either users or organizations.

Okay. So you have one account with a hundred repositories but it’s going to have two jobs running so if they’re using a lot, it’s going to be really slow but you could do that.

Yeah. Theoretically, we just limit it to number of jobs running at one time.

What happens when somebody pushes a change and Travis sees that— runs build, runs the test and something fails. What happens at that point?

The build iss going to fail. It’s going to be shown to you in our WebUI. So, we’re going to turn the build page red a little bit. There’s also— you have a couple of options for like the basic one is we’re going to send an email notification to the email you have registered your GitHub account with. So you’ll have an email saying your build has failed and you are going to receive a link to that build on our web app. So you can have a look at the build log. Then inspect what went wrong.

We also support other channels for notifications. For example, Slack which I think is a proper one. You can have a message print in special Slack room – Slack channel where again would include a link to the build log and also the status of the build— pass or fail. I know we are supporting [inaudible] chat also. There might be other ones that I— my memory is failing me— maybe Emma has other examples.

Yeah we have support for iOS, C—.

So you’ve got a lot of options for finding out that your build failed [crosstalk]? Another way that I think is really cool is you have good GitHub integration. So, if a build was— I don’t know how this works— I don’t know if your GitHub that made this but if you have Travis set up on a GitHub project and for example, somebody submits a pull request you see right there on the GitHub page for the pull request, you’ll see the results of the Travis build. Is that something you did or is that something GitHub does?

I think it’s a little bit evolved co-dependently over time. It actually also supports several other— I think it’s a general thing for any CI products at all on Github. Now that I think it originally started with our integration with GitHub. I’m not sure about that so if I’m [chuckles] totally wrong, sorry [chuckles].

Sounds reasonable to me—

I’ll buy it [crosstalk].

I’ve only ever used Travis for— with GitHub integration but sounds good to me.

[Inaudible] has mentioned functionality. I have no idea if it was first or not.

Yeah. I know that. Also, another interesting thing is that the build badge on the repo page that a lot of people do, you can embed an image that is served by our API that whenever you go to a GitHub project— your project page, you can see right there. A lot of people like to put it in the Read Me right there and says, “Yes.” One of the little tags that they put at the beginning of the thing like, “Go here for the documentation and our Travis build is passing right now and what not.” The build passing logo was pretty neat and important thing in the early days of Travis from what I understand. It’s exciting because a lot of times, I will look at a project that I’m interested in to some personal level or something like that and right there at the top of the Read Me, it says, “Build Passing” and I’m like, “Oh, it’s cool. It is my product.” That’s neat.

If you’re setting up a project on Travis, say you’ve got some – oh you need tools that are not really part of what you guys provide by default. For example, what I do, we use Mercurial not Git. I think you have support for Mercurial but then say you want to install where you have some command line tool that you’re using as part of your build process and you need Travis to be able to run that.

Is that possible to set up?

So yeah. It’s definitely possible. The thing is, most of the time, if it’s not already present on the VM, you’ll have to download it. So, your build could take a little longer because of that. But we don’t restrict this kind of operation. So yeah, you can download your— the software you want to use.

Afterward, you call it. You specify all these steps in your .travis.YAML file.

As I said, I don’t believe we support Mercurial that’s on— it’s been talked about but we haven’t really incredibly Git centric work flow at the moment.

I’ve never tried it. You just say that— you say somewhere that— used to— that Mercurial is installed on your VM images.

It might be, yeah. It’s probably on the VM images but if you have Mercurial repo of that you wanted to run Travis every time that you did a push or whatever. I don’t really do that functionality that exist right now.

Okay. Well, too bad. I love Mercurial. So, I had never—.

Yeah [crosstalk].

—once switched but it’s— Git has the advantage of having such a big ecosystem to what Dominic said. So I guess because you allow people to do that; that must mean that you always reset the VMs back to the fresh state since the build’s done. Is that right?

That’s absolutely right. We essentially terminate and delete the VM after it’s done. So every VM that starts up is started from an image. In the case of our container based builds, started from a doc or image. Each time and any changes that were made are completely blown away. You have a new fresh VM, each time you can pretty much augment however you need to do so.

TravisCI— we’ve talked mostly about GitHub that’s vary support for say Bitbucket or other host?

Unfortunately, not at the moment. This might change in the future but right now, we’re focused on providing the best CI experience with GitHub.

That sounds good.

We’re getting close to being out of time. Is there anything about Travis that we haven’t touched on that you think is important and we should talk about?

One thing I would like to say is that, I think we’re still in the early days of our iOS support. I think there is a lot of thing we’ll want to improve in the future to provide better experience. Yeah, I think in the future, we’re going to be better at supporting iOS projects.

I’m happy to hear that. Although if you had asked me based on my experienced with Travis which is relatively limited, I’m using it for some open source libraries that are for Mac and iOS. I’ve been quite impressed. It was really easy to get them set up and running. No hassle at all. Like 5 minutes the very first time I get it. So I think you’re doing a good job. I’m glad to hear that more stuff is coming.

Thank you. Yeah.

Thanks and important note and with that regard, if you have any suggestions or ideas for a thing that we could do better in the future with iOS development, again, or iOS support. Please let us know cause we’re always ready to listen to what people want to have in their builds; very community driven and yeah.

Yeah. It’s a great project. So thanks for telling us about it.

If you’re listening and you’re not doing Continuous Integration, you should cause it’s really valuable and Travis could be a great way to do that. So check it out.

Should we get to the picks?

Let’s do it.

Jaim, do you have some picks?

Yeah, I’ve got one pick today. I’m going to do a cheese pick. So at the grocery store that I go to, they got cheese car of a fancy cheeses. And every once in a while, they do a Grilled Cheese out there and put it out there. But you can sample at in. Normally it has a grilled cheese. That was good. Thanks to this grilled cheese sandwich and take off but one was excellent. I guess, Smoked Gouda and I don’t know if it really matters where we get it from. This one was made in Wisconsin but I’ve used in sandwiches like a Salami and smoked Gouda or summer sausage to grilled cheese. So look for some kind of cheese. Smoked Gouda is an excellent cheese. I’m a big fan.

That’s my pick.

Nice. You might make me have a cheese pick. We’ll see. Dominic, how about you? Do you have any picks for us?

Yes. I have one. It’s a product. In full disclosure, is the last product I worked on but I’ll go and tell what it is actually. It’s Smooch, Smooch.io.

Smooch.io is a ZK, an iOS ZK, an Android ZK that allows application mobile, application developers to engage with their customer. And what this ZK does is that one line of code, you can have an in-app chat view where your customers or users of your application can— you can communicate with them; they can communicate with you. I think, it’s a great product and they are solving a problem that’s really important for mobile application developer which is retention. How can you make sure that your users are engaged with your app and they keep using and returning to your app every time? So it’s called Smooch and the URL is Smooch.io.

Nice. Somebody was just asking about this kind of thing. I’ve never seen Smooch before. But it looks pretty cool. Emma did you have a pick for us?

Yes, it’s going to point out that apparently, Slack just added support for calling in the Slack application which is neat.

Oh I’ve been wanting [crosstalk].

—Yeah. It’s not, it’s just audio at the moment but I’m assuming that there’s going to be video soon, too. I don’t know if it was just added or it’s beta thing but I don’t know, it may be neat. I guess that’s the— seems to me— coming out of the acquisition of screen hero last year.

Yeah. That’s— that would be really nice because right now people switch to Skype when they want to do audio calls.

I’ve got couple picks today. My first pick is just an article that I’ve found. It’s actually on Hacker News right now called The Most Important Object In Computer Graphics History Is This Teapot. It’s about the history of computer animation but in particular, it’s about the Utah teapot and the University of Utah and their Computer Science Department and the important role they played in the development of Computer Graphics. This is just near ender to me because I went to the University of Utah. When I was growing up my dad actually worked that, one of this companies that spun out of the University of Utah that was a big pioneer of free graphics called Evans and Sutherland. It’s fun to read about this history that people I know were close too.

My second pick is based on Jaim’s pick. It’s cheese pick. It is called Big John’s Cajun Cheddar from Beehive Cheese Company. It’s a local cheese company here that makes some really good cheeses that I like. Along with that would be, I don’t know what you call it, it’s a chocolate cheese festival that they do here. It’s just get to go. Samples of chocolate and cheese from lots of different local chocolate and cheese makers and I’m looking forward to going it’s on the Saturday, March 19th and Sunday the 20th at the Natural History Museum of Utah. Probably not too interesting to those who are outside of Utah but I think we have a few listeners here. So those are my picks.

Based on the iPhreaks charter, if you pick something that I can’t pick up at the store, just send me some. Just so you know.

Okay. Or I could bring you some if we meet up in San Francisco.

Perfect [crosstalk]!

—in San Francisco.

Can I get you both to just send me cheese? [Chuckles] Indiscriminately since [inaudible].

Well sure. But we can’t set a precedent because I don’t have money to buy cheese for every guest. [Chuckles] It is a really good cheese and they have some other cheeses that I really like, too.

I’ll trade you some cheese for some protein.

Okay. I’ll do that, too. I guess that’s Dominic’s Department but it definitely takes some—.

Yes. I’ll provide some.

Alright guys. Well, thanks for coming on. It was great to talk to you to learn a little bit more about TravisCI and how we can use it as iOS developers and all the cool stuff you’re doing behind the scenes. So thanks for being here.

It’s great to be here. Thanks for—

Yeah. Thanks a lot. Plus one.