Panel

Cesare Rocchi (twitter Studio Magnolia)
Pete Hodgson (twitter github blog)
Ben Scheirman (twitter github blog NSSreencast)
Andrew Madsen (twitter github blog)
Jaim Zuber (twitter Sharp Five Software)
Rod Schmidt (twitter github infiniteNIL)
Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion
 01:31 - Cesare Rocchi Introduction

CocoaConf Boston
iCloud for Developers: Automatically Sync Your iOS Data, Everywhere, All the Time by Cesare Rocchi

03:53 - Auto Layout

Cocoa Auto Layout Guide

04:45 - Resolutions

Spring and Struts
Localization
Right-Left Languages

09:15 - Using vs Not Using Auto Layout

Constraints
Using Interface Builder

22:40 - Auto Layout & Animation

Esoteric Animations

26:53 - ASCII Art
 29:46 - Intrinsic Size
 33:07 - Apple saying you should have used Auto Layout last year
 36:22 - Open Source Tools that give Auto Layout-type Capabilities

Wrappers

 Picks

Online 3D Model Converter (Ben)
Saint Arnold Icon Gold (Bière De Saison) - Saint Arnold Brewing Company (Ben)
NoFlo (Rod)
Cocoa Slopes (Rod)
Dev Juice: Using your tech support incidents (Andrew)
objc.io (Andrew)
The Choosatron (Jaim)
The Replacements (Jaim)
Reveal (Pete)
Bitter American (Pete)
Teensy 3.0 (Pete)
The Best Map Ever Made of America’s Racial Segregation (Chuck)
Kindle (Chuck)
Kindle for Mac (Chuck)
Clean Office (Chuck)
FrameAccessor (Cesare)
App.net (Cesare)
Appsterdam (Cesare)
Wasatch Brewery: Polygamy Porter (Rod)

Next Week
 iOS Development with Vim with Jason Felice
 Transcript
 CESARE: By the way, I have a whole set of pictures of Starbucks bartenders trying to spell correctly my name and write it on the cup.

[Laughter]

CHUCK: Hey everybody and welcome to Episode 19 of The iPhreaks Show! This week on our panel, we have Pete Hodgson.

PETE: Insert amusing British culture reference here!

CHUCK: Ben Scheirman.

BEN: Hello from H-Town!

CHUCK: Andrew Madsen.

ANDREW: Hi from Salt Lake City.

CHUCK: Jaim Zuber.

JAIM: Hello from Houston! I’m not actually in Houston, but it feels like I’m in Houston.

[Laughter]

JAIM: It’s like 95 degrees out here in Minnesota. I could like call a van that’s full of ice cream or something, I don’t know.

CHUCK: [Laughs]

BEN: Yeah! It’s only 87 right now, so you’re actually hotter than us.

JAIM: I think we switched.

CHUCK: And humid?

JAIM: Humid? Not super humid, but yeah, pretty bad.

CHUCK: We also have Rod Schmidt.

ROD: Hello from Salt Lake City!

CHUCK: I’m Charles Max Wood from DevChat.tv. We have a special guest this way, and that’s Cesare Rocchi or Rocci.

CESARE: Rocci. Rocci. Right.

CHUCK: Rocci. Yeah, I knew that!

PETE: You almost did it!

CHUCK: I almost did it, yeah. I’m famous I guess for botching people’s last names, but I speak Italian and I read Italian, and Italian’s read like it’s written. Anyway, Cesare, since you’re new to the show, do you want to introduce yourself really quickly?

CESARE: Yes! I’m Cesare. Hello from my office, which is in Italy on East Coast in Rimini, to be exact. I’m a iOS developer, I got started in 2007, and yes, that’s before the SDK, the official SDK was released. I did a bunch of client work. Now, I’m focusing on my applications. I speak at conferences; I’ll be at CocoaConf in Boston at the end of October. I write books; my latest book is “iCloud for Developers” published by The PragProg. That’s all. There’s more, but that’s all at the moment.

CHUCK: [Laughs]

BEN: Is your book like a coping mechanism for iCloud?

[Laughter]

CESARE: Yeah, kind of. And yes, there is a chapter about Core Data and iCloud. And it’s not anti-pages.

CHUCK: [Laughs]

BEN: It’s not like, this page intentionally left link?

CESARE: No!

BEN: [Laughs]

CESARE: Though I thought of that [laughs].

CHUCK: It looks and feels like a big band aid for your pain that you have.

 

By the way, I have a whole set of pictures of Starbucks bartenders trying to spell correctly my name and write it on the cup. [Laughter]

Hey everybody and welcome to Episode 19 of The iPhreaks Show! This week on our panel, we have Pete Hodgson.

Insert amusing British culture reference here!

Ben Scheirman.

Hello from H-Town!

Andrew Madsen.

Hi from Salt Lake City.

Jaim Zuber.

Hello from Houston! I’m not actually in Houston, but it feels like I’m in Houston. [Laughter]

