This week we talked with Richard Hipp, the creator of SQLite, about its history, where it came from, why it succeeded as a database, how it’s development is sustainably funded, and how it’s the most widely deployed database engine in the world.
The Changelog #201: Why SQLite succeeded as a database with Richard Hipp, creator of SQLite |> News and podcasts for developers |> Changelog
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York and L.A. bid on iOS developers, providing them with salary and equity upfront. The average iOS developer gets an average of 5-15 introductory offers and an average salary offer of $130,000/year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It’s totally free for users, and when you’re hired they also give you a $2,000 signing bonus as a thank you for using them. But if you use the iPhreaks link, you’ll get a $4,000 bonus instead. Finally, if you’re not looking for a job but know someone who is, you can refer them on Hired and get a $1,337 bonus as thanks after the job. Go sign up at Hired.com/iphreaks]
JAIM: Hello everybody. Welcome to episode132 of the iPhreaks Show. Today on our panel we have Andrew Madsen.
ANDREW: Hello, from Salt Lake City.
JAIM: And I’m Jaim Zuber who needs no introduction. Sure has a bit of an ego problem today. Our guest today is Felix Krause.
Felix, you want to say something about yourself?
FELIX: Hey everyone. Thanks for having me. I’ve calling today from San Francisco.
ANDREW: Can you tell us a little bit about what you do and why you’re interesting? I think a lot of our listeners already know who you are.
FELIX: I’m Felix. I developed this open source stuff I call Fastlane. It’s a set of open source command [inaudible] tools to help you automate all aspects of building and deploying application. Recently, I joined Twitter to work full-time on Fastlane that’s why I’m in San Francisco now.
ANDREW: I’ve used Fastlane a little bit especially lately. I think it’s really cool; probably a lot of our listeners have used it. It’s gotten quite popular, but I’m curious to know how the whole thing started. When did you start on Fastlane and what was the motivation behind that?
FELIX: At one of my previous companies had [inaudible], we had the solution and mobile absolution for golf clubs. Every golf clubs have their own application which all had the same coop but different content.
Basically, we had to maintain and publish a few dozens of applications all with the same code. So every time I update the code, I needed to deploy new versions to the app store. I decided to automate all these and develop something for this company in particular. Then I was talking with other iOS developers; they were all really interested in how I did the deployment, not too much about how they [inaudible] the effects. I then decided to implement the same thing the right way, so that’s all the companies around the world can use the same thing I use for this company.
ANDREW: Was this something you just did on your own, like in your spare time at first? Were you able to get the company to sponsor it? Because it’s been open sourced since the very beginning, is that right?
FELIX: Yes, it’s been open sourced since the beginning. I developed this during my last year at the University in my spare time. The way I usually do it, I develop it not being open sourced and as soon as it’s ready and people have tested it, I make the repository public on GitHub.
ANDREW: I like that style of development; it keeps you from putting something out there that’s embarrassing.
Tell us a little bit about how – can you give us a really high-level overview of how you put Fastlane together? It’s a whole collection of tools, right?
FELIX: Yeah, it’s important to know that Fastlane tools is like a collection of tools that help you with all kinds of things. For example, there’s deliver, there’s snapshot, there’s frameit; each of these tools solve one very specific tasks and Fastlane itself is a tool on top of all these other tools that connects all Fastlane tools and third party tools into one workflow, so you just define which tools and which steps to run and Fastlane will execute them in the right manner.
Additionally, Fastlane integrates with a lot of third party tools, so right now they’re around 113 integrations available.
ANDREW: I want to get back to this because I think we can talk about it in more depth, but you have a plugin architecture essentially. Other contributors can pretty easily write new actions for Fastlane to integrate with some other – just to integrate with some other tool or to perform some action that is not built in and can helpfully contribute those back if they’re useful.
FELIX: Yeah, that’s right. It’s very flexible. When Fastlane first launched, there were only ten integrations and now it’s over a hundred. Most of them were contributed by users, so there’s even a command which is ‘Fastlane newaction’ and then it will help you set up a new action for you so you just have to write implementation itself. You can even extend Fastlane locally so only you have a new action that is, for example, very particular to your own company. Additionally, you can also always call typescript or other type of script from within Fastlane so you can easily use your existing bids, script and automation scripts.
ANDREW: So what language is Fastlane itself written in or are these tools written in?
FELIX: It’s all written in Ruby, in particular – interesting is that all configuration files so each of the tools has configuration files like a fast file, a deliver file, a snap file – they’re all based in Ruby, similar to what CocoaPods does with the pod file. This allows the user to have a very flexible configuration.
Most users don’t know the right [inaudible] configuration files because it basically looks like a configuration between json and yml. You can do better flexible things; you can have loops there, you can fetch values on the month from the remote server. You can even extend it to use your own gems within this configuration files.
ANDREW: Why did you choose Ruby? Was there some reason at the beginning for that? Were you inspired by another project? What was your thinking behind that?
FELIX: There are two big reasons for that. The first one is that CocoaPods is based on Ruby, so I thought it’d make sense to use the same language to offer better integration. Secondly, the most Nomad tools which is developed by Matt Thompson; these are tools like ShenZhen, Cupertino and so on. They are a big inspiration for me because these tools are so simple and works so well, and they were also based on Ruby. At the beginning, I integrated some of them within Fastlane.
ANDREW: That actually leads perfectly into what was going to be one of my next questions which is, probably a lot of people know about Nomad. I think it’s been around longer than Fastlane. How does Fastlane differ from or improve upon Nomad? Because some of the things that Nomad does are the same sorts of things that Fastlane does.
FELIX: Yes, that’s true. In the beginning, many of the tools used Nomad tools – some of them. In particular, Shenzhen is a very cool project. So I just integrated them because I don’t want to reinvent – I didn’t want to reinvent the wheel. The problem is that Nomad tools are not actually implemented anymore so the only one with commit excess is Matt Thompson who is not working on it anymore.
Basically, I had to re-implement the most important project, Shenzhen which is now available within Fastlane under the name of ‘gym’. It was completely rewritten under that Fastlane architecture and supports the latest API for Xcode 7.
In general, Fastlane is using Nomad tools and is still using some of that.
ANDREW: Interesting. I don’t think I realize that at all that it was actually using some of Nomad.
FELIX: For example, there’s one project called Cupertino to register devices of fetch [inaudible] profiles. For a long time, Fastlane was using that to register new devices but after the recent changes of the app with the developer portal, I completely switched to Spaceship, one of the Fastlane tools to register new devices.
JAIM: So your initial problem you were trying to solve was you work with golf clubs. By golf, we’re not talking about the driver or the number 9, we’re talking about caddy check, like golf clubs where people go and play. You had an application which you light-labeled for different golf clubs so you would have to maintain a bunch of different versions of the application that’s specific for some golf club in Florida or some golf club in Scotland. Is that what you were trying to solve?
FELIX: Yes, correct. Basically light-labeling of applications. It has nothing to do with golf clubs themselves, it was just that we had a lot of applications and I didn’t want to manually deal with that.
JAIM: Okay. So there’s a number of companies that have app that do light-labeling and they’ve got different processes for doing a bunch of different applications. It’s not what most of us are doing day to day; most of the companies, they don’t have hundreds of applications. What are some of the things that these tools help you with for people who are just doing – have one application?
FELIX: Interesting question. In the beginning, I thought about doing it primarily for white labeling applications, but people started using it for their own app, like if they’re only working on one application.
One example that Fastlane helps you save a lot of time very quickly is generating screenshots using snapshots. So you generate localized screenshots for all the language and device combinations, then upload them using deliver. The interesting thing about that is it supports about ten languages with six devices now moved to [inaudible] pro and five screenshots each, you end up with 300 screenshots you have to generate and then you have to upload ten to iTunes connect.
This is something that is not scalable because you have to change the screenshots every time you change the design of the application, or every time there’s a new device or every time you add in your language. [Crosstalk]
JAIM: So it’s screenshots for iTunes connect for what goes in the App Store?
FELIX: Yes, that’s what I mean.
JAIM: Typically, how that works – I’ll talk to whoever is in charge in saying what screens are going to be taken pictures off? How do you determine what screens to take images of and which languages?
FELIX: Within snapshot, you provide a UI automation file which is based on Objective-C or Swift which tells snapshot how to navigate in the app like tap here, tap here and do this, then that would take the screenshots.
JAIM: Very cool. So it just runs a UI automation script?
FELIX: Yes. [Crosstalk]
JAIM: Very nice.
FELIX: It was used. It was based on UI automation up until a few months ago. Recently, snapshot 1.0 uses UI testing which is now Objective-C and Swift.
JAIM: Okay, very nice. So you just run through your app. So for UI testing, you just press the record feature if you’ve got UI testing in the app, click on some things and designate that these are the things you take a screenshot of.
FELIX: Yes. While it sounds very simple, it depends on how much accessibility support the application already has but if you have good accessibility, [inaudible] would be really fast to implement.
ANDREW: I used snapshot on a project I was working on a few weeks ago and I was very impressed. It’s just a really cool tool that took a lot of pain out of something that was pretty hard before. Because it was an app that has seven localizations and runs on iPad and iPhone. That’s a lot of screenshots to take by hand so I very much appreciated what you did there.
FELIX: It’s great to hear.
ANDREW: And there’s another part of that that I used that I also thought was super helpful which is that you have a tool for uploading all these kind of metadata to iTunes Connect. So if you take a bunch of screenshots with the new version of your app and going to iTunes Connect, you have to drag all of these image files in for each localization and it’s pretty tedious but you have a tool called deliver that will upload all of those automatically.
FELIX: Yes, that’s correct and it works seamlessly with snapshot. So if you generate this [inaudible] using snapshot and then just run deliver, it just works. Up until now in iTunes connect, you had to upload screenshots one by one. At least now you can upload them five at the same time.
ANDREW: Yeah, but it’s five at the same time if you’ve got lots of devices and localizations and still a lot. I think I had to upload 125 or something like that – 175 maybe, screenshots.
FELIX: Did you try using deliver for that?
ANDREW: I did. Used deliver and it went really smoothly but if I had not used deliver, that would’ve taken me quite a long time.
FELIX: Yeah. Deliver not only upload screenshots but those app metadata and binaries. So with deliver, you ca actually upload all the metadata, the binary and even submit your app for review.
ANDREW: So turns out that I found Fastlane really useful just to use manually to do this kind of stuff but it seems like a big use case for Fastlane as for continuous integration. Can you talk about that a little? How do people – how are people using Fastlane there? I think most of our listeners know but for the benefit of those that don’t, maybe explain a little bit about what continuous integration means especially for iOS developers.
FELIX: Right. So with continuous integration, you usually set up a server that verifies that all tests are passing and you add compiles after each and every commit. This is very useful to detect regressions early, to detect if you break something very early so you can easily fix it or revert the change.
Fastlane itself is not a CI server but can easily be used on new CI system, on new CI server. Most people use something like Jenkins or Travis CI or some other host CI solution. There is also Circle and Bitrise, and all of these hosted CI solutions that offer iOS machines have Fastlane pre-installed actually. You can then use Fastlane to run the test.
It sounds easy to run tests; it just [inaudible] built but actually there’s a lot of things to consider like the available simulators, the iOS version and a lot of bots to back around so that the simulator doesn’t crash.
Fastlane does all that for you. There’s one tool dedicated for testing which is called scan and scan does all that for you. It’s pre-installed on the CI machine so you can easily use it there. That’s what Fastlane people use.
As an alternative for running a CI server for iOS project is of course Xcode bots or Xcode server which has really nice UI. You set it up when you own Mac mini or a Mac machine and it’s lightly integrated into Xcode.
ANDREW: I’d like to step back a little bit and talk about – you talked about how you got started with Fastlane. It’s gotten really popular. I know a lot of people are using it; you just mentioned that it’s pre-installed on one of these hosted CI solutions and I’m curious to know how you worked on growing the community and causing Fastlane to become popular, [crosstalk] have good support system.
FELIX: Yeah, that’s an interesting thing. I don’t know why [inaudible]. One interesting story that I actually had two versions of snapshot a few years ago, so I launched snapshot three times basically with different implementations obviously.
The first version was based on Apple script and it had ten GitHub starts. No one really used it except for me. Then I had a second version called our screenshot. This was also not popular, like 20 stars on GitHub. The current one has, I think, 1.5 thousand now. So it just took a while to get it right so that people see these tools, understand them and want to use them. With each tool I launched – with each new feature I launched, the spike of people visiting these tools was getting bigger and bigger. That’s mostly because more people were fascinated of how these tools work and to see how easy it is to use them.
One of the main marketing things that – basically the iOS Dev Weekly which comes out every Friday. Since I had zero marketing [inaudible] obviously because of an open source project and I was doing it in my spare time. I was definitely – it was always my goal to get into and this was probably one of the most important things to get into.
ANDREW: how interesting. Yeah, that doesn’t surprise me. I think so many developers subscribe to that. We’ve had Dave, the guy who does iOS Dev Weekly in the show before. He just does such a good job with it that it has become really a go-to resource for a lot of developers but that doesn’t surprise me.
I think I heard about Fastlane on Twitter just from a friend tweeting about it.
FELIX: Yes, or me personally, Twitter’s the main communication platform. So I communicate with all my developer friends there, and in general, I tweet mostly about Fastlane obviously. This is something I use but some people don’t read all the tweets so they just glance over it so they miss some news. Secondly, some people don’t use Twitter and those were the people I was able to reach with iOS Dev Weekly usually.
At the beginning, when I started Fastlane I had 200 followers maybe so I was really happy to get something else. I was very lucky that Walter [inaudible] from CocoaPods was kind enough to retweet my first few tweets which helped me a lot to get more followers and more attraction on the GitHub repo.
ANDREW: So step one, make friends with [inaudible] or maybe Dave.
ANDREW: Yeah. We’ve had [inaudible] on the show, too. He’s a cool guy.
ANDREW: How many people now have contributed to Fastlane? I get to sense that it’s still you doing a lot of the work but I think you’ve done a good job at attracting other people to help with it. Is that true?
FELIX: Yeah. As for now, I’m the only one having the overall concept across all repos but I do have a lot of contributors for some of the projects. Right now, I think 250 people contributed to all the repos.
It’s hard to get the actual number because there are like 25 repos now already. It’s really hard to keep track.
A lot of people told me it was their first contribution to open source; just little things like correcting spelling mistake within the source code and these kind of things but – this is back when we did well. People in general submit issues on GitHub so all the discussion happens publicly which is something I really like so people can search for issues and take part of the conversation.
ANDREW: We talked on our episode last week about open source projects and what it takes to run an open source project and managing one. Relevant to that last episode – I think I mentioned on our last episode that I tried to encourage people to go out and contribute. I’ve actually made a small contribution to Fastlane myself. I must say it was quite easy because of the way you’ve designed the project. It was quite easy to dive in and add a little bit of – it was a little new feature that was useful to me and I added it. It was a pleasant experience so I think you’re doing a good job. I would say to listeners that this might be a good way, if you’re using Fastlane, to liking it, contributing to it would be a good way to get in to open source in that way.
FELIX: That’s good to hear. What kind of contribution was it?
ANDREW: There’s an action for setting the version number of your project based on your repository revision.
FELIX: Yeah, the number of commits was it?
ANDREW: Right, and I added support in doing that in a Mercurial repository because I use Mercurial rather than Git network. So there was already an action there; I just added branch to it so that Mercurial would work.
FELIX: Right. Sounds good. For example, there’s one repo which is called countdown and it allows you to quickly get started to contributing to Fastlane so it will clone all the repos and describe how you can run tests, how you can run the tools locally and how you can submit a pull request so it would really easy to – fun to use to get started.
It also gives you tips on how to debug in Ruby, how to configure your text into these kind of things because most people of course are iOS developers so they are usually not familiar with Ruby. But in general, the language is so easy that many people just say, “Excuse me for my Ruby; I’m not a Ruby developer,” but usually it’s just fine; there’s nothing to change.
ANDREW: Yeah, I found that very helpful. I’m not a Ruby developer. I sometimes find setting up – I dabbled with Ruby before but I always find getting the host tool chain setup a little bit daunting or lots of different pieces. It’s just not what I’m used to so you gave clear instructions that made that pretty easy to get going with.
FELIX: Yeah, that’s good to hear.
JAIM: I noticed that some of these tools that you actually do code signing, provisioning – how do those work? When would you use those?
FELIX: You mean how does all the code signing tools back in general?
JAIM: Not in general but if you’re used to [inaudible] doing it through Xcode or going to the Apple sites, developer sites, how do you integrate sign certs? How would you integrate that into your workflow?
FELIX: Okay. So basically in code signing, you need two things – three things. You need the code signing identity which is basically the certificate and the pilot key, then you only have an app ID which is basically a bundle identifier. Then you have a provisioning profile that combines to do the app ID and the code signing identity.
So the concept is actually really simple; it’s just sometimes hard to understand error messages and debug issues. Xcode has some kind of syncing technique which is usually exposed using the ‘fix issue’ button. The thing is that it is using Xcode managed provision profiles.
I don’t want to touch them with Fastlane because I don’t want to break anything with Fastlane. So for a really long time, Fastlane couldn’t even do anything distractive. It couldn’t delete anything, it couldn’t revoke anything. This is for one important thing, so it doesn’t touch the manage provision profile stack, the manage provision profiles but maintains its own set of provision profiles. And it has a very strict naming rules so it will always call them bundle identifier and [inaudible] so you can easily see what kind of provisioning profile it is.
Basically, when you want to use these tools you first run [inaudible] which will make sure to have a valid code signing identity installed on the local machine then you run sigh to fetch or create a provision profile matching the code signing identity we just created. I want to have these two commands, you can only build and sign your application using a tool like gym or using Xcode.
JAIM: Okay, so these are separate than the ones that Apple will build for you through a website or whatever?
FELIX: There are separate provisioning profiles but you can see them on the app developer portal of course.
JAIM: Okay. You build it on your own then you submit them so that – you can’t see them but they’re just different than what you do normally.
FELIX: They are different from the Xcode managed ones but sigh does the same way as if you would create it manually on the developer portal.
ANDREW: So a lot off what Fastlane does requires Fastlane to interact with Apple, with iTunes Connect, with the developer portal, with Xcode, etc. I don’t know anything about this and I’m curious about how much of these stuff is covered by API that Apple publishes and how much you sort of had to figure how to do on your own?
So there are three different API [inaudible] Spaceship is using. First, there’s iTunes Connect; iTunes Connect itself offers a very nice json API because the front end is based on AngularJS so this was very easy to integrate. Then there’s the Apple developer portal which provides some kind of HTML json mixed API and it is used for certificates, provisioning profiles, devices and these kind of things. Then there’s a third API which is the Xcode API that is used by Xcode then you would click, sync, provision profiles.
So Spaceship unifies all these three peer points and provides a unified Ruby API which every developer can use to build their own tools. I saw some really nice blog [inaudible] about people using Spaceship to migrate al the devices and certificates from one account to the new one for example, from one [inaudible] to another one. So all these other Fastlane tools use Spaceship to communicate with Apple.
ANDREW: Sounds like some of that was probably pretty challenging to implement I would guess. I don’t think that Apple designed – at least didn’t design all of those services with developers in mind. I just have a feeling you’ve run into trouble that you’ve had to fix or work around.
FELIX: Let’s put it like this – it was very fun working at it so there is no documentation for this API end points but they’re all publicly available. And I can really say this is amazingly fast. For example if you generate a push notification profile using pem, it takes under one or two seconds to do everything; like to submit a signing request and then generate push notification profile. So it’s really, really fast and really, really stable and it allowed me to have a very good test coverage as well. So since this is all web-based – Spaceship itself is all just a plain HTTP client that’s why it’s so fast. It has a test coverage of 98%.
ANDREW: Has it been at all difficult for you to keep up with changes in Xcode because I think, especially in the last couple of years, Xcode has changed a lot.
FELIX: Not so much with Xcode. The thing that recently took a lot of time, changes within iTunes Connect. Just two months ago, Apple changed the way iTunes connect works regarding app metadata. For example, the name is not [inaudible] the version anymore, these kind of things.
So these are time consuming to update but the good thing is that since there’s only one place to change which is in Spaceship, I’d work a few hours in this, pushing a new version of Spaceship and all the other tools that I could get. In general, I’m really fast adapting these changes because I don’t like Fastlane to be in a broken state.
ANDREW: You mentioned at the very beginning of your introduction that you now worked for Twitter and I think this is pretty widely distributed news that Fastlane had been acquired by Twitter. I’m curious about how Twitter found Fastlane and what it is about Fastlane that they like.
FELIX: I think it was briefly after the initial Fastlane release, it was already at Crashlytics’s beta integration so you can upload your builts to Crashlytics beta testing. Basically, they reached out to ask if it was easy to integrate, there is decay; if I need any help or if there’s any way we can offer a better integration between these two tools. So we just started talking about these kind of things. Thinking about offering better integrations and making it easier for developers to use these tools. Back then, I was initially supposed to go to Apple [inaudible] internship which I basically cancelled because I want to work on Fastlane full-time.
During the summer on Twitter, we came back into the country again and we decided it makes sense to really work together and bring Fastlane forward and – what [inaudible] Fastlane became more than a full-time job so there are more and more people using it. The more people use it, the more requests you get, more GitHub issues, more GitHub pull requests, more emails so it quickly became a full-time job so it made sense to be employed to work on Fastlane full-time and that’s why I’m here now.
JAIM: That’s cool. How long have you been in San Francisco?
FELIX: Pretty much three months now since September.
JAIM: Very nice. Where did you live before?
FELIX: I’m originally from Austria, from Vienna. I studied in UK for a year and then I went straight to San Francisco.
ANDREW: Do you like San Francisco? How has the move been?
FELIX: It’s good so far. The people here are really great and there are so many fun events going on. So may like minute people. The craziest thing that happened so far is I was walking around in the park and someone recognized me and basically thanked me for all my Fastlane tools. I didn’t know this person obviously; he was just someone walking around. That’s something that happens since I’m in San Francisco.
ANDREW: Yeah, you’re only a celebrity for your GitHub projects in San Francisco.
JAIM: And Andrew, you show up to Minneapolis, you’ll be a star.
ANDREW: Yeah, right. [Chuckles]
JAIM: I guarantee it. Please do.
ANDREW: I somehow doubt that Jaim but I would like to visit Minneapolis sometime.
JAIM: I’ll put up a billboard. [Chuckles] Andrew’s coming.
ANDREW: Is there anything about Fastlane that we haven’t covered that you want to talk about?
FELIX: In general, I’m really happy about how positive and great the community around Fastlane is. I feel like every time I tweet about something I like about Fastlane, people are super happy and supportive. I can ask questions and feedback and that’s been really good. In general, I feel like when I announced that I now work full-time on Fastlane under the name of Twitter, people were extremely happy and supportive about this. It felt like everyone who contributed and every fan of Fastlane, they felt like it is their project because they contributed to it. I always ask for feedback, I value the opinion and so on.
I don’t know how it works and why it is that way but I’m super happy about how it turned out. I’m really glad about the whole community, in particular Fastlane community but also the whole iOS developer community.
JAIM: Yeah, it’s exciting to get a big company behind cool tools and having people sponsor to work on them full-time so that’s exciting for the whole community.
FELIX: Yeah, that should happen more often for more projects.
ANDREW: I think it reassures us too that you’re not going to have to stop working on it because you get another job or whatever, or let it die like unfortunately Nomad has. It’s hard to maintain an open source project when you don’t have any money coming in for it.
FELIX: Yeah, and as soon as a project becomes popular, it is just so much work. Also, you don’t only have to maintain it but you also have to bring the project forward to stay up to date otherwise it is slowly going to die.
ANDREW: I’ve been impressed at how fast you’ve responded to issues. I’ve opened two or three issues on Fastlane tools and also submitted a pull request and I think you were – had an answer and a fix for them within – seems like I went to bed and the next morning, you have updated the issue saying you have fixed it. It was super-fast turn-around so whatever you’re doing, you’re doing a good job.
FELIX: Well thank you and I’m happy about this. In general, I push releases very, very often. So in general I guess I have around three to five releases a day of different tools because every tool is like its own gem because as soon as there is a back and as soon as the fix button is back, I don’t want this back to be around [inaudible] anymore that’s why I push a fix. Because this quickly became a problem, because people kind of complained that they always need to update Fastlane, we just updated it to run it and it’s all very out of date. There is even an option in Fastlane to automatically keep itself up-to-date if they use it [inaudible].
ANDREW: If people are listening to this and they have not used Fastlane in the past and they’re interested and they want to get started using it, how should people go about learning about it and getting set up to use it?
FELIX: In general, the website fastlane.tools is a good start because you can get an overview of developer tools and what you can do with them. There is also a video of a presentation at NSConference which might help, but I just recently gave a talk at CocoaHeads in Stockholm. I tweeted about the video but I can send it to you afterwards to put it on the [inaudible] which is a good way to get started with Fastlane because I also have – during the presentation I do a live demo where I have an empty Xcode project and set up Fastlane from scratch, to generate screenshots, to build and sign application and to upload all that to iTunes connect. So I think it usually helps to see something like this in action.
ANDREW: Yeah, you should send those to us and we’ll put them in the show notes. Are there any problems that people run into using Fastlane that – not problems because of bugs or whatever but just parts of using it that are difficult?
FELIX: Yeah. Right now, some people still have difficulty setting up code signing because it is not super easy as it is now with Fastlane; you still have to understand how the basic concept of code signing works.
I have a feeling that Apple wants to let go away of that and wants it so easy for you to code sign. You see the fix issue button and the syncing of profile and these kind of things. In the long run people will probably not have to think about code signing but right now you still have to know how it works. That’s one of the main issues people currently face.
ANDREW: I can agree with that. I’ve been doing iOS development since the very beginning and it has always been hard – code signing has always been hard. It’s gotten a lot better than it was but still –. [Crosstalk]
FELIX: Sometimes you have to just revoke all the certificates, provision profiles and create it from scratch.
ANDREW: Yeah. I like the name of Fastlane’s tool, sigh. It’s good.
FELIX: Yeah. Also this name was given to me by a fan, by a contributor. It was not my idea.
ANDREW: Yeah, you’re – the names for Fastlane tools are actually pretty clever. I didn’t really think to ask but how did you come up with names?
FELIX: That’s the hardest part. Also, coming up with colors; I always want a lot of colors. For example, gym is – the name has something to do with building because of body building and gym so there’s always some kind of connection between the tool and what it does.
It’s really hard to come up with things because they have to be short, like people have to remember them. One thing else we did sometimes is to look at a list of three-letter words and just see what words there are and what words would make sense. I also make sure that the name is free because Ruby gems name has to be unique; you cannot have two gems under the same name.
ANDREW: Oh yeah.
FELIX: Usually it helps to just talk to people, as them for feedback and they have some really good ideas to just –. Hanging out with friends and asking them for random names helps.
ANDREW: There’s something – I don’t know how new this is but I just found out about it recently but you’ve now got some support for Android development in Fastlane. Can you talk a little bit about that and how that came about and where you’re going with that?
FELIX: Yeah. It makes sense to use the same deployment tool for iOS and Android basically for all major mobile platforms. It was the plan for a long time already, but now that they work full-time on it, it enabled me to focus on Android as well. So we have some basic Android support right now so you can run tests, you can build your Android application, you can upload it to Crashlytics data, you can upload it to Google Play and you can even upload app metadata to Google Play that comes out.
The basic features that is already here but we are working on improving that offering more tools, offering improved documentation. But the plan is that if an iOS team is already in Fastlane is that they tell the Android team, “Hey, Fastlane is now available for Android as well. Don’t you want to use it so we have the same tool for the deployment?”
ANDREW: Were you an Android developer? Are you an Android developer?
FELIX: Not at all, no. I’m an iOS developer.
ANDREW: Have you just had to learn fast or have you gotten help with this because I’ve never done any Android development at all and it seems daunting to try and figure out all these same problems for Android when you’ve already done it for Xcode and for Apple’s.
FELIX: Yeah, so Android is not as – Android in this process is not as complex as the iOS one. So in code signing for example is much, much better.
It is not better but it’s easier for the user. I’ve already implemented parts of it for this previous company for their golf course company because we also had an Android app. So I had some basic knowledge on how to release processed works without knowing anything about Android development itself. Now that I work at Twitter, I basically had the resources to talk to people who developed a lot of Android applications already, take about the pain points they’re facing and there Fastlane can help.
JAIM: Very cool. Anything else you want to talk about before we get to the picks?
FELIX: I think that’s all for my sites. Do you have any questions? Any [inaudible]?
JAIM: Now I’m ready to get started using Fastlane. I haven’t been using it.
ANDREW: You should, Jaim.
JAIM: The team I’ve been working with has their own setup. They might be using it under the hood but we have someone who handles all that for us. Just nice. The other projects I have were small enough where I just haven’t had the chance to. Now this would save you time; I do a lot of the stuff myself for smaller clients or things like that so I’m pretty impressed with it. I’m glad to get the intro.
ANDREW: I think each one of these tools from Fastlane, even if you’re only going to use one of these tools, they’re all useful. In particular, I’ve mentioned snapshot has been really good for me but – snapshot and deliver both but they all do something that is either difficult or would be hard to automate on your own. I really recommend checking this out. Even if you’re small, your own developer writing, your own apps – there’s probably something here that will save you time.
FELIX: Yeah, and in general going from one tool to Fastlane, the umbrella tool is very easy. It even offers to move all the existing files into the Fastlane subfolder. So it’s very easy to get started with one tool then if you like it, you can start using Fastlane to automate more and more things.
JAIM: Alright. Let’s get to the picks. Andrew, what do you have for us?
ANDREW: I’ve got a couple of picks today. My first pick is – we talked about iOS Dev Weekly. I think a lot of our listeners are probably already subscribed to that and if you don’t, definitely go subscribe. But there’s another newsletter that I’ve been subscribed to for a little while now called Swift Sandbox. This is – it’s all about Swift. I think the guy who does this, this is about his third newsletter about something but this one is the one that I’ve enjoyed the most. His other ones have been good too but – it’s just every week, an email in your inbox with a bunch of links to cool new Swift stuff. This week he covers one thing I thought that was cool, the new library from Music Theory. It’s a pretty small library that lets you do programming around music theory with scales and notes and all that. There’s also a link to something that’s gone around a little – as the server site Swift framework that has recently come out currently is only for OS 10 but they’re planning to put it on Linux when it goes open source.
You’ll just find new stuff in here, new stuff you didn’t know about Swift, new libraries, new projects, new developer tools so that’s definitely worth checking out.
My second pick, I’ve kind of almost think I’ve picked before but it’s going to be time to get your Christmas shopping done so this is a good place to do it. There’s a guy named Chris McVeigh that essentially creates his own Lego set and sells them. He does really cool stuff. He’s got some Christmas ornaments but he also has a bunch of models of old retro computers, arcade machines, things like that. I have one of his models of a 1984 Mac and I really liked it. So it’s Chris McVeigh, also known as Powerpig. Those are my picks.
JAIM: Okay. I’ve got one pick. We just did our turkey for Thanksgiving and we brined it this time. So we take two gallons of water, one to two cups of salt and you can do different things like [inaudible] some things. What really helps out the turkey, let it soak for 24 hours then you can cook it. It saved you because we got a new oven this year and this oven actually holds temperature you think it does because every other year we’ve done a turkey, it always takes an hour too long than we think it’s going to. I would’ve just torched this bird; it was too hot and it came out edible. It came out a pretty good bird and yeah, brining. Brine your turkeys next time. A lot of us grew up not really liking turkey because it was always dry and it wasn’t that good. But look up a recipe for brining next time you have to cook a turkey and it will come out looking good. That’s my pick.
Felix, do you have any picks for us?
FELIX: Yes. The first few two are about developer tools, in particular I’m a big fan of Git Tower which is a git client. I use it to stage smaller changes, just a few chunks – a few lines so it can be very specific on what you want to stage and commit.
The second pick is my iTunes setup. Every time I post a screenshot on Twitter or GitHub, people always ask me what kind of terminal do I have. How do we set it up so that they look like it? Because I got to ask this so many times already, I set up a git repo describing the set up with over 100 styles on GitHub already. This is very easy to set up; it takes a few minutes and your terminal will look much, much nicer.
Last pick for the day for me is something non-technical which is Google Flights which is a great way to find flights if you are flexible on what day or time you fly because sometimes it’s so much cheaper to book a flight if you fly one day earlier, one day later and it will help you save a lot of time and money.
JAIM: Very cool. Felix, thanks for coming on the show. We’ve learned a ton and thanks for all your work with Fastlane. It’s such a great tool and a lot of people are getting really good use out of it and I’m excited to dig into it myself.
FELIX: Yeah, thank you for having me.
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]
[Would you like to join a conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]
Join Mic, Jake, and Greg as they chat about Swift evolution, before moving onto talk about fastlane, Mic's favorite new developer tool!
Photo ©Geoffrey Stone.
Happy Holidays from the Technoskeptic! Please enjoy this premium content for free. Internet security expert, privacy advocate, and author Bruce Schneier speaks with the Technoskeptic about the public-private surveillance partnership that monitors everything we do, and what needs to happen in order to restore our privacy. If you like what you hear, please subscribe to get access to all past and future podcasts on The Technoskeptic.
Last year's New York Public Library podcast featured this wonderful reading (MP3) of A Christmas Carol by Neil Gaiman, reading from the last surviving copy of Dickens own annotated "prompt" text, which Dickens himself used to read from. A perfect, perennial listen for the Christmas season. (via Tor.com)
audiobooks / happy mutants / mp3 / podcasts / spoken word / xmas
Podcast Episode 85: Raising Chicago
Please consider becoming a patron of Futility Closet — on our Patreon page you can pledge any amount per episode, and all contributions are greatly appreciated. You can change or cancel your pledge at any time, and we’ve set up some rewards to help thank you for your support.
You can also make a one-time donation via the Donate button in the sidebar of the Futility Closet website.
In 1868, visiting Scotsman David Macrae was astonished to see Chicago transforming itself — dozens of buildings were transplanted to the suburbs, and hotels weighing hundreds of tons were raised on jackscrews. In this week’s episode of the Futility Closet podcast we’ll follow the city’s astounding 20-year effort to rid itself of sewage and disease.
We’ll also learn how a bear almost started World War III and puzzle over the importance of a ringing phone.
Sources for our feature on the raising of Chicago:
David Young, “Raising the Chicago Streets Out of the Mud,” Chicago Tribune, date strangely withheld (retrieved Dec. 7, 2015).
Robin Einhorn, “Street Grades, Raising,” Encyclopedia of Chicago (accessed Dec. 6, 2015).
Josiah Seymour Currey, Chicago: Its History and Its Builders, 1918.
Alfred Theodore Andreas, History of Chicago: Ending With the Year 1857, 1884.
David Macrae, The Americans at Home, 1870.
There’s a very extensive collection of contemporaneous news accounts here.
Aaron Tovish, “The Okinawa Missiles of October,” Bulletin of the Atomic Scientists, Oct. 25, 2015.
Wikipedia, “Norwegian Rocket Incident” (retrieved Dec. 12, 2015).
Wikipedia, “Volk Field Air National Guard Base” (retrieved Dec. 12, 2015).
Chris Hubbuch, “False Alarm: How a Bear Nearly Started a Nuclear War,” La Crosse [Wis.] Tribune, Jan. 30, 2009.
This week’s lateral thinking puzzle is from Matthew Johnstone’s 1999 book What’s the Story?
You can listen using the player above, download this episode directly, or subscribe on iTunes or via the RSS feed at http://feedpress.me/futilitycloset.
Many thanks to Doug Ross for the music in this episode.
If you have any questions or comments you can reach us at firstname.lastname@example.org. Thanks for listening!
December 14, 2015 | History, Technology, Podcast
He doesn't fully grasp what the seduction community is about, but there is truth in what he says.
For example, the Mystery Method fully deserves to be crapped upon and one can empathize with Merlin even if one doesn't agree with him wholesale.
He's an insightful guy, if you cut him some slack on this topic.
The "community" can handle it, really.
And let's be honest: most guys in the "community" are bumbling fools who don't understand the first thing about real self-improvement—even if there are exceptions.
Anyway, Merlin's thesis remains valid.
It doesn't require tearing down others; he just chose to dismantle his own (somewhat true) concept of the "community" to illustrate what to do better.
That's what we should all be focusing on anyway: how can I do better?
How can you?
Page 1 of 9Older