104: Minutiæ


00:00:00   There's brief moments of time when I listen to the two of you go back and forth and for

00:00:04   a minute I'm like, man, I'm not even here anymore.

00:00:08   And I feel ever so slightly sad.

00:00:10   But then I continue to listen to you two going back and forth and I just don't even care

00:00:14   anymore because I'm entertained as hell.

00:00:17   We had recently received an email as recently as about two hours ago about how we say to

00:00:24   to each other, or say actually to you, the listener,

00:00:27   please email anyone other than us,

00:00:30   or please don't send us email, et cetera.

00:00:32   Would you like to talk a little more about this email?

00:00:34   - All right, so the first sentence is,

00:00:36   I'm a little surprised about your whole email topic.

00:00:39   Now, this is already kind of like spreading the topic wider

00:00:43   because this started with Marco getting specific feedback

00:00:47   and bug reports about Overcast, right?

00:00:49   But then this sort of expanded into like the entire topic

00:00:52   of us getting email.

00:00:53   And so this feedback is not about Marco and his bug reports, really.

00:00:57   It's really about when we say on the show, please don't email us about whatever.

00:01:02   Right. So I already think this is kind of off topic and it's just like it's

00:01:05   related to the discussion, but whatever we want this.

00:01:08   It's not interested in really discussing how Marco handle his feedback.

00:01:12   He's more interested in discussing the joke that we do when we say, please don't

00:01:15   send us email.

00:01:16   And he says it makes him feel like that we don't appreciate the listeners that,

00:01:20   you know, I find a good sentence here.

00:01:22   He says he loves us, loves the show.

00:01:23   It doesn't make me feel entitled to anything.

00:01:25   I know that obviously, and I know that it's impossible to get back to everybody.

00:01:29   But what is impossible is to appreciate your position,

00:01:31   to appreciate the fact that people devote their time to actually tell you what they think,

00:01:35   to appreciate that people are the ones that are attracting sponsors, etc.,

00:01:39   to appreciate that a podcast by nitpickers is going to attract nitpickers,

00:01:42   to appreciate that so many people really care.

00:01:44   And I know you do appreciate your listeners, but the whole email joke,

00:01:46   the whole annoyance is neither funny nor respectful.

00:01:48   It's strange, off-putting, very arrogant and makes me kind of angry.

00:01:51   "It makes my engagement feel pathetic and needy.

00:01:54   "It's really not that hard just to say

00:01:55   "a few nice words, you know?"

00:01:57   To this I would say that we don't have a,

00:02:01   ignoring the fact that most of the time we're just joking,

00:02:03   right, because jokes can be hurtful too, right?

00:02:05   We don't have a blanket ban on email.

00:02:09   We don't say, it's like a prohibition.

00:02:11   In fact, we encourage, tacitly encourage email

00:02:14   by responding to email on the show.

00:02:16   And a lot of the followup is about things

00:02:18   that people send us, either corrections for things

00:02:21   expansions on topics, we take real-time feedback and real-time follow-up from the chat room

00:02:25   from people saying the same thing, right? So it's clear that we're not like, nobody

00:02:28   ever emails us anything, you know, for whatever reason. We don't say that.

00:02:32   I mean, there's a feedback form on our site that I made when we made the site. Like, we

00:02:37   have this form on the site that says "send feedback". If we wanted to not actually receive

00:02:42   any feedback, we would just take the form down.

00:02:44   Like Marco, like Marco and his app doesn't want to imply that he's providing support,

00:02:48   just fries the feedback bank.

00:02:49   So first of all, I would say the premise of the idea that we just are saying we don't

00:02:52   want any feedback.

00:02:53   That's not our message at all.

00:02:55   We do very frequently though say, "Please don't email us about whatever topic."

00:03:00   And that is specifically focused on whatever it was we were talking about.

00:03:04   So if it's like, "I'm going to tell you about this toaster oven I got.

00:03:10   Please don't send me email about slot toasters."

00:03:13   And then I follow up by saying, "I know about slot toasters.

00:03:16   I know slot toasters exist.

00:03:17   I know that they are different than toaster ovens.

00:03:19   I am reviewing toaster ovens, right?

00:03:21   - And they're worse.

00:03:22   - Right, you know, like, right?

00:03:24   And part of that is like, the please don't email thing

00:03:27   is a long running gag from any podcast

00:03:29   that we've listened to and been on in the past.

00:03:30   So if you don't have that context,

00:03:31   maybe that doesn't make much sense.

00:03:32   It's also kind of a joke like,

00:03:34   oh, I don't wanna hear from those people

00:03:35   who are just gonna tell me about the slot toasters, right?

00:03:37   But it's very specifically focused on this one thing.

00:03:39   It is not saying please don't email me ever about anything.

00:03:42   If you know something cool

00:03:44   about a new DisplayPort specification,

00:03:47   Yes, send us the email about it.

00:03:48   If you say I've been an Apple genius for X number of years

00:03:51   and this is my experience, yes, send us email about it.

00:03:53   Like, of course we want that email.

00:03:54   Like we read it on the show, we appreciate it.

00:03:56   We appreciate our listeners.

00:03:57   So I don't want people listening to think,

00:03:59   and I don't think most people do,

00:04:00   but this person does apparently,

00:04:01   that we don't want feedback from anybody.

00:04:05   It's 50% of the time a joke

00:04:07   and the other 50% of the time very focused

00:04:09   kind of exasperation at a particular type of feedback

00:04:13   that we expect to get because we said something

00:04:15   that we know leaves us open to a particular kind of correction and we're trying to say,

00:04:19   you don't need to send us that correction because we are fully aware that we have either

00:04:22   intentionally ignored this thing or whatever.

00:04:25   Right, it's a way, I use it as a way to preempt getting a whole bunch of emails that begin

00:04:33   with "well, you know..." and some big argument about something that like, I know the thing

00:04:37   I just said is contentious, or I know there is something that other people are going to

00:04:42   want to tell me about what I just said, and I'm just like, I don't want to engage that

00:04:45   entire discussion right now.

00:04:47   It's a way for me to basically try to preempt

00:04:50   getting a whole bunch of duplicate emails

00:04:53   telling me something I already know.

00:04:54   And that saves everybody time.

00:04:56   - And it's not to say it's not annoying.

00:04:57   If you're annoyed by it,

00:04:58   it's totally your right to be annoyed by it.

00:04:59   It can be annoying, I fully admit that.

00:05:02   But we are human and we get exasperated sometimes too,

00:05:04   and we express that on the show.

00:05:06   - Yeah, so this email was from Pell D.

00:05:09   I feel like we should attribute, I'm assuming him.

00:05:13   And what I had replied to him or her, I'm thinking him,

00:05:17   and saying, and what I said was,

00:05:19   we don't, or we say don't email us,

00:05:22   either because we really don't care about the minutiae,

00:05:24   minutiae, minutiae, all the nuance of the topic at hand.

00:05:29   - You're gonna get on me about Bezel,

00:05:31   but you're gonna go minutiae, okay.

00:05:33   (laughing)

00:05:35   Minutiae, Kit Tacy, like, touche.

00:05:37   - I was pretty sure it was minutiae,

00:05:39   and then I was envisioning all the emails of it,

00:05:41   saying to me, "No, it's not minutiae, it's minutiae."

00:05:43   So should people not email you about the correct pronunciation of minutiae?

00:05:46   So please do not email me.

00:05:49   See?

00:05:50   That's a perfect use.

00:05:51   It's a perfect use of it.

00:05:53   Anyway, let me try this again.

00:05:56   So we say please don't email us either because we really don't care about the minutiae of

00:06:01   the topic at hand or because we know we won't be able to respond to everyone.

00:06:05   And actually that reminded me as we were talking of another piece of follow-up, which is I

00:06:10   I saw a handful of people, generally speaking from Europe, who seemed confused about the

00:06:16   whole toaster oven thing.

00:06:18   Yeah, someone asked me, "Isn't that just a grill?"

00:06:20   And then I realized we had a language barrier between English speakers.

00:06:25   I think it was someone from the UK or some other thing that Marco can tell us the correct

00:06:29   name of.

00:06:30   Can we maybe just put a "U" somewhere in it?

00:06:32   Would that make them know what we're talking about?

00:06:33   A "touster oven"?

00:06:34   Yeah, no, it was great.

00:06:36   It was great because someone said, "Isn't that just a grill?"

00:06:38   And I replied, "No," because I didn't look up where they were from or something, but

00:06:42   I was confused by it.

00:06:43   And then another person who obviously speaks the variant of English that that person was

00:06:47   speaking, tweeted back to them and said, "I think that what you mean by grill isn't what

00:06:51   they mean by..."

00:06:52   Seriously, it's like an actual language barrier.

00:06:54   We don't know the words for things.

00:06:56   But we put links in the show notes, right?

00:06:58   You can click on them and see what it is.

00:06:59   It's a thing.

00:07:00   Toaster ovens are a thing in America anyway.

00:07:02   And so if you live in one of these barbaric countries that doesn't really have a toaster,

00:07:07   Doesn't have toaster ovens basically. It's like a little tiny oven that can serve either as a toaster or an oven hence

00:07:14   Toaster oven and they're extremely convenient if you'd like to reheat something especially something bready

00:07:20   pizza being the most obvious example

00:07:23   French fries anything like that if you want to reheat something bready

00:07:28   But you don't want to do so in the microwave because then it'll end up all gummy

00:07:31   Toast oven is a great way to do it now. Yes, you could use a traditional oven

00:07:35   but why in the world would you start up what is probably

00:07:38   multiple square feet worth of space

00:07:41   to heat one slice of pizza or two slices of pizza?

00:07:44   And so a toaster oven is the best of both worlds

00:07:46   because it's a little tiny oven,

00:07:47   big enough for usually a slice of pizza or two,

00:07:50   or it's a toaster, big enough for maybe a couple of bagels

00:07:53   or something like that.

00:07:54   - Right, and it tends to heat up just about as quickly

00:07:57   as doing it in the microwave for me.

00:07:58   Like if you're gonna, I mean, it's not 30 seconds,

00:08:01   but if you're gonna reheat a slice of pizza,

00:08:03   A toaster oven has it done in like two or three minutes at most.

00:08:06   And so it's way faster than using a full-size oven.

00:08:09   Nobody should ever put a pizza in a microwave, I just want to say that.

00:08:13   Oh, completely agreed.

00:08:14   But anyway, so if you don't know what a toaster oven is, well perhaps it's time to move to

00:08:19   a different country.

00:08:22   But nevertheless, maybe you could import it or something like that.

00:08:25   So you need nationalized healthcare or toaster ovens?

00:08:27   I'm going toaster ovens.

00:08:28   I think I might too.

00:08:29   The brand of my toaster oven Breville apparently that's a proprietary eponym.

00:08:34   See I did remember that from the past episode.

00:08:36   It's pronounced Brazil.

00:08:38   That is a proprietary eponym in the UK like Kleenex or whatever and so someone in the

00:08:42   chat room says a Breville refers to something we would call a grill in the UK for sandwiches

00:08:47   so they've taken that entire brand and turned it into you know that it's a signifier for

00:08:51   the entire category of things like a panini grill type of thing or whatever but anyway

00:08:56   that's definitely not what I'm talking about.

00:08:57   and follow the links in the show notes.

00:08:59   I'll show you exactly what we were talking about

00:09:01   last week's show notes, not this week's show notes.

00:09:02   - Yeah, we're not gonna put in this week's show notes

00:09:04   because it was already there.

00:09:05   You should have clicked the links, kids.

00:09:08   - Our first sponsor before we've done a single topic

00:09:10   is Igloo.

00:09:11   Igloo is an internet you'll actually like.

00:09:13   It's kind of funny that this is the first tech

00:09:15   that we're discussing is the sponsor itself.

00:09:18   With Igloo, you can share news, organize your files,

00:09:20   coordinate calendars, and manage projects all in one place.

00:09:24   This is like taking the best of the web

00:09:26   productivity apps, things like calendars, Twitter like micro blogs, file sharing, task

00:09:29   management, wikis, and more, all available privately and securely for your company or

00:09:34   group intranet.

00:09:35   Alu intranets are highly functional, stylish, and easy to use, with a widget-based drag

00:09:40   and drop interface.

00:09:41   Their latest upgrade, Viking, revolves around documents and how you interact with them,

00:09:45   gather feedback, and make changes.

00:09:46   They've even added the ability to track who has read critical information to keep

00:09:50   everyone on the same page.

00:09:52   It's kind of like read receipts in your email, but less annoying, and it helps you

00:09:55   track whether employees have read and acknowledged policies, signed off on legal agreements,

00:10:00   or confirmed completion of training materials.

00:10:05   Igloo is all built on their advanced HTML5 platform.

00:10:08   It's a fully responsive platform and offers all these features, even things like previewing

00:10:12   and annotating documents, all that is done in HTML5, so it works no matter what device

00:10:20   you're on.

00:10:21   You have all that functionality, all the annotations, all the admin controls, everything, whether

00:10:25   you're on a computer, iPhone, Android phone, or even a Blackberry, and when new devices

00:10:28   and screen sizes hit the market, igloo already works on them.

00:10:31   So if your company has a legacy intranet that looks like it was built in the 90s, you should

00:10:35   definitely give igloo a try.

00:10:37   Igloo is even completely free to use for as long as you want if you have a group of 10

00:10:44   or fewer people.

00:10:45   And then if you get past 10 people, it's very reasonably priced after that.

00:10:48   So really, if you have a group of 10 or fewer people, igloo's free for you.

00:10:52   Just go try it, it's amazing.

00:10:53   Anyway, sign up for a free trial at igloo software comm slash ATP. That is igloo software comm slash ATP

00:11:01   Thanks a lot to a glue for sponsoring our show. Once again, they've been a longtime sponsor a friend of our show

00:11:05   Yeah, very much. Thank you a glue

00:11:08   We should talk about the photos app that we all thought may have kind of gone away

00:11:15   Hang on real-time follow up on the Breville. It's not a panini. It's not a panini press look at the thing

00:11:20   I just put in the show notes. It's the thing like

00:11:23   It's like a a clamshell thing that closes and it has two little compartments for

00:11:28   Bread like if you cut a piece of bread on diagonal and it kind of like heats them from both sides

00:11:33   Different than a panini breast which is you know the flat surfaces with the little ridges on them

00:11:37   This is a common thing like that's what they prefer. I've seen them in the US

00:11:41   I just I don't think many people have them, but that's what they call it

00:11:43   That's what they call a Breville and if you read the history of the thing, that's that's really peculiar

00:11:47   I mean well, I've seen them before but it looking at the chat room

00:11:51   It seems like in the UK and Australia everyone has one of these and I cannot think of any one of my friends or family

00:11:56   That has one so it's labeled there as a durable stainless steel jaffle maker. So are those jaffles?

00:12:02   Is that like that's what we call this thing. I want to try to pronounce that word. I don't think maybe it's jaffa le

00:12:07   Jaffle like waffle

00:12:11   So quick aside I was at work

00:12:14   this is a year ago now and somebody was one of my

00:12:19   Co-workers was talking about doing something in JavaScript and at one point he said something about just song and I was like what oh my god

00:12:26   I think he was saying it. I you know

00:12:31   Comically and or ironically or whatever, but what I heard just saw I was like wait what and sure enough