It’s like 95 degrees out here in Minnesota. I could like call a van that’s full of ice cream or something, I don’t know.

Yeah! It’s only 87 right now, so you’re actually hotter than us.

I think we switched.

And humid?

Humid? Not super humid, but yeah, pretty bad.

We also have Rod Schmidt.

Hello from Salt Lake City!

I’m Charles Max Wood from DevChat.tv. We have a special guest this way, and that’s Cesare Rocchi or Rocci.

Rocci. Rocci. Right.

Rocci. Yeah, I knew that!

You almost did it!

I almost did it, yeah. I’m famous I guess for botching people’s last names, but I speak Italian and I read Italian, and Italian’s read like it’s written. Anyway, Cesare, since you’re new to the show, do you want to introduce yourself really quickly?

Yes! I’m Cesare. Hello from my office, which is in Italy on East Coast in Rimini, to be exact. I’m a iOS developer, I got started in 2007, and yes, that’s before the SDK, the official SDK was released. I did a bunch of client work. Now, I’m focusing on my applications. I speak at conferences; I’ll be at CocoaConf in Boston at the end of October. I write books; my latest book is “iCloud for Developers” published by The PragProg. That’s all. There’s more, but that’s all at the moment.

Is your book like a coping mechanism for iCloud?

Yeah, kind of. And yes, there is a chapter about Core Data and iCloud. And it’s not anti-pages.

It’s not like, this page intentionally left link?

No!

Though I thought of that [laughs].

It looks and feels like a big band aid for your pain that you have.

Yeah.

So you travel out here for CocoaConf?

Yes.

Isn’t like an 8 or 9 hour difference for you?

Well, time slice-wise, it should be 6 hours. The trip should be around 11 hours or so, the East Coast is the closest to Europe so it’s kind of easy. But I flew to Dallas for the CocoaConf in May or April, I don’t remember, and that was a longer trip, so I don’t fear long -- Last year, I flew to Sydney for a conference. So definitely, I don’t fear long trips.

Wow. Alright, well, we brought you on the show to talk about “Auto Layout”.

Yeah, but please don’t say I’m an expert [laughs].

You know more than I do! [Laughter]

In the field of novices, anyone can look like an expert. [Laughter]

That is so true.

Right.

Jaim has been watching you try and code iOS.

And?

It’s getting there.

In the field of novices…yeah. Anyway, let’s talk about it. What is it?

Auto Layout is a way to make developers crazy, and that’s the first joke. [Laughter]

It’s a technique to build layouts dynamic, or as I prefer to say, fluid layout. I think you’re well-versed in web development so you know about responsive design. More or less it’s the same so you have a bunch of techniques to dynamically build, resize, and make reactive a user interface according to either the device or the orientation of the device.

That makes sense. I guess the question is this, you really only have a couple of resolutions for any given device. You have the 4-inch iPhone, the 3 ½ inch iPhone, and the iPad, iPad Mini, so design and layout just allow you to build your Views once and then have it kind of Scale?

Well, don’t forget about the Mac because Auto Layout is also on the Mac.

ANDREW: Oh…

Somebody has a beard?

It happens. [Laughter]

It was Andrew, but he doesn’t care about the Mac. [Laughter]

He said, “Mac? I’m out of here.”

Should I go on or –

Yeah, go ahead.

So don’t forget the Mac because Auto Layout is also available on the Mac. And we have many more problems on the Mac because the window can be resized. But for the long time -- and when I say that, it’s more or less either 3 or 4 years – we had just 2 resolutions – to be correct, 2 foreign factors: One for the iPhone, and one for the iPad. And then with the release of the iPad Mini and the iPhone 5, now we have 4, and that’s not comparable to the forest of resolutions and 4 factors that you have on Android. For example, the Android developers have been kind of lucky to have many resolutions since the beginning because –

Wait, wait. You said lucky? [Laughter]

It’s a matter of perspective, right?

Yeah.

Conceptually lucky. And also their mindset since the beginning was, “Okay, we have to take into account different resolutions.” Whereas, very recently, one year ago more or less, the iOS developers had to kind of switch or review and change in the mindset of resolution 4 factors. That happens mostly with the release of the iPhone 5 because you have this –

Approaches aren’t [unclear]?

Yes.

We have this mechanism before this to deal with what happens when you rotate a phone. So suddenly, your View went from 320 points wide to 480 points wide.

Right.

And you could make a View like resize along that line. So where does that break down? And why do we need Auto Layout that we’ve had?

That’s like the Struts and Springs stuff, right?

Yes, the Spring and Struts, which is by the way still valid as an approach. You can build your application even for iOS redacted using Spring and Struts. Apple, let me say, at the moment, doesn’t force you to adapt Auto Layout. You can go with the good old approach named Spring and Struts. All the layout is a different approach if you like to build the same application; the same layout, the same behavior, the same reactivity according to the orientation of the device and stuff like that. But probably, as a technique, looks towards a future in which will have different resolutions, or the problems that we have on the Mac, like the resize of the window.

