The Nitch Podcast

Episode 58: Fifty Shades of Black

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 24 May 2013 00:00:00 +0000

Episode 58: Fifty Shades of Black

May 24, 2013

Running time: 1:09:23

Jonathan and Kelli talk about the upcoming screencast episode, performance problems with KnockoutJS, and the massive implications of Google's recent announcements at the IO conference.

Download (52.4 MB)

Titles We Considered

I Feel So Naked
Ten Pounds of Crap in a Five Pound Bag
Duck!
My Head Already Looks Messed Up
Google Now On Your Face
Fifty Shades of Black
Smart Toastery
It's Freaking Star Trek
That's Not the Computer
Like GoDaddy but with Less Underwear

Episode 57: Flossing With Rails

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 17 May 2013 00:00:00 +0000

Episode 57: Flossing With Rails

May 17, 2013

Running time: 32:05

Jonathan and Kelli talk about building - and more importantly, testing - REST APIs with Rails and RSpec.

Download (23 MB)

Titles We Considered

Pure Kelli
Sounds Like Work
Totally Broken
Flossing With Rails

Episode 56: Eighteen Hours Since Last Twisted Ankle

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 10 May 2013 00:00:00 +0000

Episode 56: Eighteen Hours Since Last Twisted Ankle

May 10, 2013

Running time: 33:16

Jonathan and Kelli talk about how to quote a project for a client who needs an app that can run everywhere.

Download (24.1 MB)

Titles We Considered

18 Hours Since Last Twisted Ankle
A Great Fit for the New Reality
Unwittingly Conceived
Not More Painful

Episode 55: Nerds in Grass Skirts

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 03 May 2013 00:00:00 +0000

Episode 55: Nerds in Grass Skirts

May 3, 2013

Running time: 36:35

Jonathan and Kelli talk about experimentation with the Lua programming language and the possible implications on cross-platform application development.

Download (28.2 MB)

Titles We Considered

Cat Fricassee
The Spaz Family
The Four Would Hurt So Bad
Nerds in Grass Skirts
Winnie The Poohing It

Transcript

Jonathan Stark: Hello, and welcome to the Nitch podcast for Friday, May 3rd, 2013. I'm Jonathan Stark.

Kelli Shaver: I'm Kelli Shaver.

Jonathan: We're here to talk about building apps that run everywhere. This week, we talk about Kelli's experiments with the Lua programming language, and the possible implications for cross-platform development. Please stay tuned. The Nitch podcast is next. I think I did it right.

Kelli: You got it right that time.

Jonathan: It's a record. One week in a row.

Kelli: [laughs] You get a cookie.

Jonathan: [laughs] Yes. I could use a cookie. If I sound loosey-goosey, if I sound a little free and easy...

Kelli: Yeah, you do, a little bit.

Jonathan: Do I?

Kelli: Yeah.

Jonathan: It's because, now that I have this fancy office that I go to during the day, occasionally, I left my microphone stand there. I'm actually holding my mic, American Idol style.

Kelli: Wow. I'm too lazy for that. I'd have to improvise a mic stand.

Jonathan: I have a huge bin of tinker toys here, and I thought about it. But I was like, "If I do that, I'll probably have to sit forward at a desk, and I really would rather recline."

Kelli: That's true. There is that.

Jonathan: I'm reclined and untethered. I'm off-stand.

Kelly: You sound very mellow.

Jonathan: I am. It's been a long day, and a long week. Like you said, it's only Wednesday.

Kelli: No kidding. This has been my battered and bruised week.

Jonathan: Yeah, seriously. I assume you had cat fricassee for dinner?

Kelli: [laughs] I wanted to.

Jonathan: For the dear listener, I think I have this story right, about the original ankle injury, but I might not. I was telling Erica tonight that you're...

Kelli: I was out, going for a walk actually. We've been going out to the high school track and just walking/jogging around it. I was just totally not paying attention to what I was doing. I was busy talking and not looking where I was going. The track turned, and I didn't, and I stepped off the edge and twisted my ankle very badly.

Jonathan: [laughs] Oh, God. I did have this story right. Let's be honest, you were looking at your phone.

Kelli: No, actually, I didn't have my phone with me.

Jonathan: [laughs]

Kelli: You know me, I never take my phone with me.

Jonathan: Fuel Band? No?

Kelli: No.

Jonathan: How do you like that Fuel Band, by the way?

Kelli: I like it. I like it better than Up Band, for what I want to use it for.

Jonathan: Yeah, that makes sense. Anyway, so you went to the doctor and you got crutches, and it started to get better until...

Kelli: Yeah, I went to the doctor and I got crutches, and that lasted about a day and a half. I said, you know, "Screw that," and I stole Richard's boot from when he broke his foot.

Jonathan: The benefits of being spaz family.

Kelli: Yeah, we can just pass around the medical...all the casts and braces and things.

Jonathan: The medical supplies. [laughs]

Kelli: Yeah. [laughs] Yes, it's sad. If anyone ever needs a spare prosthetic eye, I've got one of those here, too.

Jonathan: Oh, yeah?

Kelli: Yeah. It was starting to feel a little bit better, and I got up this morning, and I hadn't made it to the point of putting the boot on yet. I got up and I took one step, and I stepped on a Lego block that the cat had left there, that he'd dragged out of Kira's room. As you know, that's extremely painful.

Jonathan: Yeah, there's only one move that you make when you step on the Lego.

Kelli: Yeah. I made that move, and now I'm kind of back to square one.

Jonathan: Yeah. Cat fricassee. I'm telling you, the only thing worse than stepping on a Lego? Four-sider.

Kelli: Yeah. I've done that, too. Oh, that hurts.

Jonathan: It's a good thing your cat's not into D&D.

Kelli: Yeah, I know. He's stolen the 12 before, but not the 4. The four would hurt so bad.

Jonathan: Dear listener, you can imagine it's been a long three day week so far. Not to mention wrestling with the email protocol.

Kelli: Ah yes, and all the actual work we've had to do.

Jonathan: Yeah actual work. Spelunking around in WordPress config files and wacky old database tables. It's just so much going on there.

Kelli: Trying to figure out PHP's internal mail functions and working with Amazon SES, and not working with it, and all that good stuff.

Jonathan: Yeah, I want to publicly commend Kelli for updating the config for sendmail. You did that first try, that wasn't even the problem. I was very impressed [laughs] by that actually. The config that you posted, unreadable.

[laughter]

Jonathan: That was like Latin. I was like, "Not even going to try to read this. I'm just gonna believe that it works."

Kelli: I didn't post it there for you to read. I posted it for my own reference, because I wasn't going to try to figure it out again.

Jonathan: [laughs] Good idea. Not to go into it to much, but the concept was we wanted to use Amazon SES, to send all of our email, for reasons I won't go into. But it is a great way to send email. We have this huge WordPress install on top of it, and who knows how many calls there are to mail. So, why don't we just update the underlying thing that sends mail on the entire machine, then never worry about it again.

Kelli: Yeah.

Jonathan: You nailed that out of the gate, but PHP pulled out the rug from under us.

Kelli: [laughs] Yeah.

Jonathan: Anyway, it's fixed.

Kelli: We ended up not using sendmail at all, and just connecting to SES via SMTP with WordPress plug-in, but it's fixed and now anything else we have to send from the server, not through PHP, will still be piped through SES.

Jonathan: Correct. Any of our cron job logs, and all that stuff, should ship to us appropriately. So listener, if you ever have to work with SES and WordPress, go with SMTP, and you'll be happy.

Kelli: Yep. We can recommend a plug-in.

Jonathan: [laughs] Exactly.

Kelli: A lot of them are at least two years old.

Jonathan: This seems like an old problem with WordPress. Its old and solved. Anyway, that isn't what we want to talk about.

Kelli: We want to talk about fun stuff.

Jonathan: We want to talk about Lua.

Kelli: Yes.

Jonathan: They should of went all the way and called it luau.

Kelli: Luau, yeah. It would be more mellow. It would fit the way we feel tonight.

Jonathan: I feel like it is a mellow language.

Kelli: It feels that way.

Jonathan: It's very chill.

Kelli: It is.

Jonathan: I always picture like a necklace of flowers. Lua developers wear a lei and a Hawaiian shirt.

Kelli: Like flip-flops, if anything.

Jonathan: Grass skirt.

Kelli: [laughs] I wouldn't go that far.

Jonathan: [laughs] Grass kilt, so...

Kelli: That's kind of scary, considering Lua's primary usage as an embedded scripting language for a lot of game engines. I am picturing these bearded nerds in grass skirts.

Jonathan: [laughs] These shirts come in...

Kelli: Inscripting their WoW engines.

Jonathan: Especially the old joke, these T-shirts come in large, extra large, and programmer.

[laughter]

Jonathan: Grass skirt and neck beard. Enough of that damaging image and tempting visual. Lua, every time it comes up...let's start off by saying, I know next to nothing about Lua.

Kelli: I don't know a whole lot more than you do, but, apparently, I know enough to talk about it.

Jonathan: You've written a simple proof of concept game, and that is a quantum leap. I messed around with "Hello World," and we looked at the webscript.io website, which was super cool. I have to admit, I never used it after I originally thinking it was super cool.

It takes two seconds to learn Lua. The basics, the syntax, just so easy. I know next to nothing about it, but every time it comes up, it comes up in this context of gaming, so I never pay that much attention to it. In my mind, it's related to Corona. Is Corona a Lua library, do you know?

Kelli: Corona's, I guess, a Lua engine or library, whatever you want to call it, for iOS game development.

Jonathan: So it's like a runtime? Or is Corona more like...Corona is to Rails as Lua is to Ruby?

Kelli: I believe the latter.

Jonathan: That's my impression. It's some kind of Lua-based framework, but for game engines. I always think of it as a game thing and I'm not a game guy, so I immediately like, "I've got other stuff to worry about." A bunch of things that came out of your experiment seem pretty interesting and worth looking into. Can you give a rough idea, for the dear listener?