00:12:38   He meant just saw Jason. God. I just did it again accidentally my boss used to say H over

00:12:42   What H over that's when you put your H over an item

00:12:46   - Yep. - And the H-over style

00:12:49   and the links.

00:12:50   (laughing)

00:12:51   He was just avoiding trying to pronounce that word

00:12:53   because he knew it was such a problem.

00:12:55   (laughing)

00:12:56   - That's true because you never know when that'll go wrong.

00:13:00   But for the record, it's hover.

00:13:01   - We'll talk about them in 20 minutes.

00:13:03   All right, sorry for the derail, photos, back to photos.

00:13:05   - Yeah, so let's talk about photos.

00:13:08   We had all, not genuinely, but kind of wondered,

00:13:10   hey, what happened to photos?

00:13:12   Because somebody had pointed out to us

00:13:14   that it disappeared from Apple's website.

00:13:16   Well, apparently it's back.

00:13:18   It's back in a big way,

00:13:19   because it's actually in the latest Yosemite beta.

00:13:23   Now, have either of you guys tried this?

00:13:25   - What, are you crazy?

00:13:26   I was actually gonna try it,

00:13:27   like not on my computer with my actual photos,

00:13:29   but just to load the program

00:13:31   and throw some sample photos at it or whatever.

00:13:33   But then I realized,

00:13:34   and I'm pretty sure this is still the case,

00:13:35   that you have to upgrade to the 1010.3 beta,

00:13:40   and I wasn't willing to do that,

00:13:41   just to try the Photos app, so I'll just wait.

00:13:44   - Yeah, that's the reason I'm not using it,

00:13:45   because I'm not going to run a beta OS on my main computer, so that's not going to happen.

00:13:50   Yeah, I've already put in a lot of time doing stuff like that. I deserve a break.

00:13:56   I also feel like this is a good opportunity that I really should take to go back and clean out some

00:14:02   of my photo library, because there's so many times—I'm sure this happens for a lot of people—I'll go on

00:14:08   a trip or something, or we'll do a shoot with the kid or the dog or both or whatever, and we'll just

00:14:13   dump all the photos into the photo library

00:14:15   and then just never really pick through them.

00:14:17   So I have these giant 30 gig folders

00:14:21   full of some shoot or something like that

00:14:22   and it's like, if I just took an hour to go through this,

00:14:25   I would probably delete 95% of those pictures

00:14:28   and just keep the 5% of the best ones

00:14:31   that I actually want to see again.

00:14:32   And basically I need to apply that process

00:14:35   to five years of photos.

00:14:38   It's like spring cleaning, I keep meaning to do this

00:14:39   and maybe this is my motivation to do it finally.

00:14:43   Do you guys have that problem?

00:14:45   - I used to use iPhoto,

00:14:47   this was, I don't know, three, four years ago now,

00:14:50   and I felt it was nothing but a burden.

00:14:53   And there's probably a million and seven ways

00:14:56   that you can blame that on me,

00:14:57   and probably a million and six of them are correct.

00:15:00   But for whatever reason,

00:15:01   I just didn't have a workflow

00:15:02   that really worked well for me.

00:15:04   And what I've ended up doing since then is just eschewing,

00:15:06   that's how you pronounce that word, right?

00:15:08   Eschewing iPhoto altogether.

00:15:10   This is the Accidental Pronunciation Podcast.

00:15:12   And now what I'm doing is,

00:15:15   and I think it was Bradley Chambers,

00:15:17   learning to love photo management

00:15:19   in combination with some scripts from Dr. Drang.

00:15:23   And so basically what I do is I have all of my pictures

00:15:27   renamed consistently and stored consistently

00:15:30   in my file system.

00:15:30   And that's as close as I get to any sort of organization.

00:15:33   And I wish I had a better organization system

00:15:36   in so far as something where maybe I've tagged pictures

00:15:40   that I think are really good

00:15:41   or I've grouped them into events or what have you,

00:15:43   the sorts of things that I suspect

00:15:45   Photos app will be great for.

00:15:47   But for whatever reason,

00:15:48   it just felt like such a pain in the butt with iPhoto

00:15:50   that I never really did it.

00:15:52   - I think I've described my system before.

00:15:54   I put them all in iPhoto and then I star rate them.

00:15:56   And the only cleaning I really do,

00:15:59   I tend to be like not want to get rid of pictures

00:16:03   of my kids, even if like they're not framed correctly,

00:16:05   or even if they're a little out of focus,

00:16:07   'cause sometimes they're still cute.

00:16:08   But what I do is I do rate them all.

00:16:10   And when I feel like doing a little cleaning,

00:16:13   I just show all the one stars,

00:16:14   and the one stars are basically like,

00:16:15   you should really delete these,

00:16:16   'cause the lighting is really bad,

00:16:18   or it's blurry, or whatever.

00:16:19   And I will delete,

00:16:20   I'll look at every picture when I load them into iPhoto,

00:16:23   I'll delete the ones, obviously,

00:16:24   they're like, excellent, I took a picture of my foot,

00:16:25   or like something, you know, they're totally bad.

00:16:28   But all one star ones, and then when I wanna clean,

00:16:30   it's really easy for me to just show a smart album

00:16:32   that shows one star, and then just go through

00:16:34   and just delete whole swaths of them.

00:16:35   - Yeah, but see, then you can't see the ones around them

00:16:37   that were better, so you can really know,

00:16:39   Like which of these do I need to keep?

00:16:41   - One star means, I mean I can look at the pictures.

00:16:43   Like it's like these are so blurry.

00:16:45   Like they're not, I'm not one starring.

00:16:46   If it's in focus and people are in the,

00:16:48   like those never get one star.

00:16:50   One star basically means you should really delete this.

00:16:52   One star is the thing that most people

00:16:53   would delete immediately.

00:16:54   I just let them stew and then if I feel like cleaning house,

00:16:57   I delete all, I think I deleted every one star

00:17:00   from my collection a couple years ago

00:17:01   and it was a lot of photos.

00:17:02   But now I just kind of let them build up.

00:17:04   - Maybe you're just letting them develop like a Polaroid.

00:17:06   Like figuring maybe it'll get better

00:17:07   I just leave it here for a little few more hours.

00:17:10   And also, a picture that is actually out of focus, sometimes we do family calendars where

00:17:17   you make the calendar for the year with pictures and everything and they have these little

00:17:20   collages where you can put the pictures.

00:17:21   Sometimes there's little spots on the calendar for small photos.

00:17:24   And even a picture that's blurry, like it's not in focus, when you shrink it down to be

00:17:28   like one of the small thumbnails at an angle in the corner of a calendar thing, it doesn't

00:17:32   actually even look that bad.

00:17:33   So occasionally that's why I'm kind of keeping the one stars around.

00:17:36   Or if it's like me trying to see a picture of like,

00:17:40   what do I have on this shelf in this year?

00:17:44   Where was that thing or whatever?

00:17:46   - Oh my God.

00:17:47   - Yeah.

00:17:48   I wish this system was more intelligent about finding things.

00:17:51   For example, I do keyword them,

00:17:53   but my keywords are limited to like,

00:17:55   I have a keyword for each of my children

00:17:56   and then one keyword for me and my wife,

00:17:59   'cause I'm not gonna do us individually.

00:18:01   You know what I mean?

00:18:02   And that's about it.

00:18:03   And you just think like, why do you need to do that?

00:18:05   doesn't the faces feature find all the people that you want for you?

00:18:08   Well, I started doing this before the faces feature existed, long before, first of all.

00:18:12   But second of all, no, it's not reliable enough.

00:18:15   Like me manually keywording them is much more reliable than faces.

00:18:18   I wish I could turn faces off because it's always grinding away, making the fans spin

00:18:22   up on the MacBook Air to try to detect people's faces.

00:18:25   But that's the same thing I do with iTunes.

00:18:28   Starring them and basically using the star as a threshold system easily lets me sort

00:18:32   get what people are trying to get by cleaning things out, which is just like, "Just show

00:18:36   me three stars or better." Those are the good pictures. There's very few of them. Suddenly

00:18:39   my collection becomes small and manageable. And if I want to share photos on PhotoStream

00:18:44   or send them to relatives, I just show the three stars. It's super manageable. People

00:18:48   want their collections to actually be like that. I can't bring myself to throw out the

00:18:51   two-star ones, but the one-star ones I do delete.

00:18:53   Now, going back to the Photo app for a second, I think, so one thing that we were skeptical

00:18:59   of or hesitant or whatever the right word here is.

00:19:02   We are disasters.

00:19:04   Yeah, right. I'm still sick. I have a good reason. We were wondering like, you know,

00:19:10   one of the issues with cloud service backed things and iCloud stuff in particular is that

00:19:15   there's pretty much no visibility into the storage and no recourse if it does something

00:19:21   crazy like delete half your contacts. Like it's pretty hard to recover from that in a

00:19:25   lot of cases for a lot of these services.

00:19:28   And if you have this on your Mac and it has all these files sitting there locally, you

00:19:32   can back up these files and then hopefully have some way to reimport them if you had

00:19:37   to nuke your whole iCloud account and start clean or restore a bunch of stuff that was

00:19:41   deleted.

00:19:42   And it seems from earlier reports that the storage layout of it, you can import things

00:19:48   off disk and it can just leave them where they are and not copy them in.

00:19:51   But by default it seems to maintain a very iPhoto-like library structure so that these

00:19:56   files are just sitting there as files on your disk.

00:19:59   All of your photos are there by default.

00:20:01   It will only be smart and try to delete some of the originals or cache things online only

00:20:06   if you enable the special low space mode.

00:20:09   So you can just have one computer that has the whole library on it and has all those

00:20:13   originals sitting there as files and you can always reimport them later.

00:20:16   So it does seem like it is durable enough in that way to be used as your main photo

00:20:21   app, at least once they work out any glaring bugs.

00:20:24   It's actually even better than that.

00:20:25   We should explain what the experience of this is.

00:20:27   So iPhoto was an app and Aperture was an app that Apple had both discontinued, both being

00:20:31   replaced by this app.

00:20:32   Both mediocre.

00:20:33   Yeah.

00:20:34   Functionality-wise, Photos does not include all the functionality of Aperture.

00:20:37   It includes most of the functionality of iPhoto.

00:20:39   So this application is coming into people's lives with the expectation that you've already

00:20:44   got all your photos in one of these other applications or in a folder of crap somewhere.

00:20:49   And it handles all those situations.

00:20:51   So like if you have an iPhoto library, when you start it up it will import that iPhoto

00:20:55   library and it won't actually make duplicates of the files, it'll just make hard links to

00:20:58   them.

00:20:59   We'll put a link in the show notes explaining the hard links.

00:21:01   Basically it doesn't take up any more room on your disk, but it makes a separate parallel

00:21:04   structure of its own.

00:21:07   At that point your libraries are divorced from each other and if you make changes to

00:21:10   either one of them, the changes are no longer visible.

00:21:12   So it's a one-time kind of import process that doesn't actually take up much more disk

00:21:17   space, but at that point they're diverged, like they're not kept in sync with each other.

00:21:21   If you have a file full of pictures that just like you've organized yourself, you can just

00:21:25   start photos up, make a new empty library, and import those pictures.

00:21:29   I believe it will copy them, no it won't copy them in that case.

00:21:32   You can tell it to leave the pictures where they are.

00:21:33   There's a preference, kind of like the iTunes preference of copy media into the library.

00:21:37   You can tell it, "Don't move my stuff, I have it arranged in folders."

00:21:40   Just reference them from where they are, and it will do that.

00:21:42   It will leave them in your nice organized folder structure.

00:21:44   It will put a little thing in the app that shows you like,

00:21:46   oh, by the way, this picture isn't in a library.

00:21:48   It's referenced from another location.

00:21:50   And if you want to work that way,

00:21:51   which I would totally recommend not doing

00:21:53   because it's crazy and you're a crazy person,

00:21:56   the application will do that for you.

00:21:57   You can organize your photos into little folders by date

00:22:01   and name them whatever the heck you want,

00:22:02   and then just reference them from the Photos app

00:22:04   and continue that crazy workflow

00:22:06   where you act as a little person

00:22:08   putting things into folders

00:22:09   and then reference them from the application.

00:22:11   And just like iPhoto, you can hold on the option key

00:22:14   on launch and switch among different libraries.

00:22:16   The only limitation you have is,

00:22:18   and this is all just like totally local,

00:22:20   forget about network connection.

00:22:21   This just all works totally locally,

00:22:22   no cloud stuff involved at all, right?

00:22:24   If you wanna do some cloud stuff,

00:22:26   then you can designate one library as like,

00:22:29   the what, the system library, whatever,

00:22:31   like the iPhoto, the iCloud library.

00:22:33   One library on your system can be cloud backed up.

00:22:36   And then you have the choice of,

00:22:38   do I want to keep all the originals on my Mac

00:22:40   and then also put them in the cloud,

00:22:42   or they want to use whatever it calls

00:22:43   like smart or advanced storage

00:22:45   or whatever some other preference that says,

00:22:47   I don't care if they're all on my Mac,

00:22:48   you can actually take some of them off my Mac

00:22:50   as long as they're in the cloud,

00:22:51   and that's the second option.

00:22:52   So this is an extremely flexible application

00:22:54   that does things in pretty much the smartest way possible

00:22:57   given the current file system technology we have,

00:22:59   that leaves every person able to do whatever it is

00:23:02   that they want with their photos.

00:23:04   The only bad thing about it transition-wise

00:23:06   is if this app is completely buggy and like erases stuff

00:23:09   and destroys your photos and they get lost in the cloud

00:23:10   and everything, any changes you made after that initial

00:23:14   kind of one-time import process will be lost

00:23:17   because once you do that import,

00:23:19   you are now leaving iPhoto behind.

00:23:21   I suppose you could import your photos into both of them

00:23:23   in parallel, but then you will actually be duplicating

00:23:25   because the one-time import with the hard linking stuff,

00:23:28   it doesn't take up much more space,

00:23:30   that's not an ongoing thing.

00:23:32   So there is a transition point.

00:23:34   And so I suspect if I try out this program,

00:23:36   I will try it out and then, I don't know,

00:23:40   maybe just like bail out after importing

00:23:42   a couple of pictures into it

00:23:43   and then reimport those same things into my photo library.

00:23:46   Like I still don't have a good transition pan,

00:23:47   but spec wise, the photos application

00:23:51   seems like it does all the right things

00:23:53   to make everybody except for aperture users who are screwed.

00:23:57   It will import your aperture library,

00:23:58   everybody happy except for the people who use the aperture

00:24:01   and will miss all the features that aperture have

00:24:03   that this doesn't have in terms of advanced photo editing.

00:24:06   Well, the editing controls are actually not that far off.

00:24:09   This is one of the reasons I'm very excited about this app,

00:24:11   that the actual editing process

00:24:14   and the controls you have for editing are very advanced

00:24:17   and really are pro-level editing tools

00:24:19   compared to Aperture and Lightroom.

00:24:22   Lightroom is probably slightly more advanced

00:24:24   in certain areas.

00:24:25   Aperture, I'm not sure I haven't used it in a couple years,

00:24:26   but it's probably very closely matched

00:24:30   to those editing tools.

00:24:31   Where it falls short is in the organizational tools

00:24:34   things like Aperture and Lightroom, and especially if you're coming from Aperture, I think it's