And don’t forget the localization.

Right. That overlaps with localization and good luck if one of your applications supports German. [Laughter]

My suggestion is to start with the German localization even before the English localization [chuckles]. And don’t forget about the right-to-left languages, so all the layout was brought in also to address issues related to right-to-left languages.

I found a German; he just assumed that every word is 100 characters.

Yeah, the shortest.

What are the examples when you would want to use it versus when you maybe wouldn’t? I guess I’m asking what the tradeoffs are for using Auto Layout versus just kind of doing it on your own.

If you’re in iOS 6, don’t use it in about a month… [Laughter]

Maybe we could start with that ‘why do people hate an Auto Layout so much’.

I think I can say all of that because I’m one of them. I’ve tried to use Auto Layout for about the last 5 projects I’ve started, including both iOS and a very significant Mac app. In every case, I’ve ended up eventually just turning it off and going back to Springs and Struts and manual layout in code. The reason for that is almost entirely interface builder, which allows you to edit your Auto Layout constraints, but it has a very frustrating UI. The problem is it tries to make sure that your layout is always fully constrained so it won’t let you create ambiguous layouts. That actually is a big pain because if you delete a constraint just because you want to edit or you’re going to add a new one or something, it will immediately sort of refresh and create new constraints to fully constraining the layout. So essentially, it’s always going behind your back and changing things and not allowing you to be in control. It makes small changes so you get a layout working perfectly and then you want to add one new View or something. It makes those kinds of small changes a huge pain.

Sounds hopeful

Andrew, did you try using the ASCII Art programming for layouts?

Yeah, I did. That’s actually better because you have full control; obviously, it’s not going to insert lines of codes for you. The problem is, I like using interface builder to design my interface because I don’t really want to write a whole bunch of layout code even if it is constraints. And one of my problems with writing code to do user interface layout is I think that makes it harder to add new things or make changes because I can’t just drag something to it a new position; I have to figure out coordinates or figure out constraints.

Inevitably, you’ll see somebody open up a nib with Auto Layout enabled and then it’ll start that like move the mouse over and you’ll see the resize handles and you jump out of your seat and you’re like, “No! Don’t touch it!” because immediately when you touch it, all of those sort of handcrafted constraints that you created are going to be rewritten to satisfy the new layout; it tries to interpret what you’re doing, and usually, it gets it wrong. Oftentimes, I would do like a really quick sample using Auto Layout. And whatever Xcode gives me, I would just say, “Okay, that’s fine.” It looks fine in the retina like the tall simulator, the 4-inch iPhone display. And then when I run it and it ends up on a 3 ½ inch, the buttons are overlapping each other because it did the wrong thing.

Can we take a step back and talk about the constraints thing? Because I don’t know if we actually described what that was.

Oh, right. Constraints are kind of man in the middle if you like because we build the Spring and Strut approach, you declare either in interface builder or in code if you stick to the left, stick to the right, and that’s all. You do the same with constraints, but constraints can – first of all, in Spring and Struts, you always declare stick to the left, stick to the right and so on and so forth according to the superview. Whereas, the big news in Auto Layout, is that you can declare constraints between different Views belonging to different branches in the UI rendering hierarchy. So the expressiveness of Auto Layout is way, way bigger than the Spring and Struts approach. But you also have issues like the ones we’ve already mentioned. So Auto Layout is inspired to declare diff programming so you don’t set explicitly the X of a component, but you say, “I want this component to have the same X or Y or whatever or height, width, and so on and so forth of the superview or some other component.” And then when your application is running, you have a mechanism that calculates which are the actual values for X and Y and height and width and so on and so forth for each component. That’s a mechanism based on an algorithm, the Cassowary algorithm that solves linear equations because essentially, when you declare a bunch of constraints, you are declaring a system of linear equations and there is an algorithm that solves that, assigning a value for each variable. As a developer, when I first started playing with Auto Layout, I felt I had to give up some control. If you are a control freak, it’s not for you because there’s this guy in the middle that kind of automagically does something for you.

And with those, that kind of linear equation thing, when we are talking about ambiguous constraints, that’s the one that’s like more than one solution for the equation, right?

Yeah. You can stumble upon a few cases – Well, the case the you’ll want is the one in which there’s this one solution so one single unique set of values for each of the variables from your system of equations. But you can stumble upon 2 bad cases; one is no solution, or multiple solutions. I don’t know which one to prefer; both anyway will require you to go through the code, or unfortunately for you, open interface builder and try to find out a solution. The solution can be: provide an additional constraints that overrides in a way that the constraint solver is happy at runtime or at compile time, in the case you’re using interface builder, or running your own code. These are the 2 cases that you want to avoid, whereas, you want to chase the case in which there’s this one unique solution.