Kelli: Of what the game is and what I did?

Jonathan: Yeah. Let's start there.

Kelli: It's a very basic little arcade game where you're flying a spaceship and shooting asteroids, pretty much. That's all there is to it.

Jonathan: It's a side-scroller, basically.

Kelli: Yeah. A side-scrolling little arcade shooter. I'm using the, it's called LOVE, is the little game engine that I'm using. You just write the Lua scripts and you can package it all up as an executable for Mac, Linux, Window, whatever.

Jonathan: LOVE handles the packaging part? There's nothing about Lua that has anything to do with packaging, or anything like that?

Kelli: Right. Basically, you're just taking your Lua scripting and dumping it in the compressed file that is the .exe or the .app.

Jonathan: It's like a renamed zip file, I think.

Kelli: Yeah.

Jonathan: The first thing I see, when I see a game like that, I'm like, "OK. Conceptually, there aren't that many elements to it. There's a few different asteroid images, there's a spaceship base, and that's an image." You're like, "Oh, this would be really easy to render with HTML and make it move with JavaScript or maybe CSS." Maybe, but it would kind of be a pain to make a side-scroller. The thing that really would be brutal is collision detection.

Kelli: Yeah. Collision detection, sound effects. Sound effects wouldn't be that big of a deal now, I guess.

Jonathan: It's getting better. But it still would be...I would have to look it up. I wouldn't be able to just hack my way through it.

Kelli: The collision detection, definitely.

Jonathan: Is there something about Lua that makes collision detection easier, or is it something that's built into all of the frameworks? There's really two things. There's collision detection and physics.

Kelli: In the first place, let me say a couple of things. There are libraries out there for both. There are a couple of collision detection libraries that I've looked into. For this little thing that I've built, I ended up just kind of rolling my own. Actually, I think what made it easier to do, is just how clean and simple the language is.

Jonathan: Really?

Kelli: It doesn't get cluttered up with a lot of...I don't know, it just felt really clean. You could write this sort-of, kind-of complex thing and not over-complicate or confuse yourself.

Jonathan: Right. For the benefit of people who haven't seen Lua, the first thing I said when I saw it was, "This looks just like CoffeeScript."

Kelli: It looks similar.

Jonathan: It has that sort of lack of curly braces and semicolons that you expect from Python or Ruby. Is it significant white space, or is that...?

Kelli: No.

Jonathan: Or do they close it up? Their blocks are closed, right?

Kelli: Yeah.

Jonathan: It's just really, really clean-looking. It almost looks like pseudo-code.

Kelli: It almost does.

Jonathan: Is that why you think it's attractive to game developers? Just because the syntax is so clean?

Kelli: I think it's attractive to game developers because of that, because it has really a low learning curve. From what I understand, it's designed to be embedded in other applications, so it's very easy to do that. Maybe you have your game engine built in C, and then you allow people to script things in Lua. There's an API for doing that that's built in.

Jonathan: I see. There's lots of bridges to other languages?

Kelli: Yeah.

Jonathan: The reason why this is most interesting to me, I guess there's a couple of reasons. One is that, sure, the syntax is clean and great, and that's really nice, and everybody always likes that, but is that enough incentive to learn another language? No, not really.

But looking at it, it comes with all these different packaging options, which is super-compelling. It kind of reminds me of PhoneGap, in a way, where it's like, "You can write this thing, it's going to end up running just like it's supposed to run wherever." So that's cool.

Kelli: Yeah. Write your Lua script for one client at once, and then package it for all these different platforms. If you're doing a lot of things that tie into manipulating stuff with a file system or that kind of thing, then yeah, you may have to have, "OK, this is the Windows version, this is the Mac version." But, just for basic stuff like that, it feels like it is pretty much a "write once, run everywhere," where "everywhere" is a platform that supports the Lua runtime.

Jonathan: Cool. To keep this in the context of our normal spiel. Maybe I'm wrong, but I don't feel like a lot of people who listen are really into writing games, so they're probably like, "Who cares about this?"

Kelli: Yeah. It actually had some other interesting uses, outside of games, that I discovered when I was looking into it.

Jonathan: Oh, cool. What are those, before we go on?

Kelli: Adobe Lightroom. The interface is built in Lua.

Jonathan: Oh yeah? So you can extend it with...

Kelli: Yeah. MySQL Workbench plugin system is Lua.

Jonathan: Really?

Kelli: Yeah, and Apache and Nginx can both execute Lua.

Jonathan: As what?

Kelli: Like anywhere within the whole request-response process, you can inject some Lua code in there to do something.

Jonathan: Like in the same way that mod_PHP works?

Kelli: Yeah.

Jonathan: With Apache, you activate a lua plug-in and Apache hands off .lua requests too.

Kelli: I don't know about handing off .lua requests. I haven't really looked into it much with Apache. I just read that just a few minutes ago, but I know with Nginx, you can actually directly manipulate the data that's coming in with Lua script that's embedded in your server config file.

Jonathan: Oh, I see what you mean. Wow, geez. Holy God, who would go that deep into a Web server? I guess that's cool though, if you have a real lightweight Web server like that, you might explicitly want it so that you can customize it simply to do a very particular thing for your user-base.

Kelli: Right, if you're doing something, you could potentially build your whole system there directly on top of a web server, if you're serving some specific need.

Jonathan: Wow. If you're crazy because I would never do that.

[laughter]

Jonathan: That's very interesting though.

Kelli: I kind of want to try it.

Jonathan: Yeah. Just to get a feel for it. Every time I see a pop-up, I'm like, "Damn, this is really cool and robust," and I don't have a use for it. At least, I don't think I do, because the reputation of it is for game programmers.

Kelli: That is its primary use.

Jonathan: The thing about it that I think is compelling for people who are doing Web apps and building API's and trying to reach this global market, regardless of what device their on, is that it does have tons of integration with different environments, so that's really cool. And the other thing is that I feel like there is becoming a...I wouldn't say demand, but I would say that people are getting so used to Physics in the user interface of touch devices.

Even if it's just like the bounce-back on a scrolling list or if it's deceleration of a carousel that you flicked. They're just all OS stuff on like iOS. Windows phone has unbelievably gorgeous animations. 3-D animations are beautiful and the whole interface. You could say that they're gratuitous but it definitely enhances the experience.

If you are using a device eight hours a day on-and-off to 24 hours a day on-and-off, if you're me, a small enhancement like that, or it's actually a big enhancement, a cosmetic enhancement, if you will, becomes a big deal. It's especially, I think, useful for touch because it makes things look like they're responding more like things in the real world.

Kelli: It makes it look like they're actually responding to a physical touch.

Jonathan: Right, the rubber banding all that. Then you get inside of a Web app, let's say, or you get inside of a PhoneGap app and it is a pain to make any of that stuff work. You could easily double your code base trying to get rubber banding on a list for you working.

When you're in this situation of building stuff for mobile or for smart phones, there is constantly this tension between how much polish you want to add and this point of diminishing returns where, in order to add 10 percent more polish, you have to double your code base.

Kelli: Yeah, 80 percent more code for 10 percent more polish.

Jonathan: Right. But then it's like a self-defeating thing because you add that more code and maybe you make that thing work, but then you degrade the performance of everything else.

Kelli: Yeah, been there, done that.

Jonathan: But I feel like, eventually, there will be an expectation that even productivity apps and utility applications are going to have physics and maybe even 3-D animations. Definitely have animations, probably have 3-D animations and certainly have physics-style reactions. I could even imagine user interfaces that, even in productivity software, need collision detection.

Kelli: Yeah, I can too. I think that's only going to become even more relevant as we start to get into touch-list gestures.

Jonathan: Yeah, and 3-D touch list gestures. Not just swipe left and right, up and down, but also Kinect and MYO and Leap motion. Detect how the z-index, how close you are to the interface and how far away you are. It's unbelievably sensitive. To then take input that is so refined and then just use it to manipulate this 2-D space in this very clunky, chunky way is just not going to be compelling.

Kelli: Yeah, it's going to feel very awkward.

Jonathan: Yes, yes, it's like playing guitar with gloves on.

Kelli: [laughs] yeah.

Jonathan: It's just like, "This is awful."

[laughter]

Kelli: Yeah, yeah and actually I am very interested about the idea of taking something like this little game engine and maybe a physics library, or two, and seeing about building an app that's not a game. Maybe it's a little productivity app or some kind of monitoring tool.

Jonathan: It has to be a to-do list.

Kelli: Yeah, well it's either going to be a to-do list or a Twitter client.

Jonathan: [laughs] Right, right, right. It's like the "Hello World" of building an app. To-do list or a Twitter app. The big story...I feel like there will be a convergence of...

Kelli: The gaming physics.

Jonathan: Yeah, the gaming developers and the productivity developers and the Web developers. I feel like they're all going to end up creating...if you're creating an interface, you're creating an interface. Certainly you don't have to go to the lengths of like, say an EVE online style interface to interact with sales force.

My friends and I used to joke about, years ago, when we first started playing Halo, we were like, "When is Microsoft going to release Halo Meeting?" Because that's what we used to do. We're all over the northeast, U.S., we hardly ever got to see each other and we would all plan like, "Tonight we're all going to play Halo." Half the time we would just stand in a room with bombs going off around us. We'd hang out and talk.

Kelli: Yeah, I've done that many, many times.

Jonathan: It's weird. We could just talk on the phone but it's so much different doing it in a 3-D space and its way better than video chat. I don't know why. I'd rather video chat with my kid, but if I'm going to hang out with my friends, I'd rather be in Halo because then you could blow stuff up occasionally.

[laughter]

Kelli: Nice. I'm not a big fan of video chat. I'm always self-conscious. "Aww, I have to put on pants."

Jonathan: Well, you don't have to put on pants.

Kelli: I know. Just don't stand up.

Jonathan: Normally around the house, I just wear a tuxedo jacket and no pants.

[laughter]

Kelli: Just for those conference calls.