00:24:38   going to be, if you were really heavily using those organizational systems of vaults and

00:24:44   all these things, most of that is not going to transfer over gracefully. So that's really

00:24:50   where Aperture users are going to be very rightfully upset. But besides that, it looks,

00:24:55   again, I haven't used it yet, but it sure looks like the editing and processing of the

00:25:01   photos is just as good as Aperture was.

00:25:03   But they don't have the interface of doing the pics.

00:25:06   A lot of Aperture was about professional photographers

00:25:09   taking lots of photos and then designating

00:25:12   the ones they think are good in an efficient manner.

00:25:15   There's no workflow like that, as far as I can tell,

00:25:17   built into photos.

00:25:18   Whereas Aperture, so much of Aperture

00:25:20   was focused on the editing tools, which is one thing,

00:25:23   and then this whole, like you said,

00:25:25   the vaults and the management, and then the picking process.

00:25:28   I forget what they call it.

00:25:28   Is that the word they use?

00:25:29   I think so.

00:25:30   It might be.

00:25:30   I don't know.

00:25:31   Again, it's been a couple of years since I've used Aperture.

00:25:33   But yeah, I mean Aperture and Lightroom are both gonna be way better for what pros actually do.

00:25:38   Like my wife, Tiff, is not gonna use this photo app. I can already tell you that. She's not gonna use it.

00:25:42   She has, even Aperture and Lightroom are too heavy-handed for her.

00:25:46   She just uses Bridge and a bunch of directories because like the one she does client shoots,

00:25:50   she doesn't want to bring it into some giant library

00:25:52   program and have it organize things for her. Like she does it all in the file system with Bridge and does all the picking that

00:25:58   way and it works great for her.

00:25:59   Most pros are going to have a system like that where they're going to use one of these pro apps

00:26:03   To do all that organizational and stuff and managing the shoots and managing the picking and all that stuff

00:26:08   They're not going to use this app, but that's fine. This isn't made for them

00:26:11   this is made for the people like me who and and of course everybody else but like

00:26:17   People like me who were using

00:26:19   Aperture and or lightroom for its advanced editing controls primarily and then secondarily we would occasionally touch some of these library functions

00:26:27   but we were mainly there for the editing controls.

00:26:30   That's definitely the case for me.

00:26:31   I know it's the case for a lot of people

00:26:34   who bought SLRs in the last eight years

00:26:38   and got into photography as a nice hobby.

00:26:40   Just having these nice editing controls

00:26:43   built into the main photos library mechanism

00:26:47   on iOS devices and Macs is going to be awesome.

00:26:49   Because for all these years, we've

00:26:51   had to decide between something that's fully integrated

00:26:55   into Apple's ecosystem and syncs everywhere

00:26:57   and is all in all the photo pickers and all that stuff,

00:26:59   or has great editing controls and pro stuff,

00:27:03   and there were always these things you'd have to give up

00:27:05   one way or the other,

00:27:07   and this looks like it's perfect for people like me.

00:27:10   Any prosumer who's really into SLR photography,

00:27:13   but is not doing pro photo shoots actually for clients

00:27:17   every day or on the weekends or whatever,

00:27:19   this is for us, and I'm very much looking forward to that.

00:27:22   - I think the editing controls,

00:27:23   like the adding intelligence to the editing controls

00:27:25   is really important because they default for most photo apps, including Apple's, with the

00:27:30   exception of the little magic wand enhance button.

00:27:33   They give you one button, it's like, "You don't understand all these crazy controls.

00:27:36   Press the magic wand and maybe it will make your photo look better or maybe it won't."

00:27:39   And if you press that button and didn't like it, you're like, "Whatever."

00:27:41   And then you're faced with, "Okay, well, so the magic wand didn't work?

00:27:44   Here's 8,000 sliders.

00:27:45   Good luck."

00:27:46   And if you don't know how to use those sliders, it's daunting to figure out how to just, you

00:27:51   know, there's a million different combinations and you're trying like, "I don't know, do

00:27:53   I move this and that or whatever?"

00:27:55   Well, so Photos has this sort of intelligent thing

00:27:57   where they give you sliders that are sort of meta sliders

00:28:00   that cause the other sliders to move

00:28:01   in what it hopes are pleasing ways.

00:28:03   And you're like, oh, well, that's bad.

00:28:04   I don't want it to be smart

00:28:05   and move those other sliders around.

00:28:06   I wanna move the actual sliders.

00:28:07   Well, the great thing is you can use these meta controls

00:28:10   that influence the other sliders to try to,

00:28:12   like most people can do that and say,

00:28:14   oh, I would never have thought

00:28:15   to put those other sliders in this position,

00:28:17   but when I slide this top slider,

00:28:18   all these other things move around.

00:28:19   But you still have the ability to edit

00:28:21   every single one of the detail sliders manually as well.

00:28:24   So if you want to use the sliders by hand, you can.

00:28:26   But most people have no idea how to get good results

00:28:28   with that so they can use those other meta sliders.

00:28:30   So it's a big step up from either Magic Wand

00:28:33   or you're on your own.

00:28:34   - And all these edits are fully synced,

00:28:37   not just like burning it into a JPEG and syncing that.

00:28:40   The actual edit states are synced so that you can go

00:28:43   on your phone or your iPad and make adjustments

00:28:46   and that syncs back.

00:28:47   - Well, in theory, I mean, let's be serious.

00:28:50   - Well, I mean, this is all based on CloudKit.

00:28:52   So far, our CloudKit stuff has been solid.

00:28:54   - Why didn't my contacts sync, Marco?

00:28:56   Contacts, it's like a tiny set of data, why?

00:28:59   - That's a good question, I have no idea.

00:29:01   - My faith is like, yeah, I'm ready to be impressed.

00:29:04   - It seems like, you know, I've heard rumblings,

00:29:08   I'm sure everyone's heard these rumblings,

00:29:09   that like, Eddy Cue's team took over iCloud,

00:29:13   something something, and was really like,

00:29:15   revolutionizing and fixing stuff like a year ago.

00:29:17   Like that's when all this stuff started, allegedly.

00:29:20   and it seems like CloudKit and the Cloud Photo Library stuff

00:29:25   and all the stuff that came out of that

00:29:26   that's all based on CloudKit,

00:29:28   seems like that is most likely to be

00:29:31   the result of that rumor.

00:29:33   And that we're seeing now,

00:29:34   they're doing good things with the cloud stuff now.

00:29:38   Rather than the initial iCloud services stuff,

00:29:40   which was the document stuff,

00:29:42   which is a fairly simple problem set,

00:29:45   but it was done kinda oddly, but mostly worked.

00:29:49   Key value store, which works all right,

00:29:50   and then core data sync, which was a disaster,

00:29:53   'cause they tried to tackle this incredibly complex problem

00:29:56   that really can't be done well

00:29:57   in the way they attempted to do it,

00:30:00   and of course, so it sucked.

00:30:02   CloudKit was like, we talked about this

00:30:04   when they announced it back in the summer,

00:30:05   like CloudKit is Apple kind of saying,

00:30:08   okay, we're gonna do a cloud service

00:30:09   that actually is much easier to do well,

00:30:13   and so far, it seems like they did.

00:30:16   So I'm pretty confident in this service probably being good.

00:30:21   I mean, we'll see what happens in practice

00:30:24   once it's launched full scale and everything,

00:30:25   and we've all been using it for a few months.

00:30:27   But I think all the pieces seem to be in place

00:30:30   for this to actually be good and work pretty well

00:30:33   most of the time or all the time.

00:30:35   - Well, just the fact that they're dogfooding it so heavily,

00:30:37   I think is a pretty big change from, say, iCloud

00:30:41   with Core Data or Core Data with iCloud

00:30:42   or whatever the terminology was.

00:30:45   The impression I had was that nobody was dogfooding that,

00:30:48   but just like you said, Marco,

00:30:50   it sounds like Apple's heavily dogfooding CloudKit,

00:30:55   and that's definitely a good thing for all of us,

00:30:58   because I think Apple is fairly tolerant

00:31:01   of third-party developers having to jump through hoops,

00:31:04   and fairly intolerant of their own people

00:31:07   having to jump through hoops.

00:31:09   - Oh yeah, that's fair, and as far as I know,

00:31:10   I don't think any Apple app ever used Core Data Sync.

00:31:15   I'm pretty sure we never found one.

00:31:16   I know some people were trying to like,

00:31:18   they were asking around on Twitter like, you know,

00:31:20   a year ago or whenever, like,

00:31:20   "Does any Apple app actually use this?"

00:31:21   I don't think we ever found one.

00:31:23   But anyway, I'm confident.

00:31:25   And also, you know, I wouldn't necessarily like

00:31:27   be all nostalgic for Aperture,

00:31:29   because Apple has been a terrible steward of Aperture

00:31:31   since the beginning.

00:31:32   Like, it always had delays, issues,

00:31:35   it was always pretty buggy,

00:31:37   it always had terrible performance.

00:31:39   Most of all, it would just go years

00:31:42   without any major updates,

00:31:44   and everything was always just too little, too late.

00:31:46   It was always getting better soon

00:31:48   and never actually great.

00:31:50   That's why Lightroom does so well,

00:31:52   because Apple basically said,

00:31:55   "Hey, we're gonna eat at Apple."

00:31:56   I think they basically invented the category

00:31:58   of apps that work like this, basically.

00:32:01   I think, I'm not sure about that.

00:32:02   Please email Casey.

00:32:04   (laughing)

00:32:05   And then Adobe came in with Lightroom

00:32:08   and just ate their lunch,

00:32:09   because they just iterated so much faster

00:32:11   and it was so much better.

00:32:13   Apple really, you know,

00:32:14   Aperture was always pretty badly neglected.

00:32:16   So, you know, rose colored glasses and everything,

00:32:19   I don't think we're gonna see people looking back

00:32:21   in six months saying, "Oh, I really miss Aperture."

00:32:23   Like, I don't think so.

00:32:24   And for the few who do say that,

00:32:26   I think they're probably gonna be misremembering

00:32:29   how good it actually was.

00:32:31   - I thought I saw somewhere,

00:32:33   and it might have been in Jason Snell's review,

00:32:35   but I thought I saw somebody had loaded

00:32:37   just a crud load of images, of pictures,

00:32:40   into the new Photos app,

00:32:42   and they said you could scroll that thing

00:32:44   at a solid 60 frames per second like it was nothing.

00:32:46   - I will be excited to see that if that's true.

00:32:48   That's why I wanted to try it.

00:32:49   I'm like, I've gotta see this

00:32:50   'cause it is so terrible in iPhoto.

00:32:52   I have maybe 30, 40, maybe I have more than that.

00:32:55   40,000 photos, 50, and maybe it's up to 60.

00:32:57   Anyway, it doesn't seem like that big a number,

00:32:59   but I wanna see that scroll nicely.

00:33:01   - We are also sponsored this week by H-Over.

00:33:05   H-Over is the best way, oh, it's also Hover, or Hova,

00:33:09   all of those things.

00:33:10   Hover is the best way to buy Manix domain names.

00:33:12   Go to hover.com and you can get 10% off your first purchase by using promo code "SLOTTOASTERPEOPLE".

00:33:21   When you have a great idea, you want a great domain name that's catchy and memorable.

00:33:24   Hover gives you exactly what you need to find the perfect domain for your idea so you can

00:33:28   get started actually working on it.

00:33:30   Like I've mentioned before, if I'm working on a new project, I need to find a name first.

00:33:34   I can't really move forward without a name.

00:33:37   That just blocks me until I get a name, and domain names are the very first thing I go

00:33:40   to go to search, and hover is great for that.

00:33:43   Hover gives you easy to use powerful tools to bio-manage domains so anybody can do it,

00:33:47   and the support team is always ready if you need a hand.

00:33:50   They're known for their no-wait, no-hold, no-transfer phone service, so when you call,

00:33:54   a real-life human being is ready to help.

00:33:57   They pick up the phone, that's it, they're ready to help you, you're not put on hold,

00:33:59   you're not transferred to anybody, that's it, they pick up and they help you, it's amazing.

00:34:04   Plus they have great online tutorials and email support if you hate the phone like me.

00:34:08   You can find new domain names that you want to get up and running in less than 5 minutes.

00:34:11   All you gotta do is type in a few keywords, and Hover will show you the best available

00:34:15   options across all TLDs out there.

00:34:18   Now if you've ever used any other domain host before, you know that it can be a pretty unpleasant

00:34:23   experience at a lot of these different companies.

00:34:26   They make it very complicated to buy just what you need, or they try to upsell you with

00:34:29   crazy stuff, or they make you pay extra to upgrade for things that really should be included.

00:34:34   Hover does not believe in this kind of approach.

00:34:36   Instead of charging you for something that should just be there, Hover includes everything

00:34:39   you need with your domain.

00:34:40   You get a smart control panel, you get whois privacy, always for free on any domain that

00:34:44   supports it.

00:34:45   They even offer this really cool service called Valley Transfer Service.

00:34:48   Now what they do is, if you will let them, they will log into your old registrar and

00:34:52   do any transfers for you.

00:34:55   They'll transfer over all your DNS and everything so it's all correct because it's very easy

00:34:58   to get that stuff wrong and then your site's down for a few hours, it sucks.

00:35:01   They will log in and do it for you if you want because some registrars make it pretty

00:35:05   difficult to leave and of course they don't. They also have this great email service. Hover

00:35:10   has great solutions for your own custom email address for your domain. 20 bucks a year gets

00:35:14   you a fully functional email account at your domain with 10 gigs of storage. You guys remember

00:35:18   when Gmail came out, it was 1 gig, this was like in 2004, and that was revolutionary to

00:35:25   have a gigabyte. No one could ever use that much. Well, we do. And Hover now offers 10

00:35:31   a year for just 20 bucks. Now if you need more than that, for just $29 a year, you can

00:35:36   get the big mailbox. It's actually what it's called. It's called Big Mailbox. That gets

00:35:39   you a terabyte of storage plus some other nice bonuses. So $29 a year gets you a mailbox

00:35:44   that can hold a terabyte of email, which I think sounds like my personal hell. They even

00:35:49   have email forwarding for just $5 a year, so you can keep using, if you already have

00:35:53   an email account somewhere else like Fastmail, whatever, you can keep using that for just

00:35:57   $5 a year. That will forward your email for your domain to anywhere you want.

00:36:00   Anyway, all this is great.

00:36:01   You can get 10% off your first purchase from Hover

00:36:03   by going to hover.com and use promo code SLOTTOASTERPEOPLE,

00:36:07   all one word, SLOTTOASTERPEOPLE.

00:36:10   Thanks a lot to Hover for sponsoring our show once again.

00:36:13   - Okay, so there was a little bit of a surprise

00:36:17   within the Photos app, and some people went spelunking.

00:36:20   I'm assuming it was Steve Troutonsmith.

00:36:23   Is that right, Steven Troutonsmith?

00:36:24   I'm sorry, but that guy.

00:36:27   and we have, he, they, someone has discovered UXKit.

00:36:32   So UXKit appears to be sorta kinda UIKit for the Mac.

00:36:37   Marco, do you wanna talk about this a little bit?

00:36:41   - Yeah, so it's a private framework that is used

00:36:43   only by the Photos app at the moment

00:36:45   that Apple shipped with the Photos app beta.

00:36:47   And it appears, you know, you can't,