Will interface builder tell you when you’ve kind of got a system that’s ambiguous? Can you do that at kind of compile time? Or do you have to actually run the app and rotate it around and find your iPad Mini and plug that in and stuff to find out whether you’ve got an ambiguous definition or not?

It depends on the case. Now, I don’t remember exactly, interface builder and iOS 6 tries to, whatever you do, tries to build something that is not ambiguous at compile time. Of course, you cannot cover the runtime thing so even if everything is okay in interface builder and the compilation is good, at runtime, you might stumble upon either some, not crash, but for sure you can stumble upon some non-desirable [unclear].

And I guess if you’re using that ASCII Art technique, where you’re kind of defining the layout programmatically, then great compiler has no chance of detecting that before runtime so then you’re just going to run it and look for their bugs.

It just does its syntax check, as far as I remember. So it tells the syntax of the ASCII string is correct or not, but of course, it cannot cover at all what happens at runtime. So you’ll have to find out yourself either testing the application on either the simulator or the real device. In the console, you can have a few helpers. One is some tracing mechanism that not only tells you there’s something ambiguous, but also where is the ambiguity. It prints out the hierarchy of your Views and says, “Here, in this exact note, there’s an ambiguity,” so there’s a point you have to change.

Stomped.

Yeah, it does.

Probably because the topic is boring, probably.

It’s a very hard topic to talk about because it’s so visual. It’s like – I’ll try to think of an example like how you could explain some of the things like when we you were talking about the hierarchy and you’re not just depending on your parent, or your superview; you can also depend on your -- and I’m kind of trying to visualize it. I think it’s hard when you don’t have a visual prop.

Yeah. One thing I think that beginners coming to Auto Layout might get -- I think you’re guaranteed to get frustrated with is that at least in today’s Xcode, when you drag a View onto another View, it gives you some initial set of constraints that’s doing that to satisfy what it thinks you want, and you can seize in interface builder. But if you’re like, “Well, I don’t want it to be centered. I want it to be X number of pixels from the left edge always or vice versa,” you can’t just go in and delete them. In fact, if they’re not blue, then you can’t delete them at all; they’re provided by Xcode. I think that’s a common frustration for people who don’t really understand how it works. To get around that, you have to add sufficient redundant constraints supplying what you do think is valid, and then the ones that were generated by Xcode then become blue and editable, and then you can delete them, which is kind of it’s on the wing. This is certain to change in like a month, but this is the kind of thing what I see in new people running into.

Right. Well, to go a little back to one of the questions that you asked, for example, I don’t use Auto Layout for every project that I’m working on. To be honest, I’m a big detractor or opponent of interface builder, probably because my applications mostly are custom applications. So I hardly use the built-in NavigationViewController buttons and stuff like that. So I’ve write my own layout code, which I find easier, probably takes a bit more time, but I feel I have much more control about everything that’s going on. Plus, and we all know that diffing code is easy, diffing the interface builder versions can be a nightmare. Though, I’m told that in one month, things will be better.

The soon will come up tomorrow.

For example, when I’m prototyping, the goal is to get out a version as soon as possible to test an idea or to see if something is doable or something like that, Auto Layout is off; Auto Layout does not even exist in my dictionary. Probably because, I feel I’m quicker in writing my own code, my own layout code, and I don’t want to deal with ambiguities or there are multiple solutions and stuff like that. In that case, I manually set whatever value I need for my variables X, Y, and so on and so forth, and I feel fine. And I’m sure that if the first program that is good or satisfactory, that’s a good starting point for future versions. But I guess this is not all about the layout per se, but it’s about interface builder.

One thing that you mentioned like custom layout sometimes can be a pain because you can’t actually see which you’re working with all the time inside of interface builder. Another thing that sort of drives me crazy or drives me away from using interface builder for everything is when you have some sort of complex animation, like you might want to move something to the right in order to make a room for some other new thing that you’re going to bring in. At any time I’m doing things like that where I need to animate the layout of one thing to a new position, I know it’s possible in Auto Layout, but I tend to drop down the code for that and I just say, “Oh, this is my original rect, and I will use some numbers relative to that in order to move it to the right or whatever.” I might save that so that when I toggle it back, then I can just restore back to the original rect in an animation block and I don’t have to worry about it. Do you have any tips or anything on how you would do that with Auto Layout and not [unclear]?

It’s funny because I think that Auto Layout with animations is pretty cool. When you first hear the theoretical description of Auto Layout, you might think, “Well, it should be a mess to work with Auto Layout + Animations.” Fortunately, it’s not because when Auto Layout is on, you can write your code or prepare your interface builder thing for the first View. And then when you want to animate that View, you just write a new constraint and call layout if needed, that’s all. That’s probably the easiest part of Auto Layout. Of course, the new constraint that you provide as to override one of the values of the old layout otherwise, nothing moves. But that’s pretty trivial. The first time, I thought, it must be a mess with Auto Layout + Animations – it’s not.