Jonathan: Yeah, it sucks. I'm Winnie-the-Poohing it all the time.

[laughter]

Jonathan: Anyway, off track there. I don't think this is right around the corner, but I would not be surprised to see a convergence of more game-style, not gamification, not any of that B.S. marketing stuff, but like actual game programming...

[crosstalk]

Kelli: Like the immersive environment.

Jonathan: Like inside of a sales force app. There's this ongoing debate in mobile development about whether or not you should look platform-resident when you build an application. Of course there are exceptions, but I feel very strongly that your default should be that your app should look like your app and like your brand and it should only make affordances for the particular platform it's on in very specific cases.

But by and large, users should be able to go from an Android version to an iPhone version to a Windows phone version and easily get around your interface without having to relearn it.

Kelli: Yeah, I agree. I've seen apps where the interface has changed a fair bit between platforms and it's just, "Why?"

Jonathan: Yeah, I mean forever Twitter on Android and Twitter on iOS were a complete disconnect.

Kelli: Instagram. Instagram was for a while too and it may still be. I haven't used an Android in a while.

Jonathan: Windows phone is a huge violator of this because the operating system is so in-your-face, I guess. The metro interface is so in-your-face, and it's nice, but it does have that "my way or the highway" feel to it.

Kelli: Yeah. You're going to design how they want you to or you're not going to be on the platform.

Jonathan: Right. I tweeted something about...I can't remember what the app was. It might have been Facebook. The Facebook app on Windows phone is unusable, not because it's bad, but because I can't figure out how it's supposed to work. Because it's a very complicated app. There's a ton of stuff going on in the Facebook application.

I use Windows phone all the time but I cannot figure out like, "What does the back button do? What happens when I swipe left or right here," because, generally in the Windows phone environment, swipe left and right in an app is reserved for switching between tabs. There's no notion of swipe to delete an item in a list. That gesture is basically banned on Windows phone.

Kelli: That would get...yeah, that's just breaking a lot of pretty much accepted patterns at this point.

Jonathan: On other platforms, right? And it's not that it's bad. It's cool the way that they have it. The OS is a little too pushy for me. And apparently it's actually enforced in their approval process because I tweeted jokingly, "How come is this app totally unusable on Windows phone? Why does it look the same on iOS, Android, mobile Web, and every browser, and then Windows phone, it's completely different?"

Kelli: It's because Microsoft made them do it that way.

Jonathan: Yeah, somebody tweeted that back to me. I have no idea what their experience level is with Windows phone. It was a while ago now but that was the impression. Boy, I'm making a long story longer. [laughs] The point is that, with rare exceptions, I don't think you should give into looking platform-resident because that's the platform vendor trying to create more lock-in.

There's nothing about that that's advantageous to the developer except for things like affordances that have become commonplace and that is where I would make exceptions. But the funny thing is, when people have that debate and you can be on one side or the other but people debate should you or shouldn't you be, and everybody gives games a free pass. Like in that debate, everybody says the same thing as soon as they start talking about it.

Kelli: Games should be the same.

Jonathan: Yeah. So that was my retort to everyone who was like a big, "Oh no, it should look like an iOS app and it should look like an Android app." And I am like, "Well what about Angry Birds?" Like why does Angry Birds get to look like Angry Birds everywhere?

Well, games are different. I'm like, "OK well, why?" Shouldn't it be buttons? Your app should look like your app. Obviously, I understand that a game is an extremely graphic-intensive environment. It's like a totally different type of thing because you don't have controls the same way that you do with a Twitter client.

Kelli: Like a ListView?

Jonathan: Yeah, you don't even have a ListView. Man, I am making this longer than it needs to be. I am good at that.

Kelli: I see where you are going though. I can see the light at the end of the tunnel now.

Jonathan: I am slowly coming to a point. It's not a great point, so I am really trying to work it, build up the anticipation. And that point is that all these apps are going to be just like games, eventually. In the sense that the old school desktop metaphors of a button. I'm not saying ListViews are going to go away, or buttons are going to go away, but it's going to become a lot more like direct manipulation of business objects...

Kelli: The beta.

Jonathan: Or objects of interest. I can imagine a lot more physics, a lot more collision detection, and seeing the platform start to disappear when you're in the app.

Kelli: It's going to become a lot more immersive and it's going to be less, "Here's a thing you use," and more, "Here's an environment that you interact with."

Jonathan: Right. The point being is I'm getting more and more interested in Lua. I guess that's not the point, that's the outcome, is that I'm getting more and more interested in Lua.

Kelli: [laughs] It's definitely piqued my interest now and I'm going to do some experimenting with it in my copious free time.

Jonathan: [laughs] Big questions from me are, let's say the expectation of a user interface, even for a productivity or utility app, becomes such that people are expecting it to be this immersive, almost game-like experience. I feel like that will be at the expense, somewhat, of some of the stuff that the web is totally good at, like accessibility.

Kelli: Accessibility, and just the rapid and easy dissemination of information.

Jonathan: Right. I don't know how I feel about it, I'm sort of torn about the whole thing. If we went into game-y apps...

Kelli: The sci-fi geek in me would be like, "This is awesome."

Jonathan: Awesome, right. Then the flip-side, it's impossible to imagine that something like that would be usable with a screen reader.

Kelli: This is why your little game-y app needs to pull all of its data from your API.

Jonathan: I suppose that is the escape hatch. If the interface is separate from the game, really, it's like slapping a really cool Halo interface on top of Zork.

[laughter]

Kelli: You can still open up the...

Jonathan: I just got the weirdest visual on that. That is like...

Kelli: Yeah, me too.

Jonathan: [laughs] Oh God, I would love that. The API is the escape hatch. If you really need access to this data and services, this isn't the client for you, because you can't use it for some reason like you don't have fingers or whatever. But you've got these other options because this is just one interface for it.

Kelli: That just goes back to what we we've been saying all along. Regardless of how well designed your interface is and whether that intent is to be purely informational or immersive or what have you, one interface is never going to be the perfect fit for everything.

Jonathan: That's for sure.

Kelli: Wow, I got a "you know" and a "what have you" both in that sentence.

[laughter]

Jonathan: We both have to drink.

Kelli: I didn't get any booze.

Jonathan: What?

Kelli: I know I said I was going to, but then I just totally forgot.

Jonathan: You promised yourself.

Kelli: It was going to be my reward for absolutely nothing.

Jonathan: Cat tried to kill you. That's probably enough for this week, don't you think?

Kelli: Probably.

Jonathan: Hopefully we've piqued your interest in Lua, and if you have some kind of need for that kind of interface, then you can look into it, or you can just keep it on your radar as things develop.

Kelli: If nothing else, it's a fun thing to play around with. I've enjoyed it. I'll send you a link to my silly little game.

Jonathan: Yeah. Post it in the show notes.

Kelli: A silly little web page up for it.

Jonathan: Cool. Of course that will be in the show notes.

Kelli: Source code's on GitHub and all that stuff.

Jonathan: Natch.

[laughter]

Jonathan: All right. That's our show for this week. I'm Jonathan Stark.

Kelli: I'm Kelli Shaver.

Jonathan: We hope you would join us again next week for the Nitch podcast. See you later.

Kelli: Bye

Episode 54: The Royal You

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 26 Apr 2013 00:00:00 +0000

Episode 54: The Royal You

April 26, 2013

Running time: 36:56

Jonathan and Kelli talk about jQuery vs. Zepto... and other pointless debates.

Download (27.8 MB)

Titles We Considered

It's All Geek to Me
It Just Feels Dirty
The Royal You
Fuzzy Points

Transcript

Jonathan Stark: Hello and welcome to the Niche Podcast for Friday, April 26, 2013. I'm Jonathan Stark.

Kelli Shaver: And I'm Kelli Shaver.

Jonathan: This week, we talk about GQuery versus Zepto, and other pointless debates. Please stay tuned, the Niche Podcast is next.

Kelli: You did that wrong, but I won't correct you.

Jonathan: What did I do?

Kelli: You forgot the whole bit about building apps that run everywhere.

Jonathan: Oh crap! A couple weeks ago I said the wrong date. [laughs] That's right. That's OK, we'll run with it. [laughs] That'll be an Easter egg for the regular dear listener.

Kelli: Both of them.

Jonathan: [laughs] Exactly. Both of our moms are listening?

Kelli: [laughs]

Jonathan: What did you say about the nerds in the other room?

Kelli: I said they're doing scary difficult math, and I don't even understand how it's actually math. It has no numbers. It's just all Greek alphabet and funky symbols.

Jonathan: That's where my inferiority complex kicks in. I feel like I should understand that, but I don't.

Kelli: Yeah. Right now, I think they're, [babbles] "looking through time" or something.

Jonathan: [laughs] Oddly enough, earlier today I actually derived a function.

Kelli: Wow.

Jonathan: Which I haven't done since high school. I don't know if you saw this on Facebook, but me and 100-and-change people have been doing this "100 Days of Burpees" thing.

Kelli: Yeah. I wondered if you were still doing it, because I hadn't seen updates in a while.

Jonathan: I've been plagued by injuries. If you skip two days, you have to start over. I've had to start over twice now.

Kelli: [groan of sympathy]

Jonathan: It's hard! It's a really demanding exercise. It's crazy. In five minutes, you get all the exercise you need for a day. It's really demanding. It hurt my wrist, and my hip, and I'm falling a part. I need a few replacement parts.

[laughter]

Kelli: An eyeball.

Jonathan: I haven't lost an eyeball yet. I know you recently popped a gasket. [laughs]

Kelli: Yeah.

Jonathan: Because of all your exercise.

Kelli: Yes, all this getting into shape is going to kill me.

Jonathan: [laughs] I've been more out of shape since the house fire than I have in a long time, because I usually use a standing desk, but I haven't.

Kelli: Yeah.

Jonathan: But also, I derived a function out of...the way the burpees thing works is, day 1 you do 1, day 2 you do 2, on and up to 100. I was like, "Oh, this is like a normal number series, Fibonacci or something."