00:36:49   no one's like disassembling it, I don't think,

00:36:51   but you can class dump it and you can kinda see

00:36:53   just like what classes and methods are contained within it

00:36:56   from the Objective-C runtime.

00:36:58   - It's not just photos, by the way.

00:37:00   People say that Xcode 6.3 beta also uses UXKit.

00:37:03   - That's interesting if that's true.

00:37:05   I do not know that.

00:37:05   - Yeah, there's a tweet from Don Mowry saying that.

00:37:08   I suppose it's easy enough to confirm,

00:37:10   but I put a tweet in the show notes.

00:37:12   - That is interesting.

00:37:13   Well, anyway, so, and what it appears to be

00:37:16   is a subset of UIKit ported to the Mac,

00:37:19   and so there are things, and just like, you know,

00:37:22   with the UI prefix replaced with UX,

00:37:25   And so there's things like, I think there's a UX navigation

00:37:28   controller and stuff like that.

00:37:29   And there's UX color or UX-- all this.

00:37:33   Because normally, between UIKit on the iPhone

00:37:35   and AppKit on the Mac, there are a lot of big differences,

00:37:39   but a lot of also just little superficial differences.

00:37:42   The prefix for UIKit is just UI.

00:37:45   The prefix for AppKit is NS.

00:37:47   And so you have some classes like UI color versus NS color,

00:37:51   and UI image versus NS image.

00:37:53   And many of these classes that have these superficial name differences aren't that

00:37:58   different, or the Mac version supports some ancient stuff that no one really uses anymore,

00:38:03   so you might as well just unify them.

00:38:06   So there's a lot of overlap that seems trivial, and many people have written C macros or utility

00:38:14   classes to have a unified codebase that shares some of this code between iOS and Mac more

00:38:19   easily.

00:38:20   So this appears to be Apple's version of this on this one app in this one team, where this

00:38:27   is their translation layer to have the same code, probably, to have the same code running

00:38:32   on iOS and Mac.

00:38:35   So the question is, is it just this one team?

00:38:38   Is it just this one app?

00:38:39   Or is this going to be a more widespread thing?

00:38:41   Is it going to become public?

00:38:43   And is this going to be the new unified UI framework so that you can share a lot more

00:38:47   code between iOS and Mac?

00:38:49   That's all, basically nobody knows anything about that yet, everyone's just speculating,

00:38:54   but that's why this is interesting. What do you guys think?

00:38:58   Guy English had a good point, and it's the analogy that came to mind when I thought it

00:39:02   was well. So, setting aside that Xcode 6.3 also appears to use it according to this tweet,

00:39:09   Guy pointed out ProKit.framework, remember that?

00:39:11   Yeah, all the pro apps, Logic and everything, Aperture.

00:39:15   What are the other apps that used it?

00:39:19   Maybe Shake when that was out.

00:39:21   Not Final Cut.

00:39:22   Well, maybe Final Cut.

00:39:23   Anyway, a whole bunch of Apple's apps that look different, like the window chrome was

00:39:26   different, it was darker and sometimes it was smaller and they had their own little

00:39:30   weird set of controls and everything.

00:39:31   They used ProKit framework, which was a framework shared among Apple applications that gave

00:39:39   a different UI.

00:39:40   I mean, I assume it wasn't just look and feel.

00:39:42   I assume it had other features as well.

00:39:43   But the point is that it was a framework that was not for public consumption

00:39:47   That Apple used on multiple applications that never became the future of AppKit, right?

00:39:53   So the idea that UXKit could just be a thing that Apple uses internally to make its applications

00:39:58   This is a completely viable idea. It's not crazy to think

00:40:02   Oh, well now once they UXKit like because Apple also does the opposite they they take

00:40:07   Frameworks they use them privately for a release or two and then make them public, right?

00:40:12   So now we can't tell whether this is going to be one of those things that's used privately

00:40:16   and becomes public, or is it just another ProKit that Apple will use internally to make

00:40:20   its life easier when it makes its applications, but it is not the future of making UIs on

00:40:25   the Mac.

00:40:26   There is some debate around this from smart programmers who are saying, "Look, you really

00:40:30   don't want to have the unified framework because the Mac and iOS UI-wise are different."

00:40:37   And the very low-level stuff, the foundation classes, that's like the data structures,

00:40:41   the networking, stuff like that, that all is unified already.

00:40:45   And what's mainly not is UI stuff.

00:40:49   And there is a great argument to be made there that many people have made that that should

00:40:53   be separate because just porting an iOS app directly to Mac and using a lot of the iOS

00:41:00   interface paradigms like navigation controllers and things like that, it doesn't really work

00:41:04   well on the Mac.

00:41:05   It's really not like that's kind of a waste of what the Mac is good at and it just kind

00:41:09   and it feels like you're clicking an iPad app basically.

00:41:11   - But what about things like collection views,

00:41:13   like the fancy iOS collection views

00:41:14   that sort of reflow themselves,

00:41:17   or even just something like a better table view.

00:41:19   I mean, I know they've improved table view

00:41:20   getting rid of NSL and everything.

00:41:22   Those type of things kind of span the range.

00:41:24   I mean, they might still have weird APIs

00:41:26   like touches begin inside cell,

00:41:28   and it's like, what do you mean touches?

00:41:30   There's no, you know what I mean?

00:41:31   What you have to think is, look, this framework exists,

00:41:34   and the class names make you think it's very UI,

00:41:37   Like why would Apple bother making this?

00:41:39   And for the Photos app, the obvious answer to me is,

00:41:42   the photos for the Mac app looks like photos for iOS,

00:41:46   right down to zooming out and seeing that giant grid

00:41:48   of like photos for this month or week or year.

00:41:50   Like it is very clearly a Mac-ification

00:41:54   of the iOS Photos app.

00:41:56   So UI wise, you know, ignoring like the backend

00:41:58   and how it stores photos and the iCloud

00:42:00   and everything like that.

00:42:02   So much, it looks much more like,

00:42:04   hey, someone ported iOS photos to the Mac

00:42:05   in anything like, "Hey, someone made a new version of iPhoto."

00:42:09   So if you have the existing Photos app, which presumably uses UIKit, and you wanted to make

00:42:15   a Mac version of that, being able to reuse, if not that code directly, then that code

00:42:23   indirectly or the structure of the program, it would be really convenient to have something

00:42:27   like UXKit where you can get the benefit of all that UIKit code and get some semblance

00:42:33   of a Mac version up and running faster.

00:42:35   That doesn't answer the question of why it would be used in Xcode, but historically Xcode

00:42:39   has been used to dogfood all sorts of weird stuff like garbage collection and, uh, what

00:42:43   was the other one, it was dogfood-arc, I think?

00:42:45   Did it dogfood-arc first?

00:42:47   Anyway, that could also just be Xcode dogfooding things, because if you're gonna experiment

00:42:51   with weird technologies you should definitely do it on the application that developers use

00:42:54   to write programs.

00:42:56   The argument of "you should keep them separate" is weakened once you start looking at, like,

00:43:02   What things in iOS would you not have on the Mac, and vice versa?

00:43:07   And I think that list is actually a lot smaller than you might expect if you're starting to

00:43:12   make this argument.

00:43:13   And if you look, like, as you said, Collection View, that's applicable to both.

00:43:19   So many little components.

00:43:20   UI Control, UI Image, UI Image View, UI Label, Table View, Text View, so many of these things

00:43:27   actually, like, there's not a great argument that they shouldn't be the same on both.

00:43:32   It's really just the very high level structures, the very high level navigation concepts, navigation

00:43:38   layouts, that kind of stuff should be different on both.

00:43:41   But that's really a very small part of UIKit in the grand scheme of things.

00:43:44   And you don't even know, like you say "Oh, navigation controller, we don't really push

00:43:47   new things on it."

00:43:48   But there's no reason you couldn't make a Mac app that in one of its windows does a

00:43:52   sort of UI navigation controller thing of pushing a new view on and popping it off.

00:43:57   It might be weird, but arguably a lot of the existing OS X apps do a lot of iOS-y type

00:44:04   things.

00:44:05   Hell, I think in Messages it has buttons that aren't buttons but are just colored text.

00:44:09   I think I pointed that out in my Yosemite review if I meant to.

00:44:12   There's a details button or something in Messages that is not a button, it is just blue text.

00:44:15   It's like, "This is not iOS, what do you think you're doing here?"

00:44:17   But people accept it.

00:44:19   It's like, "Alright, whatever, I know when I click that I get details."

00:44:23   serving certain interests, as an iOS programmer who doesn't know much about the Mac, it

00:44:29   would make me way more likely to start tackling a Mac app if this stuff was more consistent.

00:44:34   And I know, like, if I just dive into the Mac and really am committed to it, I could

00:44:38   work through AppKit pretty well, I could figure it out, you know, that's not the only reason

00:44:44   I'm not making a Mac app, but it would definitely make me a lot more likely to make a Mac app

00:44:48   sooner and it would make it a smaller undertaking if a lot of this stuff is unified, instead

00:44:53   of having all these little superficial differences, some big, some small.

00:44:58   That has to play in somewhat to any decision they make to this.

00:45:02   If Apple wants to encourage more Mac apps, if they want to populate the desolate, awful

00:45:08   landscape of the Mac App Store, which is really sad in a lot of places, if they want to help

00:45:13   populate that with more, better apps, if they want to get more people making Mac apps, more

00:45:18   people using the Mac for a lot of this stuff. They have to make it easier for developers.

00:45:22   Right now, all the people who are saying this shouldn't be unified are all long-time Mac

00:45:30   programmers. Long-time iOS programmers, I think, are very excited about this idea. We

00:45:37   look at the Mac as like, "Well, we could go here fairly easily, but all this stuff

00:45:41   is needlessly different."

00:45:43   Yeah, and like even if you made the core of your app like oh it's all written in

00:45:48   sort of completely platform agnostic manner and it doesn't really matter or

00:45:51   I'm using some framework that's on both places like core data or something, the

00:45:55   UI part is like you see like oh and just we'll just put a different UI on top of

00:46:00   it. I'm not gonna say it's the hard part but it's a surprising amount of work and

00:46:03   if you have to repeat it and keep them in sync and every time you want to add a

00:46:06   feature you have to add it in both places of a totally different code

00:46:08   using different APIs it's just it's a lot of extra work. I'm not sure UXKit

00:46:13   it makes it, you know, lowers the barrier enough to really move the needle on the Mac

00:46:19   App Store because it has other problems, you know, and it's just there's so few Mac users,

00:46:25   like I think you'd have to really make it a low barrier for someone's, "Hmm, I can address

00:46:28   the market of like hundreds of millions of iOS devices or like a couple of Mac people

00:46:33   like there's like a million or two or five or whatever."

00:46:36   So the iPhone is just such a monster and that's just one iOS device compared to the Mac, right?

00:46:41   But if this was their goal, like their long-term goal, like we're going to dog food this, we're

00:46:46   going to see if it's possible, because we as Apple have a bunch of iOS apps that we've

00:46:50   decided this is the right way to do photos with the stupid view where you zoom out and

00:46:53   see everything as a big thing and you put your finger or your cursor over it and see,

00:46:57   you know, that's the future of photos.

00:46:59   We already wrote that app.

00:47:01   Can't we just get that to run on the Mac?

00:47:02   Well, no, because X, Y, and Z.

00:47:03   It's like, well, okay, so we have a job to do.

00:47:05   We can use this UX Git framework to be the first people to try to do that.

00:47:09   But Apple has way more resources to throw towards the successor to iPhoto than the average

00:47:15   developer with an iOS app who might be thinking about making a Mac app.

00:47:18   So if Apple runs this experiment and decides, "Boy, this really makes porting much easier,"

00:47:23   then what do they do about it?

00:47:24   Do they just say...

00:47:26   How would they...

00:47:27   Assume that this is a successful experiment inside Apple and assume that the goal of it

00:47:30   was to see if this is something that developers might want for the reasons that Marco stated.

00:47:34   How does Apple then at WWDC announce this as a thing?

00:47:38   And tell, like, what is the messaging?

00:47:41   It's like, so you're thinking of writing a Mac app.

00:47:43   If you have an iOS version, then look at UXKit,

00:47:47   'cause you could reuse a lot of that same code,

00:47:48   changing all the capital I's to capital X's or something.

00:47:51   But otherwise use AppKit, or is the message like,

00:47:54   this is the future of writing Mac applications.

00:47:57   It just happens to look like the iOS one.

00:47:59   But even if you never write an iOS Mac,

00:48:00   we're telling you you should use UXKit

00:48:02   to write your Mac apps.

00:48:04   - Well, honestly, I think if they actually unified it,

00:48:07   it would just be called UIKit Everywhere.

00:48:09   - Yep.

00:48:09   - Like that's the direction they would go.

00:48:11   They would work from iOS back to the Mac,

00:48:14   and they would just bring over everything named UIKit

00:48:17   that makes sense to have on the Mac.

00:48:19   And also, one advantage they would have here is right now,

00:48:22   they're maintaining two different frameworks.

00:48:24   They're maintaining two different UI libraries,

00:48:26   and AppKit is very, very old,

00:48:30   and there's a lot of cruft in there from the olden days.

00:48:33   UIKit was kind of like a rewrite of AppKit for the iPhone,

00:48:38   and to be more modern and to be more efficient

00:48:42   and have all these new capabilities

00:48:44   and be simpler in a lot of ways.

00:48:46   UIKit is like, it is the rethink of AppKit,

00:48:49   it is the rewrite of AppKit.

00:48:51   They just didn't replace AppKit with it quite yet.

00:48:53   - If they were gonna call it UIKit everywhere though,

00:48:55   doesn't that count?

00:48:56   Because the code is not the same.

00:48:58   Like UXKit, I'm led to believe,

00:49:00   is more or less just a wrap around the existing App Kit

00:49:03   APIs to begin with.

00:49:04   And maybe they would gut that out later.

00:49:06   But I don't think you can pull that out

00:49:07   because you have to maintain support for App Kit

00:49:09   for a long, long time into the future.

00:49:11   So linking against the--

00:49:13   if they called it UI Kit, you couldn't link against

00:49:18   that framework if one set of code

00:49:21   is the native code for the iOS devices, and another set of code

00:49:24   is the wrap around App Kit.

00:49:26   I don't know how you could do that with the same name.

00:49:29   I think the reason the X is there,

00:49:32   it just doesn't make sense to me.

00:49:34   It's not going to be a single unified code base.

00:49:36   It's going to be two separate code bases.

00:49:38   And having two separate code bases in a framework

00:49:40   with the same name on two--

00:49:41   I mean, I suppose you could pull it off,

00:49:42   because the SDKs are in different folders.

00:49:44   This is the iOS SDK, and this is the Mac SDK.

00:49:46   But it just looks like--

00:49:47   I mean, think about looking up documentation for it.

00:49:49   Surely there would be differences.

00:49:50   So I don't know.

00:49:51   Messaging-wise, though, that's--

00:49:54   we'll get to those after the next sponsor.

00:49:55   but that is a weird message that like AppKit,

00:50:00   we've been evolving and improving for a long time,

00:50:02   but now, you know, it's like,

00:50:05   I always wonder that when they bought Next,

00:50:07   like how, I wonder how long the NS prefix will keep,

00:50:09   I wondered initially,

00:50:10   would they keep the NS prefix and everything?

