Charles: Hi everybody and welcome to the iPhreaks Show. This week on our panel is Jaim Zuber.
Jaim: Hello from Minneapolis.
Charles: Rod Schmidt.
Rod: Hello from Salt Lake.
Erica: I’m Charles Maxwood from Devchat.tv and this week we have a special guest. That’s Erica Sadun.
Charles: Do you want to introduce yourself real quick?
Erica: Hi, I’m Erica Sadun from Denver.
Charles: Denver, that’s not that far away. Do you want to give us a brief introduction? I know you have a book and a few other things that you’ve done.
Erica: Let’s see. I program. I write about programming. I spend my nights trying to take over the world with two small lab rats.
Jaim: You’re the silent third partner on the show I see.
Erica: I am, or at least that would be what I would want to be if I actually were engaged in world domination. Yes, I’ll go with that.
Jaim: I’m guessing if you were involved. The shows will go better for them.
Erica: I don’t think that’s necessary or valid assumption. The joy of the show is the fact that it will never happen.
Jaim: We should probably tell our audience that we’re talking about Pinky and the Brain; two lab rats.
Erica: One is a genius, the other is insane.
Jaim: I tried. You want to sing? You want to sing the intro?
Erica: [Singing] They’re laboratory mice. Their genes have been spliced. They’re Pinky, they’re Pinky, and the Brain, Brain, Brain, Brain, Brain.
Jaim: There we go.
Rod: I’ve never seen that show.
Charles: It’s Animaniacs. It’s one of the segments they have on that show. It’s all on Netflix. My kids love that show.
Jaim: Definitely, pick worthy.
Jaim: I watched it when it came out when I was in college. It’s good for adults. It’s good for kids. It’s good stuff.
Charles: Yeah, I think I was a teenager when it was out. Anyway, we did bring you on to talk about Swift from 2.0 to 3.0 and Swift style. We’ve talked quite a bit about Swift from 2.0 to 3.0. Are at least people moving from Swift 2.0 to Swift 3.0? I’m wondering if you can just give us the elevator pitch for your book about that. Then will go dig into Swift Style.
Erica: I think that moving code from Swift 2.0 to Swift 3.0 is probably going to go down in history as the biggest pain point in the evolution of the language because so much happened, so much changed. It was the one shared, huge trauma for anyone who was already in the language and trying to develop in the language.
Charles: Got you. Given that it’s the day after election day, it’s followed very closely by having to choose between Donald Trump and Hillary Clinton.
Jaim: Too soon.
Charles: I know.
Erica: I wrote that book to help. I don’t think we’ll help you with US elections but it will certainly help you understand not just what changes have happened in the language but why they changed and how you can refactor each part of your code. It is a very practical and pragmatic book.
Charles: Got you. Where should we take it up?
Erica: It’s just a self-published book. It’s available only on iBooks and at Leanpub. The reason I worked with those two vendors for my self-published book, is they allow me to update whenever I feel like it. If anybody finds an error or problem, whatever, I can push an update that day. Amazon doesn’t like you update your books.
Charles: Alright, let’s talk about Swift Style here for a minute. One thing that I see with a lot of systems and a lot of programming languages that I’ve worked with, is that people come out with style guides because there’s so many different ways to write something and they like to see something consistent in the way that the code is formatted. Are there particular problem that your approach to Swift Style helps people avoid?
Erica: I have to step back a little and explain about the project.
Erica: It’s less a Swift Style guide in and of itself and more discussion of Swift Style. Wherever there are multiple approaches, I do try to describe different ways, different developers approach style challenges and what are the strength and weaknesses of each approach. The reason I do this is that I don’t think you can’t write one universal guide that applies to every individual, every working group, and every situation that comes up. People’s needs vary by project and they also vary by the kind of house that they’re working in. Whether it is a contracting house, whether it is all in-house work, whether you are a single person, house or whatever, each of these has their own challenges. There are certain things you can do with style.
The reason you do a style guide is to enhance rateability, to enhance safety, to try to make your code consistent and more maintainable, to allow anybody who is trying to validate a work audit code, to make that job easier for them and so forth. There’s a lot of things that style does to promote all these goals. What my book does is it goes really, really depth in terms of what are all this challenges in Swift and how do you approach them.
Jaim: With both developers thinking of a style guide is the thing that we argue over spaces, new lines, where do you put this phrase? Where do you close it? How do you do things? It sounds like you’re getting into something quite a bit deeper if you’re talking about different types of houses being different fit for different styles.
Erica: I do start with spacing and bracing because that’s a reasonable thing. It is a reasonable approach that people should be thinking about.
Charles: I know but I want to be right.
Erica: When you do develop Swift development, it is a ridiculously tough, heavy language. As soon as you start working with defaulted arguments, when you start working with generics and constraints and all the things that go into a Swift method declaration. You can end up with a function or a method that’s like 10 lines of declaration and 1 line of code. That’s a real thing that happens. And because of that, the bracing style you adopted for C# or for other languages out there, they may no longer work quite as well in the Swift scenario. For example you may be a One True Brace a person and find that a more hybridized style works better for you when you’re developing code.
Jaim: You should explain the One True Brace. What does that mean?
Erica: In the beginning K&R came to us and they gave us One True Brace which is an opening brace at the end of the declaration line and a closing brace that co-aligns with the beginning of the declaration line, so it’s in column number one. The opening brace can be however far across to the right as it needs to be. What you end up with is a code that has more vertical compactness. It’s really the most adopted style. It is almost universally used in Apple. It’s the most common style for Objective-C. It is the most style you see for bracing in general.
Rod: When you said hybrid approach, explain what you mean by that.
Erica: Well, if in the beginning K&R gave us the One True Brace, there was Allman who is famous for BSD-style which has co-aligned left hand bracing. There’s a character term before the opening brace. What that does is lets visually scan between opening and closing braces. It’s a much more expansive bracing style but it’s one that immediately lets you visually understand where a bracing scope starts and ends. It’s very handy for doing that kind of scoping view.
When you start working in Swift if you mixed up the all men style for your external races with One True Brace for pretty much everything else. What happen is you create much more readable results and it helps counter balance any particularly heavy declarations that would otherwise be unreadable because what happen is the code inside the scope tends to flow in the declaration and it becomes quite confusing.
Jaim: Maybe you can provide some examples of how to mix the Allman and the One True Brace Style. What would be the example of how they’re going to mix?
Erica: Well, for the most part I just stick with One True Brace but if you have a function or a method which has a six lines of declaration before the first line of code, if you move that brace down into the Allman position, what it does is it creates a single line of space between your implementation and your declaration. That just does wonders for Swift readability.
Jaim: Great, that’s one thing I always liked about the Allman style. I think I started off doing the K&R way and I think it was probably the Microsoft C++ [00:18:33] that noticed the Allman style. If you do C# that’s probably the default and that was always very readable. It always knew where it started or where it ended. I gradually had that beat out of me in the Apple world. With Swift it was just final. It was not how things are done. I’ve gotten used to K&R style. I forgot my point but I agree that it’s very readable. I think that’s one thing that we sacrifice especially if we have a long method signature where we’re putting different declaration each line. It could be tough to see where the actual code begins. That’s a good point.
Erica: Swift is particularly susceptible to having this really complex declarations. It has so much that happens before the implementation that knowing that if you’re dealing with a more complex system that you know “Oh! I can do this and I can suddenly make an improvement just by just adjusting one particular point in style”. I think that’s a really good tool in the arsenal of anyone who’s doing coding as their work.
Jaim: Definitely, I think style is important for a lot of ways and some of them you mentioned earlier. But just having not to think where to put each space, each new line, each brace, each opening, closing. If you work at a code base for a week or two it doesn’t matter what the code style is, you can get used to it. You’re not thinking about that thing, you’re thinking about your code and the problems that you’re trying solve.
Erica: The example I used, I actually have two examples the first one is if you’re sailing across from a beautiful person of whichever gender you particularly desire, and in that person’s tooth is this big wad of spinach, you’re not going to be enjoying yourself and you’re not going to be paying attention to what that person says. All your focus is going to be on the thing that’s out of place.
Jaim: That’s a good point. The spinach itself, not having anything which, just a little bit weird.
Erica: Good style lets you focus on things without being pulled out by things that are relevant to the meaning and semantics of what you’re writing. The other example I give is that if you have a window and the window has a streak on it? Again you fixate on the streak of the window instead of looking through it, to the vista that’s beyond it. Good code should be a clean window. It should let you see the meaning and intent behind it. You shouldn’t be thinking about the craftsmanship of the code.
Rod: Earlier you mentioned the long declarations like a function definition with generics and everything. I often struggle with how to format these and Xcode doesn’t really help much in the matter with its auto formatting, can’t do it manually. What do you recommend for those long declarations? Do you split them up in separate lines? Do you align everything? What do you recommend for that?
Erica: I really do split things up a lot. I think where declaration should be on its own line and where you add constraints to your generics. If arguments have defaults, I put each arguments on a separate line because if you have a lot of defaults what happens is you may have an external label and internal label, the type and default and that takes up a lot of horizontal space. If you put those arguments on individual lines, you can pull out much more information when reading through that. I try to keep any information after the name of the function or method and before the opening parenthesis for the arguments. I tried to keep that very very short and if I can’t keep it short, I put it on a separate line.
Rod: What about linewidth, what’s the recognition there?
Erica: Well, with line width, you can do what the standard the library group does. They follow LLVM standards and for them it’s an 80 character width. They use two space indentation and I find their stuff feeling very, very cramped. I personally prefer four space indentation, I don’t use tabs and it’s a thing I don’t really care what spacing you use, just whatever you use, be consistent. There are some houses that would go beyond 120. I personally think that Xcode does a really good job in terms of wrapping and in last things need to be pulled out to draw attention, to them to make them different in terms of how you read through them? I generally say just let Xcode do its thing. Let Xcode handle the wrapping in less few [00:24:34] deliberately moving something to a new line keep give it more prominence.
Charles: I find that really interesting because in a lot of ways I tend to write mostly utilitarian code and so I’m not thinking about, “Oh, does this need more attention?” I mean I do that when I’m writing about fiction and doing some of art. It’s, “Okay, how do I embellish or accentuate this important thing?” But I just never considered doing that with a code where, “Oh, I’m going to put it on its own line so people could see it, where it will call it out.” A lot of times I call things out with a comment. It’s interesting to me to think about, “Okay, as I am declaring the signature of this function that I would put a new line in there to call attention specifically to this argument or this default setting for the argument or anything else”.
Erica: I try to be very cautious with comments. I try not to make everything so commented that you can’t see the code. When deciding whether to use structure or to use a comment? I ask myself am i doing this to emphasize what this does? Or am I doing this to try to add an explanation of why it’s there?” For me, comments always explain why and basic structure naming and things like that. Those should be explaining what to the roles.
Jaim: That’s a good point. Definitely try and make your code self-explanatory about what is happening, whatever language constructs and [00:26:30]. If I put why and the why is like “I’m doing it this way. I’m not an idiot. There’s actually a reason for it but it might be a little bit surprising why I did something this way.” Definitely let the 00:26:42] be self-explanatory. I’ve worked with code styles were commented even down to increment i++, increment the counter. It’s like “Okay, that’s pointless.”
Erica: It’s not only pointless but what it does is it did values. The comments that really are important because when you’re given this cognitive overload of too much information, it keeps you from recognizing what’s important and code readability is the whole point of adopting good style. Everything you do should be in service of future proofing your code for reading it, for using it, for maintaining it and eventually for expanding or correcting it.
Jaim: That’s a good point. I never put it together but if you’re commenting that’s self-explanatory from the code, you have duplicated logic. That’s two things that you have to keep in sync when you change one thing. A lot of developers aren’t changing the comments when they need to change. They’ll change the code and leave the comment because they think it was important. Then you like to put the comment that doesn’t much what’s actually happening. That’s a good point.
Charles: My comment is you will get crammed in there when it’s like if you change this, if you change this formula, or you change this variable then you’re going to see weird behavior because it actually regulates thing. It’s an explanation, it’s a kind of, “Danger, Will Robinson!” Instead of the actual, “This is important. You should know that this is important.”
Erica: A comment should create a breadcrumb trail design intent and what approaches you have tried and why you made it particular decision. A good comment says, “I’m doing it this way because it augments the code. It explains the reasoning that you can’t pull from just looking at the final product.” Swift like most other modern languages, uses two kinds of comments. There is in-line comment for documenting that design history and then there are the API comments that are similar to Doxygen, HeaderDoc, Javadoc. The Swift version of these creates a way for API consumers to provide at the point of use documentation using standard mark up.
Charles: What are your feelings about those kind of comment systems? Because to me, in a lot of cases, it feels like so much cruft. I’d rather see the documentation generate it somewhere else but at the same time those comments being right there with the code makes it easier to change the documentation with the code. I can definitely trade-off there.
Erica: You have to first of all decide who is going to consume this code. If you are just writing something in a playground, honestly when would you ever need API documentation for your APIs? If you are writing a library that’s going to be consumed not only within your working group but your entire house or even be distributed as a framework say, for people who use your services. I think you owe it to those users, to spend a significant amount of time making your API consumable and expected. If your API for example, has no obvious complexity, you should be telling people about that. Things that look like their all of one complexity but are in factor old and squared, you don’t want to surprise people with that because unless that’s documented what you’ve done is you’ve basically distributed a known bug.
Charles: Yeah, that makes sense. I’m curious what in your discussion of style do you think is the hardest decision for people to make when they’re looking at how do we want to structure this so that it best meet whatever goals we have, be that communication or readability or something else.
Erica: That’s really a good question. The thing is I don’t think there’s any single decision point beyond the big one which is I am going to carefully think about my style to create a consistent experience for consumers of my code. I think that’s the one thing you either get past or you don’t get past. After that a lot of it is going to be things like, do you always include self work? Do you allow self to be inferred? Do you left the line [00:32:34] or not? Do you approach certain things like iteration using for in versus for each?
There are significant advantages and disadvantages to that. Let me give you a particular example and before I tell you my guidance on it, let me just kind of throw it at you. When you’re declaring a static function or static method, the member that is basically associated with the type rather that associated with instances, do you declare public static or static public?
Jaim: I always do public static but whether the alternatives and why?
Erica: It’s either static public or public static. You can’t make it simpler than that. Say why you’ve chose that style over the other.
Jaim: When I do it, I just do the access modifier first because that’s what I’m used to seeing public, private. The first thing I do if I scan a file is like, “Okay, what public? What’s internal protected private?” Just so I know what the interface is if I’m changing something. For me, I write public first because it allows me to look at the thing for the first time and know what’s public and what’s private with a quick glance.
Charles: I was going to say the same thing but for me it’s just that’s the way I’ve seen it done, that’s the way when I was writing Java in college that’s the way they showed us to do it. That’s the way I’ve always done it since then so I didn’t have a good reason for it.
Rod: Yeah, I didn’t even know you can put static before public.
Erica: I always put the access modifier first and the reason why I put the access modifier first is because auditing is such an important task when it comes to access modifiers. You need to be able to go through your code, make sure that every single member of the type has been audited. That it is intentionally public or not public, whether it is internal or [00:34:59] and by putting it first, it lets you scan down the left column and it puts it in a known place. If you want to be strict about this, you will always use the word internal rather than just going with the default because you will know that every item has been audited rather than overlooked.
Jaim: How do you draw if it’s has been audited and overlooked. What does being explicit give you?
Erica: You can use Var X, let’s say that’s a member. Var X defaults to internal access. If the internal keyword isn’t there, you can’t tell if that person made that internal intentionally or they simply forgot to add an access modifier from there. If you always include internal keyword as the first thing, then you know that it’s a deliberate choice. It cannot possibly be an error by a mission.
Jaim: That’s a good point. You’re explicitly saying, “I want this to be internal not just I’m being lazy and just want to [00:36:28]. I should admit that’s probably the right approach for at least larger project where the developers that I rarely do for myself. I cannot leave it for [00:36:42] which I think improving about starts about the thing that probably we do more explicitly.
Erica: That’s why understanding the context of style is so important. Again, are you going to be publishing for others? Are you working in a group? Are you just doing your own code? Is this a hobby project? Is this something that’s going to be Open Source and then put onto GitHub where there are potentially many consumers of this. All of these things help guide your decision about how much style you want to introduce and what kinds of style you should consider.
Jaim: Yeah, that makes sense. The challenges, a lot thing the things we’re talking about can sight terrible worst within you team. Everything we’re talking about can just be the argued for immensely and definitely [00:37:39] because either way it would be fine. The work will go on with right code [00:37:43]. That could be great. How do we avoid just getting wired into this style guide works which can happen.
Erica: Buy a book that talks about it. Then you going to go section by section saying “Oh, we’re going to go with option A here, option B there.” “Oh she’s really in favor of options.” “See here, Let’s do that definitely,” And then have a style sheet. The second you adopt the style sheet, you fix it. You say, “This is how our house rules work. Everything going forward conforms to this style sheet”.
Rod: Why is it important for the team doing the style and everyone use it?
Erica: For one thing it sets up an anti-turbulence system. Code moving from one person to another person, only has to focus on correctness, on design, on expectations. It doesn’t make you look at the minutia. Everybody uses the same style. It may be things that you think are a little bit silly in some cases or things that you would have gone slightly a different way but it’s an agreed-upon contract. Now your conversations aren’t about left aligning columns. You’re conversations are about the code. You’re reading no longer has to think about all the details of how it’s layed out. You can’t read through the code and your only interest is actually the code itself. It takes you out of the bother of the structure of the thing and lets you leave where true development is supposed to happen which is in the taking of concepts and turning them into algorithms.
Rod: Well said.
Jaim: We should point out that the conversations may not be concerned with the [00:40:03]. At least starting off.
Erica: Have your fights early and then you never have to worry about it again.
Charles: I guess the one thing that I’m wondering about is what is the ultimate outcome that you’re looking for from this? Is it a style guide or is it just having the conversation so we understand why people are doing what they are doing.
Erica: No, I think everybody should have a style guide. If there’s a multi person system involved and or they’re doing an Open Source. So long as there’s a connection between people, a style guide no matter how weird and trust me I went and interviewed with so many people and some people do some such ridiculously weird stuff but it’s okay because they’re consistent. If I’m reading their code and I know their style, then I can live with it. Let me give you an example of one of these weirdnesses. Take the colon in tight declaration, where would you put the colon? I’m talking about something as simple as let X colon integer into type equal to. Where does the colon go?
Erica: What’s with the verb?
Jaim: No, right after the variable.
Erica: Oh the variable. Well that makes a lot more sense. Okay, in some cases, some of the developers that I interviewed they put it next to the type. They say that the colon, the role of the colon, I’m not promoting this by the way, is to establish the type therefore the semantics between the column and the type are far stronger. Things that have a greater semantic association should be closer to each other. There are Swift coders out there who will do let X space column space colon int space equal space to.
Rod: This is madness.
Erica: Yeah, I find it completely weird but there is reason there. It’s rational and when I read these people’s code and I know three different people who do this and they do it on a variety of languages, it’s a consistent reading experience. I don’t have to think about it. I will look down on this people, I will have to stay for them but I will be able to read their code.
Jaim: I agree. The only thing worst than a bad code standard is no code standard.
Rod: With different languages if I’m on a team and there’s no real style guide what I do on the past, I just [00:43:18] out there. Objective-C, I would just [0:43:21.0] New York Times. With Swift I would do [00:43:24]. Does your book provide a quick start with doing that or we have to dig in and tweak every little thing?
Erica: I decided not to do that. This book has sort of been on my back burner for a couple of years now. I just really felt Swift didn’t know what it was as a language yet. I wasn’t ready to make decisions. I kept keeping notes and I kept talking to people and reading their code. Trying to see how the language was developing. It wasn’t really until 3.0. People had enough experience in Swift 3.0 to have really strong opinions about it that I felt comfortable starting to write this. Initially it was just going to be a style guide for myself. I figured, “Okay, maybe a page or two.” Then it became a pamphlet and it became a chapter and then it started getting really really big.
I realize I didn’t just want a style guide that says, “Do this.” “Prefer that.” I wanted to write about why. I didn’t want to go to anybody and say, “Here is a style guide for you to adhere to without being able to justify every single recommendation. In the process of finding those justifications, the process of finding those reasons, it really made me understand Swift better. Understand what it is as a language, where it’s going as a language. I thought that that process plus all the various decisions that came out of it and all the guidance, I thought it was really fun. The feedback I’m getting from early readers is that they are amused and enjoying just the process of not just looking at things but challenging their assumptions of how you should do it and what matters and what doesn’t matter. I think the only thing that a majority of people really agree on, is that semicolons are stupid.
Rod: Yes. I’m glad they’re gone. What about tools? Do you recommend using linters and formatters and stuff like that?
Erica: I absolutely love linters. Linters catch things that people never do. The human mind gets too close to the code it builds and linters can just automatically pick up a lot of things about style and fix them for you. While I write my own linting thing, I wrote it because I was trying to explore style. I wasn’t actually trying to write a linter. I think probably the best effort for a linting is coming from the Realm guys.
Rod: What’s that called, SwiftLint?
Erica: Yeah, I think it’s called SwiftLint. It’s a JP Simard.
Charles: Yes he’s been on the show before.
Erica: Does he speak with an accent?
Charles: I honestly don’t remember.
Erica: But the name it surely doesn’t sound the way I read it in my head.
Rod: What about formatters? You find those can be useful or on a team, maybe, where everyone has to use the same format?
Erica: I am not really that familiar with formatters to be honest. Can you give me an example?
Rod: I can’t think of a particular one off hand but there are tools out there.
Erica: You mean the ones like LLVM people use for wrapping?
Rod: That’s a fundamental part. AppCode lets you specify the style of the formatting of your code with all kinds of detail.
Erica: I can just stick with XCode in just the default because that’s what most people who read my stuff tend to use. I try to live in that world.
Charles: Do you have a conversations that people should have as far as styles in their task?
Erica: Yes and No. I think that testing is a fundamental part of writing correct code. I think that the test style is something I really don’t touch on because I think test driven development just didn’t fall under my umbrella. I’m going to very courteously say that’s an exercise best left for the reader. But it’s a really good question.
Jaim: Erica anything else about Swift Style that we haven’t covered, that we should get too?
Erica: I don’t know. I can talk about style for days so I hope people buy it. It’s been picked up by pragmatic press. It should be out December and I had fully, as I said intended it to be a very short thing and then it got bigger and bigger. Then Pragmatic was kind enough to pick it up. I’m working with my development editor and we are editing the draft. I just got a whole load of technical review back from lots and lots of coders who have very strong opinions about what I wrote. I’m in the middle of updating the text so that it really reflects even more viewpoints.
Jaim: That’s awesome. That sounds like it will be live right about the time this episode goes.
Erica: It will make a perfect holiday gift.
Rod: For the whole family.
Erica: For the family, yes. And because Pragmatic has their beta program, they do allow you online access before the book is actually printed because the book itself cannot be printed until early, mid January. Just the realities of dealing with physical production so the beta version, which they do sell as an online eBook will helpfully be there right there in December.
Jaim: Very cool, I’m looking forward to checking that out.
Charles: Alright, let’s go ahead and do some picks. Ah Rod? Do have some picks for us?
Rod: I just want to pick Erica’s books. Her books go into really great detail on lots of topics that aren’t covered in other books and I really appreciate that. That’s my pick.
Erica: Oh thank you.
Charles: How about you Jaim?
Jaim: Alright I’ve got one pick. I know this has happened to all of you, where your party and someone puts on some tunes, heavy metal and you have a conversation and you’re not sure if its doom metal, brutal death metal, tactical death metal or brutal tactical death metal and that’s totally embarrassing. I’ve been there, we’ve all been there. What can you do? There’s a site called everynoise.com which allows you to drill into different genres and will give you examples of the genre and you don’t have to go into death metal or heavy metal. They have a post teen pop, industrial metal, a [00:52:58] disco. If you want to check out what a [00:53:00] disco is. Deep breakcore? What is that? I don’t know. Deep danish pop, who knows? everynoise.com. Do not go to the site if you have something to do within the next day or two. You will be checking out Russian Pop and Minimal Wave. Anyway, everynoise.com, check it out it’s definitely worth trying. Brings you back to the days when you can just try different stuff and figure that out. Very cool so check it out. everynoise.com
Charles: Alright, I’m going to jump in with a couple of picks. First one is I got the conferences up for next year so if you’re interested in iOS remote conf, go check it out at iosremoteconf.com.
I am also going to quickly pick a tool called Toggl. I recently hired a business coach to help me level up on some stuff and she recommended it to me and told me to use it to keep track of all the stuff that I’m working on. If you go to toggl.com, you can enter the tasks that you’re doing. As a contractor, I hated tracking time. I also work for consultancy at one point and I hated tracking time for them too but as it turns out, it’s important if you want to figure out where your time is going and what you’re spending it on and what you shouldn’t be and what you should be. I recommend to people that they use a tool like Toggl to track your time for a few weeks and see where your time is going and get a good idea of what you can improve of. Erica, do you have some picks for us?
Erica: I do have some picks and these are all apps that have moved out of App Store and are being sold by third party developers for the Macintosh. I just want to give them a little bit of promotion because I use them all the time. I’m just really happy that they’re able to stay in business. I want them to stay in business because I like their products. They are SpamSieve which I just installed a few weeks ago because mac Sierre it’s doing a terrible job of junk filtering. I just couldn’t live with it anymore. I went out and I bought SpamSieve, the training was not pleasant but now that it’s trained it’s doing a really fabulous job.
Jaim: I use that too and it works great.
Erica: My Belbox is back under control. Sierra was traumatic but I’m back to normal. Another one is Keyboard Maestro, because I have everything on my Mac [00:56:11] this lets me use Emacs command no matter what app I’m in. That’s another one. The last one is the BetterTouchTool, which lets me do really, really weird touch combinations on my MacBook Pro’s touchpad. I’m just happy that I can do things like special holding taps and other things that are not build into the system and have those just as customizable as my Keyboard Macros. That’s been a real benefit to me for getting work done.
Jaim: I have to ask how did you alt F in Xcode?
Erica: Command F?
Jaim: No, the alt F, like the word forward, the Emacs command.
Erica: You mean the ctrl F? It’s built in.
Charles: Well, ctrl F is forward one character and alt F is forward one word.
Jaim: Which is broken in Xcode, starting Xcode 5.0. [00:57:20].
Erica: For most of those things, because honestly, I haven’t touched my Macros for years. My Macros know how to make things happen. My fingers know how to make things happen but it doesn’t go through my head anymore it’s all muscle memory. But the way you set those up is you use the arrow keys and use Keyboard Maestro with arrow keys and so you set option F for whatever it is that you are doing to do to the right keyboard combination with the arrows. I know for example command V with is page down and option V which is page up. It’s like my fingers know what to do. I figured it out once. Once you figure it out it’s in your Macros set so you don’t have to think about it again.
Jaim: This is true. I still have the muscle memory where I type those weird Fs over my Xcode because I don’t have Keyboard Maestro so, awesome. That’s pick worthy for me.
Rod: You can remap those Jaim, in Xcode preferences.
Jaim: Maybe. I’ll try it.
Erica: The Xcode keyboard binding panel is really amazing. Two things that I have specialized there are F8 and F9. Not that you could ever use those on the new MacBook but so long as they continue to exist. I have one that executes playgrounds which is F8 and F9 toggles between rendered layout and raw markup.
Charles: Awesome. I’m going to push this to the end of the show. If people want to follow you, see what you are doing, check you out on twitter and anything like that. What would they do?
Erica: On twitter I’m Erica Sadun and my website is ericasadun.com. Pretty much I have zero imagination, so if you want to contact me on any other service you can probably guess how to.
Charles: Alright, we’ll go ahead and wrap this show up. And we’ll get catch everyone next week.
Jaim: See you!
Charles: Awesome. Thankyou Erica that was way fun.
Erica: Thank you.