How much of that is done, actually for you, if you have a small box in your upper right corner and you want to make that fill the screen and you’d give the diff constraints, so it’ll just do the animations for you? It’ll just kind of make a best guess?

Yeah. You provide the new values, in this case, for dimensions of your View. Then you call, not the new values, the new constraints that you want when the animation is over, and then you call layout if needed. That’s all. The difficult part is probably to come up with the right set of constraints to change the current layout to build the animation.

Okay. Does this work pretty clearly if you have different aspect ratios and stuff like that?

Yeah. With all the layout and constraints, it’s all relative. It’s all about you and the relations that you’re providing in the formal equations to the constraint solver.

Okay. So what’s the most Esoteric Auto Layout Animation you’ve done?

I tend to do pretty simple animation like move out and stuff like that. I really didn’t experiment with Esoteric animations, but it’s comforting to know that if I want to deal with animations and Auto Layout is on either because I was running it the first time I solve the project or because I’m working on a team that really believes in Auto Layout, in both cases, I know it’s not a nightmare to work with Auto Layout, to work with animation when Auto Layout is turned on.

Oh, very nice. Yes, it’s really cool to think that you could do kind of animations like that while you’re moving across the screen and I have to break out the ‘when you’re eligible’ book that I’ve forgotten many, many years ago [chuckles].

Right. Right.

Good stuff.

And also, you can use the animations that the Animation Layer provided in UIView. You don’t have to dig in CALayer Animation and stuff like that.

Oh, very nice.

Do you guys want to talk about the ASCII Art thing at all, and go into that detail and what that is?

Yeah, let’s do it!

That’s probably the most Esoteric aspect of Auto Layout. So you have this ASCII like syntax that allows you to define a constraint instead of building the constraint in interface builder, or using the very verbose method that you have in code to create the constraint. It was a very compact syntax, say for example, that a button has to stick to the left or stuff like that. It’s very concise – I’m trying to dig up an example because I – You can build constraints either for the horizontal or vertical axis, and then you can…Well, one not so nice thing is that in a string, you have to use the exact name of the variable that you have used to refer to, for example, a UIButton or a UIView. So, that’s weird. And if you mistyped that, of course, the compiler cannot help you. But you cannot do exactly the same thing that you do in code or interface builder. For example, you have a hyphen to refer to a standard margin, which is I think it’s 8 on the Mac and 10 on the iOS. You can say that between 2 elements, there has to be exactly 100 points – by the way, everything is in points and not pixels – or at least 100 points, or at most 100 points, and so on and so forth. The syntax is so Esoteric that you can also express priorities. We didn’t discuss this, but you can assign a priority to each constraint so that’s actually kind of hint to the constraint solver because you might want a constraint to be more important than others, and so on and so forth. In my experience, these kind of Esoteric strings, should be pretty short in general. So it’s better to break them down to different constraints instead of ending it up with a 200 characters string that probably would be very hard to debug it.

Do you want to talk about Intrinsic Size? That was a concept that came up when Auto Layout was first introduced and it was somewhat confusing at first.

Intrinsic Size is a method that you have probably on UIComponent. It’s available on anything that goes on screen, essentially. Of course, it returns a value, but that value is different according to the type of component. For example, if you have a standard button and either you put that in the design user interface builder or you create an extensive code, of course, you adds a View, a button as a nonzero intrinsic size. Because Apple thought, and I agree, that a button at least should have the width of its label plus some padding probably. Whereas, other components like UIView return a zero dimension because they can contain self-components and stuff like that. And by default, the runtime has no idea what would be the right or default dimension of a UIView. So sometimes, you have to play also with intrinsic size to come up with a solution in a too many solutions scenario or no-solution scenario. That’s a method that you can actually override to return, in your custom components for example, to return what you think is the right dimension, or even something that is nonzero.

One technique that is handy is if you accidentally resize the label. If the label, for instance, is using intrinsic size to provide its width and height, and you resize it, you will stick to whatever size you resized, which might be bad if you want to localize and your string might be longer or shorter.

Right.

Or, if you’re just typing in the label in interface builder, but in code it may be some dynamic string, you want it to be intrinsic sized. The way you can get back to that is by clicking on the label and hitting command =, which will kind of looks like shrink wrapping frame back to what the label’s contents are. But in reality, it’s setting the width and height back to intrinsic size, which will change as the content changes.

Right. So there’s always this going back and forth. That’s probably the not nice part in Auto Layout, that you’re constantly forced to think both at design time and the trying time at the same time (no pun intended), whereas, in many other cases, you’re not force to do that. When you write Auto Layout codes, everything is fine, everything compiles, what would you do at runtime. So that’s why you have to test a lot.

Apple made some quips at WWDC in the iOS 7; control sizes have changed; I don’t know, it feel like read between the line, it was kind of like, “Well, we told you to use Auto Layout last year…”

You’re right.