00:50:11   'Cause it's kind of weird, you know, NS next step,

00:50:13   like why do all these KOHO classes have NS prefix?

00:50:16   I bet there's tons of people just starting out programming

00:50:18   for the Mac and wondering what the hell

00:50:19   this NS crap is about, right?

00:50:21   But it's held on for a surprisingly long time, right?

00:50:25   And if they get out from under it and say,

00:50:28   all right, this is the new thing, and we call it UXKit,

00:50:32   and maybe in the future it'll be unified,

00:50:34   but for now we have UIKit and UXKit.

00:50:36   And I still think they would be stuck

00:50:39   maintaining three things--

00:50:41   AppKit, UXKit, which is on top of AppKit, and UIKit.

00:50:45   So it wouldn't be-- maybe long, long term it's a unification.

00:50:48   But I don't know, the messaging just-- it seems weird to me.

00:50:51   Yeah, I mean, that's fair about maintenance.

00:50:53   The messaging I don't think would matter.

00:50:55   I mean, look, they have two languages now.

00:50:57   - Well, but one of them is clearly a successor to the other.

00:51:01   - Yeah, I think it's gonna be long-term.

00:51:02   And by the way, a lot of people are speculating

00:51:04   that UXKit might be Swift-only or Swift-native.

00:51:08   I think we can already tell it's not

00:51:10   just by inspecting the file and everything,

00:51:13   but if you look at the timing of this,

00:51:18   the Photos app was introduced at the same time

00:51:20   as Swift Beta 1.

00:51:21   When Swift Beta 1 was announced at WWDC last year, very few people inside Apple had even

00:51:27   used it yet.

00:51:28   So I think it's extremely unlikely that there's any Swift code in the Photos app.

00:51:32   Well, there's probably some Swift code.

00:51:35   That's the way they would, you know, but I don't think it's written from the ground up

00:51:38   in Swift, and I think you're right that this is an Objective-C framework.

00:51:41   The whole point of Swift is you can call through to the Objective-C frameworks, and half of

00:51:45   the stuff they did in Swift 1.2, which we didn't even talk about, was making it less

00:51:49   painful and less awkward to interoperate between Swift and Objective-C stuff by adding a whole

00:51:54   bunch of annotations that you can mark up an Apple. I'm assuming it's marking up its

00:51:57   own Objective-C APIs with all these annotations that mean nothing to Objective-C but totally

00:52:01   let Swift know how it needs to write the adapter classes to be less annoying.

00:52:05   Exactly, and I think that's the biggest sign as anything that Objective-C is not going

00:52:10   to go away two years from now. This is going to be a very long-term replacement. Right

00:52:17   now, look at how many Apple classes are still using C++, as there are so many APIs that

00:52:23   are still in C++ that I don't think we have to worry anytime soon that Objective-C is

00:52:28   going to be just ended.

00:52:29   Well, I mean, it could be ended in the sense that they tell you when you're writing your

00:52:33   application the only code you will ever write is Swift.

00:52:35   You could get away with that, but it's like, "I'm not limited.

00:52:38   I can call all the existing frameworks and APIs.

00:52:40   I can call them all from Swift, right?

00:52:43   I can do weird C-style stuff too."

00:52:45   So you could say, third-party developers, if you were starting a fresh new application

00:52:49   and opening a new project in Xcode, write all your code in Swift, and you'll be fine.

00:52:54   They're not at that point yet, but that's where they want to get.

00:52:56   And that point could come way before all the Objective-C code is gone, because that's going

00:53:00   to take forever.

00:53:02   People at Apple are going to be writing Objective-C for a long time, but they could be telling

00:53:04   all third-party developers, "We would like it if you just wrote all your code in Swift,

00:53:10   and you won't be limited in which APIs you call."

00:53:13   The idea of a Swift-only or a Swift-native API, what's the selling point of that other

00:53:18   than ideological purity at this point and in the near future?

00:53:24   Surely that day will come, but unless there's some big advantage in terms of speed or interface,

00:53:31   it's going to be difficult to justify it because then you'd be cutting off all the people with

00:53:34   existing Objective-C apps and there's a lot of them.

00:53:38   I would not expect a Swift exclusive API

00:53:41   for anything important to be available in the next,

00:53:45   I don't know, two years at least.

00:53:46   I mean, I think it's gonna be a while.

00:53:49   - Apple likes to move fast.

00:53:50   They like to like, "Oh, it's sooner than I expected.

00:53:52   "I didn't think," you know, and in fact,

00:53:54   they will probably do it with something important

00:53:56   when they decide to do it,

00:53:57   but it seems like it's just way too soon now.

00:53:59   So that probably means that whatever your estimate

00:54:01   was two years, like maybe cut that in half.

00:54:03   'Cause don't they always surprise us where it's like,

00:54:06   You know, the way they herd everybody into whatever new thing they want to do is like

00:54:11   the new hotness is only available with X and...

00:54:13   Yeah, but not necessarily... first of all, not necessarily on this level of like the

00:54:18   language level of what you're doing with the API level, not necessarily on that level,

00:54:21   and also I think the last time they did that, like with, what was it, with Carmen, like

00:54:26   when was the last time they did that?

00:54:27   Oh no, the best example I think is how you can't build applications for older versions

00:54:31   of OSs with the newest version of Xcode.

00:54:34   They want to push everybody to the newest version of Xcode.

00:54:37   And that's why people have to keep seven versions

00:54:38   of Xcode running on old machines.

00:54:40   Like they're like, you can't even target, you know,

00:54:43   Snow Leopard anymore with this thing.

00:54:44   And like they are pushing people up their OS support chain

00:54:48   forcibly by saying, look, you're gonna have to have

00:54:50   this version of Xcode, 'cause it's the only way

00:54:51   you can develop for the iPhone 5,

00:54:53   but you can't develop for Snow Leopard with it.

00:54:55   So, you know, all these people keeping these VMs alive

00:54:58   with ancient versions of Xcode and the old SDKs,

00:55:00   that is Apple aggressively pushing people way too fast.

00:55:03   Like as soon as people are running VMs

00:55:05   with old versions of your IDE,

00:55:06   you know you're going too fast.

00:55:07   And that is a very common thing that people do.

00:55:10   - Yeah, actually a lot of Mac developers need to do that.

00:55:13   - I think it'll be sooner.

00:55:14   I tend to come down on this closer

00:55:16   to Jon's point of view than Marco's.

00:55:18   I think the push to Swift is going to be more aggressive

00:55:21   and sooner than any of us expect.

00:55:24   I think I'm on the edge.

00:55:27   I almost want to say something will be Swift specific

00:55:31   or this year, maybe at the end of the year,

00:55:35   I think perhaps it's more reasonable

00:55:37   to say sometime in 2016, but I think it'll be soon.

00:55:39   I think it'll be really soon.

00:55:41   And certainly Swift is making

00:55:43   some really significant steps in doing so very quickly.

00:55:48   What I keep thinking is, you know,

00:55:51   Swift is supposed to make a lot of the dangers

00:55:54   of Objective-C go away.

00:55:55   And that's of course causing a lot of,

00:56:00   I don't know about drama, but maybe doubt in the community, especially amongst those

00:56:05   who have worked with Objective-C for a long time.

00:56:08   But I think that if Swift prevents really silly programming errors, and if it's a little

00:56:16   more stable eventually, and it runs faster eventually, it's in Apple's best interest

00:56:21   to push everyone that direction.

00:56:23   And I think they will, and I think they'll do so really aggressively.

00:56:25   Yeah, but I mean, honestly, I think most of the drama is already really fizzling out,

00:56:33   and I think it's only a matter--it's only a couple more Swift revisions.

00:56:37   I mean, look at how much they did in 1.2.

00:56:39   It was a pretty substantial upgrade in a lot of ways, and I don't even use it yet, but

00:56:44   I can tell just by looking at what they changed and other people's reactions to it, it's a

00:56:47   pretty substantial upgrade.

00:56:49   I read a bunch of these blog posts of like, "We switched our big project to Swift," or

00:56:53   rebuilt a big project in Swift and here's how it went."

00:56:56   And overall it seems to be, people are mostly okay with the language itself, with a few

00:57:04   minor differences here and there, but mostly okay with the language itself, but they just

00:57:09   complain that the tools are immature still.

00:57:11   That's working itself out pretty quickly, really.

00:57:13   They just added the incremental compilation, which was probably the biggest complaint in

00:57:18   its absence before.

00:57:20   In less than a year, Apple has eliminated most major complaints about the language.

00:57:28   There's still some minor complaints, and there's still some people who really object to certain

00:57:32   things about it that will probably never change, but for the most part, they've already addressed

00:57:37   many, many good complaints about it in less than a year.

00:57:42   And they're moving really fast.

00:57:43   They're making big, big breaking changes, almost so much like it's frustrating reading

00:57:48   the documentation for the language and trying to learn the language just to the point you

00:57:51   think you're actually learning things, they change it all.

00:57:53   And you're like, "But I just learned how it worked before, now it's totally different

00:57:56   again."

00:57:57   And they don't do it in minor ways.

00:57:58   Like, "Oh, we tweaked this little syntax here, but there's big fundamentals."

00:58:02   Just wait until they add exceptions and regular expressions, people's brains are going to

00:58:05   explode, right?

00:58:06   This is why I haven't learned it yet.

00:58:07   This language is moving fast.

00:58:10   And it's like, "Wow, at one point it was a big change.

00:58:13   I feel like, well, my program got five times faster and I didn't change anything.

00:58:17   might compile times are lower.

00:58:19   It's still super young,

00:58:21   and I think it's probably still super buggy,

00:58:22   and they've got a long way to go.

00:58:23   But I think the inclination is to think,

00:58:26   well, it's young now, and there's these big changes,

00:58:29   but the rate of change will slow down.

00:58:30   And I expect it to not slow down,

00:58:33   to make people uncomfortable with the amount

00:58:35   that it doesn't slow down for the next couple of years.

00:58:38   At a certain point, it's gonna be kinda like

00:58:40   the change fatigue with the OS.

00:58:41   Go like, all right already.

00:58:43   My annoyances with whatever features in Swift

00:58:46   are now dwarfed by my annoyance that you keep changing

00:58:49   the language every three months.

00:58:51   We understand you're addressing all of our problems

00:58:53   and trying to make things better,

00:58:54   but now I just want it to be stable so I can write some code

00:58:56   and feel like I actually know the language.

00:58:58   That's gonna happen in like eight months

00:59:00   if they keep up this pace.

00:59:02   - Yeah, hopefully.

00:59:02   I mean, I said last year I was gonna wait about a year

00:59:05   before I even looked at it,

00:59:07   and so far that's working out very well.

00:59:09   I can see in passing, oh, they're making

00:59:11   all these big changes, but I have no investment in it.

00:59:14   I haven't even read the Apple Swift book yet,

00:59:17   the thing they release on iBooks for free,

00:59:18   I haven't even read that yet.

00:59:19   - That's good because every page of it has changed by now.

00:59:22   - I know.

00:59:23   And so I'd rather just wait until it settles down,

00:59:26   at least most of the way.

00:59:28   I would expect within the,

00:59:30   you said within the next couple years,

00:59:31   I think it will be pretty stable even in a year from now.

00:59:35   - But I think the reason I don't think

00:59:37   it'll ever really stay is just like,

00:59:39   built into this language is the idea

00:59:41   that it is a versioned language,

00:59:42   and there's no backward syntax compatibility,

00:59:46   their entire path forward, and we'll see how this works,

00:59:48   is that the IDE is going to update your source code.

00:59:51   They're not going to support Swift 1.0, 1.1,

00:59:54   for the source.

00:59:56   It's not like I wrote this in Swift 1.0,

00:59:58   and I'm gonna be able to compile it in Xcode 9

01:00:00   many years from now.

01:00:01   No, you won't, no, you can't even compile that now probably.

01:00:04   Their whole strategy is source compatibility, forget.

01:00:06   I mean, maybe they'll change their policy.

01:00:08   When it comes to the maturing point,

01:00:10   they're gonna say, okay, now the new policy is

01:00:11   we will actually respect the sanctity of your source code

01:00:13   and not require you to like, you know,

01:00:15   use our refactoring tools to upgrade the syntax.

01:00:18   But they're not in that phase yet.

01:00:19   They're in the phase that says,

01:00:21   "We told you we're gonna break syntax compatibility.

01:00:23   "We are going to.

01:00:24   "We're never gonna compile your Swift 1.0,

01:00:26   "1.1 stuff anymore.

01:00:27   "So just get used to it and you better upgrade to Swift 1.2.

01:00:30   "And by the way, 1.3 will do the same thing to you."

01:00:33   - Our final sponsor this week is Automattic,

01:00:35   your smart driving assistant on your smartphone.

01:00:38   go to automatic.com/ATP.

01:00:41   So, automatic is this little dongle

01:00:43   that plugs into your car's OBD2 port.

01:00:46   It's the same port they use at the mechanics

01:00:48   or the dealers where they check it for error codes.

01:00:50   It's usually in the driver footwell.

01:00:52   Automatic plugs into that, and so all the information

01:00:54   that the dealers can get and the mechanics can get

01:00:56   out of your car, automatic can get,

01:00:58   and it has a smartphone app that integrates with this

01:01:00   and does cool stuff.

01:01:01   So, one thing it does, so by the way,

01:01:03   this works on iPhones and Android phones,

01:01:06   which is pretty great.

01:01:07   And it can show you by combining the smarts in your car

01:01:10   with the smarts in your phone, it shows you things like where

01:01:14   you've driven and how efficiently you drive.

01:01:16   It gives you feedback on your driving in real time that can

01:01:19   save hundreds of dollars a year on gas.

01:01:22   They can even call emergency services for free in a serious

01:01:26   crash, so if your car crashes and your phone is at all

01:01:30   workable, it can use your phone to call emergency

01:01:33   services for you.

01:01:34   This could really seriously be a benefit here.

01:01:37   Automatic also can diagnose any check engine light code.

01:01:41   So because it's in that port that all the mechanics use,

01:01:44   if there's any kind of error code

01:01:45   that causes the check engine light to come on,

01:01:47   the car has a lower level error code than that.

01:01:50   It's just not showing you

01:01:51   'cause it usually just lacks the display for that.

01:01:53   That's why it just says check engine.

01:01:55   But usually there's some lower level code.

01:01:57   And a lot of those codes are really obvious things

01:01:59   that you can fix.

01:02:00   Things like the gas cap isn't sealed all the way.

01:02:03   stuff like that you can just fix that yourself or you know minor parts swaps

01:02:06   you can do you know you can go to a mechanic instead of going all the way to

01:02:09   the dealer and paying all this money so it can save you lots of money with check

01:02:12   engine light codes it can give you lots of money savings on gas it can call the

01:02:16   emergency services for free in a crash and it even has little useful things

01:02:20   like parking reminders again it's combining your car with your phone so it

01:02:24   knows where you parked and you can use the automatic app on your phone you just

01:02:28   go find your car again they even have integration with a few different things

01:02:32   So they integrate with the Nest learning thermostat.

01:02:35   So for example, if you're headed home,

01:02:37   and Nest has you in away mode, so your house is cold

01:02:40   in the winter, Automattic knows you're

01:02:42   getting close to your home, so it will tell the Nest

01:02:45   to turn the heat on.

01:02:46   And so then by the time you get home,