I looked around and went, "No, it's not Fibonacci." I couldn't find it anywhere." I'm like, "There's no online calculator for," maybe I didn't know what to call it. I was like, "Well, if you think about it. If you do seven...I was picturing the numbers, one, two, three, four, five, six, seven."

Kelli: Yeah.

Jonathan: Just randomly. If you take the very first number one, and the one right before seven, and you add them together you get seven. If you take two and five, you get seven. If you take three and four, you get seven. It's really just seven times, and you have to figure out how many times, to times the seven.

I was like, "Oh, well, it's obviously N*N-1/2+1."

Kelli: [laughs] Obviously.

Jonathan: [laughs] It totally works. I was extremely proud of myself, but I didn't use any -- no Greek letters though.

Kelli: No Greek letters, yeah. My high school math teacher was the football coach.

Jonathan: That's pretty weird.

Kelli: It was [inaudible 04:05] .

Jonathan: Home Ec Teacher. [laughs]

Kelli: No, he was the football coach in my senior year. It was the first class of the day, and he liked to read the paper. I didn't actually do much math, that year.

Jonathan: [laughs] I see.

Kelli: If we get beyond basic algebra and geometry, I'm lost.

Jonathan: Yeah, I aced all my math classes, until calculus senior year, which I failed.

Kelli: Richard is taking a calculus 2, college calculus 2, right now.

Jonathan: I blame my teacher, frankly.

Kelli: Yeah, I blame mine.

Jonathan: I guess so, if he's just reading the paper.

Kelli: [laughs] I think we did three or four lessons earlier.

Jonathan: Delicious. [laughs]

Kelli: When you're 17, you don't think to complain about those things, because, "Hey, easy A."

Jonathan: Right. But, goddamn it, now I want to know how a helicopter works, and you need calculus for that.

Kelli: Yeah. [laughs]

Jonathan: What a week. [laughs]

Kelli: Yes.

Jonathan: We have both been heads down working, and also all sorts of political stuff in the news. Just a very distracting couple of weeks...

Kelli: Yeah, it has been.

Jonathan: ...in terms of fun apps that run Everywhere content. But something came up the other day that really grabbed my attention, I think because of the statement and the person who made the statement. As dear listener will know, we're big fans of the BD Conf, Breaking Development Conferences.

At a recent BD Conf, I think it was Orlando, Paul Irish did a talk called, "The Mobile Web Is in Trouble," which, coming from Paul Irish, is a pretty rad thing to say. I think he's a developer advocate at Google, and, just like a wicked web guy, he's got a bunch of really popular web projects to his credit, Modernizr, Yeoman, and...

Kelli: Isn't Boilerplate his, too?

Jonathan: Yeah. HTML5 Boilerplate and Mobile Boilerplate, all that stuff. Again, he's very, very dedicated to mobile. I've seen him give a bunch of talks that are super cutting-edge web -- sorry, I didn't mean to say "mobile," he's a web guy in general. A bunch of really super interesting, cutting-edge talks.

When you see him talking about stuff, it's like, "That's a great demo, but it's only supported in Chrome Canary bleeding-edge nightly." [laughs]

Kelli: [laughs] Yeah.

Jonathan: In six months, maybe I'll worry about it, but it's always so far ahead of the curve that you almost can't come up with a use case.

Kelli: It's just eye candy.

Jonathan: Yeah, exactly. For a particular...

Kelli: Practical, yeah.

Jonathan: If I see something that is limited to a particular browser, especially a particular version of a browser, for support, I don't care. I immediately don't care about it. But it is pretty amazing, and that's where everything comes out of, of course. Things like WebRTC, and even accelerometer support, GPS, and all that stuff.

It's good to have your thumb on that, but when he comes and does a talk at a big conference, a big web conference about "The Mobile Web Is in Trouble," it makes you think, "What's he talking about?"

Kelli: Yeah, you sit up and listen.

Jonathan: Right. That is exactly what I did. I read LukeW's notes on his talks, which is always a great resource for quickly getting up to speed with what's going on at...He goes to BD Conf a lot, so that's a good way to keep up to date with the "thought leaders," to use a hackneyed term. In the space they're doing is follow LukeW and read his notes on his different talks, because he goes to great talks, way more than people who have real jobs can afford to do.

Kelli: [laughs]

Jonathan: [laughs] He just has a great take on it. If you go to lukew.com, you can follow that stuff. His notes on this one...there was just one particular bullet point that stood out for me -- especially because I'm totally guilty of this -- which is that the size difference between jQuery and Zapto, which is advertisers are dropping jQuery replacement JavaScript library -- the size difference is about a third of a typical sized JPEG.

Which is to say that it's barely any different when you consider that most sites are going to have a ton of JPEGs [laughs] that need to be downloaded, and the difference in downloading a little bit more of JavaScript is negligible.

Kelli: Yeah. Insignificant.

Jonathan: You can agree with that or not, but before I looked at it like that, I would have said something like, "Every bit of performance..."

Kelli: Every bit counts.

Jonathan: Yeah, every bit counts. But really, there's two sides to that. When you think of all of the development resources that end up getting thrown behind Zepto that would have maybe been better served doing something else, you start to think, "It's great that anybody can start a library and gain traction, but...

Kelli: Is it a good use of your energy?

Jonathan: Yeah.

Kelli: Worthwhile?

Jonathan: Really. jQuery is, maybe it's a little bit of an edge case because it's so dominant. But it's really hard to argue with jQuery. It's really, really hard.

Kelli: Yeah, it is, especially now with 2.0 and the modularity that you have there.

Jonathan: Yeah. They basically addressed every argument you could make against jQuery. You can swap out the selector engine to something that is basically a thin wrapper for a query selector All, or you can compile it using Grunt, which is like a compiler for websites basically.

You can compile pieces of it, just the pieces you're using, or obviously you can minify it. There are other build tools you can use that just use the pieces of jQuery that are important to you. They removed support for IE less than 9, so all of that [inaudible 11: 00] coat is gone. Now jQuery, inside of jQuery, the new IE6 is basically Android on 2.3, which is the new crap browser that they have to support, so, irony.

But the big picture thing is worth thinking about. How much do you gain all the way across the life cycle of the application. How much do you really gain by using Zepto versus jQuery? It reminds me of arguing about the footprint of a PHP framework. It's like the footprint doesn't really, it does matter, I admit that it does kind of matter, but it doesn't really matter.

Kelli: Yeah, especially if you're talking about a file-size footprint and not, say, a memory footprint.

Jonathan: Oh, yeah. That's what I mean.

Kelli: Who cares if your framework is 60 megs if you're only using a tiny portion of it? So what?

Jonathan: Yeah, like...

Kelli: Hard drive space is cheap, and it's not hurting anything by being there.

Jonathan: Right, I'm the first person to say that it bothers me to download a monolithic PHP framework, but it doesn't really...but I realize that I'm being ivory tower about it.

Kelli: It really only bothers me if I have to hunt through all of that to find the thing I need to use.

Jonathan: Right, which really isn't...it's more a function of the documentation and...

Kelli: ...and developer skills.

Jonathan: Yeah.

Kelli: Their experience.

Jonathan: Right. If you assume that the performance, the memory footprint, the functionality is all the same between framework A and framework B, it's still executing on the server side, what difference does it make how many files there are? Who cares?

Kelli: Yeah. It doesn't as long as, if you're comfortable with using both, it doesn't matter if you have more files. If you know how to use it, you know how to use it. It doesn't matter if it's bigger.

Jonathan: Right. Obviously it's a different debate when you're talking about front-end code, because you have to transfer it over the network. But the point is the same. Where I could actually -- and I think we do it on the podcast -- talked about how, "Oh, geez, KPHP just seems so crufty." Like, who cares?

We could talk about it, and we can have an opinion about it, but it's one of those things like...But does it really matter, and are we using our skills in a productive way, or are we just naval gazing?

Kelli: Yeah, unless the reason your framework is so large is because you've gone to great lengths to abstract stuff, way beyond a level that is reasonable and makes it sane, and easy, and logical to use. Then who cares?

Jonathan: Right. You can imagine someone saying like, "Single page, PHP, NBC framework," and everyone be like, "Wow." It's just one file. I just have to install this one file. I'm going to relearn...

Kelli: Don't use Zen. You can use (inaudible 14:18).

Jonathan: Yeah, exactly. The thing I don't like...

Kelli: I don't like Zen.

Jonathan: ...about Zen is the API...not the API, but everything is just so verbose and confusing. The documentation is just too...it's too many features, which is different.

Kelli: I feel kind of the same way about Symphony. Less so, but...

Jonathan: The big point is that you can have holy wars about stuff that's just stupid. In his talk he's like -- talented web developers, because I think it's Thomas Fuchs behind Zepto, and he's like this originally this scriptaculous guy, and prototyped doT.js. Here you've got a really talented guy who is -- I almost want to say wasting his time, and wasting everyone's time by writing a jQuery alternative that is barely smaller.

But the marketing, if you want to call it that, is very attractive because it included the dropping support for crappy browsers. Like we don't need that crufty crap for IE6. Everybody wants that code to be gone, not that anybody ever looks at it, or thinks about it really, inside of jQuery...

Kelli: You just feel dirty having it there?

Jonathan: You just feel dirty having it there, exactly. It feels clean to have it gone.

Kelli: Even though it's not that much code?

Jonathan: Yeah, evidently, because they took it all out of jQuery 2.0, which has been released by the way, the official release. It's like 20 percent smaller than the jQuery 1.9. I'm guilty as charged, but it is really interesting when you think about it like, "How could that time have been better used"? Really the weak point on the Web right now, I think, is tooling. It's just not much there.

Kelli: There's what?

Jonathan: Tooling.

Kelli: Tooling, yeah.

Jonathan: Tools, like Workflow. I've got the beta version of Chrome developer tools. I'm a huge fan of the Chrome developer tools, Firebug people, it's similar to Firebug. It's just getting better and better with each new release. But it's still not...when you have a memory problem with your JavaScript, it's like...