How would that have helped us? What does that mean? If you’re using Auto Layout, then you’d be okay; why is that okay? Whereas, if we’re just doing Springs and Struts in iOS 6, we probably have to adjust our Views.

First of all, fun fact, I don’t know if you ever noticed that they switched; the UISwitch component changed default dimensions 3 times. The few first editions, we had the first one. And then in iOS 5, I guess, it got a bit larger, width-wise. Now, in the future, it will have a different size again. I still think that if you’re building something for – well, of course, it always depends on what you’re building – I still think that you don’t need the Auto Layout to build an iOS redacted application. But let me restate my bias towards Custom Views and Components. That’s probably why I don’t feel kind of hurt by the introduction of Auto Layout or by the changes that will be introduced in the future iOS 7. For example, I have an application in the store. When I read my Twitter timeline, I see people rushing and trying to adapt refactor and change their applications and to make them ready for further soon, probably soon release of iOS 7, whereas, I’m well-rested; I don’t suffer any sleep deprivation for that because I have a fully custom application. I’d probably change or tweet the fonts or stuff like that, but it’s so custom that I don’t need to review the code and change the color of the navigation bar or stuff like that.

That’s funny I’ve heard people saying the other thing as well, saying like, “My app is so stalked that I didn’t have to do anything and it’s just going to look amazing in iOS 7.”

Of course, building –

It’s the middle ground. It’s the middle ground of those --

Yeah. Right. Which has the most applications, right?

Of course, if you build a completely custom application with completely custom components, at the beginning, it’s not nice; whereas, if you go with standard components, it could probably be easier.

But it pays off in these scenarios in which everybody is rushing and I’m here [chuckles].

I’ve got one last question. Auto Layout kind of sucks at the moment, maybe it’ll get better. Doing all these stuff by hand is kind of annoying. Is there anything else that’s out there like open source tool or something that is a little bit of best of both worlds that gives you like Auto Layout type capabilities, but doesn’t sucks that much?

Well, there are a few third-party libraries, and they are all kind of wrappers around the API of Auto Layout because, as I said, to build a constraint, in an instance of a constraint, you have to provide I guess either 6 or 7 parameters. So people came up with a few wrappers around this method and ways to make the code more readable. But essentially, they all go down to NSConstraint layout to building instances of that clock.

So they’re just kind of like a little internal DSL on top of the –

Yeah, sort of. But as far as I’m aware of, for sure there are no tools that do the job of interface builders because nobody is crazy to build a –

Nobody is so crazy to go to the competitor or of the interface builder if you’re on GitHub trying to provide a nicer syntax for Auto Layout code.

Now, I’m motivated to go try and build interface builder.

Let’s do it. I’m ready!

It’s just XML, right?

Basically. [Laughter]

Yeah.

I’m sure the format for nibs is really well-documented so what’s the big deal?

XSLT way fine.

[Laughs] Yeah.

[Laughs] Alright! Well, let’s do the picks then! Ben, why don’t you start this off this week?

Okay! I have 2 picks. The first one is, I wanted to play around with GLKit and SpriteKit while I was at CocoaConf. I attended a good talk of Jonathan Blocksom, and he was just kind of the state of the OpenGL type frameworks on iOS and Mac. I got kind of inspired that you could just open up a COLLADA file directly in Xcode and it shows you the model, which I thought was pretty awesome. So with about 10 lines of code or maybe even less, I had a free 3D model of a wagon spinning on the screen. I found the wagon from some online 3D model gallery, I forgot the name of it, but it was in the wrong format. I used this online 3D model converter to convert it into COLLADA’s file format, and it worked just like a champ so I thought that was pretty cool. This is an “Online 3D Model Converter”, which might be useful. And then the other pick is a local Houston beer, sorry you can’t get it anywhere else. It’s “Saint Arnold Icon Gold”, it’s a Saison-style beer. It’s super good.

Awesome. Rod, what are your picks?

Alright, my first pick is called “NoFlo”. It is a flow-based programming environment for JavaScript that I saw on Kickstarter that looks very interesting. Flow-based is where you have these components kind of black box as in you can connect other components up with data, dataflows. It looks very interesting. That’s my first pick. There’s actually a book on it written in the 50s by a guy who’s updated it recently, too, so it has a long history. My second pick is “Cocoa Slopes” which is a one-day conference in October 12th that will be held in Ogden, Utah. There’ll actually be 3 speakers – I think there’s like 12 speakers or so. Of those 12, there’d be 3 of us from the CocoaHeads SLC Group, which will be Andrew will be one of them, and then Aaron London, and myself. So if you’re interested in attending that, you can go to mobileslopes.com and sign up. And those are my picks.

Paul Mayne is speaking at that, too.

That’s right.

He is not a regular attendee, but he comes to Salt Lake CocoaHeads, too. He’s the developer, the designer really behind the Day One.

Oh, awesome

So are you going to go skiing?

Yeah! I think there’s like free skiing the next day.