01:02:47   your house is nice and warm for your arrival.

01:02:50   And even if you don't have a Nest,

01:02:52   they have integration with IFTTT, if this, then that.

01:02:55   So with that integration, you can integrate

01:02:57   countless other online services with your Automattic device.

01:03:00   So it's really great.

01:03:01   There's also an API.

01:03:02   You can download your driving data.

01:03:04   You can subscribe to events, like when you start and stop

01:03:06   the car, when your check engine light comes on, et cetera.

01:03:08   There's a whole API for use for whatever you want.

01:03:11   And if you have an Android phone,

01:03:12   they even have a feature called Do Not Disturb mode,

01:03:15   so that if you want, you can have it automatically mute

01:03:17   your phone buzzing or beeping while you're driving,

01:03:20   so you don't get distracted by those notifications.

01:03:22   So great stuff here.

01:03:23   automatic.com/atp.

01:03:26   And this is normally about $100.

01:03:28   There's no subscription fees.

01:03:30   This is one time up front, just $100.

01:03:33   There is no monthly fee.

01:03:35   You can buy the device, that's it.

01:03:37   Now there's a special offer for the podcast listeners, 20% off.

01:03:40   So for you guys, by going to automatic.com/atp, it's just $80.

01:03:45   20% off.

01:03:47   So just $80.

01:03:48   Free shipping in just two business days, and they have a 45 day return policy.

01:03:54   This is really risk free.

01:03:55   Fantastic deal.

01:03:57   $80.

01:03:58   free shipping in two days and a 45 day return policy.

01:04:01   Automatic.com/ATP.

01:04:03   Thanks a lot.

01:04:05   - And speaking of different ways

01:04:08   of writing your user interfaces,

01:04:11   a couple of things have happened over the last weeks

01:04:13   or months that a few listeners have asked us to talk about.

01:04:17   And the first, actually might have even been a year ago now,

01:04:20   is Async Display Kit.

01:04:22   Do you wanna tell us about that, John?

01:04:24   - Yeah, all this talk about UX Kit has,

01:04:26   Like the idea, oh, UXKit is a successor to AppKit,

01:04:29   and AppKit has this corrupted UIKit,

01:04:31   you know, learned from AppKit and did things better,

01:04:34   which is why it seems nicer to do a lot of things in UIKit

01:04:37   than it is in AppKit and everything.

01:04:38   And AsyncDisplayKit and the other topic we'll go after

01:04:43   about React, or React Native, rather,

01:04:47   point to sort of a larger leap above both the AppKit

01:04:52   and the UIKit paradigm, particularly having to do

01:04:55   with the requirements that certain things only be done on the main thread, laying out

01:05:00   the UI drawing, and there's some exceptions to that, where you can try to do some of those

01:05:04   things off the main thread, but generally that leads to sadness, unless you're super

01:05:07   careful and know what you're doing.

01:05:10   And that's a limitation kind of built into the framework, a framework that if you trace

01:05:15   its lineage through, you know, OpenStep and NextStep, AppKit going way back in time, made

01:05:20   sense when you didn't have a multi-core CPU in your little handheld crazy phone.

01:05:24   Symmetric multiprocessing was barely a glimmer in people's eyes back then.

01:05:29   Forget about these 12-core CPUs and everything like that.

01:05:34   But the reality is that now we do have multicore in everything, and even if you just offload

01:05:40   some of that work to another core, it can be a big benefit.

01:05:43   So AsyncDisplayKit is a thing, I think it's a thing that Facebook made for its native

01:05:47   applications, the paper application, where they wanted to do layout calculations.

01:05:52   basically math of saying how wide is this,

01:05:53   how much room is it going to take up, blah, blah, blah.

01:05:56   And they wanted to do it in parallel,

01:05:57   not on the main thread,

01:05:59   because they didn't want to block the main thread.

01:06:00   They wanted the main thread to be available

01:06:01   to pick up events and process them

01:06:03   and make the UI, you know, reactive,

01:06:06   not to use that word, the next thing.

01:06:08   And so they made AsyncDisplayKit,

01:06:11   which is a thing on top of AppKit

01:06:14   that lets you do UI type calculations

01:06:17   in asynchronously and possibly in parallel

01:06:21   and other threads and then do it in a nice way

01:06:24   so that the actual layout gets done on the main thread

01:06:26   as it has to to work with the thing,

01:06:28   but you can actually do the calculations elsewhere.

01:06:30   And that's what makes me look at UXKit and think like,

01:06:34   this can't really be the future of anything.

01:06:36   It seems just like an interim step

01:06:38   because I would wanna see a leap,

01:06:40   like UIKit was a nice step up from AppKit,

01:06:42   but it was kind of like more like a cleaned up AppKit,

01:06:45   but it didn't revisit some fundamental assumptions

01:06:48   in light of the hardware realities that we have today.

01:06:52   And I think something like,

01:06:54   something that incorporated something like Async Display Kit

01:06:57   into the fabric of the framework would be much better

01:06:59   than someone taking AppKit or UIKit

01:07:01   and layering another framework on top of it

01:07:03   to offload stuff to other threads and stuff like that.

01:07:06   - Yeah, so Async Display Kit was most,

01:07:10   gained most of its fame, I guess, from paper,

01:07:14   which was, is an app that Facebook wrote

01:07:17   as a kind of alternative to their traditional Facebook app.

01:07:21   And it's actually the app that I use on my phone

01:07:23   because it freaking supports sending messages,

01:07:26   which is nice.

01:07:27   You don't have to have a separate app for that.

01:07:28   But anyway, it's very pretty

01:07:29   and the animations are very cool and it's very nice.

01:07:34   And that and Async Display Kit powers it.

01:07:36   Now lately, Facebook has taken a different approach

01:07:40   'cause React Native is Facebook, right?

01:07:41   I'm not making that up, am I?

01:07:43   - I think you're right.

01:07:45   - All right, well, we'll just assume I'm right, why not?

01:07:47   email me and tell me if I'm wrong.

01:07:49   Anyway, so React Native is also by Facebook

01:07:53   and React originated as, or at least to my knowledge,

01:07:58   as a JavaScript front-end framework,

01:08:01   kind of, sort of, but not really at all like Angular.

01:08:04   And then somebody at Facebook said,

01:08:06   "Well, you know what?

01:08:07   We could do something on the Native side with this."

01:08:12   And so there's an unbelievably good video

01:08:16   that I had seen by way of Andy Matuszak,

01:08:20   who has been coming up a lot lately, actually, on the show.

01:08:23   And it's an overview by one of the developers

01:08:27   of React Native at Facebook,

01:08:29   talking about how it works and kind of what it does.

01:08:32   And I haven't watched it for a week or two

01:08:35   since whenever it came out.

01:08:36   And so I can't really get into the specifics

01:08:39   'cause I'll steer us into a black hole of incorrectness.

01:08:42   But some of the stuff that it does was just unreal,

01:08:46   including being able to mess about with your UI

01:08:49   without doing another build.

01:08:52   And so you can have your app running in the simulator,

01:08:57   fart around with some stuff in Xcode,

01:08:59   and it will refresh itself in the simulator

01:09:02   without recompiling.

01:09:03   And additionally, you could actually connect Chrome

01:09:07   to the app, the running app,

01:09:09   kind of like we talked about, I think, last episode

01:09:11   with web views, but this isn't a web view.

01:09:14   This is all real honest to goodness native stuff.

01:09:17   And so you can connect Chrome,

01:09:19   they have some sort of interpreter connector, whatever,

01:09:21   and you can connect Chrome to your native app

01:09:24   running React Native and go inspecting it.

01:09:27   Kind of like, what was the third party thing

01:09:29   that got Sherlock this year?

01:09:31   Do you know what I'm thinking of?

01:09:32   - Oh yeah, the thing that exploded all the views.

01:09:34   - But yeah, so it's kind of similar to that.

01:09:36   And I haven't played with it yet,

01:09:38   But just watching this half an hour video,

01:09:41   my mind exploded probably 15 times.

01:09:44   Reveal, thank you for the chat room.

01:09:46   It was revealed that I was thinking--

01:09:47   - You're not gonna try and pronounce that?

01:09:49   - No, thank you person in the chat room.

01:09:51   Marius Sirachi, that's totally wrong.

01:09:54   Anyway, this video is really, really incredible.

01:09:59   And Marco especially, I'd be,

01:10:02   well, you haven't seen this, have you?

01:10:04   - No, of course not.

01:10:04   - Okay, nevermind.

01:10:05   So you're useless.

01:10:06   - Hey, in my defense, I did spend all day today

01:10:08   making another Go program.

01:10:10   So I was in this century.

01:10:12   - Okay, well that's good.

01:10:14   I would like to hear about that if we have time.

01:10:15   But John, what are your thoughts on this React Native thing?

01:10:18   Have you done React, the JavaScript framework at all?

01:10:21   - I retweeted a thing from like,

01:10:23   someone was making a joke, like a sign of the W3C

01:10:25   and it was one of those signs of the library.

01:10:27   I said, there have been blank days

01:10:31   since a new JavaScript framework

01:10:32   and it had zero whiteboard.

01:10:35   Like, I'm pretty sure I know what React is

01:10:38   and have seen it, like the JavaScript version

01:10:40   for web applications.

01:10:41   You can correct me if I'm wrong, Casey,

01:10:43   'cause you've watched the thing,

01:10:44   'cause I haven't watched it yet.

01:10:45   But React is the one where they do,

01:10:47   where they have all,

01:10:49   is it the one where they have like the DOM

01:10:51   sort of as a structure not actually connected to the DOM

01:10:54   and they do diffing against it

01:10:55   to figure out what actually needs to be updated

01:10:57   and that ends up being faster?

01:10:58   It's like, it's one of those crazy solutions

01:11:00   that has to do with,

01:11:01   it's not Shadow DOM, Crystal, TD, and the thing,

01:11:03   although that's a separate thing.

01:11:04   and web components are related to this,

01:11:06   but it's like, you would think it would be so much slower

01:11:09   to build these parallel structures in memory

01:11:13   that aren't the DOM,

01:11:14   and then figure out what the changes are

01:11:16   by diffing it against something else.

01:11:17   And then only at the end,

01:11:19   after you've done this crazy diffing thing

01:11:21   and it's just these abstract memory structures

01:11:22   that have no connection to the browser that you say,

01:11:24   now, finally, I know what I have to update in the DOM,

01:11:26   and you do the minimal update to the DOM,

01:11:28   but updating the DOM is so damn slow

01:11:30   that doing that diffing ends up being way faster

01:11:32   than doing it like the quote unquote direct way.

01:11:36   - It's worth pointing out also the Flipboard thing

01:11:38   on this topic, where Flipboard came out,

01:11:40   I think it was yesterday or the day before,

01:11:42   it was very recent, and they launched a web version,

01:11:45   and then their engineering department posted

01:11:47   this whole thing, how they're basically doing

01:11:49   a React-like diffing system in the middle

01:11:54   of this whole system where they're basically,

01:11:55   they basically rewrote part of WebKit

01:11:58   that just runs on a canvas.

01:12:00   And it's a very small part, but still.

01:12:02   Yeah, they call it a web version.

01:12:04   I put scare quotes around a web, because once

01:12:06   your entire application is just a big Canvas tag

01:12:08   that you draw stuff in with your own framework,

01:12:10   yeah, I guess that's the web.

01:12:11   But you've just reinvented ActiveX controls.

01:12:14   Like you're--

01:12:15   Oh, no, that's terrible.

01:12:17   That's really insulting.

01:12:17   Come on.

01:12:18   You know what I mean.

01:12:19   But you are not-- it's a difference.

01:12:20   We used to talk about this with Flash.

01:12:22   The web is-- we know what the web is.

01:12:24   And anything that is a rectangle in a web page in which

01:12:27   some other program runs is not the web.

01:12:29   And Canvas is like the borderline of that.

01:12:31   It's like, well, is that the web?

01:12:33   Or is it like you've written, you know, yes,

01:12:36   that you have a nice display layer

01:12:38   and you could in theory do everything yourself.

01:12:40   And they're not doing everything themselves,

01:12:42   but it's like, as many people pointed out

01:12:44   in terms of like accessibility

01:12:46   of a Canvas native application,

01:12:48   like unless you're signing up to re-implement,

01:12:51   you know, UI kit or app kit

01:12:52   with all the accessibility things

01:12:54   that are inherent there and support for all the tools,

01:12:57   it strikes me a lot as a big rectangle on a webpage

01:13:00   where other things happen,

01:13:01   which may be fine for Flipboard, but I don't think it's--

01:13:03   - That's fine for Flipboard.

01:13:04   - Yeah, right, but React is more like,

01:13:07   we're going to take the web as it exists

01:13:09   and we're just going to find out a nicer way

01:13:11   for you to write applications

01:13:13   or what they think is a nicer way.

01:13:15   React has some weird stuff going on.

01:13:17   They violate, they sort of sacrifice a lot of sacred cows.

01:13:21   They're the big things, I think,

01:13:22   also where they like mix JavaScript handlers in line with these fake things that look like

01:13:28   tags but really aren't and freaks people out because it looks like you're doing like the

01:13:31   old style on mouse over equals whatever but you're not really because that's not actually

01:13:35   DOM markup that's just a way to communicate with the like there's a lot of weird things

01:13:40   about React but I think that's all besides the point because I think the important part

01:13:43   of it is that it is a different model and it's a very different model from AppKit and

01:13:47   UIKit of how to make GUI applications and it's like well that's for the web the web

01:13:52   is so different than native, it has to be different.

01:13:54   And React Native is like, what if we take that same model

01:13:57   and apply it to native things?

01:14:00   Does that work?

01:14:01   Is it actually better than using UIKit or AppKit?

01:14:03   And some people apparently think it is.

01:14:04   I think the jury's still out on whether this new paradigm

01:14:08   is the way to go, but I think this combined

01:14:10   with AsyncDisplayKit show two different

01:14:13   potentially complementary approaches

01:14:16   that show, that are so different from AppKit and UIKit

01:14:21   and UXKit that it's like, it makes UIKit and UXKit

01:14:25   and AppKit look like Objective-C 2.0,

01:14:28   and it makes these things look like potentially Swift

01:14:30   or something like, I just feel like there's a bigger leap

01:14:32   to be had and it's like, I would recommend that Apple

01:14:36   not invest some huge amount of time pushing some unified

01:14:41   UIKit, UXKit type of thing for the future

01:14:43   because that transition will take a long time

01:14:44   and when you're done with the transition,

01:14:45   what you've got is basically,

01:14:46   now everything's as good as UIKit.

01:14:48   And UIKit may be nicer than AppKit in important ways,

01:14:50   but it is not sort of a large,

01:14:55   it's not as big a leap, potentially as big a leap

01:14:57   as Swift potentially is over Objective-C.

01:15:00   Like I'm looking for the next big step.

01:15:01   And I would say refine what you have now,

01:15:03   make AppKit better as you've been doing,

01:15:05   make UIKit better as you've been doing,

01:15:07   and get busy working on whatever the next big thing is.

01:15:10   And if it's something like React Native, fine.

01:15:11   If it's something that incorporates the ideas

01:15:13   of Async Display Kit, fine.

01:15:14   If you think you can retrofit those to both UIKit

01:15:17   and AppKit and let people do more things

01:15:18   off the main thread, maybe try that too.