Kelli: Dove tools are just going to lock up and crash and burn. Because of the way threading is held in Chrome, you're not going to lose the whole browser, but that tab is going to become useless rather than kind of recover from that memory problem and say, "Oh, hey, this is where your error is."

Jonathan: The other day, I'm working on this sort of big slide show thing, a responsive slide show, a jQuery plugin. And it's very responsive in that it takes an ordered list, so ordered list, LI, with image, caption, photo credit. That's the baseline experience.

If you come to the site with a crap phone, you're going to see this list of photos with captions. If you have CSS, then of course the CSS is going to make it look a little nicer. If you have JavaScript, it's going to make it a little nicer. If you have really awesome JavaScript and touch events, it's going to make it even nicer.

One of the things that, what I'm testing it on, like a laptop, the new modern browser, and I was getting like a two-second delay every time I would try and switch from one slide to the next. What do I look for? There's memory profiling tools and I can see, "Oh, the paint is taking a long time." But there's no...OK, that's better than we used to have, but if you compare it to Xcode -- which I hate, but it is awesome. Xcode is like, "Here's your problem, click here to fix it." It's pretty amazing.

Kelli: The debugging in Xcode is nice.

Jonathan: They have an easier nut to crack, so they've gone farther with it. But it is true that the tools on the Web kind of stink ,and we're seeing more and more of them emerge from places like The Filament Group and Remy Sharp and Google and all over the place.

But still it's nothing compared to native development, and when you look at the numbers, people are spending according to -- I don't know where these numbers come from, if it's flurry or what, which would naturally be skewed -- but the ad networks are saying that people are spending more and more time in native applications, and the time in Mobile Web has sort of plateaued.

There's a lot of ways to take that, but I think his point is well taken, which is that people are spending their time worrying about stupid stuff and not contributing to the overall platform, which is sort of the beauty of the Web as a platform.

Kelli: The openness of it.

Jonathan: Exactly. If you don't like something, you can...

Kelli: Make it better...

Jonathan: ...you can make it better. Just go and send some poll requests to your favorite project on GitHub.

Kelli: Yeah.

Jonathan: That's funny, because we've had conversations before, speaking of GitHub, about the GitHub effect on development. I think that it's fair to say that there's a bit of a decision paralysis that exists now because of GitHub.

Kelli: There is. You have so many options, and maybe you find a project that you like, but then there's so many different forks of it and...

Jonathan: There's always a newer thing that sounds cooler, so you never get good at anything. You're always in this constant state of learning this new plug-in, or learning this new little framework, and slapping it into a project, and you never use anything twice.

On the one hand, as someone who's using lots of GitHub projects, there's this desire to be on the cutting edge and have the latest and greatest thing that has dropped support for IE6 or whatever.

Kelli: On the other hand, sometimes you need to use things that just work.

Jonathan: Yeah, let's get some work done, people.

Kelli: I don't know about you, but I've got a pretty standard set of gems and libraries and things like that, that I will use on projects. If I need something that goes beyond the capabilities of those, then I'll go looking for new things, but I definitely have some defaults when it comes to libraries and things that I'll use.

Jonathan: What are those for you these days?

Kelli: JQuery is one of them, even on mobile, and I know you and I had disagreed on that.

Jonathan: Yep, but now, with 2.0, I'd definitely change my mind.

Kelli: JQuery and I use Font Awesome a lot. Actually I've recently had a chance, with the CSS simple library that I did a while ago, couple weeks ago, [phone rings] I had a chance... It's our weekly podcast phone call...

Jonathan: [laughs]

Kelli: I recently had a chance to use that on a real life project, so that was nice. Then there's several ruby gems, like Rabble for building API, rest APIs and AWS gems and things like that.

Jonathan: Oh, wow. I was expecting you to say more things that I was familiar with, but some of those are new to me, so that's cool. We should definitely link to all that stuff. I think it would be good to do a show that's updated from the last time. We did a show on this a while back.

Kelli: We did, but I think we've both probably changed a few things.

Jonathan: I've shifted back a little bit toward jQuery and even deeper into AWS, as I know you have as well. That would be good to do. Maybe next week, we'll do a show about our toolboxes, basically.

Kelli: Not so much offering software, but I'm thinking more libraries.

Jonathan: Frameworks and libraries.

Kelli: Libraries and gems and that sort of thing. I'm doing a lot more ruby development than I was probably the last time we did that.

Jonathan: Cool.

Kelli: If I have to do anything in PHP, it's going to be CodeIgniter.

Jonathan: The only thing that I've used in PHP framework-wise besides CodeIgniter is Slim.

Kelli: That's one I would consider.

Jonathan: It's super, it is lightweight, but that's not the point, in terms of file size and everything. It's just very straightforward. It's not perfect, that's for sure, but again, I think it's more about just learning your tools, getting down with them because the difference -- maybe that's the theme of the show -- is just be pragmatic about, really what are you gaining by constantly keeping yourself on this learning curve? What is the benefit?

Kelli: Every now and then, there's a tool that comes along, and it is going to be better and it may be smaller or it may be faster, and it's important to keep up to date and be aware of what's going on so that you can make those decisions of when that's a better tool to use.

But a lot of times, you just need to get things done, and don't necessarily need to be playing around with the newest and greatest on every project.

Jonathan: The decision paralysis that I mentioned earlier, that sort of comes from the popularity of GitHub, I think there's a flip side to that too, which is that I feel like everything I write has to be publishable. I feel way more self-conscious when I code now, because I'm storing everything in GitHub and it's private probably, but I still feel like, "oh, well, how could I abstract this?" I really should encapsulate this differently and make it more repurposable.

Kelli: I should do this so I can release it on GitHub.

Jonathan: Right. It totally slows me down.

Kelli: I don't write just for me anymore.

Jonathan: Right. Me neither. I don't write to solve the problem, now I'm writing to solve the problem and create a framework or a plug-in or a library.

Kelli: Something that someone else can use.

Jonathan: Exactly.

Kelli: I guess there's value to that, because you end up getting things that you can later reuse. But at the same time, if you're putting a lot of effort into creating this nicely polished, jQuery plug-in that does some funky 3D transform on your screen when you hold the phone at a 32 degree angle in a dimly lit room...should you really be wasting your time on that? When are you ever going to need it again?

Jonathan: Exactly. It's like a highly specialized code. Some of the libraries that you see are, in my opinion, way, way too clever. A classic example is a hash bang, URL's...that was a mistake. It's stuff like that I see cropping up. Like, "Oh, we're going to do all, we're basically going to" -- how do I say this -- "We're going to try and hack around the behavior of the way browsers work to make it a little bit faster." And when I see hacks, I'm like, "That's a hack," and if I don't have a problem...Until I know exactly what the problem is, I'm not going to do a hack.

Kelli: I tried that on the app I'm working on. I tried it a couple of months back and we got about twp days into it and, "OK, this is a waste of time."

Jonathan: Which?

Kelli: The...

Jonathan: Hash bangs?

Kelli: No, just trying to come up with clever things to sort of outwit some of the default browser behaviors.

Jonathan: Exactly, outwitting the browser, that's exactly it. The people who make these browsers have been doing it for a long time and they're some very...

Kelli: They're a lot smarter than I am.

Jonathan: They are -- not you, I mean...

[laughter]

Kelli: You said that with a lot of enthusiasm. [jokingly]

Jonathan: I meant you, the royal you. I meant you, dear listener. They're wicked smart, like every time I read one of these things, I'm like, "Oh my God, these dudes and dudettes have thought this through way more than a Web developer can , because they don't even get it."

Kelli: Because we don't have to, because they've done it for us.

Jonathan: Right. You don't realize, not you...

[laughter]

Jonathan: People don't realize how good we have it right now.

Kelli: On this week's podcast, John talks about how dumb Kelli is. [jokingly]

Jonathan: It's just so true, though.

[laughter]

Kelli: Thanks. [sarcastically]

Jonathan: Not that. If you wanted that, you could just go into the Greek room next door. [jokingly]

Kelli: [laughs]

Jonathan: No, I'll give you an example that I think everybody can appreciate. Responsive web design, everybody's talking about it. It's the cool thing. A big issue with responsive web design is, what images do we send? If somebody's on a tiny little phone, or somebody's on a 30" cinema display -- imagine a retina cinema display -- it would be nice to send that 10,000-pixel image only to the desktop, and send down a 20k .jpeg version of it to the mobile device.

The consideration isn't really the size of the screen in most cases.

Kelli: It's the bandwidth.

Jonathan: It's the bandwidth, right. I don't want to make a decision about what size file to send based on the width of the view port. What I really want to know is the bandwidth. Because that 30" cinema display might be tethered to an iPhone, connected to the Internet over the iPhone. What you really care about is the bandwidth.

A lot of people have called for bandwidth media queries, like, "I just want to know the connection speed." But if you spend 10 minutes Googling around for "bandwidth media queries" and read? There are posts about why even the concept of that is so stupid, that it's ridiculous.

If you talk to a browser vendor, someone who makes browsers...

Kelli: They laugh at you.

Jonathan: They would just laugh at you. It's totally impossible.

Kelli: That's how packets work.

Jonathan: Right. There's no way to do it. The way that the Internet works makes it impossible for bandwidth media query to exist. Even if it didn't, your bandwidth can change at any time, so then what?

Kelli: It can change in the middle of a download.

Jonathan: Anyway, the point being is...what is the point?

Kelli: [laughs]

Jonathan: This particular point...

Kelli: [laughs] The point is, Kelli is an idiot.

Jonathan: [laughs] I'm glad that's clear. [sighs] I didn't want to say it.

[laughter]

Kelli: Someone had to.

Jonathan: The point is -- a couple of things here. You're not going to outwit the browser, the people who are making the browser. You're not going to do it.