If we had snow.

Oh, sorry, not skiing. There’s free sky diving simulation and all that stuff the next day.

Right.

Yup. Yeah, it sounds really fun. And I’ll probably be there, too, because it’s not too far from here.

Andrew, what are your picks?

I have 2 picks today, and the first one is “Apple Developer Tech Support Incidence”. I’m not sure how to link to that other than there was a post on the unofficial Apple weblog about it a few days back. These are, when you have a paid membership in an Apple Development Programming, you get 2 of these developer tech support incidence per year. You can buy more; I think they’re $50 each or something like that. I think a lot of people don’t use them. I just submitted the first one ever that I’ve ever used on Friday; in 8 years as an Apple developer, I’ve never used one of these. I haven’t got a response back, but this is pretty much the only way you can get personal code-level support from Apple outside of WWDC so they can be very valuable when you have a problem. Let’s see how it goes with the one I’ve submitted. My other pick is hopefully not a duplicate, I don’t know, but it’s “ObjectiveC.io” which is sort of online magazine, I guess you call that magazine about Objective C and related topics. They’ve done 3 issues so far. Really my pick is number 2, which is their issue about Concurrent Programming. There’s a bunch of articles about Concurrent Programming in Objective C and they’re really good. They’ve got sort of beginner-level stuff, and also more in-depth stuff. I’ve learned from reading these so it’s good stuff.

Plus 1 on that. I have been going through those over the past few weeks.

Technically, it’s a mailing list.

Nice. Jaim, what are your picks?

I got 2 picks. I’m going to pump up my hometown, which is not Houston, I’m from Minneapolis. First one is the “Choosatron”. Do you guys remember those choose your own adventure books you had when you were a kid, and like the second choice you made, you got [unclear] guru or something because we always want to the back and then roam through? Choosatron is an Arduino-based kit that lets kids create their own kind of choose-your-own adventure style games and let their friends play them with actual device. It’s a kit. You can build it with just a screwdriver so you can get kids hack it on hardware and stuff – kids or adults; WiFi enabled. They’re in Kickstarter right now and they kind of crush their goals so it’s happening. You can hopefully order them soon beyond what’s on the Kickstarter. That’s the Choosatron. Second thing, “The Replacements”, the band from my hometown, Minneapolis; kind of read and I did a couple of nights ago and some video clips I’ve hit in the YouTube. I saw some stuff on Twitter, it’s good stuff, so I’m excited to hopefully come near.

Those are my picks!

Awesome. Pete, what are your picks?

My first pick is a re-pick, I re-picked myself. A while ago, I picked an app called “Reveal”, but given the topic today, I thought it would be good to re-highlight this app. It’s a native Mac application that connects to your running iPhone app or your Mac app and kind of shows you the View hierarchy live and it lets you kind of explore them out and see all the different layers and edit things on the fly and mess around with values and kind of change whatever the text is centered and the font and the size and things. It’s very, very cool. It’s really impressive. Just go to the website, revealapp.com (Reveal as in ‘I’m revealing myself’), and just watch the video. It’s pretty cool stuff. I just tweeted them to ask them if they do anything particularly to help with Auto Layout, but they didn’t get back to me in time so I don’t know if they help specifically for Auto Layout. But if you’re not using Auto Layout, then check it out, it’s really cool. My next pick is a beer pick. I’ve been inspired by Ben to get back to picking beer. This week, I’m picking “Bitter American” from 21st Amendment here in San Francisco. Normally, I don’t really like 21st Amendment’s beers, but Bitter American is good. It’s a session beer so it’s low-alcohol, it’s like 4 and a bit percent, but it’s also very nice and hoppy and flavorful, and it comes in a can. So, Bitter American. And then my third pick is inspired by that reference Arduino just now. It’s a Arduino-like thing called “Teensy”, which is from this dude in Portland, I think. It’s a very small Arduino-compatible microprocessor prototyping thing. It’s really cool, it’s $19, and it does all the cool stuff that an Arduino will do, but it’s very small and fun to use.

So “Teensy3” is my third pick. That’s it!

Awesome. Well, I throw out a couple of picks. My first pick is actually something that’s going to be picked on the Ruby Rogues tomorrow by somebody else, but they were sharing it today, and I thought it was cool. And since none of those of guys are on this show, I can share. It’s on wired.com, and it’s “The Best Map Ever Made of America’s Racial Segregation”. It shows all of these different cities, including Salt Lake City incidentally, and kind of the way that they’re divided up, it’s really interesting. It shows like New York City so it’s got the different colors with the different races and you can see different patches of color in the town…

Yeah, the one for Detroit was really like a start contrast just like one road divides one race versus the other. Really interesting, yeah.