01:15:20   but I'm not going to say this is my next Copeland 2010 type of thing, but I do look at these

01:15:27   other frameworks and I'm not convinced that they're the future, but they look different

01:15:31   enough from the present that I'm interested in potential ideas for the future.

01:15:35   Yeah, I agree. I think you're totally right that if you're going to make everyone do a

01:15:40   big transition, if there is this other thing that has come up in computer science-y type

01:15:46   circles and everyone thinks this is a really great idea and it turns out in practice to

01:15:49   to really be a really great idea,

01:15:51   it is definitely worth considering.

01:15:53   Is it worth, if you're gonna force people

01:15:55   to go through a transition,

01:15:56   to make a bigger leap, like Swift?

01:15:58   - It's not even like computer science-y,

01:16:00   just recognizing the hardware.

01:16:01   The hardware is so different now.

01:16:03   The frameworks we have are not a good match

01:16:05   for everything being multi-core

01:16:06   because of the main thread constraints.

01:16:08   And GCD helps that a lot.

01:16:10   GCD does help, but for UI code, it doesn't help

01:16:13   because it's like certain things you have to do

01:16:15   on the main thread or bad things happen.

01:16:17   And so that's like the Async Display Kit.

01:16:18   is like we're going to hack around that limitation

01:16:21   of Apple's frameworks and say,

01:16:22   you just sit there framework, don't worry,

01:16:24   we'll actually do the UI updates on the main thread,

01:16:26   but we're gonna do a whole bunch of other math over here

01:16:28   in our sort of play world.

01:16:30   And same thing with React, our sort of play world of,

01:16:33   this is not the UI,

01:16:34   but this is our little fake model of the UI

01:16:37   so we can actually take advantage of parallel processing.

01:16:39   And then we'll get back to you with like,

01:16:40   okay, now that your actual UI,

01:16:42   or now your actual DOM, please do this change.

01:16:44   And that is hacky and clever,

01:16:46   but it shows that the current frameworks

01:16:49   are just not a good fit for current hardware.

01:16:51   - Well, I think the multi-core hardware rendering

01:16:54   on main thread thing is kind of red herring.

01:16:57   In practice, the reason why a lot of UI code now

01:17:02   is tricky to write is not because drawing calls

01:17:06   have to happen on the main thread.

01:17:07   It's because, jeez, is it declarative versus procedural?

01:17:12   Whatever the, it's a different paradigm,

01:17:15   is what I'm saying.

01:17:16   It's not that it's tricky to write.

01:17:17   It's just that if you have performance concerns,

01:17:20   like you want to treat it more like a game engine, where

01:17:23   it's like, if you're going to do anything,

01:17:26   you have to be done, because I have to pull the next event off

01:17:28   the queue.

01:17:29   You need to leave the main thread alone.

01:17:31   Do not-- that's the whole thing of GCD.

01:17:32   Stop blocking the main thread, for crying out loud.

01:17:34   I don't care what you have to do.

01:17:36   Get in, get out.

01:17:37   I need to get the next event, because if it's

01:17:39   stuttery when it's scrolling, it's super bad.

01:17:41   And that's why AsyncDisplayKit has this cool--

01:17:44   one of the classes they have is like,

01:17:45   Say you're gonna show a big giant grid of images

01:17:47   and they're coming from the internet.

01:17:48   You can't wait to get all those downloaded

01:17:50   to figure out what sizes they are so you can lay it out.

01:17:52   It'll take forever.

01:17:53   So there's like this procedural thing

01:17:55   where like we'll download super low res versions of those

01:17:59   and asynchronously bring in the higher res versions

01:18:01   but just so you can get a scrollable correctly laid out

01:18:04   thing as soon as possible so you can start scrolling it.

01:18:07   That's the type of thing that's very difficult to do

01:18:09   with the existing framework

01:18:10   which it's like they don't expect sort of asynchronous

01:18:12   updates to all these features.

01:18:16   It should be easier than it is.

01:18:17   And it's not because of, like you said,

01:18:20   declarative versus procedural, that's part of it.

01:18:22   And you could say, oh, it's easier if I could describe

01:18:24   my UI in this way instead of writing a bunch of code

01:18:25   to make my UI in this way.

01:18:27   But it's like for large grids with lots of things on them,

01:18:32   I don't want to block the main thread with the amount,

01:18:34   I don't want my main thread to be blocked

01:18:37   if N is really large for something that's performance

01:18:41   is dependent on the number of items.

01:18:43   - Yeah, but I think it's more, you know,

01:18:45   like you said, like with GCD,

01:18:46   we can already step off the main thread, come back later.

01:18:49   Like, it's more of a paradigm shift.

01:18:52   It's not that like the APIs have to happen

01:18:55   on this main thread, it's that like,

01:18:56   the paradigm for how you update the UI,

01:18:59   like, 'cause the way React does it,

01:19:01   like if you look, like I don't know React,

01:19:03   so whenever I see snippets of React code,

01:19:05   it just breaks my mind.

01:19:07   Like, I'm looking at it and I'm like,

01:19:08   oh my god, this is totally backwards, inside out,

01:19:12   upside down, and in French.

01:19:14   Like it's so, it looks so foreign to me

01:19:17   'cause it's so different from what I'm used to.

01:19:20   - Yeah, so let me jump in here.

01:19:21   So one of the links is,

01:19:23   that we're gonna put in the show notes,

01:19:24   Why React Native Matters, and this is by Joshua,

01:19:28   I'm guessing that's Josh Haber.

01:19:30   Anyway, he says, right now we write UIs by poking at them,

01:19:34   manually mutating their properties when something changes,

01:19:37   adding and removing views, et cetera.

01:19:39   This is fragile and error prone.

01:19:40   Some tools exist to lessen the pain,

01:19:43   but they can only go so far.

01:19:45   UIs are big, messy, mutable, stateful bags of sadness.

01:19:48   React lets us describe our UIs for a given state,

01:19:51   and then it does the hard work of figuring out

01:19:54   what needs to change.

01:19:55   It abstracts all the fragile error prone code

01:19:58   out away from us.

01:19:58   We describe what we want,

01:19:59   React figures out how to accomplish it.

01:20:01   UIs become composable, immutable, stateless value types.

01:20:04   React Native is fantastic news.

01:20:06   And that's building, oh, it's Josh Abernathy, I'm sorry.

01:20:09   That's building on what you were saying, Marco,

01:20:11   where this is just a whole different model

01:20:14   of how you interact with user interfaces.

01:20:17   And it makes a lot of sense.

01:20:20   Maybe the particulars are a little bit wonky

01:20:22   and I'll concede that.

01:20:23   But the premise of really this is just moving

01:20:27   from one concrete state to another

01:20:29   and it should just be a finite state machine,

01:20:31   hopefully in theory.

01:20:33   That is a really cool premise.

01:20:34   And building on that, going back to Andy Matuszak,

01:20:38   he tweeted a few days ago,

01:20:39   put a link in the show notes,

01:20:40   "I say with confidence as a former UI kit author,

01:20:43   "React's model for the UI layer

01:20:44   "is vastly better than UI kits.

01:20:46   "React Native is a huge deal."

01:20:49   In another tweet, "They've just got to figure out

01:20:50   "the interaction and animation pieces."

01:20:53   And so he goes on just briefly,

01:20:54   "To all asking me what's React, filter bubble danger,

01:20:57   "you must watch the broader development landscape

01:20:59   "don't get trapped in one platform."

01:21:00   And I think that's a really good call.

01:21:02   And this is something very interesting

01:21:04   that's influenced from a web framework coming into native

01:21:09   and it's making some really interesting moves.

01:21:13   And I wouldn't be surprised if something along these lines

01:21:17   gets adopted by Apple in the same way

01:21:19   something along the lines of Reveal,

01:21:20   which isn't an apples to apples comparison,

01:21:22   but, you know, Reveal was kind of Sherlocked.

01:21:24   It wouldn't surprise me if they took a very similar

01:21:27   spiritual, spiritually similar approach

01:21:29   to whatever replaces UIKit and AppKit

01:21:32   eventually one day maybe. Oh yeah, because you know React, I mean it's making big waves,

01:21:37   and it's making waves with a lot of the people who matter with such decisions. People like Andy Matuszak,

01:21:42   and like people who are developing these frameworks, people who are in important positions, or were, or know people, you know like, or those

01:21:50   you know the new people in those positions. These are, it's making big waves. I've heard so much about React.

01:21:55   Every JavaScript framework out there besides React that's come out in the last decade, I hear nothing about because I don't care.

01:22:02   React makes big enough waves that I keep hearing about it.

01:22:05   Like, I don't know anything about Angular.

01:22:07   Is that the one that has like a million different levels

01:22:09   of factories?

01:22:10   - Yeah, Ember and Angular, yeah.

01:22:11   Like, you don't, those are confined to the client side.

01:22:14   React is coming over to the native side.

01:22:16   Like, I think to tie this together with AsyncDisplayKit

01:22:19   was like, you know, we were talking in two different things.

01:22:21   Like, I was mostly talking about AsyncDisplayKit

01:22:23   with the performance concerns,

01:22:24   and you were talking about React as the paradigm thing.

01:22:25   They're connected though, because React's functional thing,

01:22:29   where like, you know, you operate on state

01:22:30   and it's a value type thing, that sort of, you know,

01:22:34   lack of side effects where you just operate

01:22:36   on your arguments and return a value

01:22:37   and everything is sort of, you know,

01:22:39   like just a value type and all that stuff,

01:22:41   that you see a lot of that in Swift as well,

01:22:43   that allows you to parallelize that stuff.

01:22:45   Because if you don't have side effects,

01:22:46   if you're not, if it's not just one giant big ball

01:22:48   of mutable state, then you can only update

01:22:50   one thread at a time, otherwise you get crazy conflicts.

01:22:52   That's what, one of the many things that ties AppKit

01:22:54   to its current paradigm.

01:22:56   React, so, you know, React and AsyncDisplayKit

01:22:58   are connected because if you use the React model,

01:23:00   It doesn't matter what thread you do these mutations are,

01:23:02   it doesn't matter, you can do them all in parallel,

01:23:04   the same, like, they're side effect free,

01:23:06   they're pure functional, and so it lends itself

01:23:09   to that type of UI model, as opposed to the current model,

01:23:13   which is, we have this one thing, it is the state of the UI,

01:23:16   be super careful with it.

01:23:18   - And going back a sec to what Casey just said,

01:23:20   like, it is not past Apple to steal good ideas,

01:23:24   they do it all the time.

01:23:26   And if something is making this big of a wave,

01:23:29   and Apple's engineers and top people,

01:23:32   if Apple thinks it's a good idea, they will do it,

01:23:36   or they will do something similar to it.

01:23:38   And something like this, this is a pretty big deal,

01:23:41   like to change your entire UI API paradigm,

01:23:44   or to add a new one is a major deal.

01:23:47   And this is not something that can happen in a year.

01:23:50   This would be a big undertaking.

01:23:53   - It would have to be a Skunkworks,

01:23:54   but I think that the exciting thing about Swift is it showed

01:23:56   us, yeah, it was a Skunkworks,

01:23:58   But it was essentially one guy, one very powerful guy,

01:24:02   who had proven himself with many other things

01:24:03   that he had done in the company.

01:24:05   It's not just some random employee

01:24:06   off in the corner somewhere.

01:24:07   But for a long time, it was just one person.

01:24:10   And I'm sure there's lots of those one person type projects

01:24:12   that may or may not go anywhere.

01:24:13   But it just goes to show that you don't need buy-in

01:24:16   at the VP level to get the ball rolling

01:24:18   or something like this.

01:24:19   And maybe the ball starts rolling and then stops rolling,

01:24:21   like has happened with ZFS or whatever, other things.

01:24:24   It's not guaranteed that it's going to happen,

01:24:26   but it seems like Apple is currently an organization

01:24:28   in which something like this could start happening

01:24:31   and get killed before we ever see it

01:24:33   and something else comes along

01:24:34   and maybe React is just the hotness today

01:24:36   and then two years it's something else.

01:24:37   But it's not outside of the realm of possibility

01:24:40   that Apple can innovate in this way

01:24:42   on any subject other than file systems

01:24:43   which they seem insatially incapable of ever changing.

01:24:47   Not that I'm bitter.

01:24:48   - And tying it back, even though I really wanna end on that,

01:24:52   but tying it back, if they're gonna do something

01:24:55   like a React-style UI framework, that would be a really good thing to start with Swift

01:25:01   and to make Swift only. One of the things that makes React code look so weird is that

01:25:07   it fits in very weirdly with existing languages, which is like the syntax of declaring it and

01:25:12   using it.

01:25:13   The fact that it's using JavaScript, like this is...

01:25:16   Yeah, it's really badly bolted on. I mean, not by its own fault, but by the fault of

01:25:20   the language really, but Swift is still squishy and generally more pokeable.

01:25:27   But Swift is a much better fit.

01:25:28   The whole idea of so many things being value types in Swift, not that that is a direct

01:25:32   parallel to the idea of the UI state being a value type and everything, but it just shows

01:25:36   that the headspace, like where is Swift at in terms of immutable data, well it is much

01:25:41   more on the React side of things than Objective-C is, because Objective-C is all about everything

01:25:45   and be mutating and, "Hey, just declare this type ID.

01:25:48   "Whatever, guys, it's all right."

01:25:50   Whereas Swift is like, "No, we're gonna pin things down."

01:25:53   Lots of things that were reference types

01:25:55   are becoming value types just because we've learned

01:25:57   that making NSString reference type

01:25:59   just leaves no more headaches

01:26:00   and people forget to copy them.

01:26:02   It's like that is the mindset of Swift.

01:26:05   And so something using the good ideas

01:26:09   in React and Async Display Kit,

01:26:11   written natively in Swift,

01:26:12   would be a very interesting successor

01:26:14   to both UIKit and AppKit from Apple,

01:26:16   so someone should start writing that now

01:26:18   and in four years get back to me.

01:26:20   - And it'll give me a reason to learn Swift.

01:26:22   - Yeah, that'll be eight years later.

01:26:24   - Yeah. (laughing)

01:26:26   All right, thanks a lot to our three sponsors this week,

01:26:28   Igloo, Hover, and Automattic,

01:26:30   and we will see you next week.

01:26:31   (upbeat music)

01:26:34   ♪ Now the show is over ♪

01:26:36   ♪ They didn't even mean to begin ♪

01:26:39   ♪ 'Cause it was accidental ♪

01:26:41   ♪ Accidental ♪

01:26:42   ♪ Oh, it was accidental ♪

01:26:43   John didn't do any research, Margo and Casey wouldn't let him

01:26:49   'Cause it was accidental, it was accidental

01:26:54   And you can find the show notes at ATP.fm

01:26:59   And if you're into Twitter, you can follow them

01:27:04   [music]

01:27:34   What are we talking about?

01:27:35   Oh, your Go thing.

01:27:37   What is this about?

01:27:38   You're really getting into this Go thing.

01:27:40   - Yeah, I'm getting faster with it now.

01:27:42   And today was the first time,

01:27:44   my previous, the polar, the feed polar,

01:27:47   that's just one giant file.

01:27:49   'Cause I didn't want to figure out

01:27:52   how do I break up things into different files

01:27:54   and manage that in Go,

01:27:56   because it fit, it's a pretty long file,

01:27:58   and I should break it up now,