There might be some small gains that you can get, but you don't have to look any farther than Steve Souders. It's 10 basic principles, you just apply them as you can. If you can't, you can't, and if you can, you can.

Don't try and fake out the back button, or pretend to send down a 50 megabyte Web app, with all the code commented out, so that you can have a small dom, and then you uncomment portions as you need them. That is a solution to a particular problem, like Gmail. That's not like a library you use on every project.

Kelli: [laughs] The point of the whole thing is, is don't overthink it to the point that you're wasting time and resources.

Jonathan: Yes.

Kelli: You can always go back and optimize more as needed.

Jonathan: The other thing that drives me crazy, while I'm ranting, is that a lot of this premature optimization, BS, is, in my personal experience, always centered around a design. Now I'm going to get myself in trouble.

The BS is centered around making a bad design work. It's not a bad design, that's not the right way to put. It's a design that is responding to bad client demands, I guess. It's code that is written, to make 10 pounds of shit fit in a five-pound bag.

Kelli: [laughs] Yeah. It's not the right solution for what it's trying to do, or it's trying to do something that it shouldn't be trying to do.

Jonathan: It's like, "Make this impossible request possible." You can kind of make the impossible request less bad by doing all sorts of crazy hacks and stuff, but really the solution is to make the request less silly. Like, "How do we fit more stuff onto an iPhone screen?" You can't.

Kelli: You can't.

Jonathan: You make it smaller. That's what you already have. You already have your desktop site zoomed out. That doesn't work, so you have to pick some stuff to not put on the screen.

Or, let's use a carousel, so we can have everything on the screen in the carousel. But it's not on the screen. It's still not on the screen. So why not just prioritize your content and not put it on the screen...

Kelli: Yeah, prioritize your content.

Jonathan: ...since you're not anyway. [laughs] Then we don't have to write a carousel. [laughs] Which is going to be wonky and buggy on all different platforms. What's wrong with a scrolling page? Can someone tell me what's wrong with a scrolling page?

Kelli: Nothing is wrong with a scrolling page.

Jonathan: Thank you.

Kelli: Nothing.

Jonathan: [laughs] Scroll the page.

Kelli: Scrolling on a mobile device is ridiculously easy. It's a flick of the thumb.

Jonathan: It's very stable cross-platform.

Kelli: It is, and it's very fast.

Jonathan: Then all that content is not on the page, so let's pretend it's on the page by putting it in a carousel.

Kelli: Just put the important content on the top of the page.

Jonathan: [laughs] That would force us to decide what the important content is.

Kelli: [sarcastically] Oh.

Jonathan: That's not happening. We'll put it all in a carousel at the top of the page.

Kelli: That requires more effort than scrolling.

Jonathan: Which should be the first slide? It should be randomized, and then it should change every time.

Kelli: Automatically.

[laughter]

Jonathan: I'm not sure if we've made a point.

Kelli: I think we've made a lot of points in disguise. We've made fuzzy points.

Jonathan: We did start out by saying it was about pointless debates, right?

Kelli: Yeah, and the whole podcast has been a pointless debate, so...

Jonathan: [laughs] Exactly.

Kelli: Mission accomplished.

Jonathan: I won't try and sum up because that would just lead to another pointless debate. So I guess that's our show for this week, dear listener. I'm Jonathan Stark.

Kelli: I'm Kelli Shaver.

Jonathan: We hope you join us again next week for the Niche Podcast. Bye.

Kelli: Bye.

Episode 53: Fluffdates

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 19 Apr 2013 00:00:00 +0000

Episode 53: Fluffdates

April 19, 2013

Running time: 33:30

Jonathan and Kelli sit back and say "I told you so" for 30 minutes as they talk about Glassware, the Mirror API, and improved methods for the distribution of cat photos with Google Glass.

Download (25.5 MB)

Titles We Considered

Edison Schedule
Kinda Brilliant, Kinda Whacky
Epic Internet Toaster
Fluffdates
Maxcats
Bi-Pub/Sub
Less Frictionless
Nose Shortening
Retina Retina

Transcript

Jonathan Stark: Hello and welcome to the Nitch podcast for Friday, April 19th 2013. I'm Jonathan Stark.

Kelli Shaver: I'm Kelli Shaver.

Jonathan: We're here to talk about building apps that run everywhere. This week we sit back and say, "I told you so" for 30 minutes, as we talk about glassware, the mirror API, and improved methods for the distribution of cat photos with, wait for it, Google Glass.

Kelli: Hurray!

Jonathan: Yay! Hurray! Please stay tuned, the Nitch podcast is next. Huh...Yes, I hope my sound's not too bad, I'm recording in an actual office today.

Kelli: Yeah, in a real office.

Jonathan: Yeah. It's like a midrange hotel room type setup.

Kelli: Nice, without the bed I'm assuming.

Jonathan: [laughs] I wish.

Kelli: [laughs]

Jonathan: If it did, I'd probably be napping.

Kelli: No, you don't want a bed in your office, I speak from experience.

Jonathan: [laughs]

Kelli: It's not a good idea, cuts into productivity.

Jonathan: That will happen, yeah.

Kelli: Yeah.

Jonathan: We're both on the Thomas Edison schedule.

Kelli: Yeah.

Jonathan: I can't sleep for more than like...I can either sleep for three hours or 11.

Kelli: [laughs] It's the same here, yeah.

Jonathan: I never get sleep for 11, so...

Kelli: Yeah. I either fall asleep at 3:00 AM or 7:00 AM; those are the only 2 options.

Jonathan: Yup. Yeah, I'm almost exactly the same, it's bizarre.

Kelli: We've synchronized.

Jonathan: [laughs] Yeah, I'm on Kentucky time.

Kelli: [laughs] I was hoping I was on Rhode Island time.

Jonathan: [laughs] Anyway, very, very exciting week this week.

Kelli: Yes.

Jonathan: We are going to gloat.

Kelli: Yes, we are. [laughs]

Jonathan: It was Monday, Google published a documentation for Google Glass Developers. The current Google Glass Developers are called, "Explorers." I guess, "Glass explorers" are entitled to receive a pair of demo Google Glass glasses.

Kelli: We all hate them.

Jonathan: I'm so jealous.

Kelli: Yes. I watched an un-boxing video yesterday, it was maddening.

Jonathan: I'm in pain, I'm in physical pain.

Kelli: I am too, it just hurts.

Jonathan: Anyway, so developers are starting to get Google Glass in their hands, the actual device. Of course, Google needed to publish some documentation and guidelines for working with it. I think, we're both in the same camp, which is that I'm kind of excited about how different it is than developing for anything else that exists.

Kelli: Yeah, me too. It's completely different than making a web page. It's all over HTTP.

Jonathan: It's wacky.

Kelli: It is.

Jonathan: It's brilliant and wacky. It favors people like us, basically, people who think that content is layout agnostic or presentation agnostic content is critical, API's are hugely useful and lightweight delivery of content and services is critical.

All of the things that sort of came out of the early iPhone days when bandwidth was crappy and things were very restrained. A lot of stuff that came out of that would serve you well if you really adopted it properly.

When the iPhone came out, I'm going in the weeds here, but when the iPhone first came out, people got really jazzed about mobile web development for the first time.

Kelli: Yeah and then, they saw how slow it was.

Jonathan: Yeah, so it was kind of like going back to the dial up days of web development.

People got very smart about it or they at least realized that they needed to get smart about things like image compression, being stingy with their HTTP requests, not including a million CSS and JavaScript files, and making sure that the stuff that they were including was actually being used, all the stuff that we got lazy about in the broadband desktop days came back to bite us.

There were two big things that people could focus on as the realization sunk in. One was getting your content..."Oh no! This is going to start happening over and over again." People would try and get their content squared away, and try and make their delivery of content very lean and mean. There was a group of people who got really excited about optimizing their mobile web experience specifically for iPhone, using things like WebKit only extensions and very specific touch interactions and lots of Apple's specific extensions, home screen apps.

I was definitely in both of those camps. A lot of people were in both of those camps. Now as the time's going on...although very iPhone specific stuff, and the WebKit specific stuff had a limited usefulness when Android started to get really popular, because a lot of that stuff didn't work. Or it didn't even make sense on Android.

Then we started talking about smartwatches, and the epic Internet toaster, and then finally Google Glass. When Glass was announced, it was like, "there's no way that you can develop for Glass the same way as you can develop for any kind of mobile smartphones, and man, were we right.

Kelli: Right. You can't have this complex html JavaScript CSS web page projected onto the back of your eyeball from this little tiny prism.

Jonathan: Yes. Do you even have your head around the way it works? The model?

Kelli: Not entirely. I haven't had as much time to read up on it, as I think you have.

Jonathan: Yes. I think I have my head around it. Let's just run through it, and you can correct me where I'm wrong. First of all, let's start with the interface, because a lot of people can sort of get their heads around the interface really easily. In terms of sending information to the little screen, if you want to call it that, you can send basically only a very few kinds of content. First, is text only, which is almost like a push notification. But it's a little more interesting than that.

Then you can send html formatted content, but not with anything interactively. You can't have forms and stuff like that.

Kelli: Right. It's just styling. You're styling your HTML. You're styling your content.

Jonathan: Yes. Basically rich text. Not quite, but it's like Markdown, actually.

Kelli: Yes, that would be nice. You just push Markdown to it.

Jonathan: Yes, in fact, the html that gets created with Markdown is pretty much exactly what you can send to the screen, which is like...you can't just...it's formatted content.

They have all these templates you can use for specific kinds of things like an image with an overlay, or a video with an overlay, text overlay. You can do custom html for things like if you really want to format your content for flight information, or movie listings or lists. A very basic simple kind of html formatted data. There's no scrolling. There's no JavaScript. You can add some CSS, but it seems to be frowned upon, and very limited.

The interface is very much about sending teeny bits of information to the screen at the appropriate time, or in the appropriate context.

Kelli: What are they calling them? Cards, or...

Jonathan: Yes, cards. Which is the same terminology they use for Google Now, which I think we've said in the past. It seemed like a beta test for the kind of interface that Glass would have. Looks like we were right.

