Minutiæ
There's brief moments of time when I listen to the two of you go back and forth.
And for a minute, I'm like, man, I'm not even here anymore.
And I feel ever so slightly sad.
But then I continue to listen to you two going back and forth.
And I just don't even care anymore because I'm entertained as hell.
We had recently received an email as recently as about two hours ago about how we say to each other or say actually to you, the listener, please email anyone other than us or please don't send us email, et cetera.
Would you like to talk a little more about this email?
all right so the the first sentence is i'm a little surprised about your whole email topic now this is already kind of like spreading the topic wider because this started with marco getting specific feedback and bug reports about overcast right but then this sort of expanded into like the entire topic of us getting email and so this feedback is not about marco and his bug reports really it's really about
When we say on the show, please don't email us about whatever, right?
So I already think this is kind of off topic and it's just like it's related to the discussion, but whatever.
He's not interested in really discussing how Marco handles his feedback.
He's more interested in discussing the joke that we do when we say, please don't send us email.
Um, and he says that it makes him feel like that we don't appreciate the listeners that, you know, let me find a good sentence here.
He says he loves us, loves the show.
It doesn't make me feel entitled to anything.
I know that obviously, and I know that it's impossible to get back to everybody, but what is it impossible is to appreciate your position, to appreciate the fact that people.
Devote their time to actually tell you what they think.
To appreciate that people are the ones that are attracting sponsors, etc.
To appreciate that a podcast by nitpickers is going to attract nitpickers.
To appreciate that so many people really care.
And I know you do appreciate your listeners, but the whole email joke, the whole annoyance is neither funny nor respectful.
It's strange, off-putting, very arrogant, and makes me kind of angry.
It makes my engagement feel pathetic and needy.
It's really not that hard just to say a few nice words, you know?
To this, I would say that we don't have a... Ignoring the fact that most of the time we're just joking, right?
Because jokes can be hurtful too, right?
we don't have a blanket ban on on email we don't say it's like a prohibition please in fact we encourage tacitly encourage email by responding to email on the show and a lot of the follow-up is about things that people send us either corrections for things or expansions on topics we take real-time feedback and real-time follow-up from the chat room from people saying the same thing right so it's clear that we're not like
Nobody ever emails anything, you know, for whatever reason.
We don't say that.
I mean, there's a feedback form on our site that I made when we made the site.
Like, we have this form on the site that says send feedback.
If we wanted to not actually receive any feedback, we would just take the form down.
Like Marco and his app doesn't want to imply that he's providing support.
He just provides the feedback.
So first of all, I would say the premise of the idea that we just are saying we don't want any feedback.
Like, that's not our message at all.
We do very frequently, though, say...
Please don't email us about whatever topic.
And that is specifically focused on whatever it was we were talking about.
So if it's like, you know, I'm going to tell you about this toaster oven I got.
Please don't send me email about slot toasters.
And then I follow up by saying, I know about slot toasters.
I know slot toasters exist.
I know that they are different than toaster ovens.
I am reviewing toaster ovens, right?
And they're worse.
And part of that is like,
The please don't email thing is a long-running gag from any podcast that we've listened to and been on in the past.
So if you don't have that context, maybe that doesn't make much sense.
It's also kind of a joke like, oh, I don't want to hear from those people who are just going to tell me about the slot toasters, right?
But it's very specifically focused on this one thing.
It is not saying please don't email me ever about anything.
If...
If you know something cool about a new DisplayPort specification, yes, send us the email about it.
If you say, I've been an Apple genius for X number of years and this is my experience, yes, send us email about it.
Of course we want that email.
We read it on the show.
We appreciate it.
We appreciate our listeners.
I don't want people listening to think, and I don't think most people do, but this person does apparently, that we don't want feedback from anybody.
It's 50% of the time a joke and the other 50% of the time very focused kind of exasperation at a particular type of feedback that we expect to get because we said something that we know leaves us open to a particular kind of correction.
And we're trying to say, you don't need to send us that correction because we are fully aware that we have either intentionally ignored this thing or whatever.
Right.
It's a way... I use it as a way to preempt getting a whole bunch of emails that begin with, well, you know, and some big argument about something that I know the thing I just said is contentious, or I know there is something that other people are going to want to tell me about what I just said.
And I'm just... I don't want to engage that entire discussion right now.
I don't...
It's a way for me to basically try to try to preempt getting a whole bunch of duplicate emails telling me something I already know.
And that saves everybody time.
And that's not to say it's not annoying.
If you're annoyed by it, it's totally your right to be annoyed by it.
It can be annoying.
I fully admit that.
But we are human and we get exasperated sometimes to express that on the show.
Yeah.
So this email was from a Pell D. I feel like we should attribute, uh, I'm, I'm assuming him.
Um, and what I, I had replied to him or her, I'm thinking him, uh, and saying, and what I said was, um, we don't, or we say, don't email us either because we really don't care about the minutiae, minutiae, minutiae, the, all the nuance of the topic at hand.
You're going to get on me about bezel, but you're going to go minutiae.
Okay.
Okay.
Minutiae, Tacey.
Touche.
I was pretty sure it was minutiae and that I was envisioning all the emails of it saying to me, no, it's not minutiae, it's minutiae.
So should people not email you about the correct pronunciation of minutiae?
So please do not email me.
See?
That's a perfect use.
It's a perfect use of it.
Anyway, let me try this again.
So we say please don't email us either because we really don't care about the minutia of the topic at hand or because we know we won't be able to respond to everyone.
And actually, that reminded me as we were talking of another piece of follow-up, which is I saw a handful of people, generally speaking from Europe, who seemed confused about the whole toaster oven thing.
Yeah, someone asked me, isn't that just a grill?
And then I realized we had a language barrier between English speakers.
I think it was someone from the UK or some other thing that Marco can tell us the correct name of.
Can we maybe just put a U somewhere in it?
Would that make them know what we're talking about?
A toaster oven?
Yeah, no, it was great.
It was great because someone said, isn't that just a grill?
And I replied, no.
because i didn't look up like where they were from or something but i was confused by it and then another person who obviously knows speaks the variant of english that that person was speaking tweeted back to them said i think that what you mean by grill isn't what they mean by like seriously it's like an actual language barrier we don't know the words for things but we put links in the show notes right like you can click on them and see what it is it's a thing toaster ovens are a thing in america anyway
And so if you live in one of these barbaric countries that doesn't really have a toaster, doesn't have toaster ovens, basically it's like a little tiny oven that can serve either as a toaster or an oven, hence toaster oven.
And they're extremely convenient if you'd like to reheat something, especially something bready.
Pizza being the most obvious example, french fries, anything like that.
If you want to reheat something bready, but you don't want to do so in the microwave because then it'll end up all gummy.
A toaster oven is a great way to do it.
Now, yes, you could use a traditional oven, but why in the world would you start up what is probably multiple square feet worth of space to heat one slice of pizza or two slices of pizza?
And so a toaster oven is the best of both worlds because it's a little tiny oven, big enough for usually a slice of pizza or two, or it's a toaster, big enough for maybe a couple of bagels or something like that.
Right.
And it tends it tends to heat up just about as quickly as doing it in the microwave for me.
Like if you're going to I mean, it's it's, you know, not 30 seconds, but if you're going to reheat a slice of pizza, a toaster oven has it done in like two or three minutes at most.
And so that's it's way faster than using a full size oven.
Nobody should ever put a pizza in a microwave.
I just want to say.
Oh, I completely agree.
Yeah.
But anyway, so if you don't know what a toaster oven is, well, perhaps it's time to move to a different country.
But nevertheless, maybe you could import it or something like that.
Nationalized healthcare or toaster ovens?
I'm going toaster ovens.
I think I might too.
The brand of my toaster oven, Breville, apparently that's a proprietary eponym.
See, I did remember that from the past episode.
It's pronounced Brazil.
That is a proprietary eponym in the UK, like Kleenex or whatever.
And so someone in the chat room says a Breville.
refers to something we would call a grill in the UK for sandwiches.
So they've taken that entire brand and turned it into, you know, the signifier for the entire category of things like a panini grill type of thing or whatever.
But anyway, that's definitely not what I'm talking about.
Again, follow the links in the show notes.
We'll show you exactly what we were talking about last week's show notes, not this week's show notes.
Yeah, we're not going to put in this week's show notes because it was already there.
You should have clicked the links, kids.
Our first sponsor, before we've done a single topic, is Igloo.
Igloo is an intranet you'll actually like.
It's kind of funny that this is the first tech that we're discussing is the sponsor read itself.
with igloo you can share news organize your files coordinate calendars and manage projects all in one place this is like taking the best of the web and productivity apps things like calendars twitter like microblogs file sharing task management wikis and more all available privately and securely for your company or group intranet igloo intranets are highly functional stylish and easy to use with a widget-based drag and drop interface their latest upgrade viking revolves around documents and how you interact with them gather feedback and make changes
They've even added the ability to track who has read critical information to keep everyone on the same page.
It's kind of like read receipts in your email, but less annoying.
And it helps you track whether employees have read and acknowledged policies, signed off on legal agreements or confirmed completion of training materials.
All very useful stuff if you're running a company.
Igloo is all built on their advanced HTML5 platform.
It's a fully responsive platform and offers all these features.
Even things like previewing and annotating documents.
You have to render an Office document and have annotations on it.
All that is done in HTML5.
So it works no matter what device you're on.
You have all that functionality, all the annotations, all the admin controls, everything.
Whether you're on a computer, iPhone, Android phone, or even a BlackBerry.
And when new devices and screen sizes hit the market, Igloo already works on them.
So if your company has a legacy intranet that looks like it was built in the 90s, you should definitely give Igloo a try.
Igloo is even completely free to use for as long as you want if you have a group of 10 or fewer people.
And then if you get past 10 people, it's very reasonably priced after that.
So really, if you have a group of 10 or fewer people, Igloo's free for you.
Just go try it.
It's amazing.
Anyway, sign up for a free trial at igloosoftware.com slash ATP.
That is igloosoftware.com slash ATP.
Thanks a lot to Igloo for sponsoring our show once again.
They've been a longtime sponsor and friend of our show.
Yeah, very much.
Thank you, Igloo.
We should talk about the Photos app that we all thought may have kind of gone away.
Hang on.
Real-time follow-up on the Breville.
It's not a Panini press.
Look at the thing I just put in the show notes.
It's the thing that, like...
it's like a a clamshell thing that closes and it has two little compartments for uh bread like if you cut a piece of bread on a diagonal and it kind of like heats them from both sides different than a panini press which is you know the flat surfaces with the little ridges on them this is a common thing like that's what they prefer to i've seen them in the u.s i just i don't think many people have them but that's what they call it that's what they call a breville and if you read the history of the thing
That's really peculiar.
I mean, well, I've seen them before, but looking at the chat room, 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 that has one.
So it's labeled there as a durable stainless steel Jaffle maker.
So are those Jaffles?
Is that like, that's what we call this thing?
Yeah, I don't want to try to pronounce that word.
Maybe it's Jaffle.
Jaffle, like waffle?
Oh, goodness.
So quick aside, I was at work.
This was a year ago now.
And somebody was – one of my coworkers was talking about doing something in JavaScript.
And at one point, he said something about JSON.
And I was like, what?
Oh, my God.
That's what the French called it.
And it took me a minute.
I think he was saying it, you know, comically or ironically or whatever.
But what I heard, Jason, I was like, wait, what?
And sure enough, he meant Jason.
I just did it again accidentally.
My boss used to say H over.
What?
H over.
That's when you put your H over an item.
And the H over style and the links.
Well, he was just avoiding trying to pronounce that word because he knew it was such a problem.
Yeah.
That's true, because you never know when that'll go wrong.
But for the record, it's hover.
We'll talk about them in 20 minutes.
All right.
Sorry for the derail.
Photos.
Back to photos.
Yeah.
So let's talk about photos.
We had all, not genuinely, but kind of wondered, hey, what happened to photos?
Because somebody had pointed out to us that it disappeared from Apple's website.
Well, apparently it's back.
It's back in a big way because it's actually in the latest Yosemite beta.
Now, have either of you guys tried this?
But are you crazy?
I was actually going to try it, like not on my computer with my actual photos, but just just to load the program and throw some sample photos at it or whatever.
But then I realized that I'm pretty sure this is still the case that you have to upgrade to the 10.10.3 beta.
And I wasn't willing to do that just just to try the photos app.
So I'll just wait.
Yeah, that's the reason I'm not using it.
It's because I'm not going to run a beta OS on my main computer.
So that's not going to happen.
I've already put in a lot of time doing stuff like that.
I deserve a break.
I also feel like this is a good opportunity that I really should take to go back and clean out some of my photo library.
Because there's so many times, I'm sure this happens to a lot of people.
I'll go on a trip or something, or we'll do a shoot with the kid or the dog or both or whatever.
And I'll just dump all the photos into the photo library and then just never really pick through them.
So I have these giant like 30 gig folders full of some shoot or something like that.
And it's like if I just took an hour to go through this, I would probably delete 95 percent of those pictures and just keep like the 5 percent of the best ones that I actually want to see again.
Uh, and basically I need to apply that process to like five years of photos.
I, it's like spring cleaning.
Like I keep meaning to do this and maybe this is like, maybe this is my motivation to do it finally.
Do you guys have that problem?
I used to use iPhoto.
This was, I don't know, three, four years ago now.
And I felt it was nothing but a burden.
And there's probably a million and seven ways that you can blame that on me, and probably a million and six of them are correct.
But for whatever reason, I just didn't have a workflow that really worked well for me.
And what I've ended up doing since then is just eschewing – that's how you pronounce that word, right?
Eschewing iPhoto altogether.
This is the Accidental Pronunciation Podcast.
And and now what I'm doing is and I think it was Bradley Chambers learning to love photo management in combination with some some scripts from Dr. Drang.
And so basically what I do is I have all of my pictures renamed consistently and stored consistently in my file system.
And that's as close as I get to any sort of organization.
And I wish I had a better organization system insofar as something where maybe I've tagged pictures that I think are really good or I've grouped them into events or what have you.
The sorts of things that I suspect Photos app will be great for.
But for whatever reason, it just felt like such a pain in the butt with iPhoto that I never really did it.
I think I've described my system before.
I put them all in iPhoto and then I star rate them.
And the only cleaning I really do, I tend to be like not want to get rid of pictures of my kids, even if like they're not framed correctly or even if they're a little out of focus, because sometimes they're still cute.
But what I do is I do rate them all.
and when i feel like doing a little cleaning i just show all the one stars and the one stars are basically like you should really delete these because the lighting is really bad or it's blurry or whatever like and i will delete as i'm i'll look at every picture when i load them into i photo i'll delete the ones obviously they're like excellent took a picture of my foot or like something you know they're totally bad but all one star ones and then when i want to clean it's really easy for me to just show a smart album that shows one stars and then just go through and just delete whole swaths of them
Yeah, but see, then you can't see the ones around them that were better, so you could really know, like, all right, which of these do I need to keep?
One star means, I mean, I can look at the pictures.
It's like, these are so blurry.
I'm not one-starring.
If it's in focus and people are in the front, those never get one star.
One star basically means you should really delete this.
One star is the thing that most people would delete immediately.
I just let them stew, and then if I feel like cleaning house, I'd delete all that.
I think I deleted every one star from my collection a couple years ago, and it was a lot of photos, but now I just kind of let them build up.
maybe you're just letting them develop like a polaroid like figuring maybe it'll get better if i just leave it here for a little few more hours yeah and also like a picture that is actually out of focus sometimes we do like family calendars where you and you know make the calendar for the year with pictures and everything and they have these little collages where you can put the pictures and sometimes there's little spots on the calendar for small photos and even a picture that's blurry like it's not in focus when you shrink it down to be like one of the small thumbnails kind of at an angle in the corner of a calendar thing it doesn't actually even look that bad so
occasionally that's why i'm kind of keeping the one stars around or if it's like trying me trying to see a picture of like what some where what do i have on this shelf in this year or where was that thing or whatever like you know i wish i wish the system was more intelligent about finding things for example i do keyword them but my keywords are limited to like i have a keyword for each of my children and then one keyword for me and my wife because i'm not going to do us individually you know what i mean
And that's about it.
And you think, why do you need to do that?
Doesn't the faces feature find all the people that you want for you?
Well, I started doing this before the faces feature existed, long before, first of all.
But second of all, no, it's not reliable enough.
Like me manually keywording them is much more reliable than faces.
I wish I could turn faces off because it's always grinding away.
making the fan spin up on the macbook air to try to detect people's faces but that's the same thing i do with itunes starring them and basically using the star as a threshold system easily lets me sort of get what people are trying to get by cleaning things out which is just like just show me three stars are better those are the good pictures there's very few of them suddenly my collection becomes small and manageable and if i want to share photos on you know photo stream or you know send them to relatives i just show the three stars it's super manageable and
People want their collections to actually be like that.
I can't bring myself to throw out the two-star ones, but the one-star ones, they do delete.
Now, going back to the photo app for a second, I think... So, one thing that we were skeptical of or hesitant or whatever the right word here is... We are disasters.
Yeah, right.
I'm still sick.
I have a good reason.
Is that we were wondering, like, you know, one of the issues with...
cloud service backed things, and iCloud stuff in particular, is that there's pretty much no visibility into the storage and no recourse if it does something crazy, like delete half your contacts.
It's pretty hard to recover from that in a lot of cases for a lot of these services.
And if you have this on your Mac and it has all these files sitting there locally, you can back up these files and then hopefully have some way to re-import them if you had to like nuke your whole iCloud account and start clean or restore a bunch of stuff that was deleted.
And it seems from earlier reports that the storage layout of it, you can import things off disk and it can just leave them where they are and not copy them in.
But by default, it seems to maintain a very iPhoto-like library structure so that these files are just sitting there as files on your disk.
All of your photos are there by default.
It will only be smart and try to delete some of the originals or, you know, cache things online only if you enable the special, like, low space mode.
So you can just have, like, one computer that has the whole library on it and has all those originals sitting there as files, and you can always re-import them later.
So it does seem like it is durable enough in that way to be used as your main photo app, at least once they work out any glaring bugs.
Yeah.
it's actually even better than that like we should explain what the experience of this is so iPhoto was an app and Aperture was an app that Apple had both discontinued both being replaced by this app both mediocre yeah functionality wise photos does not include all the functionality of Aperture it includes most of the functionality of iPhoto but so this this application is coming into people's lives with the expectation that you've already got all your photos in one of these other applications or in a folder of crap somewhere
And it handles all those situations.
So like if you have an iPhoto library, when you start it up, it will import that iPhoto library and it won't actually make duplicates of the files.
It'll just make hard links to them.
We'll put a link in the show notes explaining the hard links.
However, basically, it doesn't take up any more room on your disk, but it makes a separate parallel structure of its own.
At that point, your libraries are divorced from each other.
And if you make changes to either one of them, the changes are no longer visible.
So it's a one time kind of import process that doesn't actually take up much more disk space.
But at that point, they're diverged like they're not kept in sync with each other.
If you have a file full of pictures that just like you've organized yourself, you can just start photos up, make a new empty library and import those pictures.
I believe it will copy them.
And no, it won't copy them in that case.
You can tell it to leave the pictures where they are.
There's a preference, kind of like the iTunes preference of copy media into the library.
You can tell it, don't move my stuff.
I have it arranged in folders.
Just reference them from where they are.
And it will do that.
It will leave them in your nice organized folder structure.
It will put a little thing in the app that shows you like, oh, by the way, this picture isn't in a library.
It's referenced from another location.
and if you want to work that way which i would totally recommend not doing because it's crazy and you're a crazy person the application will do that for you you can put you can organize your photos into little folders by date and name them whatever the heck you want and then just reference them from the photos app and continue that crazy workflow where you act as a little person putting things into folders and then reference them from the application and just like iPhoto you can hold on the option key on launch and switch among different libraries the only
limitation you have is and this is all just like totally local forget about network connection this just works totally locally no cloud stuff involved at all right if you want to do some cloud stuff then you can designate one library as like the what the system library whatever like the iPhoto the iCloud library one library on your system can be
cloud backed up and then you have the choice of do i want to keep all the originals on my mac and then also put them in the cloud or do i want to use like whatever it calls like smart or advanced storage or whatever some other preference that says i don't care if they're all on my mac you can actually take some of them off my mac as long as they're in the cloud and that's the second option so this is an extremely flexible application that does things in pretty much the smartest way possible given the current file system technology we have that leaves every person
able to do whatever it is that they want with their photos.
The only bad thing about it transition-wise is if this app is completely buggy and erases stuff and destroys your photos and they get lost in the cloud and everything,
any changes you made after that initial kind of one-time import process will be lost because once you do that import, you are now leaving iPhoto behind.
I suppose you could import your photos into both of them in parallel, but then you will actually be duplicating because the one-time import with the hard linking stuff, it doesn't take up much more space.
That's not an ongoing thing.
So there is a transition point.
And so I suspect if I try out this program, I will try it out and then
I don't know, maybe just like bail out after importing a couple of pictures into it and then re-import those same things into my iPhoto library.
Like I still don't have a good transition pan, but spec wise, the photos application seems like it does all the right things to make everybody except for Aperture users who are screwed.
It will import your Aperture library to everybody, everybody happy except for the people who use Aperture and will miss all the features that Aperture have.
This doesn't have in terms of advanced photo editing.
Well, the editing controls are actually not that far off.
This is one of the reasons I'm very excited about this app, that the actual editing process and the controls you have for editing are very advanced and really are pro-level editing tools compared to Aperture and Lightroom.
Lightroom is probably slightly more advanced in certain areas.
Aperture, I'm not sure.
I haven't used it in a couple of years, but it's probably very closely matched to those editing tools.
Where it falls short is in the organizational tools of things like Aperture and Lightroom.
And especially if you're coming from Aperture, I think it's going to be... If you were really heavily using those organizational systems of vaults and all these things, most of that is not going to transfer over gracefully.
So that's really where Aperture users are going to be very rightfully upset.
But besides that, it looks... Again, I haven't used it yet, but it sure looks like the editing and processing of the photos is just as good as Aperture was.
But they don't have the interface of doing the pics.
A lot of Aperture was about professional photographers taking lots of photos and then...
designating the ones they think are good in sort of an efficient manner like it's not there's no workflow like that as far as i can tell built into photos whereas aperture so much of aperture was focused on on you know the editing tools which is one thing and then this whole you know like you said the vaults and the management and then the picking process i forget what they call it is that the word they use i think so i might be i don't know again it's been a couple years since aperture but
But yeah, Aperture and Lightroom are both going to be way better for what pros actually do.
My wife, Tiff, is not going to use this Photoshop.
I can already tell you that.
She's not going to use it.
Even Aperture and Lightroom are too heavy-handed for her.
She just uses Bridge and a bunch of directories because when she does client shoots, she doesn't want to bring it into some giant library program and have it organize things for her.
She does it all in the file system with Bridge and does all the picking that way and it works great for her.
most pros are going to have a system like that where they're going to use one of these pro apps to do all that organizational and stuff and managing the shoots and managing the picking and all that stuff.
They're not going to use this app, but that's fine.
This isn't made for them.
This is made for the people like me who, and of course, everybody else, but like,
people like me who were using Aperture and or Lightroom for its advanced editing controls primarily.
And then secondarily, we would occasionally touch some of these library functions, but we were mainly there for the editing controls.
That's definitely the case for me.
I know it's the case for a lot of people who bought SLRs in the last eight years and got into photography as a nice hobby.
Just having these nice editing controls...
built into the main photos library mechanism on iOS devices and Macs is going to be awesome.
Because for all these years, we've had to decide between something that's fully integrated into Apple's ecosystem and syncs everywhere and is all in all the photo pickers and all that stuff, or has great editing controls and pro stuff.
And there were always these things you'd have to give up one way or the other.
And this looks like it's perfect for people like me.
Any prosumer who's really into SLR photography but is not doing pro photo shoots actually for clients every day or on the weekends or whatever.
This is for us and I'm very much looking forward to that.
I think the editing controls, like the adding intelligence to the editing controls is really important because they...
The default for most photo apps, including Apple's, with the exception of the little magic wand enhance button, like they gave you one button.
It's like you don't understand all these crazy controls.
Press the magic wand and maybe it will make your photo look better or maybe it won't.
And if you press that button and didn't like it, you're like, whatever.
But then you're faced with, OK, well, so the magic wand didn't work.
Here's 8000 sliders.
Good luck.
Right.
And if you don't know.
how to use those sliders.
It's daunting to figure out how to, you know, with this million different combinations, and you're trying like, I don't know, do I move this and that or whatever?
Well, so photos has this sort of intelligent thing where they give you sliders that are sort of meta sliders that cause the other sliders to move in what it hopes are pleasing ways.
And you're like, Oh, well, that's bad.
I don't want it to be smart and move those other sliders around.
I want to move the actual sliders.
Well, the great thing is you can use these, these meta controls that influence the other sliders.
To try it, like most people can do that and say, oh, I would never have thought to put those other sliders in this position.
But when I slide this top slider, all these other things move around.
But you still have the ability to edit every single one of the detail sliders manually as well.
So if you want to use the sliders by hand, you can.
But most people have no idea how to get good results with that so they can use those other meta sliders.
So it's a big step up from either magic wand or you're on your own.
and all these edits are fully synced not not just like burning it into a jpeg and syncing that the actual edit states are synced so that you can go on your phone or your ipad and make adjustments and that syncs back well in theory i mean let's be serious here well i mean this is all based on cloud kit so far our cloud kit stuff has been solid why didn't my contacts sync marco contacts it's like a tiny set of data why
That's a good question.
I have no idea.
My faith is like, yeah, I'm ready to be impressed.
It seems like, you know, I've heard rumblings.
I'm sure everyone's heard these rumblings that like Eddie Q's team took over iCloud something something and was really like revolutionizing and fixing stuff like a year ago.
Like that's when all this stuff started, allegedly.
and it seems like CloudKit and the cloud photo library stuff and all the stuff that came out of that that's all based on CloudKit seems like that is most likely to be the result of that rumor and that we're seeing now.
They're doing good things with cloud stuff now.
Rather than the initial iCloud services stuff, which was...
The document stuff, which is a fairly simple problem set, but it was done kind of oddly, but mostly worked.
Key value store, which works all right.
And then Core Data Sync, which was a disaster.
Because they tried to tackle this incredibly complex problem that really can't be done well in the way they attempted to do it.
And of course, so it sucked.
CloudKit was like... We talked about this when they announced it back in the summer.
CloudKit is...
Apple kind of saying, okay, we're going to do a cloud service that actually is much easier to do well.
And so far, it seems like they did.
So I'm pretty confident in this service probably being good.
I mean, we'll see what happens in practice once it's launched full scale and everything.
And we've all been using it for a few months.
But I think all the pieces seem to be in place for this to actually be good and work pretty well most of the time or all the time.
Well, just the fact that they're dogfooding it so heavily, I think, is a pretty big change from, say, iCloud with core data or core data with iCloud or whatever the terminology was.
The impression I had was that nobody was dogfooding that.
But just like you said, Marco, it sounds like…
Apple's heavily dogfooding cloud kit.
And that's definitely a good thing for all of us because I think Apple is fairly tolerant of third-party developers having to jump through hoops and fairly intolerant of their own people having to jump through hoops.
Oh, yeah, that's fair.
And as far as I know, I don't think any Apple app ever used Core Data Sync.
I'm pretty sure we never found one.
I know some people were trying to, like, they were asking around on Twitter, like, you know, a year ago, whenever, like, does any Apple app actually use this?
I don't think we ever found one.
But anyway.
i'm confident and also you know i wouldn't necessarily like be all nostalgic for aperture because apple has been a terrible steward of aperture since the beginning like it it always had delays issues it was always pretty buggy it always had terrible performance there's a most of all just it would just go years without any major updates and everything was always just you know too little too late it was always getting better soon and never actually great that's why lightroom does so well because like a
Apple basically said, hey, we're going to... Apple, I think they basically invented the category of apps that work like this, basically.
I think.
I'm not sure about that.
Please email Casey.
And then Adobe came in with Lightroom and just ate their lunch because they just iterated so much faster and it was so much better.
You know, Apple really, you know, Aperture was always pretty badly neglected.
So, you know, rose colored glasses and everything.
I don't think we're going to see people looking back in six months saying, oh, I really miss Aperture.
Like, I don't think so.
And for the few who do say that, I think they're probably going to be misremembering how good it actually was.
I thought I saw somewhere, and it might have been in Jason Snell's review, but I thought I saw somebody had loaded just a crud load of images of pictures into the new Photos app, and they said you could scroll that thing at a solid 60 frames per second like it was nothing.
I will be excited to see that if that's true.
That's why I wanted to try it.
I'm like, I've got to see this because it is so terrible on iPhoto.
I have maybe 30, 40, maybe I have more than that, 40,000 photos, 50, and maybe it's up to 60.
Anyway, it doesn't seem like that big a number, but I want to see that scroll nicely.
We are also sponsored this week by Hover.
Hover is the best way.
Oh, it's also Hover or Hava.
All of those things.
Hover is the best way to buy managed domain names.
Go to Hover.com and you can get 10% off your first purchase by using promo code SLOTTOASTERPEOPLE.
Slot toaster people.
When you have a great idea, you want a great domain name that's catchy and memorable.
Hover gives you exactly what you need to find the perfect domain for your idea so you can get started actually working on it.
Like I've mentioned before, if I am working on a new project, I need to find a name first.
I can't really move forward without a name.
That just blocks me until I get a name and domain names are the very first thing I go to search.
and hover is great for that hover gives you easy to use powerful tools to biomanage domains so anybody can do it and the support team is always ready if you need a hand they're known for their no wait no hold no transfer phone service so you when you call a real life human being is ready to help they pick up the phone that's it they're ready to help you don't put on hold you're not transferred to anybody that's it they pick up and they help you it's amazing
Plus, they have great online tutorials and email support if you hate the phone like me.
You can find new domain names that you want to get up and running in less than five minutes.
All you got to do is type in a few keywords, and Hover will show you the best available options across all TLDs out there.
Now, if you've ever used any other domain host before, you know that it can be a pretty unpleasant experience at a lot of these different companies.
They make it very complicated to buy just what you need, or they try to upsell you with crazy stuff, or they make you pay extra to upgrade for things that really should be included.
Hover does not believe in this kind of approach.
Instead of charging you for something that should just be there, Hover includes everything you need with your domain.
You get a smart control panel, you get Whois privacy, always for free on any domain that supports it.
They even offer this really cool service called Valley Transfer Service.
And what they do is, if you will let them, they will log into your old registrar and do any transfers for you.
They'll transfer over all your DNS and everything, so it's all correct.
It's very easy to get that stuff wrong, and then your site's down for a few hours.
It sucks.
They will log in and do it for you if you want, because some registrars make it pretty difficult to leave, and of course they don't.
They also have this great email service.
Hover has great solutions for your own custom email address for your domain.
20 bucks a year gets you a fully functional email account at your domain with 10 gigs of storage.
You guys remember when Gmail came out, it was one gig.
This was like in 2004.
Yep.
And that was revolutionary to have a gigabyte.
No one could ever use that much.
Well, we do.
And Hover now offers 10 gigs a year for just 20 bucks.
Now, if you need more than that, for just $29 a year, you can get the big mailbox.
It's actually what it's called.
It's called big mailbox.
That gets you a terabyte of storage, plus some other nice bonuses.
So $29 a year gets you a mailbox that can hold a terabyte of email, which I think sounds like my personal hell.
They even have email forwarding for just $5 a year.
So you can keep using, if you already have an email account somewhere else, like Fastmail, whatever, you can keep using that for just $5 a year that will forward your email for your domain to anywhere you want.
Anyway, all this is great.
You can get 10% off your first purchase from Hover by going to Hover.com and use promo code SLOTTOASTERPEOPLE.
All one word, SLOTTOASTERPEOPLE.
Thanks a lot to Hover for sponsoring our show once again.
Okay, so there was a little bit of a surprise within the Photos app, and some people went spelunking.
I'm assuming it was Steve Troutensmith.
Is that right?
Steven Troutensmith?
I'm sorry, but that guy.
And we've, they, he, they, someone has discovered UX kit.
So UX kit appears to be sort of kind of UI kit for the Mac.
Marco, do you want to talk about this a little bit?
Yeah, so it's a private framework that is used only by the Photos app at the moment that Apple shipped with the Photos app beta.
And it appears, you know, you can't, no one's like disassembling it, I don't think, but you can class dump it and you can kind of see just like what classes and methods are contained within it from the Objective-C runtime.
It's not just photos, by the way.
People say that Xcode 6.3 beta also uses UXKit.
that's interesting if that's true i did not know that yeah there's a tweet from don mowry saying that i suppose it's easy enough to confirm but i put the tweet in there that is interesting well anyway so uh and what it appears to be is a subset of ui kit ported to the mac and so there are things and just like you know with the ui prefix replaced with ux and so there's things like you know you i think there's like a ux navigation controller and stuff like that and you know there's ux color ux you know all this like
because normally between UIKit on the iPhone and AppKit on the Mac, there are a lot of big differences, but a lot of also just like little superficial differences.
Like the prefix for UIKit is just UI.
The prefix for AppKit is NS.
And so you have some classes like UI color versus NS color.
and UIImage versus NSImage.
And many of these classes that have these superficial name differences aren't that different.
Or the Mac version supports some ancient stuff that no one really uses anymore, so you might as well just unify them.
So there's a lot of overlap that seems trivial, and many people have written C macros or utility classes to...
to have a unified code base that shares some of this code between iOS and Mac more easily.
So this appears to be Apple's version of this on this one app in this one team, where this is their translation layer to have the same code, probably, to have the same code running on iOS and Mac.
So the question is...
Is it just this one team?
Is it just this one app?
Or is this going to be a more widespread thing?
Is it going to become public?
And is this going to be the new unified UI framework so that you can share a lot more code between iOS and Mac?
That's all.
Basically, nobody knows anything about that yet.
Everyone's just speculating.
But that's why this is interesting.
What do you guys think?
guy english had a good point and it's the analogy that came to mind when i thought it was well uh so setting aside that xcode 6.3 also needs to uh appears to use it according to this tweet uh guy pointed out uh prokit.framework remember that yeah yeah all the the pro apps logic and everything aperture logic what are the other apps that used it it was uh maybe maybe shake
when that was out and not final cut mouth maybe final cut anyway a whole bunch of apple's apps that look different like the window chrome was different it was darker and sometimes it was smaller and they had they had their own little weird set of controls and everything they use pro kit framework which was you know a framework shared among apple applications
uh that gave a different ui and i mean i assume it wasn't just look and feel i assume it had other features as well but the point is that it was a framework that was not for public consumption uh that apple used on multiple applications that never became the future of app kit right so the idea that ux kit could just be a thing that apple uses internally to make its applications this is a completely viable idea
It's not crazy to think, oh, well, now once the UX kit, like, because Apple also does the opposite.
They take frameworks, they use them privately for a release or two, and then make them public, right?
So now we can't tell whether this is going to be one of those things that's used privately and becomes public, or is it just another pro kit that Apple will use internally to make its life easier when it makes its applications, but it is not the future of making UIs on the Mac.
Yeah.
And there is a great argument to be made there that many people have made that that should be separate because just porting an iOS app directly to Mac and using a lot of the iOS interface paradigms like navigation controllers and things like that, it doesn't really work well on the Mac.
That's kind of a waste of what the Mac is good at and it just kind of feels like you're clicking an iPad app basically.
But what about things like collection views, like the fancy iOS collection views that sort of reflow themselves and, you know, or even just something like a better table view.
I mean, I know they've improved table view, getting rid of NSL and everything like those type of things kind of span the range.
I mean, they might still have weird APIs like, you know, touches begin inside cell.
And it's like, what do you mean touches?
There's no, you know what I mean?
Like, what you have to think is, look, this framework exists and the class names make you think it's very UI kit.
Like, why would Apple bother
making this and for the photos app the obvious answer to me is the photos for the mac app looks like photos for ios right down to zooming out and seeing that giant grid of like photos for this month or week or year like it is very clearly a macification of the ios photos app so ui wise you know ignoring like the back end and how it stores photos and the iCloud and everything like that
uh so much it looks much more like hey someone ported ios photos to the mac than anything like hey someone made a new version of iPhoto like it is it is just and so if you have the existing photos app which which presumably uses ui kit and you wanted to make a mac version of that being able to
reuse if not that code directly then like that code indirectly or the structure of the program it would be really convenient to have something like ux kit where you can get the benefit of all that ui kit code and you know get some semblance of a mac version up and running faster
That doesn't answer the question of why it would be used in Xcode, but historically, Xcode has been used to dogfood all sorts of weird stuff like Garbage Collection and... What was the other one?
It was DogfoodArc, I think.
Did it DogfoodArc first?
Anyway, that could also just be Xcode dogfooding things because...
If you're going to experiment with weird technologies, you should definitely do it on the application that developers use to write programs.
The argument of you should keep them separate is weakened once you start looking at what things in iOS would you not have on the Mac and vice versa.
And I think that list is actually a lot smaller than you might expect if you're starting to make this argument.
And if you look like, as you said, like, you know, collection view, that's applicable to both.
So many little components, UI control, UI image, UI image view, UI label, like table view, text view, so many of these things.
Actually, there's not a great argument that they shouldn't be the same on both.
It's really just the very high-level structures, the very high-level navigation concepts, navigation layouts, that kind of stuff should be different on both.
But that's really a very small part of UIKit in the grand scheme of things.
And you don't even know.
You say, oh, navigation controller, we don't really push new things on it.
But there's no reason you couldn't make a Mac app that in one of its windows does a sort of UI navigation controller thing of pushing a new view on and popping it off.
It might be weird, but...
Like, arguably, a lot of the existing OS X apps do a lot of iOS-y type things.
I mean, hell, I think in Messages has, like, buttons that aren't buttons but are just colored text.
You know, I think I pointed that on my Yosemite review.
If I didn't, I meant to.
Like, there is just, like, a details button or something in Messages that is not a button.
It is just blue text.
It's like, this is not iOS.
What do you think you're doing here?
But people accept it.
Like, it's like, all right, whatever.
I know when I click that, I get details.
For serving certain interests, as an iOS programmer who doesn't know much about the Mac, it would make me way more likely to start tackling a Mac app if this stuff was more consistent.
If I just dive into the Mac and really am committed to it, I could work through AppKit pretty well.
I could figure it out.
That's not the only reason I'm not making a Mac app.
But...
it would definitely make me a lot more likely to make a Mac app and sooner, and it would make it a smaller undertaking if a lot of this stuff is unified, instead of having all these little superficial differences, some big, some small.
And that has to play in somewhat to any decision they make to this.
Like, if Apple wants to encourage more Mac apps, if they want to...
populate the desolate, awful landscape of the Mac App Store, which is really sad in a lot of places, if they want to help populate that with more better apps, if they want to get more people making Mac apps, more people using the Mac for a lot of this stuff, they have to make it easier for developers.
Right now, all the people who are saying this shouldn't be unified are all longtime Mac programmers.
Longtime iOS programmers, I think, are very excited about this idea.
Because we look at the Mac as like, well, we could go here fairly easily, but all this stuff is needlessly different.
Yeah.
And like, even if you made the core of your app, like, oh, it's all written in sort of completely platform agnostic manner, and it doesn't really matter, or I'm using some framework that's on both places like core data or something.
The UI part is like,
So like, oh, we'll just put a different UI on top of it.
I'm not going to say it's the hard part, but it's a surprising amount of work.
And if you have to repeat it and keep them in sync and every time you want to add a feature, you have to add it in both places with a totally different code using different APIs.
It's just, it's a lot of extra work.
I'm not sure UXKit makes it
you know lowers the barrier enough to really move the needle on the mac app store because it has other problems uh you know like and it's just there's so there's so few mac users like i think you'd have to really make it a low barrier for someone i can address the market of like hundreds of millions of ios devices or like a couple of mac people like there's like a million or two or five or like it's so the iphone is just such a monster and that's just one ios device compared to the mac right but
If this was their goal, like their long term goal, like we're going to dog food this, we're going to see if it's possible because we as Apple have a bunch of iOS apps that we've decided this is the right way to do photos with the stupid view where you zoom out and see everything as a big thing and you, you know, put your finger or your cursor over it and see, you know, that's the future of photos.
We already wrote that app.
Can't we just get that to run on the Mac?
Well, no, because X, Y and Z. It's like, well, OK, so we have a job to do.
We can use this UXKit framework to be the first people to try to do that.
But Apple has way more resources to throw towards the successor to iPhoto than the average developer with an iOS app.
who might be thinking about making a Mac app.
So if Apple runs this experiment and decides, boy, this really makes porting much easier, then what do they do about it?
Do they just say, like, how would they?
Assume that this is a successful experiment inside Apple and assume that the goal of it was to see if this is something that developers might want for the reasons that Marco stated.
how does apple then at wwc announce this as a thing and tell like what is the messaging it's like so you're thinking you're writing a mac app if you have an ios version then look at ux kit because you could reuse a lot of that same code changing all the the capitalized capital x's or something uh but otherwise use app kit or is the message like this is the future of writing mac applications it just happens to look like the ios one but even if you never write an ios mac we're telling you you should use ux kit to write your mac apps
Well, honestly, I think if they actually unified it, it would just be called UIKit Everywhere.
Yep.
That's the direction they would go.
They would work from iOS back to the Mac, and they would just bring over everything named UIKit that makes sense to have on the Mac.
And also, one advantage they would have here is right now...
They're maintaining two different frameworks.
They're maintaining two different UI libraries.
And AppKit is very, very old.
And there's a lot of cruft in there from the olden days.
UIKit was kind of like a rewrite of AppKit for the iPhone and to be more modern and to be more efficient and have all these new capabilities and be simpler in a lot of ways.
ui kit is like it is the rethink of app kit it is the rewrite of app kit um they just didn't replace app kit with it quite yet if they were going to call it ui kit everywhere though doesn't that come because like the code is not the same like ux kit i'm led to believe is more or less just a wrap around the existing app kit apis to begin with and maybe they would like
gut that out later but I don't think you can pull that out because you have to maintain support for AppKit for a long long time into the future right so linking against the if they called it UIKit you couldn't link against that framework if like if one set of code is like the native code for the iOS devices and another set of code is the
the wrapper around app kit i don't know how you could do that with the same name it seems like like i think the reason the x is there like it just doesn't make sense to me like it would seem it's not going to be a single unified code base it's going to be two separate code bases and having two separate code bases in a framework with the same name on two platforms i mean i suppose you could pull it off because the sdks are in different folders you know this is the ios sdk and this is the mac sdk but it just looks like
I mean, think about looking up documentation for it.
Like, surely there would be differences.
So, I don't know.
Like, messaging-wise, though, that's... We'll get to this after the next sponsor.
But that is a weird message that, like...
app kit we've been evolving and improving for a long time but now uh you know it's like i always wonder that when they bought next like how i wonder how long the ns prefix will i wondered initially would they keep the ns prefix and everything because it's kind of weird you know ns next step like why are all why don't all these cocoa glasses of ns prefix i bet there's tons of people just starting out programming for the mac wondering what the hell is ns crap is about right but it's it's held on for a surprisingly long time right and and
you know if they get out from under and say all right this is the new thing and we call it ux kit and maybe in the future it'll be unified but for now we have ui kit and ux kit and like i still think they would be stuck maintaining three things app kit ux kit which is on top of app kit and ui kit like so it wouldn't be maybe long long term it's a unification but
The messaging just, it seems weird to me.
I mean, that's fair about maintenance.
The messaging I don't think would matter.
I mean, look, they have two languages now.
Well, but one of them is clearly a successor to the other.
I think it's going to be longer.
And by the way, a lot of people are speculating that UXKit might be Swift only or Swift native.
I think we can already tell it's not just by inspecting the file and everything.
But if you look at the timing of this,
The Photos app was introduced at the same time as Swift Beta 1.
When Swift Beta 1 was announced at WWDC last year, very few people inside Apple had even used it yet.
So I think it's extremely unlikely that there's any Swift code in the Photos app.
Well, there's probably some Swift code.
That's the way they would... But I don't think it's written from the ground up in Swift.
And I think you're right that this is an Objective-C framework.
The whole point of Swift is you can call through to the Objective-C frameworks.
And half of the stuff they did in Swift 1.2, which we didn't even talk about,
making it less painful and less awkward to interoperate between Swift and Objective-C stuff by adding a whole bunch of annotations that you can mark up at Apple.
I'm assuming he's marking up his own Objective-C APIs with all these annotations that mean nothing to Objective-C, but totally let Swift know how it needs to write the adapter classes to be less annoying.
Exactly.
And I think that's the biggest sign as anything that Objective-C is not going to go away two years from now.
This is going to be a very long-term replacement.
Right now, look at how many Apple classes are still using C++.
So many APIs are still written in C++ that I don't think we have to worry anytime soon that Objective-C is going to be just ended.
Well, I mean, it could be ended in the sense that they tell you when you're writing your application, the only code you will ever write is Swift.
Because you could get away with that because it's like, I'm not limited.
I can call all the existing frameworks and APIs.
I can call them all from Swift, right?
And I can do weird C-style stuff too.
So you could say third-party developers, if you were starting a fresh new application and opening a new project in Xcode...
write all your code in swift and you'll be fine like they're not at that point yet but that's like the way they want to get and that point could come way before all the objective c code is gone because that's going to take forever like the actual people at apple are going to be writing objective c for a long time but they could be telling all third-party developers we would like it if you just wrote all your code in swift uh and you won't be limited in which apis you call it like the idea of like a swift only or swift native api
What's the selling point of that other than like ideological purity at this point and even in the near future?
I don't, you know, surely that day will come.
But unless there's some big advantage in terms of speed or interface, it's going to be difficult to justify it because then you'd be cutting off all the people with existing Objective-C apps.
And there's a lot of them.
Yeah, and yeah, I would not expect a Swift exclusive API for anything important to be available in the next, I don't know, two years at least.
I mean, I think it's going to be a while.
Apple likes to move fast.
They like to like, oh, it's sooner than I expected.
I didn't think, you know, and in fact, they will probably do it with something important when they decide to do it, but it seems like it's just way too soon now.
So that probably means that whatever your estimate was, two years, like maybe cut that in half.
Don't they always surprise us where it's like,
uh you know the way they herd everybody into whatever new thing they want to do is like the new hotness is only available with x and yeah but not necessarily first of all not necessarily on this level of like the language level of what you're doing like the api level not necessarily on that level and also i think the last time they did that like with what was it with carbon like when was the last time they did that no the best example i think is how you can't build applications for older versions of os's
uh with the newest version of xcode they want to push everybody to the newest version of xcode and that's why people have to keep seven versions of xcode running on old machines like they they're like you can't even target you know snow leopard anymore with this thing and like they they are pushing people up their os support chain forcibly by saying look you're gonna have to have this version of xcode because it's the only way you can develop for the iphone 5 but you can't develop for snow leopard with it so you know all these people keeping these vms alive with ancient versions of xcode and the old sdks
That is Apple aggressively pushing people way too fast.
As soon as people are running VMs with old versions of your IDE, you know you're going too fast.
And that is a very common thing that people do.
Yeah, actually, a lot of Mac developers need to do that.
I think it'll be sooner.
I tend to come down on this closer to John's point of view than Marco's.
I think the push to Swift is going to be more aggressive and sooner than any of us expect.
I think I'm on the edge.
I almost want to say something will be Swift specific or this year, maybe at the end of the year.
I think perhaps it's more reasonable to say sometime in 2016, but I think it'll be soon.
I think it'll be really soon.
And certainly Swift is making some really significant steps in doing so very quickly.
And what I keep thinking is,
Swift is supposed to make a lot of the dangers of Objective-C go away, and that's, of course, causing a lot of, I don't know about drama, but maybe doubt in the community, especially amongst those who have worked with Objective-C for a long time.
But I think...
I think that if Swift prevents really silly programming errors and if it's a little more stable eventually and it runs faster eventually, it's in Apple's best interest to push everyone that direction.
And I think they will.
And I think they'll do so really aggressively.
Yeah, but I mean, honestly, I think most of the drama is already really fizzling out.
And I think, you know, it's only a matter, it's only a couple more swift revisions.
I mean, look at how much they did in 1.2.
It was a pretty substantial upgrade in a lot of ways.
And I don't even use it yet.
But I could tell just by looking at what they changed and other people's reactions to it.
It's a pretty substantial upgrade.
I've read a bunch of these blog posts of like, we switched our big project to Swift and rebuilt a big project in Swift and here's how it went.
And overall, it seems to be people are, you know, kind of mostly okay with the language itself with a few minor differences here and there, but mostly okay with the language itself, but they just complain that the tools are immature still.
That's working itself out pretty quickly, really.
They just added the incremental compilation, which was probably the biggest complaint in its absence before.
In less than a year, Apple has already eliminated most major complaints about the language.
There's still some minor complaints, and there's still some people who really object to certain things about it, and that will probably never change.
But for the most part, they've already addressed many, many good complaints about it in less than a year.
And they're moving really fast.
Like they're making big, big breaking changes, almost so much like it's frustrating, like reading the documentation for the language and trying to learn the language just to the point you think you're actually learning things.
They change it all.
And you're like, but I just.
learned how it worked before now it's totally different again and like they don't do it like in my there are minor ways like oh we tweak this little syntax here but there's like big fundamental like just wait until they add exceptions and regular expressions people's brains are going to explode right this is why i haven't learned it yet this language is moving yeah i mean this language is moving fast and just it's like wow 1.2 was a big change but like well my program got five times faster and i didn't change anything and you know like my compile times are lower like
it's still super young and i think it's probably still super buggy and they've got a long way to go but like there's the i think the inclination is to think well it's young now and there's these big changes but the rate of change will slow down and i expect it to like to not slow down to make people uncomfortable with the amount that it doesn't slow down for the next couple of years like at a certain point it's going to be kind of like you know the change fatigue with the os go like
are right already like my my annoyances with whatever features in swift are now dwarfed by my annoyance that you keep changing the language every three months like we understand you could you're addressing all of our problems and trying to make things better but now i just want it to be stable so i can write some code and feel like i actually know the language that's that's going to happen in like eight months if they keep up this pace
yeah hopefully i mean like i you know i said like last year i was going to wait about a year before i even looked at it and so far that's that's working out very well like i i can see in passing oh they're making all these big changes but i have no investment in it i i haven't even read the the apple swift book yet the thing they release on my books for free i haven't even read that yet that's good because every page of it has changed by now i think i know
And so I'd rather just wait until it settles down at least most of the way.
I would expect within the... You said within the next couple of years, I think it will be pretty stable even in a year from now.
But I think the reason I don't think it'll ever really stable is just like built into this language is the idea that it is a versioned language and...
backward there's no backward syntax compatibility their entire path forward and we'll see how this works is that like the ide is going to update your source code like they're not going to support swift 1.0 1.1 one you know for like the source like it's not like i wrote this in swift 1.0 and i'm going to be able to compile it in xcode 9 many years from now no you won't no you can't even compile that now probably like their whole strategy is source compatibility forget i mean maybe they'll change their policy like that's when it comes to the maturing point they're gonna say okay now the new policy is
We will actually respect the sanctity of your source code and not require you to use our refactoring tools to upgrade the syntax.
But they're not in that phase yet.
They're in the phase that says, we told you we're going to break syntax compatibility.
We are going to.
We're never going to compile your Swift 1.0, 1.1 stuff anymore.
So just get used to it, and you better upgrade to Swift 1.2.
And by the way, 1.3 will do the same thing to you.
Our final sponsor this week is Automatic, your smart driving assistant on your smartphone.
Go to automatic.com slash ATP.
So Automatic is this little dongle that plugs into your car's OBD2 port.
It's the same port they use at the mechanics or the dealers where they check it for error codes.
It's usually in the driver footwell.
Automatic plugs into that and so all the information that the dealers can get and the mechanics can get out of your car, Automatic can get and it has a smartphone app that integrates with this and does cool stuff.
So
So, by the way, this works on iPhones and Android phones, which is pretty great.
And it can show you, by combining the smarts in your car with the smarts in your phone, it shows you things like where you've driven and how efficiently you drive.
It gives you feedback on your driving in real time that can save hundreds of dollars a year on gas.
They can even call emergency services for free in a serious crash.
So if your car crashes and your phone is at all workable, it can use your phone to call emergency services for you.
This could really seriously be a benefit here.
Automatic also can diagnose any check engine light code.
So because it's in that port that all the mechanics use, if there's any kind of error code that causes the check engine light to come on, the car has like a lower level error code than that.
It's just not showing you because it usually just lacks the display for that.
that's why it just says check engine but usually there's some lower level code and a lot of those codes are really obvious things that you can fix things like the gas cap isn't sealed all the way you know stuff like that you can just fix that yourself or you know minor parts swaps you can do you know you can go to a mechanic instead of going all the way to the dealer paying all this money so it can save you lots of money with check engine light codes it can give you lots of money savings on gas it can call the emergency services for free in a crash and it even has little useful things like parking reminders and
Again, it's combining your car with your phone, so it knows where you parked.
And you can use the Automatic app on your phone to just go find your car again.
They even have integration with a few different things.
So they integrate with the Nest learning thermostat.
So for example, if you're headed home and Nest has you in away mode, so your house is cold in the winter, Automatic knows you're getting close to your home, so it will tell the Nest, turn the heat on.
And so then by the time you get home, your house is nice and warm for your arrival.
And even if you don't have a Nest, they have integration with IFTTT, If This Then That.
So with that integration, you can integrate countless other online services with your automatic device.
So it's really great.
There's also an API.
You can download your driving data.
You can subscribe to events, like when you start and stop the car, when your check engine light comes on, etc.
There's a whole API for you to use for whatever you want.
And if you have an Android phone, they even have a feature called Do Not Disturb Mode.
So that if you want, you can have it automatically mute your phone like buzzing or beeping while you're driving.
So you don't get distracted by those notifications.
So great stuff here.
Automatic.com slash ATP.
And this is normally about $100.
There's no subscription fees.
This is one time up front.
Just $100.
There is, again, no monthly fee.
You can buy the device.
That's it.
Now, there's a special offer for the podcast listeners.
20% off.
So for you guys, by going to automatic.com slash ATP, it's just $80.
It's 20% off.
So just $80.
Free shipping in just 2 business days.
And they have a 45-day return policy.
This is really risk-free.
Fantastic deal.
80 bucks, free shipping in two days, and a 45-day return policy.
Automatic.com slash ATP.
Thanks a lot.
And speaking of different ways of writing your user interfaces, a couple of things have happened over the last weeks or months that a few listeners have asked us to talk about.
And the first, actually might have even been a year ago now, is Async Display Kit.
Do you want to tell us about that, John?
Yeah, all this talk about UXKit has, like, the idea, oh, UXKit is a successor to AppKit, and AppKit has this cruft that UIKit, you know, learned from AppKit and did things better, which is why it seems nicer to do a lot of things in UIKit than it is in AppKit and everything.
And AsyncDisplayKit and the other topic we'll do after about React...
or React Native rather, point to sort of a larger leap above both the AppKit and the UIKit paradigm, particularly having to do with the requirements that certain things only be done on the main thread.
laying out the ui drawing and there's some exceptions to that where you can try to do some of those things off the main thread but generally that leads to sadness unless you're super careful and know what you're doing uh and that's a limitation kind of built into the framework a framework that if you trace its lineage through you know open step and next step app keep going way back in time made sense when you didn't have a multi-core cpu in your little handheld crazy phone like the
multi you know uh symmetric multi-processing was barely a glimmer in people's eyes back then forget about these you know 12 core cpus and everything like that um but the reality is that now we do have multi-core in everything and even if you just offload some of that work to another core it can be a big benefit so async display kit is a thing i think it's a thing that facebook made for like its its native applications the paper application where
they wanted to do layout calculations just basically math of saying how wide is this how much room is it going to take up blah blah blah and they wanted to do it in parallel not on the main thread because they didn't want to block the main thread they wanted the main thread to be available to pick up events and process them and make the the ui you know reactive not to use that word the next thing um
and so they made async display kit which is a thing on top of app kit that lets you do ui type calculations in asynchronously and possibly in parallel and other threads and then do it in a nice way so that the actual layout gets done on the main thread as it has to to work with the thing but you can actually do the calculations elsewhere and that's what makes me look at ux kit and think like
This can't really be the future of anything.
It seems just like an interim step because I would want to see a leap.
Like UIKit was a nice step up from AppKit, but it was kind of like more like a cleaned up AppKit, but it didn't revisit some fundamental assumptions in light of the hardware realities that we have today.
And I think something like...
Something that incorporated something like Async Display Kit into the fabric of the framework would be much better than someone taking AppKit or UIKit and layering another framework on top of it to offload stuff to other threads and stuff like that.
Yeah, so Async Display Kit gained most of its fame, I guess, from Paper, which is an app that Facebook wrote as a kind of alternative to their traditional Facebook app.
And it's actually the app that I use on my phone because it freaking supports sending messages, which is nice.
You don't have to have a separate app for that.
But anyway, it's very pretty.
And the animations are very cool.
And it's very nice.
And Async Display Kit powers it.
Now, lately, Facebook has taken a different approach because React Native is Facebook, right?
I'm not making that up, am I?
I think you're right.
All right.
Well, we'll just assume I'm right.
Why not?
Email me and tell me if I'm wrong.
Anyway.
react native is also by facebook and react originated as or at least to my knowledge as a javascript front-end framework kind of sort of but not really at all like angular and then somebody at facebook said well you know what we could do something on the native side with this and
And so there's an unbelievably good video that I had seen by way of Andy Matushak, who has been coming up a lot lately, actually, on the show.
And it's an overview by one of the developers of React Native at Facebook talking about how it works and kind of what it does.
And I haven't watched it for a week or two since whenever it came out.
And so I can't really get into the specifics because I'll steer us into a black hole of incorrectness.
But some of the stuff that it does was just unreal, including being able to mess about with your UI without doing another build.
And so you can have your app running in the simulator, fart around with some stuff in Xcode, and it will refresh itself in the simulator without recompiling.
And additionally, you could actually connect Chrome to the app, the running app, kind of like we talked about, I think, last episode with...
with web views but this isn't a web view this is all real honest to goodness native stuff and so you can connect chrome they have some sort of interpreter connector whatever and you can connect chrome to your native app running react native and go inspecting it kind of like um what was the third party thing that got sherlocked this year do you know what i'm thinking of oh yeah the thing that exploded all the views but yeah so it's kind of similar to that and
I haven't played with it yet, but just watching this half an hour video, my mind exploded probably 15 times.
Reveal.
Thank you for the chat room.
It was revealed that I was thinking.
You're not going to try to pronounce that?
No.
Thank you, person in the chat room.
Marius Sirachi.
That's totally wrong.
Anyway, this video is really, really incredible.
And Marco, especially, well, you haven't seen this, have you?
No, of course not.
Okay, never mind.
So you're useless.
Hey, in my defense, I did spend all day today making another Go program.
So I was in this century.
Okay, well, that's good.
I would like to hear about that if we have time.
But, John, what are your thoughts on this React Native thing?
Have you done React, the JavaScript framework at all?
I retweeted a thing from, like, someone was making a joke, like a sign of the W3C, and it was one of those signs of life where I said there have been blank days since a new JavaScript framework and had, you know, zero whiteboard.
Yeah.
i'm pretty sure i know what react is and i've seen it like the the javascript version for web applications you can correct me if i'm wrong casey because you've watched the thing because i haven't watched it yet but react is the one where they do where they have all is it the one where they have like the dom sort of as a structure not actually connected to the dom and they do diffing against it to figure out what actually needs to be updated and that ends up being faster it's like yep it's one of those crazy solutions that has to do with
it's it's not shadow dom crystal td and the thing although that's a separate thing and web components are related to this but it's like you would think it would be so much slower to build these parallel structures in memory uh that aren't the dom and then figure out what the changes are by diffing it against something else and then and then only at the end after you've done this crazy diffing thing and it's just these abstract memory structures that have no connection to the browser that you say now finally i know what i have to update in the dom and you do the minimal update to the dom but
Updating the DOM is so damn slow that doing that diffing ends up being way faster than doing it like the quote-unquote direct way.
And it's worth pointing out also the Flipboard thing on this topic, where Flipboard came out, I think it was yesterday or the day before, it was very recent, and they launched a web version, and then their engineering department posted this whole thing, how they're basically doing...
a react like uh diffing system in the middle of this whole system where they're basically they basically rewrote part of webkit that just runs on a canvas it's and it's a very small part but still yeah that's what they call it a web version i put scare quotes around a web because once your entire application is just a big canvas tag that you draw stuff in with your own framework like yeah i guess that's the web but like you've just reinvented
active x controls like you're right oh no that's that's terrible that's really insulting come on not you know what i mean but like you are not it's a difference we just talk about this with flash like the web is we know what the web is and anything that is a rectangle in a web page in which some other program runs is not the web and canvas is like the borderline of that it's like well is that the web or is it like you've written you know yes you you have a nice display layer and you could in theory do a
do everything yourself and they're not they're not doing everything themselves but it's like as many people pointed out in terms of like accessibility of a canvas native application like unless you're signing up to re-implement you know ui kit or app kit with all the accessibility things that are that are inherent there
and support for all the tools.
It strikes me a lot as a big rectangle on a webpage where other things happen, which may be fine for Flipboard, but I don't think it's... That's fine for Flipboard.
Yeah, right.
But React is more like, we're going to take the web as it exists and we're just going to find out a nicer way for you to write applications or what they think is a nicer way.
React has some weird stuff going on that, you know, they violate, they sort of sacrifice a lot of sacred cows.
They're the big things, I think, also where they, like, mix...
javascript handlers in line with these fake things that look like tags but really aren't and freaks people out because it looks like you're doing like the old style on mouse over equals whatever but you're not really because that's not actually dom markup that's just a way to communicate with the like there's a lot of weird things about react but i think that's all besides the point because i think the important part of it is that it is a different model it's a very different model from app kit and ui kit
of how to make GUI applications.
And it's like, well, that's for the web.
The web is so different than native.
It has to be different.
And React Native is like,
What if we take that same model and apply it to native things?
Does that work?
Is it actually better than using UIKit or AppKit?
And some people apparently think it is.
I think the jury's still out on whether this new paradigm is the way to go.
But I think this combined with AsyncDisplayKit show two different potentially complementary approaches that show that are so different from AppKit and UIKit and UXKit that it's like...
it makes UI kit and UX kit and app kit look like objective C 2.0.
And it makes these things look like potentially Swift or something like, I just feel like there's a bigger leap to be had.
And it's like, I would recommend that Apple not invest some huge amount of time unit making, pushing some unified UI kit, UX kit type of thing for the future, because that transition will take a long time.
And when you're done with it in transition, what you've got is basically now everything's as good as UI kit and UI kit may be nicer than app kit in important ways, but it is not sort of a,
large it's not as big a leap potentially as big a leap as Swift potentially is over Objective-C like I'm looking for the next big step and I would say refine what you have now make AppKit better as you've been doing make UIKit better as you've been doing and get busy working on whatever the next big thing is and if it's something like React Native fine if it's something that incorporates the ideas of Async DisplayKit fine if you think you can retrofit those to both UIKit and AppKit and let people do more things off the main thread maybe try that too but
I'm not going to say this is my next Copeland 2010 type of thing, but I do look at these other frameworks and I'm not convinced that they're the future, but they look different enough from the present that I'm interested in potential ideas for the future.
Yeah, I agree.
I think you're totally right that if you're going to make everyone do a big transition...
If there is this other thing that has come up in computer science-y type circles and everyone thinks this is a really great idea and it turns out in practice to really be a really great idea, it is definitely worth considering.
Is it worth, if you're going to force people to go through a transition, to make a bigger leap like Swift?
It's not even like computer science-y, just recognizing the hardware.
The hardware is so different now.
The frameworks we have are not a good match for everything being multi-core because of the main threat constraints.
And GCD helps that a lot.
Like GCD does help, but for UI code, it doesn't help because it's like certain things you have to do on the main thread or bad things happen.
And so that's like the Async Display Kit is like, we're going to hack around that limitation of Apple's frameworks and say, you just sit there, framework, don't worry.
We'll actually do the UI updates on the main thread.
But we're going to do a whole bunch of other math over here in our sort of play world.
And same thing with React, our sort of play world of this is not the UI, but this is our little...
fake model of the UI so we can actually take advantage of parallel processing.
And then we'll get back to you with like, okay, now your actual UI or now your actual DOM, please do this change.
And that is hacky and clever, but it shows that the current frameworks are just not a good fit for current hardware.
Well, I think the multi-core hardware rendering on main thread thing is kind of a red herring.
In practice, the reason why a lot of UI code now is tricky to write is not because drawing calls have to happen on the main thread.
It's because declarative versus procedural, whatever.
It's a different paradigm is what I'm saying.
It's not that it's tricky to write.
It's just that if you have performance concerns, you want to treat it more like a game engine where it's like, if you're going to do anything, you have to be done because I have to pull the next event off the queue.
You need to leave the main thread alone.
That's the whole thing of GCD.
Stop blocking the main thread for crying out loud.
I don't care what you have to do.
Get like...
Get in, get out.
I need to get the next event because if it's stuttery when it's scrolling, it's super bad.
And like that's why Async Display Kit has this cool, you know, one of the classes they have is like, say you're going to show a big giant grid of images and they're coming from the Internet.
You can't wait to get all those downloaded to figure out what sizes they are so you can lay it out.
It'll take forever.
So there's like this procedural thing where like we'll download super low res versions of those and asynchronously bring in the higher res versions.
But just so you can get a scrollable correctly laid out thing as soon as possible so you can start scrolling it.
that's the type of thing that's very difficult to do with the existing framework because it's like, they don't expect sort of asynchronous updates to all this, like to all these features.
It's like, it should be easier than it is.
And it's not, it's not because of like, like you said, declarative versus procedural, that's part of it.
And you could say, Oh, it's easier if I could describe my UI in this way, instead of writing a bunch of code to make my UI in this way.
But it's like for large grids with lots of things on them,
I don't want to block the main thread with the amount... I don't want my main thread to be blocked if N is really large for something that's performance is dependent on the number of items.
Yeah, but I think it's more, you know, like you said, like with GCD, we can already step off the main thread, come back later.
Like, it's...
It's more of a paradigm shift.
It's not that the APIs have to happen on this main thread.
It's the paradigm for how you update the UI.
The way React does it, if you look, I don't know React, so whenever I see snippets of React code, it just breaks my mind.
I'm looking at this and I'm like, oh my god, this is totally backwards, inside out, upside down, and in French.
It looks so foreign to me because it's so different from what I'm used to.
Yeah, so let me jump in here.
So one of the links is that we're going to put in the show notes.
Why React Native Matters?
And this is by Joshua.
I'm guessing that's Josh Aber.
Anyway, he says, right now we write UIs by poking at them, manually mutating their properties when something changes, adding and removing views, etc.
This is fragile and error prone.
Some tools exist to lessen the pain, but they can only go so far.
UIs are big, messy, mutable, stateful bags of sadness.
And that's building... Oh, it's Josh Abernathy.
I'm sorry.
That's building on what you were saying, Marco, where this is just a whole different model of how you interact with user interfaces.
And it makes a lot of sense.
Maybe the particulars are a little bit wonky, and I'll concede that.
But the premise of really this is just moving from one concrete state to another, and it should just be a finite state machine, hopefully, in theory, that is a really cool premise.
And building on that,
And going back to Andy Matushak, he tweeted a few days ago, we'll put a link in the show notes.
I say with confidence as a former UI kit author, React's model for the UI layer is vastly better than UI kits.
React Native is a huge deal.
In another tweet, they've just got to figure out the interaction and animation pieces.
And so he goes on just briefly to all ask me what's react filter bubble danger.
You must watch the broader development landscape.
Don't get trapped in one platform.
And I think that's, that's a really good call.
And this is something very interesting.
That's, that's influenced from the, from a web framework coming into native and it's making some real, making some really interesting,
interesting moves and i and i wouldn't be surprised if something along these lines gets adopted by apple in the same way something along the lines of reveal which isn't an apple staples comparison but you know reveal was kind of sherlocked it wouldn't surprise me if they took a very similar spiritual spiritually similar approach to whatever replaces ui kit and app kit eventually one day maybe
Oh, yeah, because React, I mean, it's making big waves, and it's making waves with a lot of the people who matter with such decisions.
People like Andy Machusak, people who are developing these frameworks, people who are in important positions, or were, or know people, or those...
The new people in those positions, it's making big waves.
I have heard so much about React.
Every JavaScript framework out there besides React that's come out in the last decade, I hear nothing about because I don't care.
React makes big enough waves that I keep hearing about it.
I don't know anything about Angular.
Is that the one that has a million different levels of factories?
Yeah.
ember and angular yeah like you don't those those are confined to the client side react is coming over to the native side like i think the to tie this together with uh async display kit was like you know we're talking in in two different things like i was mostly talking about async display kit with the performance concerns and you were talking about react as the paradigm thing they're connected though because react's functional thing where like you know you operate on state and it's a value type thing
So that sort of, you know, lack of side effects where you just operate on your arguments and return a value and everything is sort of, you know, like just a value type and all that stuff that you see a lot of that in Swift as well.
That allows you to parallelize that stuff because if you don't have side effects, if you're not, if it's not just one giant big ball of mutable state that you can only update one thread at a time, otherwise you get crazy conflicts.
That's one of the many things that ties AppKit to its current paradigm.
React says, you know, React and Async DisplayKit are connected because if you use the React model, it doesn't matter what thread you do these mutations are.
It doesn't matter.
You could do them all in parallel the same.
Like, they're side effect free.
They're pure functional.
And so it lends itself to that type of UI model as opposed to the current model, which is we have this one thing.
It is the state of the UI.
Be super careful with it.
And going back a sec to what Casey just said, it is not past Apple to steal good ideas.
They do it all the time.
And if something is making this big of a wave, and Apple's engineers and top people, if Apple thinks it's a good idea, they will do it, or they will do something similar to it.
Something like this, this is a pretty big deal.
To change your entire UI API paradigm or to add a new one is a
major deal and this you know this is not something that can happen in a year this is a this would be a big undertaking it would have to be a skunkworks but i think that the exciting thing about swift is it showed us yeah it was a skunkworks but it was essentially one guy who one very powerful guy who had proven himself with many other things that he had done in the company it's not just some random employee off in the corner somewhere but
For a long time, it was just one person.
And I'm sure there's lots of those one-person type projects that may or may not go anywhere.
But it just goes to show that you don't need buy-in at the VP level to get the ball rolling or something like this.
And maybe the ball starts rolling and then stops rolling, as happened with ZFS or whatever other things.
It's not guaranteed that it's going to happen, but it seems like Apple is currently an organization in which something like this
could start happening and get killed before we ever see it and something else comes along and maybe react is just the hotness today and then two years it's something else like but it's not outside the realm of possibility that apple can innovate in this way on any subject other than file systems which they seem institutionally incapable not that i'm bitter
and tying it back even though i really want to end on that but tying it back uh if they're going to do something like a react style ui framework that would be a really good thing to start with swift and to make swift only uh one of the things that i that makes react code look so weird is that it fits in very weirdly with existing languages like just like the syntax of of declaring it and using it just like the fact that it's using javascript like this is
yeah it's really badly bolted on and i mean you know not by its own fault by the fault of the language really but you know swift is is still squishy and and generally more pokeable but but but swift is a much better fit like the whole idea of so many things being value types in swift like not that that is a direct parallel to the idea of the ui state being a value type and everything but like just shows that the headspace like where is swift at in terms of like immutable data well it is
it is much more on the react side of things than objective c is because objective c is all about everything be mutating and hey just declare this type id whatever guys it's all right uh whereas swift is like no you know we're gonna pin things down lots of things that were reference types are becoming value types just because we've learned that you know making ns string reference type just leaves more headaches and
people forget to copy them and they have you know it's like that is the mindset of swift and so something using the good ideas and react and async display kit written natively in swift would be a very interesting successor to both ui kit and app kit from apple so someone should start writing that now and in four years get back to me
Anyway, give me a reason to learn Swift.
Yeah.
That'll be eight years later.
Yeah.
All right.
Thanks a lot to our three sponsors this week, Igloo, Hover, and Automatic.
And we will see you next week.
Now the show is over.
They didn't even mean to begin.
Because it was accidental.
Accidental.
Oh, it was accidental.
Accidental.
John didn't do any research.
Marco and Casey wouldn't let him.
Cause it was accidental.
It was accidental.
And you can find the show notes at ATP.FM.
And if you're into Twitter.
you can follow them at c-a-s-e-y-l-i-s-s so that's casey list m-a-r-c-o-a-r-m-n-t marco armen s-i-r-a-c-u-s-a syracusa it's accidental they didn't
What are we talking about?
Oh, your go thing.
What is this about?
You're really getting into this go thing.
Yeah, I'm getting faster with it now.
Like I and today was the first time like my previous the polar, the feed polar.
That's just one giant file because I didn't want to figure out how do I break up things into different files and manage that in Go because it's a pretty long file and I should break it up now because it got longer once I finalized all the stuff I actually needed to be in the system fully.
But that's just, you know, so tonight I was working on something else.
So I have these two servers at high velocity that I bought there that I started leasing per month about a month ago.
And I haven't done anything with them yet.
Because I bought them because they were having an insane sale that was just ridiculous for what you get for both hardware and bandwidth.
where now I, for a few hundred dollars a month, I now have an unmetered gigabit of transfer, a gigabit per second unmetered of transfer.
What?
And I asked them, I'm like, before I bought it, I'm like, all right, so, you know, what's your actual policy here?
Like, if I actually use all this, what if I was hosting big podcast files?
If I made a podcast file host for us or whoever else, like, you know,
if we actually used all this bandwidth would you cut it off or like and they're like nope we actually we're like we you can use it that's the point uh so and it's it's it's a pair of machines that are each 500 megabit and they're each as good as roughly as good as a six core mac pro they have dual ssds raid with raid one uh 64 gigs of ram i mean it's like
These are insane machines.
Six-core Xeon 1660v3s, which are actually faster than the current Mac Pro CPUs because the Mac Pro seem to have skipped a generation, which they sometimes do, so I'm not surprised.
But there is a newer version of the Xeon chips that the Mac Pro uses that is out right now that Apple has not updated to and seems like they're probably just not going to at this point.
Anyway, so I have these servers that I bought because one thing I want to do, and the reason why I was so interested in having tons and tons of bandwidth available, is I want to be able to launch a Twitter card for Overcast player pages so that people who are browsing the Twitter app can play the podcast right there in Twitter cards.
Twitter cards require that all assets that are loaded within them, including media files, are served over HTTPS.
Some podcast hosts support HTTPS for their files, but most don't.
So the first thing I wanted to write was an HTTPS proxy.
And there are a few of these that exist.
There's one, I forget what it's called now.
There's one that GitHub wrote in Node.
Oh man, I'm sorry, I forgot the name.
Anyway, so there's that one, and that's fine.
I looked at it briefly.
It's mostly made for images, but fine, it would work the same way.
I decided to try to write that in Go, a basic SSL proxy.
And it's nothing.
It's like 100 lines.
I mean, it's almost nothing.
It's great.
And I also have a few other things I wanted to try.
I mentioned last week that I was using ImageX for my thumbnailing, but it was costing me a fortune.
So I'm moving my artwork thumbnailer to these boxes as well.
So I wrote just one Go program that contains those two functions, the SSL proxy and the artwork thumbnail.
Just those two functions implemented in Go.
It listens over HTTPS and is its own server.
There's no server in front of it.
There's no Nginx or Apache or anything reverse proxying to it.
It's just its own server, raw, right to the internet.
And that's all these boxes do is run this program.
So I'm hopefully going to be deploying that in the next day or so.
Cool.
And it didn't take you that long to write, it sounds like?
No, a few days.
I mean, I've been sick, so my work hours, I can only really work a few hours at a time before I go lay down, which really sucks.
But I'm extremely annoyed about that.
That is by far the worst part about being sick, is not how I feel, it's that I can't work.
That's what drives me nuts the most.
Anyway, so that's on its way out, at least.
So...
If I was working full-time at full capacity, this probably would have taken only two days.
It has actually taken something like four days, but oh well.
So how does your Go server handle the... I still don't quite understand the concurrency model of Go, but how does it handle if there are more incoming connections than...
Then like, does it, does it do multiple processes or a single process event driven?
What does it, what does it look like on the machine?
It, it can do multiple cores, but it is, it is all seen.
It's for the most part, it's single process event driven.
It's, it's, they use this concept and forgive me, anyone who's an expert listening, I'm not an expert yet on this.
So this is a, a newbie overview of what, of the way it works.
But, uh, they use this, they use this thing called go routines, which are, which are these, you know, kind of threads.
Yeah.
cooperating sequential processes or something like that yeah something like that um so it's those things and so there it's it's basically a very lightweight thread that exists within the app space it is not an os level thread so so how does it behave like at the limits like if you overwhelm it with connections to the to the other connections just wait does the do you exhaust like the number of like i you know i always look at what the behavior at the limits like that's the only reason i would ever put another server in front of it like well i know how whatever will behave
I can set these limits on number of connections.
I know people will wait.
I know what will happen.
I know when people will start getting timeouts or connections.
Whatever the failure mode is, I can choose my failure mode.
And I don't know what the failure modes at all are for Go because I've never used it.
So I was trying to do some research on that earlier today to try to figure out, do I need to put Nginx in front of it or something?
Or can I just go without it?
The responses to that question were, for the most part, a few people who did it, who just did it raw off the internet, who said, it's fine.
A few people who said you should put NGINX in front of it because of separation of roles, which I think is total BS, honestly.
The way those arguments were presented, none of them convinced me that they were valid arguments.
That was not...
There's nothing saying that having Nginx reverse proxying to this Go server is any more of a purity of roles than having the Go server serving itself.
It has this functionality built into the language.
The only reasons I could think of are the older reasons that we used to run proxy servers in that if you don't want to slow down the process, if a bunch of your clients have slow connections, you don't want to tie up
your back-end process doling out bits to the slow connections, but when it's an event-driven thing, that's not really valid anymore because you're not tying it up.
When it's doling out bits slowly, it's doing other things because it's, you know, multi-threaded and moving on to the next thing.
Right, and the way, like, it seems like you would, like, the difference between Nginx being tied up with all these connections and Go being tied up with all these connections because they both have that same event-driven style model, I don't think one would be substantially better than the other at that.
Yeah, and the failure mode is the other option.
But the real question for me is, does Google put anything in front of its servers when it runs them?
And if Google doesn't do it, which I suspect they don't because it seems like Go is designed to do this, then it's like, well, if Google's not doing it, you don't need to do it either.
If it's designed to handle the traffic that Google expects, surely you can do your podcast image thing by having the Go app talk directly to the web.
But I know nothing about this, so I'll be interested to see what the results are of your experimentation.
that's probably a bad example just because google is such an incredible scale they probably have lots of stuff in between you know the the public internet and their application servers so like that that's probably a bad example but i would be i would be interested to see like you know medium-sized sites to see like what they do right well no but google i'm saying like google do they intentionally put a layer there whose only purpose is to be you know what i mean like i would suspect that the machines that their things are
are running on the go process is listening on the ports and yes there's stuff in between but it's like do they you know do they shove nginx and there is essentially a proxy server for some reason and it makes much more sense to do that if you have a multi-process back end because then you would be tying up an entire child process when really you should just shove the
put a big buffer on the proxy, have the chaw process, ship the bytes out to the proxy, and then that chaw process is free to serve another request while the proxy server doles out those bits to the slow client.
That's like 1990s-error state-of-the-art web technology, but we've moved on from that.
Right, and there was, I saw there was one benchmark that somebody posted where they, and they showed all the code they used, and there were a few complainers in the comments, but it seemed pretty valid, where they benchmarked a simple Go program, like a Hello World kind of thing.
They're like,
simple go program raw versus nginx with a few different configurations and tweaks and the go program just had it destroyed nginx in uh in in uh request rate per second with either a b or one of the other similar tools
It was way faster with just pure go because, of course, it's doing less like and you're synchronizing to event driven things like one thing is handling and they're not going to be in sync of like when when I'm doing the work on behalf of this request and then handing back like it's just you're just yeah, it's not just adding overhead.
It's like these two desynchronized event driven things trying to talk to each other.
Exactly.
So the way these servers are set up, they actually have none of my app on them.
They don't have any access to my main infrastructure.
They don't even read the database.
They don't have anything on them except this Go program.
They don't even have PHP installed.
And they don't even have private net access back to the Linode servers that are running the rest of the app.
They have no connection whatsoever to the app.
Just my app is able to write its files into it.
And it only has the Go files.
So the risk if these things get compromised is pretty small.
And if they go down, these are kind of accessory features.
I'm going to have a CDN in front of the artwork thumbnail anyway.
I'm not doing a CDN in front of the podcast bandwidth thing, or the podcast SSL thing, for two reasons.
Number one, the bandwidth cost would be extraordinary, and I don't think I would be able to afford it.
Number two, the way this is working...
Overcast does not proxy the files normally.
And I only want to use this in areas where SSL is really required for usability or for functionality.
So that would be things like Twitter cards, the web player to avoid mixed content warnings, things like that.
In reality, that's not most uses of Overcast.
That's not most plays.
And it probably will never be.
But regardless, I still don't want to steal hits from people's files because
And so the way I've set it up that there is absolutely no caching of that SSL proxy's assets.
Every request that is made through that proxy has a corresponding request back to the origin server.
And I know they're probably not going to count my IP as unique...
I am sending the X forwarded for and X real IP headers that, you know, that's standard for proxies.
I would imagine like to prevent fraudulent download count increases, most stats services probably ignore those.
For some of the big hosts, like I already talked to Libsyn and I know SoundCloud.
I won't need to use it with them because I know how to do secure URLs for them reliably so that
That should be fine.
But either way, I still want the downloads to be counted in some way as much as possible for the origin servers.
So anyway, there's no caching involved there.
That's intentional.
But for the artwork, there is caching involved there.
There's going to be a CDN in front of it.
So if these servers go down for any reason, it's not going to be a massive deal.
It's not going to be like the whole app stops working or something big is like ugly and broken.
it's going to be a really small deal.
And so I'm just going to try it.
I have just this one 7-megabyte Go binary to put on the servers, and that's it.
There's no dependencies.
This very much appeals to me.
There's no configuration, really.
The only sensitive thing on there is going to be the private key to the SSL certificate that it uses.
That's it.
So I think it'll be interesting.
Yeah.
That was much more in-depth than I expected.
That's excellent.
What else is going on?
You want to do titles?
I think Minutiae.
That has to be it.
Yeah, but the AE, the combined AE, I don't know what that's called.
That's going to break a whole bunch of podcast clients, isn't it?
My shell script might break to embed the title.
i'll have to uh that's a different issue yeah well it's not really i'll just do i'll use itunes to edit it or something else can you believe how like a lot of podcast producers that's how they embed the id3 tags is they import the mp3 into itunes and hit command i for the info panel and type in the stuff and then export like that's crazy to me that anybody does that they should use mp3 rage and pretend it's 2002 again
Well, I'm using lame on the command line, which is pretending like it's 2004.
Similar error.
Yeah, exactly.
Why don't you use a hex editor?
Wow.
Yeah, then you have to know UTF-8 for converting that character.
That's not going to work.
It's easy enough.
Yeah, I think the new Shay is probably the best one here.
Is that little AE symbol actually pronounced like...
j t a t little i don't even know how to pronounce the little well it depends on what language you're talking about if you're talking about latin or greek which is probably where it's from uh the answer is nobody actually knows and everyone's gonna think they know and they're making it up uh and so uh i think we'll just we'll use the wonderful ae ligature and we will just uh tolerate the emails that come in because we love everybody's emails so much including the people who tell you that's not a ligature
I think it is a ligature, isn't it?
I don't know.
I'm just speculating about potential email we could get.
Yeah, as Holgate in the chat room points out, the HTML entity name for it is AELig.
So I'm pretty sure it's a ligature.
Yeah, I don't know.
I don't know the technology.
You know, font and typeface and everything.
There's lots of distinctions that I have apparently not cared enough about to memorize.
I know they exist, but I don't know what's right.