01:28:00   'cause it got longer once I finalized

01:28:03   all the stuff I actually needed to be in the system fully.

01:28:08   So tonight I was working on something else.

01:28:11   So I have these two servers at high velocity that I bought, or that I started leasing per

01:28:19   month about a month ago, and I haven't done anything with them yet.

01:28:22   I bought them because they were having an insane sale.

01:28:25   That was just ridiculous for what you get for both hardware and bandwidth, where now

01:28:31   a few hundred dollars a month, I now have an unmetered gigabit of transfer. A gigabit

01:28:37   per second unmetered of transfer.

01:28:39   What?

01:28:40   And I asked them, before I bought it, I'm like, "Alright, so what's your actual policy

01:28:44   here? If I actually use all this, what if I was hosting big podcast files? If I made

01:28:49   a podcast file host for us or whoever else, if we actually used all this bandwidth, would

01:28:56   you cut it off." And they're like, "Nope, you can use it, that's the point." It's a

01:29:05   pair of machines that are each 500 megabit, and they're each roughly as good as a 6-core

01:29:13   Mac Pro. They have dual SSDs with RAID 1, 64 gigs of RAM. I mean, these are insane machines!

01:29:21   6-core Xeon 1660v3s, which are actually faster than the current Mac Pro CPUs because the

01:29:26   Mac Pro seemed to have skipped generation, which they sometimes do, so I'm not surprised.

01:29:32   There is a newer version of the Xeon chips that the Mac Pro uses that is out right now

01:29:36   that Apple has not updated to and seems like they're probably just not going to at this

01:29:39   point.

01:29:40   Anyway, so I have these servers that I bought because one thing I want to do, and the reason

01:29:47   why I was so interested in having tons and tons of bandwidth available is I want to be

01:29:53   able to launch a Twitter card for overcast player pages so that people who are browsing

01:29:59   the Twitter app can play the podcast right there in Twitter cards. Twitter cards require

01:30:03   that all assets that are loaded within them, including media files, are served over HTTPS.

01:30:10   Some podcast hosts support HTTPS for their files, but most don't. So the first thing

01:30:17   wanted to write was an HTTPS proxy. And there are a few of these that exist. There's one,

01:30:23   I forget what it's called now, there's one that GitHub wrote in Node. Oh man, I'm sorry

01:30:29   I forgot the name. Anyway, so there's that one, that's fine. I looked at it briefly.

01:30:34   It's mostly made for images, but fine, it would work the same way. I decided to try

01:30:40   to write that in Go, a basic SSL proxy. And it's so, it's nothing, it's like a hundred

01:30:45   I mean, it's almost nothing, it's great.

01:30:48   And I also have a few other things I wanted to try.

01:30:52   I mentioned last week that I was using Imageix for my thumbnailing, but it was costing me

01:30:56   a fortune, so I'm moving my artwork thumbnailer to these boxes as well.

01:31:03   So I wrote just one Go program that contains those two functions, the SSL proxy and the

01:31:09   artwork thumbnailer.

01:31:11   Just those two functions implemented in Go, it listens over HTTPS and is its own server.

01:31:15   There's no server in front of it,

01:31:16   there's no Nginx or Apache or anything reverse-proxying to it

01:31:19   it's just its own server, raw, right to the internet

01:31:22   and that's all these boxes do is run this program.

01:31:24   So I'm hopefully going to be deploying that

01:31:26   in the next day or so.

01:31:28   - Cool, and it didn't take you that long to write

01:31:31   it sounds like?

01:31:32   - Nah, a few days, I mean I've been sick

01:31:33   so my work hours, I can only really work a few hours

01:31:36   at a time before I gotta go lay down,

01:31:38   which really sucks, but I'm extremely annoyed about that.

01:31:44   That is by far the worst part about being sick is not how I feel, it's that I can't

01:31:49   work.

01:31:50   That's what drives me nuts the most.

01:31:51   Anyway, so that's on its way out at least.

01:31:56   If I was working full-time at full capacity, it probably would have taken only two days.

01:32:00   It has actually taken something like four days, but oh well.

01:32:03   So how does your Go server handle the, I still don't quite understand the concurrency model

01:32:08   But how does it handle like you know if there are more incoming connections than then like it does it does it do multiple?

01:32:14   Processes or a single process event driven. What does it look like on the machine it can do multiple cores?

01:32:20   But it is it is all seen it's for the most part at single process event driven

01:32:24   It's they use this concept and forgive me anyone who's an expert listening

01:32:28   I'm not an expert yet on this so this is a a newbie overview of what of the way it works, but

01:32:34   They use us they use this thing called go routines which are which are these you know kind of threads

01:32:39   cooperating sequential processes or something like that yeah something like that

01:32:43   So it's those things and so there it's basically a very lightweight thread that exists within the app space

01:32:49   It is not an os level thread

01:32:51   So so how does it behave like at the limits like if you overwhelm it with connections to the other connections?

01:32:56   Just wait does they do you exhaust like the number of like?

01:33:00   You know I always look at what the behavior at the limits like that's the only reason I would ever put another

01:33:04   server in front of us like, "Well, I know how whatever will behave.

01:33:07   I can set these limits on number of connections.

01:33:09   I know people will wait.

01:33:10   I know what will happen.

01:33:11   I know when people will start getting timeouts or connections."

01:33:14   Whatever the failure mode is, I can choose my failure mode, and I don't know what the

01:33:17   failure modes at all are for Go because I've never used it.

01:33:21   So I was trying to do some research on that earlier today to try to figure out, like,

01:33:24   do I need to put Nginx in front of it or something, or can I just go without it?

01:33:29   The responses to that question were, for the most part, a few people who did it, who just

01:33:33   did it rath the internet who said it's fine. A few people who said you should put Nginx

01:33:40   in front of it because of separation of roles, which I think is total BS, honestly. The way

01:33:48   those arguments were presented, none of them convinced me that they were valid arguments.

01:33:54   There's nothing saying that having Nginx reverse-proxy-ing to this Go server is any more of a purity

01:34:01   of roles than having the Go server serving itself.

01:34:05   It has this functionality built into the language.

01:34:08   The only reasons I could think of are the older reasons that we used to run proxy servers

01:34:11   in that if you don't want to slow down the process, if a bunch of your clients have slow

01:34:18   connections you don't want to tie up your backend process doling out bits to the slow

01:34:24   connections but with an event-driven thing that's not really valid anymore because you're

01:34:27   not tying it up, when it's dulling up it slowly it's doing other things because it's multi-threaded

01:34:33   and moving on to the next thing.

01:34:35   Right, and the way, it seems like you would, the difference between Nginx being tied up

01:34:42   with all these connections and Go being tied up with all these connections because they

01:34:45   both have that same event-driven style model, I don't think one would be substantially better

01:34:49   than the other at that.

01:34:51   Yeah, and the failure mode is the other option, but the real question for me is, does Google

01:34:55   Google put anything in front of its servers when it runs them, and if Google doesn't do

01:34:58   it, which I suspect they don't because it seems like Go is designed to do this, then

01:35:01   it's like, "Well, if Google's not doing it, you don't need to do it either."

01:35:05   If it's designed to handle the traffic that Google expects, surely you can do your podcast

01:35:11   image thing by having the Go app talk directly to the web.

01:35:13   But I know nothing about this, so I'll be interested to see what the results are of

01:35:17   your experimentation.

01:35:18   That's probably a bad example, just because Google is such an incredible scale, they probably

01:35:22   lots of stuff in between the public internet and their application servers, so that's probably

01:35:28   a bad example, but I would be interested to see medium-sized sites, to see what they do.

01:35:35   Right, well, no, but I'm saying, like, Google, do they intentionally put a layer there whose

01:35:38   only purpose is to be, you know what I mean? Like, I would suspect that the machines that

01:35:42   their things are running on, the Go process is listening on the ports, and yes, there's

01:35:46   stuff in between, but it's like, do they shove Nginx in there as essentially a proxy server

01:35:51   for some reason.

01:35:52   It makes much more sense to do that

01:35:54   if you have a multi-process backend,

01:35:56   because then you would be tying up an entire child process

01:35:58   when really you should just shove the,

01:36:00   put a big buffer on the proxy,

01:36:01   have the child process shift the bytes out to the proxy,

01:36:03   and then that child process is free to serve another request

01:36:06   while the proxies have redolled out those bits

01:36:07   to the slow client.

01:36:08   That's like 1990s error, state-of-the-art web technology,

01:36:12   but we've moved on from that.

01:36:13   - Right, and there was, I saw there was one benchmark

01:36:16   that somebody posted where they,

01:36:17   and they showed all the code they used,

01:36:19   and there were a few complainers in the comments,

01:36:21   but it seemed pretty valid, where they benchmarked

01:36:25   a simple Go program, like a Hello World kind of thing.

01:36:27   They're like, simple Go program, raw versus Nginx

01:36:31   with a few different configurations and tweaks,

01:36:34   and the Go program just had, it destroyed Nginx

01:36:38   in request rate per second with either A/B

01:36:43   or one of the other similar tools.

01:36:45   It was way faster with just pure Go,

01:36:47   'cause of course it's doing less.

01:36:48   - And you're synchronizing two event-driven things.

01:36:51   Like one thing is handling,

01:36:52   and they're not gonna be in sync of like when,

01:36:54   when I'm doing the work on behalf of this request,

01:36:56   and then handing back, like it's just, you're just, yeah.

01:36:58   It's not just adding overhead,

01:37:00   it's like two desynchronized event-driven things

01:37:02   trying to talk to each other.

01:37:04   - Exactly, so that's what, I'm gonna, I mean,

01:37:06   so what, the way these servers are set up,

01:37:09   they actually have none of my app on them,

01:37:12   they don't have any access to my main infrastructure,

01:37:14   they don't even read the database,

01:37:16   they don't have anything on them,

01:37:18   accept this Go program. They don't even have PHP installed. They don't even have private net access

01:37:25   back to the Linode servers that are running the rest of the app. They have no connection

01:37:28   whatsoever to the app. My app is able to write its files into it, and it only has the Go files.

01:37:35   The risk if these things get compromised is pretty small. If they go down, these are kind of

01:37:41   accessory features. I'm going to have a CDN in front of the artwork thumbnail or anyway.

01:37:47   I'm not doing a CDN in front of the podcast bandwidth thing, or the podcast SSL thing,

01:37:52   for two reasons. Number one, the bandwidth cost would be extraordinary, and I don't think I would

01:37:57   be able to afford it. Number two, the way this is working, you know, Overcast does not proxy the

01:38:03   files normally, and I only want to use this in areas where SSL is really required for usability

01:38:10   or for functionality. So that would be things like Twitter cards, the web player to avoid mixed

01:38:15   content warnings, things like that.

01:38:17   In reality, that's not most uses of Overcast.

01:38:20   That's not most plays, and it probably will never be.

01:38:23   But regardless, I still don't wanna steal hits

01:38:27   from people's files, and so the way I've set it up

01:38:31   that there is absolutely no caching

01:38:33   of that SSL proxy's assets.

01:38:35   Every request that is made through that proxy

01:38:38   has a corresponding request back to the origin server.

01:38:41   And I know they're probably not gonna count my IP

01:38:45   as unique. I am sending the X-forwarded for and X-real IP headers that, you know,

01:38:50   that's standard for proxies. I would imagine, like, to prevent fraudulent

01:38:54   download count increases, most stats services probably ignore those. For some

01:39:00   of the big hosts, like, I already talked to Libsyn and I know SoundCloud, I won't

01:39:05   I won't need to use it with them because I know how to do secure URLs for them

01:39:09   reliably, so that that should be fine. But either way, I still want, like, I still

01:39:14   the downloads to be counted in some way as much as possible for the Origin servers.

01:39:20   So anyway, there's no caching involved there, that's intentional.

01:39:24   But for the artwork, there is caching involved there, there's going to be a CDN in front

01:39:28   of it, so if these servers go down for any reason, it's not going to be a massive deal.

01:39:35   It's not going to be like the whole app stops working, or something big is like ugly and

01:39:39   broken.

01:39:40   It's going to be a really small deal.

01:39:41   And so I'm just going to try it.

01:39:43   I have just this one seven megabyte go binary

01:39:47   to put on the servers and that's it.

01:39:49   There's no dependencies.

01:39:50   There's no, this very much appeals to me.

01:39:52   There's no configuration really.

01:39:54   The only sensitive thing on there is gonna be

01:39:57   the private key to the SSL certificate that it uses.

01:39:59   That's it.

01:40:00   So I think it'll be interesting.

01:40:03   - That was much more in depth than I expected.

01:40:08   That's excellent.

01:40:09   What else is going on?

01:40:10   You wanna do titles?

01:40:11   - I think minutiae.

01:40:12   That has to be it.

01:40:15   - Yeah, but the AE, the combined AE,

01:40:17   I don't know what that's called,

01:40:18   that's gonna break a whole bunch of podcast clients,

01:40:22   isn't it?

01:40:22   - My shell script might break to embed the title.

01:40:25   (laughing)

01:40:26   I'll have to--

01:40:27   - That's a different issue.

01:40:27   - Yeah, well, it's not really.

01:40:29   I'll just do, I'll use iTunes to edit it or something else.

01:40:32   Can you believe how, like, a lot of podcast producers,

01:40:34   that's how they embed the ID3 tags,

01:40:36   is they import the MP3 into iTunes

01:40:40   and hit command I for the info panel

01:40:42   and type in the stuff and then export.

01:40:44   Like that's crazy to me that anybody does that.

01:40:46   - They should use mp3 rage and pretend it's 2002 again.

01:40:49   - Well I'm using lame on the command line

01:40:52   which is pretending like it's 2004.

01:40:54   - Similar error.

01:40:56   - Yeah, exactly.

01:40:57   - Why don't you use a hex editor?

01:40:58   - Wow.

01:40:59   - Yeah then you have to know UTF-8

01:41:01   for converting that character.

01:41:03   That's not gonna work.

01:41:03   - Easy enough.

01:41:04   - Yeah I think nouche is probably the best one here.

01:41:08   Is that little A-E symbol actually pronounced?

01:41:13   Like, che, T-A-T, little,

01:41:16   I don't even know how to pronounce the little.

01:41:17   - Well, it depends on what language you're talking about.

01:41:19   If you're talking about Latin or Greek,

01:41:20   which is probably where it's from,

01:41:22   the answer is nobody actually knows,

01:41:24   and everyone's just gonna think they know,

01:41:26   and they're making it up.

01:41:27   And so, I think we'll use the wonderful A-E ligature,

01:41:32   and we will just tolerate the emails that come in,

01:41:36   because we love everybody's emails so much.

01:41:38   including the people who tell you that's not a ligature.

01:41:41   I think it is a ligature, isn't it?

01:41:43   I don't know.

01:41:45   I'm just speculating about potential email we could get.

01:41:47   Yeah, as Holgate in the chat room

01:41:49   points out, the HTML entity named for it is ae-lig.

01:41:53   So I'm pretty sure it's a ligature.

01:41:55   Yeah, I don't know.

01:41:56   I don't know the technology.

01:41:57   You know, the font and typeface and everything?

01:42:00   There's lots of distinctions that I have apparently not

01:42:03   cared enough about to memorize.

01:42:06   I know they exist, but I don't know what's right.

01:42:08   [BLANK_AUDIO]