Kelli: Looks like it.

Jonathan: Yes, so as a developer, you don't build the website someone visits. You don't even build a teeny little...

Its dimensions are 640 x 360 or something like that. It's basically equivalent to a 1080p 27 inch screen from eight feet away, or something like that. It's a very small amount of real estate and you don't make web pages that someone navigates to and you redirect them to Glass.mywebsite.com.

Kelli: Yes, you're publishing the information to their timeline, aren't you?

Jonathan: Yes. There's no home screen, there's no notion of browsing. In fact it's not a web device, it's an Internet device. There's this timeline which is very much mentally like a Facebook newsfeed or a Twitter timeline, where you can dip into a stream of information that is sorted in order of creation, or whatever, or publication.

That's basically it. There's a very limited interaction model you can have with one of these cards. You can imagine someone who has a WordPress site. It's like a classic '90s era spaghetti code of database results merged with html templates, you're screwed. You're going to have to build something completely from scratch that creates the database directly to return information that you would use for a Glass interface.

Just in terms of a front-end thing, there's no home screen. There's no apps from it. It's this app notion that we'll talk about in a second. From a front-end standpoint, you basically can send text, simple html, and images and video to...You don't send it directly to a user, and a user doesn't request it directly. It all integrates around this what's called a mirror API, which is a Google service that Glass users authenticate with. Let's say I'm a glass user and you're a developer that has this cat facts service, or Fluffpo.

Kelli: Yes, we'll use Fluffpo.

Jonathan: Let's use Fluffpo. You have Fluffpo and I have a pair of Google Glasses.

Kelli: You want fluffy animals.

Jonathan: I want fluff updates. I want Fluffdates, and I want them hourly. At my desktop or some other web browsing device, I would go to Fluffpo and I would authorize Fluffpo to publish my timeline. That's a radically different model.

Kelli: That is. That's completely different. Basically you're authorizing it to send you push notifications to your glasses. Kind of pub-sub model.

Jonathan: Yes, and it does remind me a lot of the Apple push notification servers, in that they're in the middle. You have to go through Apple, and push notifications, but cards are an extremely rich push notification, first of all. Second of all, the user's not necessarily going to see them. It's not like this intrusive thing.

In fact, in the documentation it says, "Most of the time, users will not see your content", because it's this stream where you're going to dip into it and out of it, and it's up to you as the developer to make sure that you're content is highly relevant. Whether that means they are currently near something that is of interest, or something just happened. The notion of going back through your RSS feeds and reading an article from two weeks ago is not going to happen.

Kelli: As a Google Glass wearer, you can't jump around within your timeline?

Jonathan: You can, but you can't rejigger it or filter it, as far as I see. You can go forwards and backwards in the timeline by swiping forward or backwards on the right earpiece. It's kind of like going forwards and backwards in your Twitter timeline. You can only go so far back before you get sick of it.

Kelli: Yes, and who's going to want to?

Jonathan: Yes, who cares? It's like it doesn't matter anymore. They are like, if somebody wants to do that, this is not the right device. All the way around, very much that is the approach they enforce. The best practices and developer guidelines, and all the UX guidelines is like, this is all about now.

Kelli: Make it count. Make it relevant.

Jonathan: As a user, I go to Fluffpo. I say, "You know what? I want hourly fluffdates. Fluff updates."

Kelli: I'm going to have to tell Josh about the fluffdates. That's good.

Jonathan: Flo-updates. Its clear in the documentation that these aren't like iOS push notifications, or like notifications in Android, but there must be some kind of...

Is the screen always on or not always on, or am I just ignoring it? Or, what the deal is there. Fluffpo has my tokens, and has my preferences, my desires stored in the Fluffpo database, so you have that information from me, when I did the dance.

Kelli: Right. So when you only want cats, it's cats.

Jonathan: And maybe I want a max. Max cats. That gets sent to me. Then let's say that you send me the cutest cat picture of all time, and I want to match that up with a picture that I'm about to take. Or, I might want to send that to someone else. That's easier, let's say I want to send it to someone else. When you publish that to my timeline, it goes through Google's Mirror API servers, so Google is very solidly in the center of all this. There's no way to send something to a Glass user without going through Google.

Kelli: Not surprising, but also understandable at the current time.

Jonathan: A little alarming, but certainly understandable at the current time. You publish that to me and you can...What you published is a very simple json post. You do a REST API post of json data to the Google servers, and it's got all sorts of information in there that indicates who it's supposed to go to. Google finds me and publishes it to my timeline. I go, "I want to share this."

When you send that information in the json data, you can include many options so that when I tap on the handlebar there on the right-hand side, it will show me what my options are. Let's just say that "share", which is one of the default options...Let's just say share is the option.

Share pops up and there's this default interface where I can share to any of the contacts on the device and send it back to the Google notification servers. Now Fluffpo not only is publishing, and I've subscribed to it as the user, but you've also subscribed to updates from me. So it pops up in both directions.

You can listen for events, or you get a callback. There's a callback URL you can provide if any of the menu items are selected by anybody. You get this callback URL pinged that says, "Hey, I want to share this with this payload of information," so these contacts that want to have that particular fluffy cache shared with them. It's like a radically different model. I can't think of anything like this.

Kelli: Yeah, I was thinking. No. I can't either. It's very different, and it's very cool.

Jonathan: It's like bidirectional PubSub. It's like pushing notifications if there are no menu options, rich push notifications. But then the fact that they're interactive and you can subscribe to events triggered by the user. It's super radical. It all makes sense. It's all using technology that's become de facto standards, like Ras, json, and PubSub. All this stuff is pretty normal.

Kelli: I'm really interested in getting this and mashing it up with Amazon SNS that we were talking about last week or the week before.

Jonathan: [laughs] Right. You have a million questions. When FluffPo gets the payload of who I want to share it with, what is in there? Is it email addresses? Is it other Google Glass accounts? Or is it these anonymous tokens that FluffPo then would send back to the Mirror API and can only share with other Glass users?

Kelli: [laughs] I'd love to know.

Jonathan: It's radical.

Kelli: When you select to share something, you're not then pushing it on from your Glass device to someone else's? You're sending a note back to the original publisher to then push it to these Glass users?

Jonathan: Share is a default one. Share might be handled differently, so I can't answer that exactly. Share might be handled differently. Who knows? Google might have that going through Google+. +1 is another default,. It's probably something they're in. Share was a bad example, but you can send custom menu options in. Let's say you send in a custom menu option, like...

Kelli: Say you're doing fundraising and you want someone to...

I don't know. Well, no, because you couldn't do any donation or anything like that through it.

Jonathan: Let's say you could. That's a good example. You add a menu option for donate. Donate comes in, and I see whatever the default options are, like share, and record audio, and all this other stuff. Then there's donate. All right donate, so I tap on that. That definitely Google's not going to handle. They're just going to pass the callback URL and you'll just handle it.

Kelli: Then it will suck money out of your Google Wallet.

Jonathan: [laughs] That is interesting. I haven't seen anything about payments or anything like that. Assuming that it was just something like you had your own custom...

Kelli: Thing.

Jonathan: Likes, or +1s, or VOD op. Or like stack overflow, you can float things up, and you would have to have it all...

Kelli: Like posts on Tumblr or something.

Jonathan: Exactly. Let's say it was a Tumblr. It is a Tumblr. Let's say you wanted to favorite it. That's a great example. You send it to me. I hit favorite. Sends that back to you. You know who I am. You've got the OAuth permission to do whatever you want, and you can favorite that through the Glass. It reminds me of when I started thinking about offline Web apps.

I couldn't even get my head around it. I was like, "Wait a minute. I'll just...no, wait. I'm offline." How can I be on the web page, but I'm offline? I couldn't get a grip on it. It's kind of like this, where it's all the same stuff, but it's reorganized in a way that is very, very nonstandard.

Kelli: I have a question about that. Is there any kind of 4G built into this, or do you need a cell phone to go through, or is it WiFi only? How does that work?

Jonathan: There are a lot of features that depend on you having an Android phone in your pocket. All 3G connectivity, or cellular connectivity goes through your phone. In order to have...

It was the location information, all is handled on your phone, not on the glasses. The glasses have accelerometer, but they don't have GPS. You connect into your phone. I want to say it was over Bluetooth.

Kelli: That would make sense.

Jonathan: Yeah, I'm pretty sure it is Bluetooth. Basically you can't do anything if you're offline. There's no notion of offline. Max did an amazing summary blog post about it that we'll link to in the show notes. There's no concept of offline. There's no concept of apps. There's no app. It's these online services that interact through the Mirror API. For example, geolocation is provided only if Glass is paired with an Android 4.x phone. Since he chose the word paired there, I assume it isn't with Bluetooth.

Kelli: Looks like I'm going to have to...I don't know. I switched to an iPhone a while ago. I'm going to have to do something.

Jonathan: There's a bunch of really interesting points that are made. I did a little Tweet storm of them last night. It's new, assuming it catches on, which I think it will. Assuming it catches on, it's a whole new way to interact with connected content services that is not Web based, but all the Web developers...

It's going to be on them to support it.

Kelli: Right, because it's not the same as going to a web page and clicking around a bunch of links. If you build web pages, you're going to have to support it because your clients are going to want deliver that same content over Glass.

Jonathan: Right. The content that's on your website is going to need to be on Glass. You're not going to call your ad agency. The only person to call is a server side web developer, basically. It's hilarious that there's no native development. I love that. There's no such thing. It's just a dumb terminal, a very, very fancy dumb terminal.

Kelli: Yeah, it is.

Jonathan: The other thing that came out in the discussions around this was smart watches, which also seem like the new wearable.

Kelli: Yeah, that seems like it's going to be...

I don't know. It's debatable. Some of them are dumb terminals for phones. They're pair with phones. I could see it working very similarly, or I could see it being a little different.