Yeah, it was really, really fascinating. Some of these other towns – Norlands was one of the interesting ones, too. It had like some just major patches of different colors and stuff; some of them, they kind of blend together. It seems like most of the cities I looked at had more of a blue tinge to it, which meant that they were mostly white people, which I guess makes sense if the country is a majority of white people. It was really, really interesting to see how it all divided out. If you live in or near of big city, it’s really interesting to see how it goes and what the different neighborhoods are. Anyway, I’ll share that because I thought it was really interesting. My other pick is just something that I use day-to-day that’s really handy, and that’s the “Kindle”. I’m also going to pick the “Kindle App for Mac” as I’ve been working through the Big Nerd Ranch Guide for iOS programming and things like that. And other books, other coding books where they actually have coding examples where you want to actually sit down and type it. It’s really handy way to do it because you can put that up on one screen and you can work on the other screen, if you have 2 screens. Finally, the last pick I have is a “Clean Office” [laughs]. It’s really funny to me, just the impact that it has. I was having the hardest time just getting sat down and getting to work. I felt like there was something that was just, in the back of my mind, that I needed to do, and cleaning up my office helped a ton with that. I don’t know what it is, but it just takes this weight off of my mind. So, I’m going to pick a clean office as well.

I’ve never heard of that. What is that?

What is what?

The clean office.

The clean office. Have you never seen such a thing?

I’ve never –

It’s under there somewhere.

Is it on GitHub? [Laughter]

Can I fork it?

Do a gem install the clean up?

Yeah, there you go. Or, pod install it, is it for CocoaPods? Anyway, I can actually see the top of my desk. Now, that’s not to say that like my bookshelf is totally organized, or the closet in this room is completely organized. But I have a workspace that I can deal with, and it’s made it really easy to kind of get my head into the working mindset. It’s nice! You should try it! Cesare, what are your picks?

Okay, my first pick is a library, a very simple library. It’s called “FrameAccessor”. When you write your own layout code for each component, you should extract the frame. And then if you want to change either the X or Y, you got to refer to the origin. Or, if you want to change the size, you have to refer to the dot size, and both are C Struts under the hood. So you end up doing a lot of typing, and this library, it’s very simple wrapper. I’m sure there are others, but the essence is that you can write instant solve your class.x to said the X, instead of writing instant solve your class.frame.origin.x, so very, very handy. Another pick I’ve checked, it’s not a double, it’s “App.net”, which by the way celebrated the first anniversary, the first year of life, few weeks ago. The way it was presented, and didn’t exist yet, I thought that’s exactly what I want - a service on which I can build a sustainable business. That’s why I’m writing a client for App.net, it’s called Neater, Neater.co, if you’re interested. Apart from that, it’s a great community, great support. It’s everything you might want if you are frontend developer. Everything you might want from a web service, if you’re a frontend developer. And the third pick is not a framework, it’s not a library, it’s not a piece of code, it’s a community. It’s called “Appsterdam”, it’s clear that they’re playing with the name of the city of Amsterdam. By the way, Appsterdam is hat quartered in Amsterdam. When you go to a conference and on the way back home, you have this kind of bittersweet feeling, “Will I ever meet again with these guys,” and so on and so forth. The Appsterdam guys put on kind of ongoing conference in Amsterdam. So there’s a space – a desk, a chair, WiFi, and you’re surrounded by people building web application, mobile applications every day, if you like. Apart from that, they organize seminars, conferences, picnics during the weekend, so it’s great. And they have embassies all around the world so in case you’re interested, you can be an ambassador of Appsterdam.

Cool!

Can I throw in one more pick?

Okay!

I’m inspired by the beer choices so I want to throw in one that you guys – [Laughter]

You guys would find interesting. It’s called “Polygamy Porter” –

It’s brewed by the Wasatch Brew Company here. Actually, it has a slogan that says, “Why just have one?” [Laughter]

I met one of the Wasatch guys here in Houston; he was at a local hamburger place. They were giving tastings of all their beers and I taste with this and 4 or 5 others, and definitely good beers.

Awesome. Alright, well, we’ll go ahead and wrap up the show. Thanks for coming again, Cesare!

Thanks for having me.

Yeah, thanks!

Yeah, great stuff.

And fine!

And to say in Italy, Grazie Mille!

Mil-le.

Mil-le. [Laughs]

[Laughs] We’ll go for it than Auto Layout.

Yeah!

[Laughs] I guess that’s a verb.

Yup. One more question, are you going to be speaking at any more CocoaConfs coming up?

Yeah, in Boston in October, at the end of October.

I will see you there!

Oh, right! Yeah, I saw you in the lineup. So yeah, definitely.

And then…any others?

Not that I’m aware of at the moment.

You just seemed like you were going to say, “Oh, and this other one.”

[Laughs] No. I know there are many in fall, but I’m not sure I’ll have time.

Alright, cool! Well, if you want to go meet Cesare, then plan on being in Boston at the end of October. Thanks again for coming! We’ll catch you all next week!

Arrivederci!

Thanks a lot!

Thanks!

Bye-bye!

Ci Vediamo!