Accidental Server Hardware
Casey:
Do you have opinions on kit lenses by chance?
Casey:
After last show where the three of us were talking about Apple's TikTok strategy with iOS, somebody tweeted at us, Pablo Bendersky, which I probably pronounced wrong.
Casey:
I'm sorry.
Casey:
Sorry, Pablo.
Casey:
And he wrote a blog post that was actually fairly short.
Casey:
So hopefully we'll remember to put this in the show notes and you can take a look.
Casey:
But...
Casey:
He made an interesting point, and the premise of it was, you know, what's interesting is that the – and I'm going to actually read this here.
Casey:
The TIC versions of iOS came with the S versions of the devices, iOS 3 with iPhone 3GS and iOS 5 with the iPhone 4S.
Casey:
On the other hand, big hardware releases such as the iPhone 4 and iPhone 5 launched alongside –
Casey:
talk releases of iOS, iPhone 4 with iOS 4, and iPhone 5 with iOS 6.
Casey:
So now not reading anymore, the general premise he drives at is, hey, even if you consider the software on a TikTok,
Casey:
And if you consider the hardware on a tick tock, what's interesting is they're offset.
Casey:
It's like 180 degree offset sine wave.
Casey:
So there's always going to be a tick and always going to be a tock.
Casey:
And that's kind of an interesting place to be in.
Casey:
And I thought that was an interesting point.
Casey:
So I just wanted to point that out.
John:
Weren't we having trouble last show thinking about which iOS release was big or small, and we were trying to list off the major features?
John:
I don't know if I buy that theory, because it just doesn't seem to me that there has been that kind of cadence to iOS.
John:
But it could be that I'm just not paying enough attention.
John:
But the fact that we were trying to think about, was that a big release?
John:
What was in that one?
John:
Either we're just old and have bad memories and can't remember what was in them, but they...
John:
They've all seemed pretty even to me at this point.
John:
Certainly none of them were like a snow leopard, you know?
Marco:
Yeah, and that's the kind of thing.
Marco:
I think I'm with you on that.
Marco:
I can't really point to any iOS release and say, oh, that one was the one that fixed most of the problems and added up much new APIs but didn't change much to the user.
Marco:
Maybe six, but I wouldn't say that's enough to really establish a pattern.
Marco:
I mean, at least OS X has had now...
Marco:
two ticks and two talks.
Marco:
It went leopard, snow leopard, lion, mountain lion.
Marco:
And those four releases, I think, have very clearly followed that.
Marco:
But even before that, they didn't really... Well, John, you're the expert, did they?
John:
No, not really.
John:
I mean, it was just more... That's why I think we're still in that early period of iOS where...
John:
It's, like, really simple.
John:
Not a lot of features.
John:
A bunch of stuff doesn't work.
John:
And then the ones that you have to get out to sort of shore up the API for public use.
John:
And then some major features.
John:
Like, it pretty much falls closely along with, you know, the 10.0, 10.1.
John:
And, like, you know, it's different because it was the SDK.
John:
What was the SDK?
John:
It was 2.0.
John:
Yeah, I think.
John:
Yeah.
John:
And, you know, and then 3, 4, and 5 roughly matching with, you know, Panther, Tiger, and Leopard.
John:
Yeah.
John:
And 6 should have been at Snow Leopard, but it wasn't because 6 brought even more features and more new stuff.
John:
It was definitely not a Snow Leopard-type release.
John:
So I still think we're in the early part of iOS's release cycle.
John:
Maybe 7 will be the first, or maybe 7 will be the...
John:
Right after 7, maybe 8 will be something that's more tame or whatever, but it seems like with all the rumors of 7 that it's not going to be a tame release.
John:
Even if it's just visual stuff, I think that will stand out in our mind.
John:
That's when they rejiggered the UI and rearranged the apps and all that business, but we'll see.
John:
I would say there's definitely no Snow Leopard.
John:
We haven't had a Snow Leopard in iOS yet.
Casey:
No, and the other interesting thing that somebody on Twitter pointed out, and I don't have this at reply handy, so I apologize to whoever you are, but they pointed out that none of us thought about Siri when we were trying to think of kind of marquee features on different iOS versions, and the three of us didn't even think about Siri.
Casey:
And I don't know what that says, but it's an interesting observation that
Marco:
obviously didn't cross my mind when we were talking about siri i just didn't say anything because it's like well you know siri i mean because it was because it was tied to the 4s as a device um mostly for marketing type reasons you know because it was tied to this device and that was the release it's like it was more like a feature of that phone and all devices from that point forward it was less of like a okay starting with ios 5 everybody gets this this cool thing
John:
Yeah, that's something they haven't done on the Mac.
John:
It's not like they roll out Time Machine and say, and if you want to use Time Machine, you've got to have a Mac that you bought this year, and that would not fly as much.
John:
And they pulled it off with the 4S as a differentiator, but it's why we don't associate it with, oh, that was the OS that had Siri.
John:
It's more like that was the phone that had Siri.
Casey:
Yep, fair point.
Casey:
Anything else on FU, follow-up, whatever we're calling it?
Marco:
I don't think so.
Casey:
All right.
Casey:
So one of the things I wanted to talk about today was, Marco, you finished, well, maybe not finished, but at least got to a stopping point for now on your PHP framework.
Casey:
And I didn't know if you had anything to share about that.
Casey:
And if not, I'm going to ask another probing question.
Casey:
But how did that go?
Marco:
I can't wait for the probing.
Marco:
Title.
Marco:
Now we have a kind of fake, kind of real show bot in the chat now.
Marco:
So with the PHP thing, so I've had this PHP framework that I've built.
Marco:
I mean, a long time ago, we built Tumblr with it.
Marco:
And before Tumblr, we built, David and I, David Karp and I built some client applications back when we were consultants before David decided to start Tumblr.
Marco:
So we had this PHP framework, and it's a basic MVC framework.
Marco:
And the reasons we wrote our own back then were that we had tried Rails, and we had tried Cake for PHP.
Marco:
And back then, this was in like 2006, we didn't, at least I didn't, and I convinced David, I didn't like all the behind-the-scenes magic that frameworks did unexpectedly.
Marco:
Some magic is good, and some magic is helpful.
Marco:
My theory was more that I wanted the framework to be more like libraries, and less like, at the time, what was trendy for, quote, frameworks, which is they would do so much for you, and so it was hard to tell, like...
Marco:
if you were seeing a certain header being set or a certain behavior or a certain filtering or certain bugs, it was hard to find where the heck that was coming from in the code.
Marco:
And this was especially a problem in Rails because of Ruby's mix-ins and that becoming especially trendy in 2006.
Marco:
So everyone was kind of overusing them.
Marco:
And so it was very, very... Much like categories in Cocoa, it was very, very hard to find the code you were looking for, to manage what was going on, because there was so much magic happening all the time with everything.
Marco:
So my theory was I wanted something that could provide helpful features like a library, but...
Marco:
where I knew everything that was going to happen and what was not going to happen.
Marco:
So it was very clear to me, okay, me as the person writing this action or this model, what is my responsibility, what will happen, and what won't?
Marco:
And so we wrote our own very basic framework with some lessons from Rails, some lessons from ourselves, some lessons from Cake.
Marco:
And we basically matured that into Tumblr, and as Tumblr went on, and then
Marco:
And it is BSD licensed, but it's not distributed anywhere.
Marco:
So our clients from before Tumblr, they all have a copy.
Marco:
A few programmers here and there have a copy.
Marco:
I have a copy.
Marco:
Instapaper is running on a copy.
Marco:
And the magazine is running on a copy.
Marco:
So it's this not really open-sourced framework, but it would be open-sourced if it ever actually got out legally.
Marco:
So what I did, when I left Tumblr, I forked it.
Marco:
And so Tumblr continued doing their own thing with it.
Marco:
and Tumblr did tons of changes to it because they had to because they grew like crazy, and they had to build in automatic sharding support and stuff like that, all sorts of stuff I've never seen.
Marco:
And with Instapaper, I didn't really have to do anything to it, so it mostly just sat there.
Marco:
And I exchanged a few things here and there, but I didn't really pull anything out, so it still had a whole bunch of stuff from halfway through Tumblr scaling that I had put in there.
Marco:
And it was also based on PHP 5.1 and 5.2.
Marco:
Even though we ran it mostly in 5.3, the late static binding support in 5.3 that was added, which makes static classes work in a useful way for the first time in PHP.
Marco:
I don't know why they didn't have that at the beginning.
Marco:
Anyway, that's a little too specialized for this show.
Marco:
I was able to modernize the framework.
Marco:
If I wanted to.
Marco:
But Instapaper's code base at that point was big enough that it was kind of unwieldy to do that.
Marco:
And it wasn't really ever worth my time to do that.
Marco:
Having just sold Instapaper, though, I wanted to start more web stuff in the future.
Marco:
And I wanted to have a really solid foundation for doing that.
Marco:
And I thought about using another language.
Marco:
But as I've discussed in this show before, much to many people's irritation...
Marco:
I don't think Ruby or Python really provide enough of a benefit over PHP that if you're already an expert in PHP that you really need to become an expert in one of those.
Marco:
I think you can pick any of those three, become an expert in one of them, and you're pretty well set.
Marco:
You don't really need the other ones unless you really want to learn a lot more languages for other reasons like personal development or market value or whatever else.
Marco:
But if you're short on time and if you don't really want to be learning tons of languages and you'd rather take one and master that one,
Marco:
I don't think you need to master more than one of those three.
Marco:
And I think the alternatives, things like Node, I would be looking at those in probably the future, but I think they're a little bit early right now.
Marco:
So I'd rather not go that way right now.
Marco:
So I figure, you know what, PHP is great for me.
Marco:
I know a lot of people hate it, but PHP is very good for me.
Marco:
I know it extremely well.
Marco:
And I know how to scale it.
Marco:
I know how to run it very cheaply and very easily with very little effort and very few 3 a.m.
Marco:
wake-ups for the sysadmin, which is usually me.
Marco:
And so I decided, you know what, there's nothing really inherently wrong with PHP that overcomes the barrier for me to master something else to this degree when I don't really want to be writing big web services as the only thing I do.
Marco:
If that was the only thing I was going to do,
Marco:
That would be fine.
Marco:
I would be very, very happy with it.
Marco:
And I would learn lots of different languages and pick the best one and really dive deeply into that one.
Marco:
But for me, the web service, and actually there's a great blog post by Brent Simmons that while I'm rambling on, you guys should read this and I'll talk about it in a little bit.
Marco:
I pasted the link in the chat.
Marco:
For me, making web services is really a supporting role to what I really want to do, which is kind of making whole products that are mostly apps.
Marco:
For me, Instapaper pretty much was that.
Marco:
The Instapaper web service was very low needs, and I devoted very little to it, for good and bad.
Marco:
Because what I really wanted to be doing was working on the app.
Marco:
And the app was the premier experience.
Marco:
Well...
Marco:
Whatever else I do in the future is probably going to be that same way.
Marco:
I mentioned in the past I have a few prototypes of things that I'm trying to figure out what I want to do next with, and they all have web components.
Marco:
But all the web components are relatively unimportant compared to the app.
Marco:
And so for me, it's not worth learning entire new web languages and mastering those platforms and learning the hard way how to scale them all and spend all that time and stress on that when I'd rather be putting that effort into the apps and just the website.
Marco:
I don't need the website to be my experimental playground.
Marco:
So, anyway, I decided this was a great time to modernize my framework, because I had only the magazine using it, and the magazine's codebase is very, very small.
Marco:
So I thought, this is a great time to modernize it.
Marco:
What I really need, though, is a test app.
Marco:
And that way I can write the test app as I modernize it so I know what I'm breaking, I know how I'm breaking it, I know what it needs to be.
Marco:
And I can play with the APIs as I'm making them and as I'm changing them to see what works, what doesn't, what ends up being more or less elegant than I expected, etc.
Marco:
And my goal here is also to open source this framework now.
Marco:
To finally make it so incredibly different from what Tumblr is running that...
Marco:
I mean, legally, I could have done it already, but I was always a little afraid to release the framework that runs Tumblr.
Marco:
What if somebody finds some security problem and exploits it against Tumblr?
Marco:
I would really not feel good about that.
Marco:
So I was always very afraid about that.
Marco:
I'm less afraid when it's my own thing.
Marco:
I at least know that I'm willing to do that to myself.
Marco:
I'm less happy about doing that to somebody else, especially somebody as big as Tumblr.
Marco:
Yeah.
Marco:
So I thought, I would love to open source this, and I would love to modernize it, and I would love to also write this sponsor tracking system that I've been meaning to do for Marco.org for months, because the way I track my sponsors for Marco.org is this giant spreadsheet that sucks, and it's so...
Marco:
It's so human-based and error-prone, and it always freaks me out.
Marco:
What if I publish something from the wrong day or the wrong week?
Marco:
What if I think a sponsor hasn't paid, but they have, or vice versa?
Marco:
What if I type a number wrong, just a typo, and something is really messed up?
Marco:
So I needed something better than a spreadsheet to manage that.
Marco:
I also, once we started this show and we started having sponsorships for this show, then I had to manage, okay, well, we sell sponsorships for this.
Marco:
That's another property to sell sponsorships for.
Marco:
So initially, it started out as just another table in my spreadsheet that was very similar to the first table.
Marco:
But then we have to build on things like, we all split the money that comes in, so I had to build in
Marco:
how to, you know, I take the money in and I have to pay you guys out your portions of it.
Marco:
So I have to, you know, that's another layer on top of this that is error prone and could be messed up and starts really pushing the boundaries of what spreadsheets can do gracefully.
Marco:
I mean, they can do it in many non-graceful ways, but what they can do gracefully is, you know, this is kind of a bad thing for them.
Marco:
And then what really killed it is I wanted all three of us
Marco:
to be able to log in and look at sponsors and sell sponsorships.
Marco:
And so we needed multi-user access.
Marco:
And then you can go Google Docs, but then it's just, the more layers you add to this spreadsheet, the crappier that solution becomes and the more likely it is, like exponentially more likely it is, that something will go wrong at some point, and that's really bad.
Marco:
So I decided, let's build this system.
Marco:
And that's a perfect test case app for my new framework, or my new version of this framework, which is almost completely rewritten, turns out.
Marco:
And it's way smaller than the old framework.
Marco:
And my goal is to open source both the framework and this example project of my invoicing system fairly soon.
Marco:
So, do you guys have anything to say after that massive tirade?
Marco:
We're like 23 minutes in now.
Casey:
I do, but I'll give John a chance because I have a comparatively much shorter monologue that I'm queuing up.
John:
Well, I'm looking at your notes, so I know what you're going to ask him, and it's exactly the same thing that I'm going to talk to him about.
Casey:
Oh, yeah, the notes.
John:
I should open that up.
Casey:
Go ahead and steal my thunder.
John:
So go for it.
John:
Yeah, the notes that apparently Casey and I use, but Marco shuns.
John:
Oh, I got it.
John:
Sorry.
John:
It was in my Chrome ghetto.
Casey:
Yeah, that's where mine is.
Casey:
So since I'm talking, I will go ahead and ask by telling a very brief story.
Casey:
So a few days back, Marco sends John and I an email saying, hey, this is up.
Casey:
Here's where you can go.
Casey:
And I load the URL and all I see is a text form and a button.
Casey:
And the text form says, give me your email address and then log in.
Casey:
And I think to myself, well, this is weird.
Casey:
I haven't created a user account or knowingly anyway.
Casey:
I haven't given him a password of any sort.
Casey:
What's going on?
Casey:
So I enter my email address, I hit the button, and next thing I know, Marco's fancy sponsorship tracker says, okay, look at your email, you'll get a login URL there.
Casey:
And so sure enough, instantly I look at my email and there's a...
Casey:
email from marco's fancy app thing then it says here click this link and you can get logged in and that's exactly what happened and so it was a very different and interesting way to handle user authentication and authorization i always get the a's wrong but handle logging in without me ever giving him a password so in summary my question to you marco and john feel free to jump in is why do you hate passwords so much
John:
Well, he does the same thing on the magazine site, which I'm assuming, was that the first place you did this?
John:
Yeah.
John:
When I saw it, I immediately knew that you were doing the same thing as the magazine site, or it seemed like it.
Marco:
Yeah, most of the same code, too.
John:
Yeah, and I didn't like it either.
John:
I complained to my wife that he's doing this thing with no passwords again.
John:
No, I...
John:
One of my first interactions I had with you and your products online was when I first signed up for Instapaper.
John:
And back then, you didn't need a password for Instapaper, which was awesome.
John:
And I love it.
John:
And not like this.
John:
You just literally didn't need a password.
John:
So for the first, whatever it was, year or two years or however long you let us not have passwords, anybody could have seen my Instapaper links.
John:
Because I didn't care.
John:
I wasn't putting anything secret there.
John:
I just loved not having another password to remember.
John:
I just had to remember my username.
John:
And there was my Instapaper.
John:
And I didn't care.
John:
It was totally insecure.
John:
Fine.
John:
Go ahead.
John:
And I guess someone could have used that to start adding stuff to my Instapaper.
John:
And then you had the option to add a password.
John:
So if someone found it and started abusing it and erased all my Instapaper links, I'd be like, all right, fine, I'll add a password.
John:
So I'm all thumbs up for not having a password.
John:
But thumbs down for every time I log in, sending me an email with the link.
John:
Because first of all, when you first did this in the magazine, there was mail backlog.
John:
And nothing is more frustrating than wanting to get into something and not being able to because your mail hasn't arrived.
Marco:
Oh, yeah, that was a one-time issue.
John:
Even when it's not your fault, say it's on the receiving end, it's email storing forward.
John:
It could be not in your control that I'm sitting here banging on my refresh button trying to wait for my thing to come.
John:
And the second thing is, this is really mostly iOS's fault, but it's the environment you're in.
John:
I use the Gmail app on iOS, and when the email comes with the link on it,
John:
I can't tap that link because then that will open in the Gmail app's built-in browser, and I'll be logged in there in some sort of right-hand side navigation pane to the Gmail app, but I'm not logged in in Mobile Safari, and that link is now dead because I think you kill them off after they get used because I don't think an hour had passed, right?
John:
And so now I have to go back to the site, make an email me another link, remember to tap and hold on it and copy the URL, then go to Mobile Safari, then paste that into a thing, and then use it, and then I'm logged in over there.
John:
So I do not find the user experience of this passwordless thing agreeable.
Casey:
Well, it's funny because I actually don't have any problem with the passwordless idea in principle.
Casey:
But I, too, was like, wait, I have to wait for a darn email to come in.
Casey:
And in retrospect, thinking about it more, I actually think, by and large, this isn't a bad setup.
Casey:
And it strikes me as a – and I'm not a security-minded, tinfoil-wearing nutjob – but it strikes me as though it's a pretty good setup.
Yeah.
John:
It's the same as using a password because if you have access to my email account, passwords don't matter.
John:
And if you have access to my email account for this thing, passwords don't matter.
John:
It's not a security thing where it's any lesser or more secure.
Marco:
Well, it is in one way.
Marco:
And that is that you can't guess somebody's password because they don't have one.
Marco:
The only way to log in is by having access to their email.
John:
You just guess the password for their email address.
John:
I mean, you're just moving, you know, moving the password they have to know from your site to their email provider.
John:
That's true.
John:
But that is a little bit better, though.
John:
Especially since so many emails have two-factor now.
Casey:
Exactly.
Casey:
It took the words right out of my mouth.
John:
If you support Google login and I can use my existing two-factor to get into your site, then there you go.
Marco:
Yeah, well, oh well.
John:
It doesn't matter because it's a sponsorship website.
John:
But I've been thinking about it because everyone always wants to solve the problem of identity on the web because it's such a pain in the butt no matter what you do.
John:
And there's just no good solution.
John:
Everything has trade-offs, and the trade-offs for this one are just a different set of trade-offs.
John:
Right.
John:
But I find it particularly, especially for the magazine.
John:
I'm subscribed to the magazine.
John:
I get it in the iOS app.
John:
Occasionally, I want to read it on the web thing, and inevitably, I somehow find that I'm using a browser on a machine that doesn't have the right cookie, and I've got to go through the email thing.
John:
That tiny delay makes me unhappy.
John:
I'd rather have it auto-fill my password or just remember what my password is or use some other means that I can get myself logged in to read the magazine articles because...
John:
It's perpetually telling me, sign up for the magazine, subscribe.
John:
You should do it.
John:
No, I do.
John:
Just show me the article.
John:
It keeps you logged in for like a year.
John:
I know, but I don't know.
Casey:
What's going on?
John:
At work, I'm always hosing my cookies, right?
John:
Because you're doing web development, and I have seven browsers, and I'm constantly wiping cookies and doing private browsing.
John:
I don't know.
John:
Maybe I just have to spread.
John:
Maybe it's like two-factor where I have to have some sort of ramp-up period where I spread the little...
John:
you know the authentication tokens to all of my browsers and all of my cookie jars as we called them back in the day uh but it hasn't happened yet okay casey
Casey:
I mean, to be honest, I don't have a whole lot to add.
Casey:
I don't mind it nearly as much as John does, but I'm not nearly as much of a curmudgeon apparently.
Casey:
But I mean, I think it's interesting because we all hate passwords.
Casey:
We all want them to go away.
Casey:
But obviously nobody's really cracked that knot on what the right answer is.
Casey:
And for me, since this is a site that I'm not going to look at every single day,
Casey:
I don't find it as egregious a pain in the butt.
Casey:
But with that said, if it was something that I use frequently, I think I would find it just as annoying as John does.
Marco:
Yeah, I think it's a very hard problem.
Marco:
I never did this on Instapaper.
Marco:
The magazine was the first place I did this publicly.
Marco:
And the way it works, in case someone is still behind on this, it basically treats every login like a password reset.
Marco:
where you say you want to log in, type in your email address, and it emails you a link with a single-use hash on it, and then the app trades that hash for a login token, and then you're logged in.
Marco:
But it's like a password reset where you don't even set the new password, you're just logged in.
Marco:
And it's interesting.
Marco:
It solves – very similar to Instapaper's original no-password accounts at all.
Marco:
It solves some problems, but it creates other problems.
Marco:
And so I'm not sure if it's a net win in general.
Marco:
I think you can look at where I've used it here, which is kind of like an admin panel.
Marco:
I think admin panels, any kind of intranet type thing where security is needed.
Marco:
Anything like that where it's not the general public having to log in and you don't have a ton of people using the Gmail app on their phone and not knowing how to copy links and stuff like that.
Marco:
Situations like that...
Marco:
I think it's a great solution.
Marco:
I will probably do this for every admin panel that I ever do again because it's so much more secure than just having some kind of admin password up there.
Marco:
It's just great for that.
John:
What makes you think it's more secure?
John:
Because I can see how it's better from your perspective as the person running the service because you don't have to store passwords.
John:
And if you don't have to store passwords, that means the pressure is off of you to keep those passwords secured and all that business or whatever.
John:
But...
John:
I don't know if that's better for the people who are using the product because as far as they're concerned, it's your responsibility to make sure the encrypted versions of the passwords don't get out and make sure you use bcrypt on the slowest setting or whatever the hell crazy stuff you're supposed to do.
John:
I think this definitely makes it better for you writing the service, but as a user of the service, I don't see any security advantages from my perspective.
John:
I just see the slowdowns.
Marco:
Well, I think the security advantage is that my service now becomes as secure as your email, which is probably more secure.
Marco:
Given that most people use webmail for their own email addresses, not for work, but most people use webmail, and most webmail services are really locking down their security really well.
Marco:
I think that's...
Marco:
I don't think it's that bad of a thing to rely on because as you said, most things are only as secure as your email at most anyway because you can always do a password reset.
Marco:
So if I were to do any kind of set your own password for this...
Marco:
Even if I would add two-factor or something, if I have some way to use your email address as a reset mechanism, for the most part, unless I have my own two-factor thing, which is possible, but I think that would be even more overkill.
Marco:
If you don't like having to wait for an email and click a link, you're going to hate two-factor.
John:
But if you're going to delegate authentication to someone else, like you're delegating to our email provider, why not literally delegate authentication to someone else and do what those sites do?
John:
Either you pick one that you decide to be blessed, which is fine for an admin site, or you have three buttons that say log in with your Facebook ID, log in with your Google ID, log in with your OpenID.
John:
In all those cases, you're delegating the authentication to an external service, but then you don't have to deal with it at all except for writing the implementation of those things.
John:
And for an admin page, you would say, okay, well, you can't log in with Facebook, and you can't log in.
John:
Well, with OpenID, but you can log in with Google, you know, like, because you can you can limit your options there.
Marco:
First of all, this is simpler and easier for everybody.
Marco:
Because, see, the big the big problem with those login with Facebook or Twitter or whatever, with those things and with OpenID, which is itself a massive train wreck of normal person usability, even for geek usability, OpenID is a mess.
Marco:
But, I mean, look at Stack Overflow.
Marco:
They were OpenID only for the first few years of their life.
Marco:
But they worked out the kinks.
Marco:
Well, but the problem was, even with that extremely nerdy audience, it was still a major problem.
Marco:
It caused tons of support.
John:
I think the environment has gotten a lot better.
John:
OpenID?
John:
Doesn't the Teespring site use OpenID?
Marco:
It offers it as an option, but I just created my own account.
Marco:
Here's the major problem with those kind of things, where you can say log in with OpenID or with Facebook or with Twitter.
Marco:
The main problem is that every time you go back to that site, you have to remember which one you logged in with the first time.
John:
Well, that's what I was saying.
John:
Just offer one.
John:
Like, for an admin site, you just pick one.
Marco:
Well, that's what I do.
Marco:
It's your email address.
John:
I mean, I don't see how it's different.
John:
When I go to the Teespring site, I click the button that says Login with Google, and I don't have to do anything further because I've already done the thing once.
Marco:
When I go to your site, every time I have to click and go get the email, and you're like, well, it should still have your cookie, but I don't... But when you go back to the Teespring site in a year, and you haven't used it in that entire year, and you go back here, and it's, oh, what did I log in with?
Marco:
Which one was it?
Marco:
It's a problem, and that creates support emails like crazy.
Marco:
You would not believe how much support that generates when you have that kind of option.
John:
But again, for an admin site, support is not an issue.
Marco:
Well, true, but I would also argue that for an admin site, there's really no benefit to doing that your way instead of my way for an admin site, because either way, you're like...
Marco:
you're likely to hit a small delay sometimes either way.
Marco:
If you're saying log in with my Google account, yeah, it might be one click, or you might have to re-log into your Google account because it might have been too long since you've last logged in, or it might want to re-authenticate you.
John:
But the Google thing has some sort of timeout.
John:
If you're making your cookies last for a year or whatever, that means anyone who finds them, it doesn't matter.
John:
But if I log in, I have to remember that if I log in on a strange machine, I have to make sure that I get rid of that so that that person can't perpetually log in as me because now they've got the cookie.
John:
You know what I mean?
John:
Whereas when you're delegating entirely to an external service, all the management of revoking access and timing out and whatever is on the external service, right?
Marco:
Yeah, but also, like, the extra level of complexity of dealing with someone else's service for this, it adds almost as many annoyances and flaws and support headaches as doing it the way I'm doing it with emails.
John:
But that's what I'm saying.
John:
So what has it been like for the magazine?
John:
Because, like, this is, the Mint site is a bad example because there's three people using it.
Marco:
Right.
John:
Whatever.
John:
But it's like, for the magazine, there's many, many more people using it.
John:
I guess you don't have anything to compare it to because you haven't implemented, like, you know, log in with your Google...
Marco:
account as well but what is that what has that been like for as you mentioned you mentioned the copying and pasting from the gmail app or whatever is that just because i mentioned it or do you actually no just that's the third of it actually i should probably use gmail at some point in my life but oh well um no with the magazine it's it's been interesting um
Marco:
I'm not sure I would use it again for a big consumer-facing thing.
Marco:
At least not yet.
Marco:
Because the main problem is that when you have a username and password...
Marco:
you can enter those no matter where you are, no matter what app or context you're in, you can enter those immediately.
Marco:
As you say, you can enter those and not have any kind of delay and just be logged in.
Marco:
As long as you know the password.
Marco:
And yeah, there's people like us who use 1Password and generate long strings of garbage, so for us it's a little bit more complicated.
Marco:
But most people don't do that, unfortunately.
Marco:
So...
Marco:
The big problem is, first of all, you're tying something to email delivery, which, similar to tying something to someone else's account, there are opportunities for that to go wrong or to be delayed.
Marco:
And email delivery can be somewhat assumed to occur.
Marco:
You can generally assume that an email will usually get there.
Marco:
There are, of course, complications there, but usually you can say an email will get there.
Marco:
What you can't guarantee is that an email will get there quickly.
Marco:
Because there's things like gray listing and all sorts of weird anti-spam measures and server configurations and everything that will frequently delay a message by like a half hour or three hours from the first time it's hearing from you or something.
Marco:
So that becomes harder when you say, all right, log in, click here, and you'll get an email in two seconds.
Marco:
Well, that's great if it comes in two seconds every time, but it doesn't always.
Marco:
It comes in two seconds for most people, and then there's like the 1% that it doesn't come in two seconds for, and they get upset.
Marco:
and they email your support, and there's really no way for you to do anything about that quickly.
John:
And they keep entering their email address and clicking the button again and again, queuing up seven emails.
John:
Which keeps invalidating their previous one.
John:
Right, exactly.
John:
And then they try to click the third one that came, not realizing that it was invalidated when you sent the eighth one.
Marco:
Exactly.
Marco:
So, you know, it's not perfect in that regard.
Marco:
And also...
Marco:
This was actually one of the last Build and Analyze episodes.
Marco:
I talked about when I made the magazine how with the goal of simplicity, I wanted it to have no settings in the app.
Marco:
There's no setting screen.
Marco:
To have everything just be available in the interface with no gear icon with a setting screen on it.
Marco:
I didn't want some big long list of checkboxes or whatever.
Marco:
I just wanted to be very, very simple.
Marco:
And the problem was that to avoid having a settings screen, I had to make other bad design decisions, like how to log out from Instapaper if you logged in to send stuff to it.
Marco:
There were other decisions I had to make that were bad decisions in order to support this one thing I thought was a good decision.
Marco:
And so the passwordless login system that uses email has a few of those things.
Marco:
There's a few weird little stupid things that I had to do to make that work that are bad design decisions, even though the email thing I think is overall a good one standing on its own.
Marco:
So one of those things is when you want to sync your account between the app and the website on your iOS device.
Marco:
Or when you want to sync your account between the app and the website regardless of where you want to be browsing it.
Marco:
Like if you subscribed in the app and you want to browse it on the website on the desktop.
Marco:
Or if you subscribe in the website and then you want to read it in the app.
Marco:
Communicating between the browsers and the website and the Apple purchase thing in these three different places when you have a password would be easy.
Marco:
It would just be, enter this username and password in the other place, and you're logged in.
Marco:
Done.
Marco:
The way I do it, though, since there's no passwords, is for the app to register its subscription with the website, I have the app
Marco:
compose an email message with an attachment that encodes a bunch of data and then it sends an attachment to my server and the server associates it with the email that sent it which has its own set of problems like well what if the email that you sent that from is not your primary email address like there's other problems with that
John:
Yeah, I think I did that a few times.
John:
I was very confused on launch because I don't use – the email address I use for signing up for web things is different than the email address I use as my iCloud app ID.
Marco:
Exactly.
Marco:
I wouldn't say that's a common case, but there's certainly enough people who do that that it's problematic if you don't support that in the way they expect.
Marco:
And so there's that issue, going that way.
Marco:
And in the other direction, I would log into the website on your device and open this link that I'll mail to you, and then it'll send you the magazine app colon slash slash garbage URL to open up in the iOS app to associate it in the other direction.
Marco:
And that's kind of ugly and can have some of its own problems as well.
Marco:
So...
Marco:
I had this technical need to associate these accounts between these two places, and passwords really would have made that a lot easier.
John:
Well, as soon as Apple comes out with the web service APIs for iCloud authentication, you'll be all set.
Marco:
We'll talk about that after the first sponsor.
Marco:
But yeah, and so I think overall, I think the patch with the system, it's interesting.
Marco:
And that's why I did it, because it's interesting.
Marco:
I do think I'm going to keep it for admin panel type stuff.
Marco:
I don't know if I'm going to launch anything else with that as the main front-end thing.
Marco:
Because...
Marco:
in fact if people were if this was like 2005 still and most people were still doing everything on their computers uh and you were logging into a website that would actually make way more sense and it would be fine and i would probably do it no question now with everyone doing things on all these different types of devices with all these different like sandboxed siloed apps and everything and everything's running full screen there's no good multitasking on ios like
Marco:
or no good interact communication.
Marco:
There's all these problems that actually now the system is less practical than it would have been in 2005.
Marco:
And so I don't think I'm going to do it again for the main login for something.
Marco:
And also another problem is that it doesn't work the way people expect.
Marco:
And because people are used to username and password or email and password, they're used to that.
Marco:
When you put something up there that they don't expect, even if it's simpler to you, in your mind, even if it's simpler,
Marco:
they're thrown off for a second.
Marco:
Like, wait a minute.
Marco:
How do I do this?
Marco:
Where do I put the password?
Marco:
Like, it slows people down, and people make mistakes, and they question themselves, and they doubt themselves, and that ultimately can make all of your goals worse.
Marco:
Like, maybe they don't finish the sign-up, or maybe they don't finish their shopping cart purchase or whatever.
Marco:
So it's a hard call if you want to deviate from the norm on something so simple as, how do you log into your site?
Marco:
that you should use caution if you're deviating.
Marco:
On the plus side, I have gotten almost zero support emails for password-related or login-related anything.
Marco:
The problem is, you know, if you can't figure it out, you probably will just give up.
Marco:
But, you know, obviously I have no password reset requests, which any support person can tell you.
Marco:
That's probably the most common request, no matter how prominent you make that link of forgot password, click here.
Marco:
What if they type their email address wrong?
Marco:
There's so many problems.
Marco:
I don't get any of those for the magazine, which is awesome.
Marco:
So it does save support by a dramatic amount, but there are other problems with it that will give me pause for using it in certain contexts.
Marco:
Anyway, this episode, our first sponsor today, is Mac Mini Vault.
Marco:
Go to macminivault.com slash try.
Marco:
This is pretty cool.
Marco:
Mac Mini Vault, they're basically a Mac Mini co-locator.
Marco:
And they've been co-locating Mac Minis in their data center since 2010.
Marco:
And the guys there have been in business since 1995.
Marco:
That's 1,995.
Marco:
Running ISPs and hosting services.
Marco:
So they have a giant cabinet and they wire it to house a whole bunch of Mac minis.
Marco:
And all the level of efficiency and volume they're able to place your Mac mini in a data center for much less than a standard co-location would cost.
Marco:
Their plans start at just $30 a month.
Marco:
And you can use the Mac Mini for pretty much anything you can think of.
Marco:
I mean, you know, it's a Mac.
Marco:
You have control over it.
Marco:
You can do whatever you want with it.
Marco:
You can use it as part of your development workflow for development and testing.
Marco:
You can even use it for web hosting, file storage.
Marco:
And if you want, you don't even have to use Mac OS X on it.
Marco:
They'll even load Windows Server on it or Linux if you request that.
Marco:
And, of course, you can access this Mac Mini from anywhere on the Internet.
Marco:
And so you have all the flexibility that your own server provides.
Marco:
You get a one gigabit per second network connection.
Marco:
The data center is redundant and secure, and there's helpful engineers on staff, as well as free hands-on hours.
Marco:
And there's no charge to diagnose and redeploy machines during the free hands-on hours, which is pretty cool.
Marco:
so you can send in your own mac mini or you can buy one directly from them and they even have rental options you can rent a mac mini so it's a lot like renting you know a dedicated server somewhere um you know low cost entry there it's fantastic so anyway uh and they also have i was really impressed i was browsing their stuff they have uh you can you can add uh extra third-party ram or like a samsung ssd that's way bigger than apples and way cheaper so they have and they'll install that for you if you if you buy the mac mini through them
Marco:
That's pretty cool that you can actually deck out a pretty nice machine there for less than what Apple would charge for the extras.
Marco:
Anyway, visit MacMiniVault.com slash try.
Marco:
You can start a free demo today or you can sign up for an account.
Marco:
Use the promo code ATP50.
Marco:
That's ATP50 for accident on a podcast, 50% off, which takes 50% off the co-location fees for the first three months.
Marco:
Great customers there, including The Meteo, the people who make Instacast.
Marco:
They host their backend thing there.
Marco:
And Crashlytics, the big, powerful, and lightest weight crashing report solution, which is a previous sponsor of my site.
Marco:
They use Mac Mini Vault as part of its testing and development environments.
Marco:
That's pretty cool.
Marco:
They have like 700 Mac Minis now, over 900 pre-wired slots for the future.
Marco:
They are well set to expand greatly with all of you going and creating accounts there.
Marco:
So go to macminivault.com slash try, start a free demo, and use our promo code ATP50 to get 50% off.
Marco:
Thank you to Mac Mini Vault for sponsoring.
John:
50%.
John:
That is the new winner for largest percentage off of a sponsor of this show, I think.
Casey:
50% for the first three months.
Casey:
I was about to comment as well.
Casey:
Good for them for really showing they mean business.
John:
I wonder if the existence of the Mac Mini contributed to Apple's decision to discontinue the XServe.
John:
Oh, I definitely did.
John:
Like we have Accidental Tech Podcast.
John:
They have accidental server hardware.
John:
Yeah.
John:
Because I don't think they made the Mac Mini thinking, this is going to go right in the data center.
John:
But as soon as they made a machine in that shape, people were like, I'm sticking 100 of those in 2U rack.
Marco:
I kind of feel like the Mac Mini, you know how when Steve Jobs introduced the Motorola Rocker phone, that terrible iTunes phone that came out before the iPhone?
Marco:
Yeah.
Marco:
And you could tell when Steve introduced that, and Gruber wrote about this a while ago, you could tell he just really did not like it.
Marco:
He did not like the product.
Marco:
He did not like that it had to exist.
Marco:
The market was demanding something like that, and so they made it kind of reluctantly.
Marco:
And he just kind of shat it out there and was okay with it.
Marco:
I think the Mac Mini was kind of like that for him.
Marco:
I don't think he gave a crap about the Mac Mini.
Marco:
Obviously, it's a very low priority for Apple most of the time.
Marco:
They hardly ever update the thing, even when the other things get updated with the same CPUs.
Marco:
It's obviously a low priority, but they keep it around because they probably do sell a good number of them.
Marco:
But it's always kind of seemed like...
Marco:
This product that they reluctantly keep in their lineup because people do love it way more than Apple seems to.
John:
Well, Jobs was probably sore about the cube thing still.
John:
And he's like, you know, I made this machine when it was much better looking and you guys didn't want it.
John:
But whatever.
John:
Here you go.
John:
It's aluminum now.
John:
It's small.
John:
It doesn't have the cool glass.
John:
Still $800.
John:
Here you go.
Casey:
Enjoy it.
Casey:
The big whiners.
Casey:
Exactly.
John:
But it's much cheaper.
John:
It's true.
John:
It's one of those products he didn't seem to have super-duper enthusiasm about.
John:
I mean, that's the weird thing.
John:
If the company is not enthusiastic about a product, but a certain subset of the customers are, and it's very clear that a certain subset of customers is really enthusiastic about the Mac Mini, people who want to stick them in data centers.
John:
And even I've seen people who just,
John:
Mac users who have lots of Macs,
John:
If you just need another Mac to just be an extra machine for back when Xcode still... Does Xcode still support distributed compile?
Marco:
I haven't tried it with the new versions.
Marco:
I don't know.
Marco:
It was always slower for me.
John:
Having a Mac Mini in the corner to be a media machine and I just need another Mac for this other room so I'll just get a Mini or using it as a server to attach your storage to and stuff like that.
John:
So I see a lot of enthusiasm for that little machine even though Apple, like you said, does not seem to be that into it.
Marco:
yeah but i mean but you know everyone always thinks myself included you know we've thought a number of times in the past we thought oh this is going to be the year they killed a mac mini and it never gets killed it's still it's still sitting there even when it goes like i mean what's the longest it's gone without an update like two years maybe without like it doesn't go down in price either like when the new one comes out it's like up still really expensive in fact usually it goes up by 100 bucks
Marco:
yeah uh yeah but it's funny i haven't for a while too like because as you say people use them as like as servers all the time there's there's so many little things you could do with them um so anyway thanks to them for sponsoring macminivault.com um so i i mentioned before the break i wanted to talk about this article by brent simmons do you guys get a chance to read it while i was rambling about various stuff before
Marco:
i read it during the day marco of course i had at least scanned it earlier okay so it's called uh 30 minutes to sync on inessential.com brent simmons's web blog and we will i said web blog and we will post it uh in the show notes i i never say web blog and uh someone just made fun of glenn for writing that so you probably pick that up in a twitter stream i yeah but he glenn also says capital web space site and i don't you know i don't do that glenn says a lot of things
Marco:
Oh, man.
Marco:
Anyway, so on... At least vlog didn't catch on.
Marco:
We can at least be happy about that.
Marco:
I should also... You know what?
Marco:
Before we talk about... Now that we're talking about stupid words for our new media crap that we invent as nerds, I've heard a lot of discussion recently about the word podcast.
Marco:
I heard...
Marco:
There's this great podcast called... I think it's called Next Market.
Marco:
I'll have to look this up.
Marco:
And this guy, he's doing interviews about people in the podcasting world talking about the business of podcasting.
Marco:
And Leo Laporte famously does not like the word podcast and uses the word netcast to describe what he does.
Marco:
Dan Benjamin has said he doesn't like it, but he still uses it because... Although he tries to do internet broadcasts and stuff.
Marco:
There's been a lot of... A lot of people who are big in the podcast world have tried to...
John:
use a different word and i think what do you guys think of the word podcast i think it's a fair it's fairly terrible and i think apple was super duper lucky that it caught on the way it did because like apple didn't coin it you know it but it was so tied to apple's product the ipod there was like a happy accident like oh i guess we own this space our name of our product's practically in it
Casey:
I've never been bothered by it.
Casey:
Not to say you guys are wrong, but it's never, ever, ever bothered me in any capacity.
Casey:
And I'm not the kind of person that says, you know, Tumblr log over Tumblr, or I might say photocopy, I might say Xerox, I might say tissue, I might say Kleenex, I never get pedantic about any of those sorts of things.
John:
See, podcast is a lame word, though.
John:
Like I can see why people who broadcast like because it pigeonholes you into like you make things that people listen to on iPods or similar devices.
John:
And that is a narrow definition of what could possibly be the future of broadcast, the future of audio programming.
John:
You know what I mean?
John:
Like that.
Marco:
Well, but for a while, for a while, blog was that kind of word.
Marco:
For a while, saying that if somebody else told you that you wrote for a blog, that was an insult.
John:
But blog has a useful definition.
John:
Podcast doesn't.
John:
Blog, if you look up on something that tries to define a blog, it's not going to ever call the New York Times a blog because it's not like a personal, single-voice publication, time-separated, linear stream of time-separated posts, not...
John:
divvied up into sections through multiple authors or whatever.
John:
A blog is distinct from just a website or writing on the web, whereas podcasts is all-encompassing.
John:
If you make an audio program that's not broadcast over analog radio but distributed through the internet instead, it's like, well, you have a podcast.
John:
And I think that's why people don't like it.
Marco:
See, I think podcasters don't like it.
Marco:
I know people love podcasts about podcasts.
Marco:
Podcasters don't like it because of the pretty bad connotation it has of being low quality.
Marco:
Because everyone's heard bad podcasts before recorded by some people talking into their built-in laptop mics for three hours about nothing.
Marco:
Well, I guess that's not that far from what we're doing.
Casey:
Okay.
Casey:
I'm glad you called yourself out on that.
John:
You think that's why?
John:
Maybe we should get someone on here who objects to it, who's a broadcaster by trade, like Leo or whatever.
John:
I mean, kind of are we now?
John:
Well, but is it because it's low quality?
John:
Because radio has terrible low quality stuff, like the guy who's on at 2 a.m.
John:
or the college kids who are broadcasting their student station.
John:
Radio is filled with terrible programming.
John:
If you don't believe me, like I said, just wake up in the middle of the night and turn on the radio.
John:
There will be something being broadcast on many frequencies, and it will not be high-quality content.
John:
But radio doesn't get slammed for that.
John:
Like, oh, that's okay.
John:
It's an amateur who... I mean, granted, because the airwaves belong to all of us and are controlled by the government, and they divvy out, blah, blah, blah.
John:
You still have student radio stations, whereas on the Internet, it's even more wide open, and maybe...
John:
Maybe the total volume is higher.
John:
Therefore, the percentage of crap is higher as well.
John:
But I really think it's because it seems like it's as if every single website had to be called a blog.
John:
And the New York Times didn't want to be on the web because they knew they were not a blog.
John:
But by putting something up, come to the New York Times blog.
John:
And it was like, no, it's distributing written word online.
John:
We're not a blog.
John:
And even though podcasts doesn't have the same connotations, it does...
John:
It does lessen it.
John:
Like you wouldn't think – if you fancy yourself as the audio equivalent of the New York Times, you don't want someone calling you a podcast.
John:
That's my impression.
John:
Go ahead, Casey.
Casey:
I just – I feel like somebody linked on Twitter today to some – I think it was a blog post actually where somebody said that nerds ruin everything.
Casey:
And I didn't even read it because I could tell or I feel like I could tell the gist of it within the first couple sentences, which was basically like people who are really passionate about things end up overanalyzing and ruining them entirely.
Casey:
And I kind of feel like that's what we're doing when it comes to the word.
Casey:
Yeah, exactly.
Casey:
When it comes to the word podcast, I don't see why it's that offensive.
Casey:
Again, I'm not saying I'm right.
Casey:
I'm not saying you're wrong.
Casey:
I don't see why it's so bothersome.
Casey:
It's just a word to describe something.
Casey:
Candidly, I have never really associated that term specifically with iPods.
Casey:
Maybe that makes me odd or different or weird, but I don't associate it specifically with iPods.
Casey:
Just like one of you guys said, I just associate it with an internet-based radio broadcast.
John:
Well, that's what happens to any word.
John:
You use any word and it just becomes the thing it is, right?
John:
But these people who have objections, their objections were at the early stages.
John:
I don't know if they're now.
John:
I mean, I guess they're still doing it now.
Casey:
They are.
John:
They're still going with netcast now because that's just what they do and that becomes – it's almost like the netcast slogan from Leo has almost become like a signature brand of his network specifically because as far as I know, he's the only one using it, right?
Marco:
Yeah, I think if anybody else said we're doing a netcast, they would think – like the fans would think he was ripping off Leo.
Yeah.
John:
Right, exactly.
John:
So it didn't work out.
John:
But the genesis of that was in the beginning.
John:
They're like, oh, I don't want to be thought of as just this thing that people put on iPods because the things that coin that term are not what I'm doing.
John:
I want to be a broadcaster and I want to have it.
John:
And then at a certain point, it just continues.
John:
Yeah.
John:
If you teleported Leo Lepore from the world before podcast to now and he wanted to start one, I think he would be less reticent to call what he does a podcast.
John:
I don't know.
John:
Maybe he would just be stubborn.
Marco:
I'm kind of with Casey on this.
Marco:
I think the word is a stupid-sounding word, no question.
Marco:
But podcasts have two main problems.
Marco:
And one problem, as Dan said in his interview on something else, I got to link to it.
Marco:
I forgot the name of it.
Marco:
Dan said earlier this week how one of the biggest problems with podcasts is the barriers involved in getting to them.
Marco:
If someone has never listened to a podcast before and hears about them and wants to get into them, then they have to...
Marco:
First of all, someone has to tell them about them because no one knows about them.
Marco:
In the rest of the world, nobody knows what the crap a podcast is.
Marco:
Or at least, for the most part, it's pretty much out of the mainstream vocabulary.
Marco:
And...
Marco:
And so you have to find an app.
Marco:
You have to have a smartphone, for the most part, or listen on your computer, which sucks.
Marco:
If you have a smartphone, you have to find an app to download or to play podcasts.
Marco:
You have to find the podcast within that app, and then you have to make time to play it, and then you have to hear it somehow.
Marco:
You have to put that audio somewhere.
Marco:
Maybe you'll be listening on headphones, but if you drive a lot and you want to listen in your car, then you need a Bluetooth connection or an oxygen cable or something like that.
Marco:
There's...
Marco:
Technically, accessing podcasts has a lot of barriers to entry right now.
Marco:
That's one problem.
John:
Everything is relative.
John:
We're going to the second problem.
John:
The reason podcasts are as popular as they are now is because the iPod lowered the barrier of the entry below some critical threshold beyond which it became possible to be a thing.
John:
Yeah.
John:
That's true.
John:
Because before that, it was like, forget it.
John:
Nobody's going to pull this off.
John:
And the iPod, in general, made it possible for people to take audio from the internet and put it in a context where they actually want to listen to it.
John:
So that was like the first hurdle.
John:
And Dan's dissatisfaction with the current one is like, oh, that's great and all.
John:
It made podcasts possible to be a thing that normal people can enjoy.
John:
But there's this next barrier of like...
John:
If you're interested in a television show, you're much more likely to say, hey, this cool new show I'm watching and tell your relative the name of that show with an expectation that they will successfully – and maybe a network – they will successfully be able to watch that show with no further help from you, right?
John:
Whereas if you tell them the name of a podcast and they never listen to podcasts, they're not going to make it.
Marco:
Yeah, that's true.
John:
So we are making progress there, but there's still the next leap.
John:
The next leap, we can see what it is out there.
John:
It's great that it's possible for people to do it on X scale, but we want to go like 10, 100 times easier.
Marco:
That's true.
Marco:
And to get there, that gets me to my second problem.
Marco:
The second big problem with podcasts is this connotation that they're low quality.
Marco:
But I think that's something that bloggers had to wait out, the internet had to wait out.
Marco:
I think that's something that every media has when it's new, that all the mainstream and the established media of the previous types all...
Marco:
assume or say or outright defame the new thing as being only for amateurs or inferior.
Marco:
Especially because a lot of times at the beginning they are inferior until people learn how to do them well.
Marco:
So I think
Marco:
I think the word podcast is fine.
Marco:
If we could pick a new one, that'd be great, but we can't.
Marco:
It's too late.
Marco:
And I think people like Leo who say netcast or who make their own alternatives, I think they're doing a disservice to the podcasting world by fragmenting this term.
Marco:
Dan sometimes will say internet broadcast or something like that, or even internet radio or internet radio shows.
Marco:
And I think the problem is that streaming radio exists, and that's something else.
Marco:
So like streaming radio, like shoutcast stations and stuff like that, or even radio-like services like Pandora, Spotify, and RDO, I think those distort the meaning.
Marco:
If you tell somebody, oh, you should really get into internet radio shows, they might think of those things instead of podcast.
Marco:
Podcast has a very specific meaning.
Marco:
that is a very large category that is very distinct from those other things and can't really easily be confused with them in the vocabulary.
Marco:
So I think we have this word.
Marco:
I think we're stuck with this word.
Marco:
And I think it's not that – people would call them amateurish no matter what you call them because they're new still.
Marco:
And I think it's only a matter of time, just like what happened to blogs,
Marco:
it's only a matter of time before that just becomes a normal word for people, and they know what you're talking about, and it doesn't always have that negative connotation.
Marco:
And it's happening more slowly with podcasts because the podcasting medium as a whole is not growing as explosively as blogs did, but it is growing more slowly.
Marco:
It still is growing.
Marco:
It still is seeping into the world and seeping into the mainstream.
Marco:
It's just, you know, it's not exploding in the course of two years.
Marco:
But I think we just have to wait it out.
John:
I think the internet broadcasting thing and those other terms, that still beats trying to coin your own new word, like netcast.
John:
Even though it may be confusing, trying to come up with a generic term for what you do that doesn't pigeonhole you under podcasts still beats trying to come up with a thing like netcast or internet.
John:
internet blast or making up some other word.
John:
That's why Netcast seems like branding for Twit, because it's like, oh, well, this is a new word that's made up.
John:
As for the popularity thing, the celebrities have arrived on podcasts.
John:
Celebrities have podcasts now.
John:
So that phase of the popularization has begun, at least, where the professionals are here.
John:
But the thing is, in general, they're not the...
John:
It's weird that they're not the radio professionals.
John:
You know what I mean?
John:
It's not like Howard Stern abandoned his radio show to have a podcast.
John:
He just went to satellite radio, right?
John:
And he's just going to retire.
John:
Well, that might be up for debate.
Marco:
We'll see.
John:
Well, but like the people who showed up are like stand-up comedians, television stars, people who are not trained as audio broadcasters.
John:
Right.
John:
But they're famous people, at least.
John:
So then you can get a podcast where a famous person interviews another famous person.
John:
It's got name recognition and stuff.
John:
Right.
John:
The thing I worry about with podcasts is the way we all listen to them hinges on the mechanism by which they come to be.
John:
We get them onto our iPods or our phones, and that relies on software created by our phone maker.
John:
How much of the podcast ecosystem right now is entirely dependent on the fact that podcasts are in iTunes?
John:
Like, say the next version of iTunes comes out and podcasts are no longer there.
John:
Period.
John:
They're gone.
John:
Then there would be this mad dash, kind of like the Google Reader thing, to reestablish that infrastructure somewhere.
Marco:
And we just don't have that kind of like... Well, they're already gone from the app on iOS.
John:
Well, you know what I mean.
John:
Like, you can't... You wouldn't be able to go into some place like...
John:
On your phone or on your Mac or your Windows PC or on basically any device, you can go somewhere and search based on the name of a podcast.
John:
If you can find the right search box, you can type it in.
John:
But if those facilities went away, like if they weren't in the iTunes store and there was no iTunes directory for them, you had to find like ATP.fm to find this podcast.
John:
and like get something that can read the feed and you had to use a third-party feed reader and stuff like having that centralized clearinghouse we rely on that so much because this infrastructure hasn't been built out like and like you said like all right fine well then what about when you're going to go in your car oh now you have another seven infrastructure barriers to overcome of how do i get this audio that i've got on my ipod or on my phone but now i want to listen to it in my car but my car just has a radio how do i overcome that and it's
John:
it's a series of annoying barriers that are preventing what you really want to just be like someone mentions the name of a podcast you know exactly where to type that name you type it in and then anywhere you are where you could potentially listen to audio you can listen to that thing and we are we are far from that
Marco:
Yeah, that's true.
Marco:
I will give you that.
Marco:
But I think the key to all this is the smartphone.
Marco:
I really do.
Marco:
I devoted a lot of the last Bill & Analyze episode to talking about this topic in particular.
Marco:
I think that the smartphone is the default device to listen to things on.
Marco:
It used to be that you'd have the iPod in your pocket and then maybe at work you'd use a computer or at home maybe you'd use some kind of stereo that used discs or something crazy like that.
Marco:
But
Marco:
I think it's very clear now that the smartphone is the new media player and not just for portable anymore.
Marco:
And I think we're going to keep going in that direction, where the smartphone is going to continue to be the center of everything, including, by the way, including the way that your car...
Marco:
Not only integrate with your media, but the way your car connects to the internet.
Marco:
I really do think that's going to go through smartphone data plans.
Marco:
I think the phone is going to be your terminal and your modem and your media player to the world.
Marco:
Just like Steve Jobs' digital hub thing back 15 years ago, whenever that was, but now it's your phone and not your computer.
Casey:
I tend to think you're right.
Casey:
And something you said a little earlier or implied a little earlier made me think, and I'm going to butcher what you said and put words in your mouth, and I'm not going to stop talking so you can't argue with me.
Casey:
But you had said or implied that podcasting isn't really new anymore.
Casey:
And obviously, this is a much more nuanced conversation than I'm giving the chance to respond to.
Casey:
But I found that interesting because I've actually had friends of mine, after they caught wind of the fact that I'm podcasting now,
Casey:
they've said to me, hey, what does it take to do that?
Casey:
Because I've had an idea for a podcast and I want to do that.
Casey:
What did you do?
Casey:
And of course, I've said, well, Marco did all the work and I just sit here, show up and act like a prima donna.
Casey:
But all kidding aside, I've had people come out of the woodwork and say, hey, I'd really love to do my own podcast.
Casey:
And what I'm driving at is it's not new in the sense that this thing as a medium has been going on for a long time.
Casey:
But I think it's kind of new in the sense that
Casey:
regular people are starting to grasp this and are starting to wonder, hey, can I get a piece of that pie?
Casey:
And I don't mean financially, just attention-wise.
Casey:
Can I get a piece of that pie?
Casey:
And so I almost wonder if we're about to see maybe not a renaissance, but a newfound interest in podcasting where –
Casey:
In the same way, everyone ended up with a blog and now everyone has a Twitter account.
Casey:
I don't literally mean everyone, but I wonder if a lot of what we would call regular people will end up having podcasts.
Casey:
And so we'll all be talking into space and nobody will be listening.
John:
It's kind of connected with blog infrastructure because I like Squarespace, right?
John:
So if someone asked that, if someone asked me, hey, I want to have a podcast, what I would tell them at this point, based only on my secondhand knowledge of Marco doing it, is like, it seems like if you just get a Squarespace site, it's pretty easy to get a podcast up and running, right?
John:
And that's like the same thing with back when we were blogging.
John:
It's like...
John:
how do I get a blog up?
John:
You don't want to tell someone, okay, step one, get a shared hosting plan.
John:
Step two, install movable type, right?
John:
Like you wanted to tell them to go to edit, edit this page.com or whatever the old frontier thing, like the, one of the first sites that you could, you just go to the webpage and you just edit it.
John:
Right.
John:
And of course the way it is now, it was a gigantic explosion and then reconsolidation of all of these web applications that you could tell anyone to use.
John:
Go to Tumblr, type in the host name you want and a username you want and a password and click a button and
Marco:
great you're blogging good you know good job like the equivalent of that for podcasting is more or less here it seems like with pot with like the squarespace type thing but we haven't seen the proliferation i mean marco you set it up was it basically that easy you just go there and oh yeah you want to have a podcast it really is that easy they uh and and yeah obviously squarespace has been a sponsor of the show for a long time and has future sponsorships so that we should disclose that but uh yeah of course it's it's extremely easy there and they aren't the only people to make it easy i mean you can
Marco:
I don't think WordPress.com, which one's the one that hosts all those sites?
Marco:
WordPress.com?
Marco:
I don't think they offer this, but there's been a million podcast plug-ins for WordPress over the years.
Marco:
You can host a podcast pretty easily in lots of ways.
John:
Are we at the Tumblr phase, though, of podcasting?
John:
Where if some random person wanted to have a blog, the reason I would direct them to Tumblr is I would say, it's the easiest... That's basically as simple as it can possibly get.
John:
You type three things and you are now a blogger.
John:
Congratulations.
Marco:
Actually, I built this Easter egg a long time ago.
Marco:
Tumblr also supports podcast hosting if you host the files elsewhere.
Marco:
I believe if you go to any Tumblr site slash podcast...
Marco:
or maybe slash podcast slash RSS, it will give you an iTunes-compatible podcast feed of any audio posts that are externally hosted.
Marco:
So try that.
Marco:
Anyway, I built that a long time ago and never documented it, I don't think.
Marco:
But it's probably still there.
Marco:
But I think...
Marco:
You know, podcasting inherently... It's like how it's really easy for people to take good photos that look kind of good, but it's a lot harder to take good video.
Marco:
I think podcasting is kind of similar in that making an audio production...
Marco:
It's inherently more work than blogging.
Marco:
To do it well, you need a certain level of equipment.
Marco:
You at least need a good microphone.
Marco:
There's a little bit more barrier just in realities of making this kind of media that I don't think we're ever going to overcome some of those barriers.
Marco:
Certainly, we're not going to overcome the problem of...
Marco:
of it being complex and and unusual to be able to be able to make a good podcast that is both good sounding and with with compelling content i mean that's you know that's always going to be every media is going to have that challenge of quality and uh and interestingness and relevance but i don't think we're ever going to reach the point of like tumblr where you type in three things and you have a podcast like i don't i don't think we're ever going to reach that
John:
I think we can get pretty close because right now the main barriers for someone doing that would be you're not going to have a good microphone because computers don't come with them.
John:
But maybe the microphones in your phone start getting better.
John:
Is voice recorder quality on your phone good enough?
John:
If we start all wearing crazy headsets like Google 4Cs?
John:
Oh, yeah.
John:
For most people, yeah.
John:
Maybe that would be sufficient.
John:
So the audio quality thing might start taking care of itself.
John:
Yeah, the content problem obviously is never going to end up.
John:
But that's not... I mean, the content problem isn't solved by better blogging tools either.
John:
People just write what they feel like writing.
John:
It's just... Like Casey was saying, for the people who he knows, they're not looking to do anything earth-shattering, but they just feel like...
John:
I could do that and my 10 friends could listen to it.
John:
I could write a blog.
John:
I could have a Tumblr blog and my 10 friends and my mom can look at it and that's enough for me.
John:
And the podcast equivalent to that.
John:
And the barrier to that is like your friends and your mom are not going to go through the effort to figure out how to get your stupid podcast onto their phone or iPod because that's just too much.
John:
They'll visit your Tumblr page and look at the amusing thing you put in there or just look at your last thing that you posted to Facebook or whatever.
John:
But podcasts are still a little bit too much of a barrier to like...
John:
Do I really want to listen to this guy's podcast?
John:
It's so much easier just to look at their blog posts because it takes more time for the thing, and you've got to set it up, and now you have the subscription, and it's automatically downloading, and how does this podcast app work or whatever?
John:
That's what I was talking about with the barriers to entry.
John:
I don't think we're quite there yet, and the other one might just be inherent that you can read much faster than you can listen, and people can talk much more than they can write.
Marco:
Yeah, that's true.
Marco:
I mean that's always going to be a problem with audio and video, like the fixed timescale media is that they're much harder to skim than text.
Marco:
And so there's always going to be limitations there and inefficiencies and just restrictions on how much time and attention people are willing to give to them.
Marco:
anyway before we go on now it's been so long before we go on to the Brent post our second sponsor and our final sponsor this episode is a returning sponsor once again welcome back Hover as a sponsor Hover is a domain registrar that doesn't suck and I mean that from the bottom of my heart I use them myself they didn't tell me to say that I use them myself and I've used a lot of domain registrars I've never found another one that I wanted to stick with
Marco:
after using them, and Hover is the one I stick with.
Marco:
They really are great.
Marco:
First of all, go to hover.com slash ATP.
Marco:
Let them know that you heard about this from here, and you'll get... Oh, crap, I forgot.
Marco:
I think it's 10% off if you use that as your entry point.
Marco:
Sorry about that.
Marco:
I don't have that in this script.
Marco:
But go to hover.com slash ATP.
Marco:
So basically...
Marco:
They have .net, .co, .com, .tv.
Marco:
They have tons of different country code top-level domains you can register with them.
Marco:
They believe that everyone should be able to take control of their online identity, get your own domain, and they make it really easy to do so.
Marco:
I've advocated for years.
Marco:
Don't use a Gmail web address as your email address.
Marco:
Don't use a Google Plus site as your identity on the internet.
Marco:
Buy your own name and do your own thing and make your own identity.
Marco:
They make it easy to do exactly that.
Marco:
Just the fact that they're a registrar that doesn't suck, that should be enough reason right there that you should go try them out.
Marco:
But in case you need more reasons, they have a very, very clean, well-designed control panel.
Marco:
It's very low hassle, low friction.
Marco:
They even have this cool thing where...
Marco:
I think they call it a migration service.
Marco:
I forget.
Marco:
It isn't in my list.
Marco:
But they have a thing where if you're willing to give them your login information for your old registrar, they will go in there and migrate all your domain names to their service for you.
Marco:
Because transferring domains can be a bit of a hassle.
Marco:
They will do all of it for you.
Marco:
Oh, I think it's called Domain Valley Service.
Marco:
It's really, really cool.
Marco:
I really do recommend them very, very much.
Marco:
I mean, I can give you the whole bullet list of what they told me to say here, but they really enjoyed the last time when I just told you how I feel about them, and I'm doing most of that now because they really are just that good.
Marco:
Yeah.
Marco:
Domain registrars, it's very, very hard to find a good one.
Marco:
And they really are fantastic.
Marco:
So thank you very much to Hover.com.
Marco:
Go to Hover.com slash ATP.
Marco:
And this is run, by the way, by the Two Cows people.
Marco:
They've been in business since like the 1800s doing all sorts of geeky things.
Marco:
So...
Marco:
You can trust these people.
Marco:
They really know what they're doing.
Marco:
They've been around forever.
Marco:
Everything rests on their reputation that they've built for years.
Marco:
Their customer service is fantastic.
Marco:
They pick up the phone.
Marco:
If you can imagine that, you call somebody and they pick up the phone.
Marco:
They actually do that.
Marco:
That's real with them.
Marco:
So, yeah.
Marco:
Go to Hover.com.
Marco:
They have email, forwards, DNS, all sorts of fun stuff.
Marco:
Check them out.
Marco:
Hover.com slash ATP.
Marco:
And thank you very much for supporting this show.
Casey:
Yeah.
Casey:
So to add to that, just a couple of days ago, my father was looking to register a domain and he's very technically savvy for someone who doesn't do this sort of thing for a living.
Casey:
But I mean, he doesn't know the ins and outs of DNS and those sorts of things.
Casey:
And so I was like, dad, just go to hover.
Casey:
I have no time to deal with this right now.
Casey:
See if you can figure it out.
Casey:
And if not, let me know.
Casey:
And like 20 minutes later, he said, oh, I've got my domain.
Casey:
It's all on hover.
Casey:
It worked great.
Casey:
Don't even bother calling me back.
Casey:
I'm all good.
Casey:
So it's really, they're really good.
Casey:
So give them a shot.
Marco:
Yeah, definitely.
Marco:
All right, so moving on.
Marco:
So now I do still want to talk about this Brent Simmons article, 30 Minutes to Sync.
Marco:
What he basically says, he suggests a solution that iCloud in its current form for developers, as we've talked about before in this show and as many people have talked about recently,
Marco:
iCloud for developers has been really a mixed bag mostly bad and any kind of database sync or any kind of complex sync for apps with iCloud has been just tons and tons of problems from simply being not functional to causing very difficult support problems to weird bugs and the biggest thing being a total lack of control over what's going on because you don't control iCloud as a developer and
Marco:
So what Brent suggests here is that Apple should make, rather than doing the current, quote, magic setup where you basically say, all right, here's my core data database, sync it, and hope nothing goes wrong, which doesn't actually work in practice.
Marco:
Rather than doing that, Brent says Apple should have basically a kind of thing where
Marco:
You can define some server-side logic for them to execute on your behalf, and the app can talk to that logic, and most importantly, people can log into it, or you can log into it.
Marco:
You can log into people's iCloud accounts from your app and manage your own data, stuff like that.
Marco:
And then they also would support things, he said, support periodic tasks like polling, Twitter, or RSS feeds or stuff like that.
Marco:
And then he also points out, which we should point out also, this is all very, very similar to a few systems that already exist out there.
Marco:
There's things like Heroku.
Marco:
which is kind of like a generic app hosting platform that is based on scalability automatically and stuff like that.
Marco:
There's also Windows Azure Mobile Services, which we should disclose is a future sponsor of this show.
Marco:
And Brent has actually done promotional videos for them.
Marco:
And they do almost exactly what he's asking for, but without the iCloud authentication integration.
Marco:
But I think – what do you guys think of this proposal?
Marco:
Do you think it's realistic that – first of all, I think Apple never will do it.
Marco:
But do you think this would be a good thing if they did it?
John:
I think Apple is two degrees removed from being able to pull off anything like this.
John:
If you think of the companies that do do it, like Google and Amazon, the first stage of getting to the point where you were even able to do this is –
John:
The company recognizes that one of the things they need to be really good at as a company is doing services in-house and that they can't do each one as a kind of custom one-off special snowflake.
John:
What they need are infrastructure tools to do that.
John:
So the reason Amazon builds up its infrastructure is we have to run Amazon.com, and it's actually a pretty popular website, and we have scaling problems, and we have these problems that are in here.
John:
So let's build ourselves tools to do that.
John:
Once you do that, you're like, okay, well, we've built these tools internally.
John:
They're not great, but it lets us build Amazon.com or lets us build Google's stuff.
John:
If we change this just a little bit and shape it up, we can sell this as EC2 or as Google App Engine or whatever.
John:
That's the second part.
John:
Apple doesn't even have that first part yet.
John:
I think they're not yet able to... They haven't yet recognized that...
John:
internal infrastructure tools are important enough to the company that they need to be is just as important as like you know ios or hardware design or silicon chips or whatever maybe they're doing it internally maybe they haven't figured out but that's that's what i think is the main barrier to them doing this is they have nothing to vend because as anyone who writes server-side software knows you can't just say oh you guys write some code and we'll run it on our servers because the first dude to put in an infinite loop goes oh
John:
huh, I guess we need some way to handle that.
John:
Oh, I guess we need to handle resource usage.
John:
Oh, we're going to run your periodic job.
John:
But I guess we need like all the things that you deal with that you have to just have an infrastructure for running arbitrary jobs in a controlled environment where you limit their CPU, but have error, you know, handling so you can let someone know why their thing didn't complete because it was using too much of this.
John:
And like, I mean, even shared hosting providers have to do crap like that, where they're just trying to divvy up their resources.
John:
Apple is so not equipped to do that.
John:
They're not even equipped to run their own things in that manner.
John:
In fact, they're
John:
farming a lot of it out to run you know the windows azure stuff which is great that microsoft's good at that but the fact that apple isn't means that i would not hold my breath for anything that apple is going to provide where you give them code and they run it on their servers for you
Casey:
I would agree with all of that, and somebody in the chat room is probably laughing by me saying that because I get a lot of grief for saying that.
Casey:
But I agree with all that.
Casey:
Wait, whom do you agree with?
Casey:
Both of you guys, really.
Casey:
I think it would be awesome.
Casey:
I don't think Apple will ever do it, and I don't think Apple is capable of doing it right now.
Casey:
But one thing I will say is that I wish that we had – this is going to sound so obvious, but bear with me.
Casey:
I wish that we had a little more insight – or not insight.
Casey:
We had a little more access to iCloud authentication, or iCloud in general especially.
Casey:
But one of the things I've been thinking about a lot,
Casey:
in the spare time I don't have, is to write a very, very, very basic list, not to do, but like a grocery list app.
Casey:
And what I mean by that is, my wife and I, we use Wunderlist right now to organize our shopping lists, one for the grocery store, one for hardware stores, etc., etc., etc.,
Casey:
And although Wunderlist is very good, it's way more heavy-handed than I need.
Casey:
I just need a list of things that are either checked off or not.
Casey:
And one of the things I've been thinking about is writing my own.
Casey:
But the problem with that is I don't want to have to, in the case of Azure Mobile Services, my understanding is you can use Facebook to log in.
Casey:
Does this sound familiar at all?
Casey:
You can use Facebook to log in.
Casey:
You can use Twitter to log in.
Casey:
You can use Windows Live to log in.
Casey:
And I think there might be one or two other options, or you can roll your own.
Casey:
I don't have the patience to roll my own.
Casey:
I get no excitement and no jollies over rolling my own authentication and login system.
Casey:
I wish I could just use iCloud to handle that.
Casey:
And I know I can when I'm talking about doing things in their own little silo, but to my knowledge, there's no way for me to really...
Casey:
sync between iCloud users easily.
Casey:
And so it's stuff like this that Brent's talking about that I think would make it really cool and maybe make it possible for me to make this grocery list app for my wife and I to share that uses iCloud as a login mechanism
Casey:
That I don't need to worry about the stuff I don't care about.
Casey:
And what's interesting to me is that Apple is usually very good at abstracting away the things that I don't want to care about and properly abstracting them.
Casey:
And in this case, they've abstracted, as many developers have said, they've abstracted too much and they haven't given us anything.
Casey:
any vision into it.
Casey:
And it's just this big black box that we have no control over and it stinks.
Casey:
And I really wish that a lot of these things that Brent talks about were possible, but I agree with John.
Casey:
I don't think that Apple's in a position that they're capable of delivering it.
Casey:
And I agree with you, Marco.
Casey:
I don't know that they have any interest in it anyway.
John:
Well, they could do the limited version of this, which is they could, you know, like I just joked about earlier, there's no reason they couldn't provide a web service to authenticate with your iCloud ID, like things that don't involve arbitrary developers giving Apple code that Apple will run on their service on your behalf.
John:
If they simply vended the services already available through the iCloud APIs, but did it through, you know, HTTP endpoint and allowed, you know, because then you could write web apps against it, right?
John:
Which basically Apple does.
John:
iCloud.com, you know, is taking advantage of its own... I don't know if it is.
John:
I know...
John:
This is going back in time.
John:
The iDisk website had a little JavaScript implementation that would hit against a regular sort of web service endpoint to do its work.
John:
And I'm assuming that iCloud stuff does similar things, and it's not just all talking to Apple service, which is then talk to the services behind the scenes.
John:
But there's no reason they can't expose some or all of the things that you currently can only do from an iOS app as a bunch of web APIs.
John:
But Apple has never – I always say Apple doesn't understand the web.
John:
kind of a harsh way to say it but you know apple's apple doesn't want to understand the web because they they want like the reason all this stuff is restricted to ios is they're not they're not google they don't win when more people use web applications or more people use the web right they want people to use ios devices so there's not really a lot of incentive for them to say oh look and now if you use iCloud as your you know thing where you store stuff you can make your web app hit it too like why would they want you to go to your web they think you should be using an ios application so
John:
there's no real advantage for them to do that.
John:
But that's one of the, one of the many, many other things that keep people away from iCloud is it's locking you in.
John:
You can't have a web app that uses that same backend.
John:
You can't have an Android app that uses that same backend.
John:
And certainly Apple doesn't want you to have an Android app or anything else.
John:
But, uh,
John:
And that's – in some degree, there's no motivation for Apple to do that.
John:
But on the other side, they could put web service endpoints for a limited set of things, and that would make people less reticent to use it.
John:
Why would I ever use iCloud?
John:
Well, people use it in iOS because, like, hey, no sign-in.
John:
Your phone is already set up with your Apple ID.
John:
It's great to not have that sign-in thing, and it's perfect.
John:
Yeah.
John:
But if that's it, that's the extent of that relationship with this authentication system, then it's like, oh, but I also wanted to have a website.
John:
And so now you've got to bend over backwards and do something like Marco did.
John:
We're like, well, newsstand just works because you're signed in with your Apple ID and blah, blah, blah.
John:
But I also want to have a website, but I can't get access to that ID.
John:
So I've got to figure out some system.
John:
Before you know, you're emailing attachments with weird data in them.
John:
Yeah.
Marco:
I think also there's a problem here of... I mean, first of all, I guess I can see why people in our little world of Mac nerds so often talk about this problem, but as a developer of web services, and again, because I have a history of doing these things myself and I've gotten pretty good at it recently, maybe I'm biased here or maybe my view is somehow distorted here, but...
Marco:
I don't see the big lineup of people wanting to build web services on Apple's cloud infrastructure.
Marco:
As a web service builder, I would never want that because they've shown that... They've shown partly that they don't really care that much about reliability necessarily or about improving it to the point where their actions speak louder than words.
Marco:
If...
Marco:
I'm sure the people working on it are trying very hard to make it work, but it just seems like as a company it isn't a very high priority.
Marco:
And you can see that in the relatively little progress it's made over the last few years.
Marco:
It just doesn't seem like it's a number one priority for the company.
John:
That's not neutral either.
Marco:
The way getting out a new iPhone is, you know.
John:
Like S3, you feel like, well, that's neutral.
John:
S3 is a bucket where I put crap.
John:
You understand the business model behind it because you pay for usage, and you're pretty sure that Amazon – well, maybe you're less sure these days, but that Amazon is not – you're not in competition with Amazon by making your application, your mobile application and your website that both use S3.
John:
Right.
Marco:
But I think the other problem with Apple stuff is that because it doesn't seem like it's that high of a priority for them all the time, it's gone through so much flux.
Marco:
If I would have built Instapaper on Apple's web service of the time when I started it, I would have been building it on something called .Mac.
Marco:
which most people don't even – have probably never even heard of these days.
Marco:
Most people who use it have probably forgotten about it.
Marco:
First, it was .Mac.
Marco:
Well, first it was whatever it was, like NetTools or whatever.
Marco:
iTools.
Marco:
iTools, that's it.
Marco:
But there was no service.
Marco:
Internet blast, something.
Marco:
And there was that, and then there was .Mac, which had some internet service-based things.
Marco:
And then MobileMe, which had more internet-based service things.
Marco:
And then iCloud, which has actually fewer internet-based service things.
Marco:
And there is... Apple's own system is in such flux here.
Marco:
I would never want to build on that infrastructure.
John:
That's exactly what I was going to ask you.
John:
If you re-conceptualize all those things you just listed, including iCloud, the current one, not as infrastructure, which clearly Apple doesn't think of them as, but merely as...
John:
There's ways to make it easier for you to develop feature-full applications for their platform.
John:
So if you look at it that way, MobileMe, .MacSync, and all that stuff was a way for you to write a Mac application so that you didn't have to write the sync stuff.
John:
GameCenter, so that you can write a game, so that you don't have to do the matchmaking.
John:
You don't have to do...
John:
the server based scoring and stuff like that, because maybe you just write iOS apps, maybe you just write Mac apps, maybe you don't know or don't care or don't want to do the server side stuff.
John:
So they're trying to make it so hey, you want to you want to write a game, but you don't want to maintain servers, write it against Game Center, you want to write a Mac application, but you don't know anything about syncing?
John:
Well, we have a framework, same way any framework works, you know, that frameworks do the work for you so that all you need to know about is, you know, dentistry for your dentist app, plus a little bit of cocoa to do the UI, right?
John:
But you don't need to know about OpenGL to make
John:
OpenGL animated stuff.
John:
I was going to say LayerKit.
John:
Core animation does that for you, right?
John:
If you look at iCloud in that respect, it's like, well, A, why the heck would it ever work outside of iOS?
John:
Because the whole point of it is just so that you can make a cool iOS app that has lots of interesting features without having to write the server stuff.
John:
And I don't have a B. Or maybe I had a B and I lost it.
John:
I don't know.
John:
But if you look at it that way...
John:
It looks less insane, but I don't – like, first of all, if it doesn't work well and whatever, then, you know, as we've talked about at length of other shows, then even in that respect, it doesn't work.
John:
So iCloud is a failure even if you narrow it just to that focus.
John:
But, you know, the reason we're talking about broadening it out to having web services and stuff like that is –
John:
You know, we want it to be an infrastructure component because lots of people who write applications don't just want it to be easier to make a cool iOS application.
John:
They want it to be easier for them to, you know, run a business or something.
John:
So S3 provides that because I don't want to deal with storage.
John:
But if I pay S3 for my usage, I get storage.
John:
And that solves the storage problem for my business product provided like people buy my product or have some other revenue stream that I can put towards that.
John:
Whereas the iCloud thing is like, well, okay, that solves my problem how to write the iOS app.
John:
But okay, now when I go to write the Android app, I have to do something different.
John:
And now when I write the web app, you know, maybe if Google does it well, you can write the Android app and the web app against the same infrastructure.
John:
And Apple looks like the odd man out of like, oh, I got to use iCloud with that.
John:
Or maybe I don't.
John:
Maybe I'll just shun iCloud like everybody else and just use whatever the other infrastructure thing is.
John:
And then once again, it ends up with Apple being fenced out of
John:
the infrastructure business.
John:
Because like Marco said, why would I ever trust them for infrastructure?
John:
Because it doesn't seem like that's what they're making.
John:
They're making this other thing.
Casey:
Yeah, but like I said earlier, as you just said, I think Apple's technologies, their developer technologies are so good at abstracting away the things we don't care about.
Casey:
A perfect example is what you brought up with core animation.
Casey:
I mean, I don't know crap about anything related to animations or OpenGL or anything like that, but I can animate the crud out of a UI view like the best of them because the core animation API is so simple and so robust.
Casey:
And it's really disappointing that Apple doesn't have an equivalent, just like you said, for what we call cloud computing.
Casey:
And I don't think I would use it even if it was available tomorrow.
Casey:
But man, would I be like, say, at WWDC, if they announced some sort of cloud computing platform, I would be really darn excited about it.
Casey:
I surely wouldn't be the first to use it, but I'd be really excited about it.
Marco:
I would stay very, very far away from that platform, honestly.
John:
Well, I mean, it's also about commitment because the fact that they have turnover, if you think of MobileMe and Sync as like, well, that was the thing we had five years ago and you wrote and sold your application five years ago and you made your money from selling that application and that time is over and now we assume you're going to write a new application –
John:
And people like, you know, bare bones with Yojimbo is like, well, actually, we've still got the old application and we'd still like to keep selling it because we kept updating it.
John:
And Apple's like, yeah, no, that time has passed.
John:
We have a new thing now.
John:
So either rewrite your application against iCloud, which doesn't seem to work even as well as ThinkServices did.
John:
or you know come up with another solution whereas if you think of something as infrastructure like if amazon decided s3 was our first attempt at storage but we're gonna we're gonna sunset s3 and we're gonna replace it with s4 because that's one more right and it's totally incompatible people go people will really regret ever starting a project that relied on s3 as the back end like i don't know dropbox you know a couple of small companies that might be impacted by this decision the
John:
And once you get that reputation, like, oh, they're not interested in building infrastructure for long term support.
John:
And especially with things like web services and stuff where you're not touching it, where it's all over a network connection, there's really no reason ever to completely sunset that type of thing.
John:
Like you can change how S3 works.
John:
I'm sure it has changed behind the scenes, change all the hardware, change all the software that runs it.
John:
You just have to present the same API endpoints to the network and then you're good to go.
John:
But Apple, like, it's not making infrastructure.
John:
It has no pretense of making infrastructure.
John:
It's changed 17 times since then.
John:
So that's why everyone is living in deadly fear.
John:
So if Apple ever did come out with something like this, they would have to explain, say, up front, we understand the difference between infrastructure and the thing that makes it easier for you to write an application that you're going to sell for three years.
John:
And this is not that other thing.
John:
So trust us.
John:
And then still, they would have to earn that trust and, you know, do a good job and so on and so forth.
John:
But that, you know, there's a big gap.
Marco:
It just seems like Apple wants to work at a higher conceptual level than that.
Marco:
They don't want to expose the guts.
Marco:
They don't want to expose server-side functionality.
Marco:
They don't want to expose low-level APIs or give you low-level data access like that.
Marco:
They want it to be...
Marco:
the ubiquity iCloud API that we expose like this in the apps, and that's it.
Marco:
And I think that's much to their downfall, really.
Marco:
I mean, there's a few cases that benefit from that, but there's so many that don't.
Marco:
And as we've discussed in one of the earlier episodes of this show, I think the whole concept of that is flawed.
Marco:
And the way they've tried to do iCloud is a simple thing.
Marco:
Just hit this flag and call this function, and it works.
Marco:
And it's not that simple.
Marco:
It doesn't just work.
Marco:
And the whole concept, I think, is flawed.
Marco:
But I don't see Apple ever going lower down the stack and ever offering that kind of deep, low-level access, execution of arbitrary code in any language with any restrictions.
Marco:
I don't see that happening.
Marco:
Any kind of server-side stuff they would do would probably be in the form of things that you initiate locally in the apps.
Marco:
Maybe it would be like newsstand API where you could enqueue a background download with a certain push notification or something like that.
Marco:
It would be these restricted cookie-cutter templates.
Marco:
It wouldn't be like, oh, you can execute arbitrary logic on the server.
Marco:
Uh, and I just, I don't see them ever getting into that business.
John:
Well, you know, the key value store, like we, we keep saying iCloud, but we're really mostly talking about the core data thing.
John:
But key value store is an example of like limited, simple functionality that does not dictate implementation.
John:
It's just so super limited.
John:
Like, you know, it's for preferences and stuff.
John:
It's not for like, Hey, star, are you data here?
John:
But, but you can imagine like that.
John:
You're like, it's different between like soap and WSDL and all that soup versus like rest, you know, where like you can imagine a really simple, uh,
John:
http api for key value store right it's like it's like it writes itself it's it's so simple because the api is so simple and no one is complaining because the concept is simple yeah no one is complaining the key value store shouldn't exist right but what brend is talking about is uh that that kind of thing makes sense because they're just having infrastructure so
John:
Let me as the application developer worry about all these other details.
John:
I just need a place that's not here.
John:
I need a place that's across the network for me to put my stuff and to be able to get it back later.
John:
I'll take care of the other details.
John:
Like it's the bargaining stage.
John:
It's like, you know, I know you want to do everything for me and make it magically work, but that's not working for us.
John:
So if you just gave me a place to put stuff and I could still use my iCloud authentication, which is really great, I'll take care of the rest of it.
John:
And, you know, and then I'll have a good application, which it's stepping down and saying, I'm willing to do more work to talk to your dumber bucket.
John:
If I can authenticate against that bucket using the iCloud ID that's already set up, please, Apple, at least just let me do that.
Marco:
All right, and with that, we should wrap up.
Marco:
Thank you very much to our two sponsors, MacMiniVault.com.
Marco:
You can go co-locate your own Mac Mini for $30 a month and less for the first three months if you use coupon code ATP50 for 50% off.
Marco:
And our second sponsor was Hover.
Marco:
Go to hover.com slash ATP.
Marco:
Get a nice discount there.
Marco:
Register domains in a way that doesn't suck.
Marco:
They are the best registrar I've ever used.
Marco:
And they're awesome.
Marco:
So go to Hover to register all your domains and related domain activities such as email, forwarding, DNS, etc.
Marco:
Thanks a lot to our sponsors.
Marco:
And thank you, John and Casey.
Thank you.
Marco:
Now the show is over.
Marco:
They didn't even mean to begin.
Marco:
Cause it was accidental.
Marco:
Oh, it was accidental.
Marco:
John didn't do any research.
Marco:
Marco and Casey wouldn't let him.
Marco:
Cause it was accidental.
Marco:
It was accidental.
John:
And you can find the show notes at atp.fm.
John:
And if you're into Twitter...
Marco:
You can follow them at C-A-S-E-Y-L-I-S-S So that's Casey Liss M-A-R-C-O-A-R-M-N-T-M-A-R-C-O-R-M-N-T-M-A-R-C-O-R-M-N-S-I-R-A-C-U-S-A-C-R-A-C-U-S-A-C-R-A-C-U-S-A-C-U-S-A It's accidental, accidental They didn't mean to Accidental, accidental Tech Podcast So long
John:
Thanks.
John:
That would have been a tight show if you hadn't had this middle section for half an hour.
John:
We talked about podcast on a podcast.
John:
You derailed yourself.
Marco:
You did that to yourself.
Marco:
I kept meaning to make that just like a blog post, and I haven't had time, so this happened.
Casey:
So now we all get to pay the price.
Marco:
Yes, exactly.
John:
You can still make it a blog post.
John:
I think it was interesting.
Casey:
Actually, I thought it was interesting, too.
John:
It is, but you're the one who's always against talking about podcasts on podcasts.
John:
I don't have a problem with it.
John:
I think it's fine.
Marco:
Well, no, I think it's okay to talk about podcasts on podcasts as long as you make fun of it first.
John:
All right, then it's okay.