Jonathan: The thing about the smart watches that is not compelling for me is that all the ones that I've seen are either basically a notification center for your phone, or they're a WiFi device that is not that interesting. They're touch screen and the interaction model is just too silly.

Kelli: Or too small.

Jonathan: Yeah, it's just unreasonably small. I don't get the watches. Even though the watches are a lot less geeky and probably more likely to catch on. The really compelling feature about Google Glass is not anything we've even talked about yet.

Kelli: No, I'm curious to see if you think it's the same thing I think it is.

Jonathan: To me the compelling feature is the camera and being able to take first person video and stills. You can capture audio, but it's only for...

I don't think you get an I think it's only for...

I don't think you get an mp3. It's just sound process for text recognition. You can capture photos and videos. To me, that's the reason why people would put it on in the first place and use it.

Kelli: To me, the appeal of it is like a phone, you have to pull it out of your pocket and look at it. A watch, you have to move your arm and look at it. Google Glass, it's just going to be right there. You can ignore it or not, or you can look at it or not. There's no special work you have to do to have access to these updates and to see what's going on. It's just there in the corner of your vision.

Jonathan: It's even more frictionless than the watch, which is a little bit more frictionless than the phone. There's definitely that. The thing about the watch that I don't dig is that it doesn't...it's a little bit less friction. You don't have to pull the phone out of your pocket, you just turn your arm and look at it. But it still requires your eyes. It basically is replicating functionality that's already on your phone.

Kelli: Yeah, and it's still going to be hard to see in the sunlight.

Jonathan: You've got to worry about the battery. There's too many...

Never mind the fact that it's going to be 200 bucks. I feel like the pros and cons negate each other. It doesn't offer anything that you can't do with your phone.

Kelli: Right, it's nothing new. It's just a different format.

Jonathan: The possible exception to that would be if you could program it to have very complex vibration notifications. I would totally dig it. I would buy one in a second if I could program different vibrations, almost like ringtones but silent, for different kinds of things so that without even looking I would know that some event of interest took place.

Kelli: Yeah, is this just a spam email from someone you don't know, or is it a message from Erica saying you need to bring home milk.

Jonathan: Exactly. When you consider Glass, which is going to be a lot more than $200 I'm sure, the thing about it that I think is the most compelling is certainly that it's even less frictionless than the watch. I feel like that's kind of cancelled out by how nerdy it is. I'm totally nerdy enough to wear it, but I know a lot of people aren't going to be.

Kelli: Yeah, I totally would. I've worn eyeglasses that are a lot nerdier than Google Glass.

Jonathan: I feel like that frictionlessness is going to be mitigated by...like, "Oh, this is so awesome. I don't have to pull out my phone. I don't even have to do anything. I just know things." I feel like that's a big plus, but a big minus is that everyone knows you're wearing them.

Kelli: I feel like the nerdiness factor of it...I don't know. I feel like it could go either way. I feel like it could be, "Oh, this is super nerdy. I'm not going to wear it." Or it could become a fashion trend.

Jonathan: It will be interesting to see. I really don't know. I imagine we?" Eventually, assuming they're popular, eventually that will go away. Or they'll get smaller and people won't even notice them.

Kelli: [laughs]

Jonathan: But the thing that concerns me about them, is that people will know that they could potentially be getting videotaped. Everyone's getting taped always, anyway. But I feel like it will introduce, at least at first, it's going to introduce this uncomfortableness into every face to face interaction.

Kelli: Yeah.

Jonathan: Unless both people are wearing them.

Kelli: [laughs]

Jonathan: In which case, fair is fair. [laughs]

Kelli: Yeah. I wonder if there was any indicator on the front of the glass that shows when it's recording, like an LED that lights up, or anything?

Jonathan: I assume there is. I would think there would be.

Kelli: People would know they're being recorded.

Jonathan: Yeah. But I mean, you could disable that easily.

Kelli: Hack it and disable it?

Jonathan: You could just put a little piece of tape over it. I don't know, it totally remains to be seen. As soon as I can get my hands on it, I'm going to not take them off. [laughs]

Kelli: Yeah.

Jonathan: We'll both.

Kelli: I'm just worried that with the projector there on the right eye which is good in my case, but I'm just worried that without a left one, it's going to take too much of my shoulder vision.

Jonathan: Yeah, I could see that. I'm worried that I'm too near sighted to use it, although it says that it projects as if it's in the distance.

Kelli: Oh, I can see that could be a problem for me. [laughs]

Jonathan: Yeah. I don't know if it's adjustable or what.

Kelli: I don't know, I'm extremely near sighted.

Jonathan: I used to be, but they shot lasers in my eyes.

Kelli: Oh, they shot lasers in my eyes too, but for different reasons.

Jonathan: Yeah. [laughs]

Kelli: Although I am less nearsighted now than I was.

Jonathan: That's good. It would be hard to be. [laughs]

Kelli: [laughs] Hard to be more.

Jonathan: Not to have gone in that direction.

Kelli: It'd be hard to be more. I couldn't get much more nearsighted than I was.

Jonathan: Yeah, you'd have to have your nose shortened.

Kelli: Yeah. [laughs]

Jonathan: So...

Kelli: What we're doing...

Jonathan: Yeah, so big long ramble about Google Glass, but we told you so.

Kelli: APIs, we told you.

Jonathan: Get your contents right away. You poor web developers are going to have to know basically API developers to make it work, and that's a good thing.

Kelli: Once you adjust, you're going to be all, "This is awesome"!

Jonathan: Yeah, it's so much better all the way around.

Kelli: It is.

Jonathan: Makes your web presence a lot more flexible. If you do native apps on multiple phones, it's going to get a lot more flexible. It's just good all the way around, so bite the bullet!

Kelli: Do it.

Jonathan: Do it. Clean up your database, create an API; get on it. [laughs] Jeez, that went by fast, 38 minutes already.

Kelli: It did.

Jonathan: Yeah. We should probably wrap.

Kelli: It was a fun 38 minutes though.

Jonathan: Yeah, I can't wait.

Kelli: I can't either, I'm very jealous.

Jonathan: [laughs]

Kelli: Everyone has got one.

Jonathan: Yeah.

Kelli: It just means the one we get will be better.

Jonathan: That's true, V2.

Kelli: Yup.

Jonathan: It will be the one with the retina prism.

[laughter]

Kelli: I don't have a retina...

Jonathan: [laughs]

Kelli: ...so what you want to do?

Jonathan: Nice. With that dear listener, that's our show for this week. I'm Jonathan Stark.

Kelli: I'm Kelli Shaver.

Jonathan: I hope you join us again next week for the Nitch podcast.

Kelli: Bye.

Jonathan: Bye...

Episode 52: Punching Kittens with Ethan Marcotte

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 12 Apr 2013 00:00:00 +0000

Episode 52: Punching Kittens with Ethan Marcotte

April 12, 2013

Running time: 43:15

Jonathan and Kelli welcome special guest Ethan Marcotte to discuss some of the non-technical challenges of Responsive Web Design: unresponsive ad units, browsing the web on game consoles, getting client sign-off without Photoshop comps, and much more.

Download (33.7 MB)

Titles We Considered

It Hurts Less if You Don't Tense Up
Things Short of Brilliance
Punching Kittens

Episode 51: BBQ Chicken Disease

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 05 Apr 2013 00:00:00 +0000

Episode 51: BBQ Chicken Disease

April 5, 2013

Running time: 38:46

Jonathan and Kelli talk all about Amazon Web Services - EC2, RDS, CloudWatch, and our new personal favorite, Simple Notification Service.

Download (29.5 MB)

Titles We Considered

BBQ Chicken Disease
A Very Different Kind of Load
Overkillish
Aggressively Abstract
That's Totally Toaster

Episode 50: Up Since '72

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 29 Mar 2013 00:00:00 +0000

Episode 50: Up Since '72

March 29, 2013

Running time: 28:10

Jonathan and Kelli talk about drag and drop on touchscreen devices and opting out of responsive web design.

Download (21.9 MB)

Titles We Considered

Up Since '72
Sweet Chunks of Code
Kissasskamasskiss

Episode 49: Bathroom Warming Party

Jonathan Stark, Kelli Shaver - hello@nitch.cc — Fri, 22 Mar 2013 00:00:00 +0000

Episode 49: Bathroom Warming Party

March 22, 2013

Running time: 1:08:01

Jonathan and Kelli talk about maintaining context in small screen apps, reconsidering jQuery for mobile projects, and preparing your content for the zombie apocalypse of smartwatches.

Download (53.4 MB)

Titles We Considered

Successfully Bowled
Fairly Pathetic
Crazy Bowl
Follow the Bouncing Bowling Ball
Dog Seeing Eye Dog
Less Smaller Than I Was Hoping
Bathroom Warming Party

The Nitch Podcast

Episode 58: Fifty Shades of Black

Episode 58: Fifty Shades of Black

Related Links

Titles We Considered

Episode 57: Flossing With Rails

Episode 57: Flossing With Rails

Related Links

Titles We Considered

Episode 56: Eighteen Hours Since Last Twisted Ankle

Episode 56: Eighteen Hours Since Last Twisted Ankle

Related Links

Titles We Considered

Episode 55: Nerds in Grass Skirts

Episode 55: Nerds in Grass Skirts

Related Links

Titles We Considered

Transcript

Episode 54: The Royal You

Episode 54: The Royal You

Related Links

Titles We Considered

Transcript

Episode 53: Fluffdates

Episode 53: Fluffdates

Related Links

Titles We Considered

Transcript

Episode 52: Punching Kittens with Ethan Marcotte

Episode 52: Punching Kittens with Ethan Marcotte

Related Links

Titles We Considered

Episode 51: BBQ Chicken Disease

Episode 51: BBQ Chicken Disease

Related Links

Titles We Considered

Episode 50: Up Since '72

Episode 50: Up Since '72

Related Links

Titles We Considered

Episode 49: Bathroom Warming Party

Episode 49: Bathroom Warming Party

Related Links

Titles We Considered