The Changelog: Software Development, Open Source - Hoodie, noBackend, Offline-First (Interview)

Episode Date: November 9, 2013

Andrew and Adam talk with Caolan McMahon from Hoodie to talk about very fast web development where you can build complete web apps in days, without having to worry about backends, databases or servers (with Hoodie). We discuss noBackend and the idea behind offline first.

Welcome back, everyone. This is The Change Log. We're a member-supported blog, podcast, and weekly email that covers what's fresh and what's new in open source. You can check out the blog at thechangelog.com, our past shows at 5by5.tv slash changelog, and subscribe to The Change Log Weekly. It's our weekly email covering everything that hits our open source radar. We'll see you next time. But this show is hosted by myself, Adam Stachowiak, and Andrew Thorpe. Andrew, say hello. Yo, what's going on? It's a good week, man. I'm excited to have this show, man. I've been wanting to talk about this topic for a while, but good times.

Yeah, I kind of dropped the ball on it, actually. I asked Kalen if we could do this a few months ago, and he said, yeah, sure, send me an email with some information. Totally forgot about it. Oh, man. We'll have to apologize for apologies we're getting a true apology to kaylin here in a bit when we talk to him but uh this is episode 111 and today's show is sponsored by digital ocean and also top towel we'll tell you a bit more about top towel here in just a bit but quick mention for them they connect connect startups, businesses, and organizations to a growing network of elite engineers around the world. And they're hoping that you're that

elite engineer. So stay tuned for a mention here in a bit later on the show for them. But DigitalOcean, a fan favorite and certainly a fan of open source, as well as a huge supporter for the changelog. So we're always excited to tell you what they're up to. But if this is the first time you're hearing about them, DigitalOcean is a simple cloud hosting provider built for developers. So if that's you, you're a developer, they build it just for you, like literally just for you. Pricing plans are at only $5 a month for a half a gig of RAM, 20 gigs of SSD drive space, one CPU, and one terabyte of transfer.

And DigitalOcean has data centers not only here in the United States in New York and San Francisco but also across the pond where not far from where Caitlin is at in Amsterdam DigitalOcean has a lot of features that really help developers get their apps launched as quickly as possible they have servers with full root access

so the moment you spin it up, full root access you can deploy that in 55 seconds. And for a faster launch, you can spin them up with a Ruby on Rails install, Docker, or even Ghost, which we had on the show back in 105. Already pre-installed, so applications right from one click. Additionally, they offer features that have a vast collection. I'm sorry. They also offer a vast collection of tutorials that cover configuring and optimizing your service.

So if you're like me, you spin up that server and you're like, I don't know where to go. They've got pretty much a tutorial for every configuration, whether it's a lamp stack or it's in Gen X or whatever it is, they've literally got a tutorial to cover your back and get you up and get you up and running. But we have a brand new promo code for this month of November and I think maybe for a couple more months.

But this one is changelogsentme. I'll repeat that one more time. changelogsentme. You can try DigitalOcean today for free using that promo code, which will get you $10 of hosting credit or basically two months free. Head to digitalocean.com to get started. And thank you to DigitalOcean for your support. Today we're joined by Kalen McMahon. He is from Hootie.

He's rocking it out. And as Andrew mentioned, he's got a little apology to say. So maybe we can start there, Andrew. Well, I don't know. I think I already apologized to Kalen personally. But, yeah, he was excited to come on the show, I think, the first time too. And I told him maybe it was a good thing because some pretty big news for Hoodie the last week or so. So maybe it's good to get him on now.

But yeah, why don't you go ahead, Kalen, and just kind of introduce yourself and Hoodie and what you're doing. Sure. So hello from sunny England. I'm Caelan McMahon and you may know me from kind of Node.js land if you do any node work. I've kind of done work with the async module, node unit, various other things in node and now I'm doing work with the Hoodie team and working on Hoodie, which is what we like to call kind of a no-backend project. And what we mean by that is that it lets you build complete applications, complete data-driven applications without worrying

about the backend. So entirely using front-end JavaScript. So no backend, that is something that is at nobackend.org. Is that something that you guys have participated in or just like a kind of a mindset you're buying into? Well, that website was set up by Gregor, who's also kind of one of the founders of Hoodie. And it's kind of it's an idea that we're trying to put out there to i suppose discuss some of the things that we've

thought about in in the hoodie project more widely and how they apply in various other spaces and so we are not the only provider of what we would call a no back-end solution but we want to kind of really explore what that means for web development. You know, it turns out there's quite a few interesting things that happen when you consider your application as being separate from the backend. So, I mean, for one, it's quite empowering.

So we often, we have this idea in the Hoodie project of a jQuery developer. And what we mean by that is someone who can design great sites, does great interactions on the front end, but doesn't necessarily know everything about all the back-end technologies, the full stack. Because what happens if you're a front-end developer and you want to do a web app?

You could design it. You could make some really nice interface. But as soon as you have to hook up persistence, emails, payments, all that kind of stuff, all of a sudden you have to learn about MySQL. You have to learn about PHP. You have to be able to administer Linux or find a service that will do that and it's you know it may as well be rocket science at that point uh i mean you know it's it's just way too much to learn it's it's not

you know it's not you're not interested it's not your job uh and so by making it accessible to to developers that that just aren't interested in all that stuff. We're hoping that, one, we can empower people to participate in making the web that wouldn't otherwise be able to. And that's an important thing. I think sometimes we forget most of us are full stack developers or you kind of do a bit of front end, a bit of back end. You know, programming is a really empowering thing to be able to do. And the more people that can participate in making the web, the better it's going to be for all of us.

So that's kind of one nice thing about approaching web apps in a slightly different way. Right. And the no back end, a little bit of a misnomer, right? It's not that there is no back end. It's that it's a generic, you're not creating the back end. There's no backend is a little bit of a misnomer, right? It's not that there is no backend. It's that there is, it's a generic, you're not creating the backend. There's no backend? What? There's like some sort of data store, emails, you know, then there's some more, I don't know, more specific higher level stuff, which is like sharing data between people, payments, all that stuff. But you're making assumptions, right?

And so somebody had to come up with these ideas and say, all right, the generic backend has to support this, this, this, and this. Is that right? Yeah, exactly. I mean, ultimately, this is a discussion about platforms, really. It's not no backend, it's a pre-packaged backend that we're providing. And you're right, we have to kind of second guess what people want. But 90% of the time, it's really easy to guess what people want from a web app. They want accounts, they want storage, all that kind of stuff yeah um but i i think where the no back end part comes in is is really how you design your application so what we want to do is kind of disentangle the app from all the implementation details of sending emails and all that kind of stuff right if you could think in terms of the intent of your application, rather than, you know, all the messy details of actually doing it, then you get much cleaner code. I mean, you get much kind of smaller code for a start, I need to download some dependencies, maybe NodeMailer.

I need to set up some kind of email service or find one to pay for online. I need to point NodeMailer at the SMTP server so I can send an email. Instead of getting kind of bogged down in all the actual deployment details, you can just say hoodie.email.send from the front end. And that's just the way your app kind of specifies its intent. Right. So I think it's called no backend, and we'll get into hoodie specifically, but just kind of laying a foundation. It's called no backend. So that's kind of obviously like a, I don't know play on the no sql stuff and and the data store part of no back-end which i would argue is probably the the most important other than user accounts um it kind of relies on no sql to an extent right because you just have to be able

to store kind of arbitrary data instead of modeling the data specifically in like a relational database yeah absolutely i mean if you look at the team, we all kind of have a CouchDB background. So there's definitely some NoSQL CouchDB influence in the design we've used for Hoodie. And it turns out that's a really good design for this kind of API. Because especially if you've been doing CouchApp you know the original design for hoodie kind of came out of the couch app idea you had to do some quite crazy things in order to make permissions work and sign up and making it all secure from the front end and so we've actually had quite a lot of practice at doing things that seem kind of crazy to most people at the time right think you

know things like being able to write to a database from the front end you know most people would would kind of throw their hands up in the air and scream and run away at that point a year ago that was like people looked at that as just a pipe dream that would never happen right exactly but most of our team a year ago we were all doing it right we were deploying apps doing that and that's the difference so okay this is a we've had this kind of a system, I don't know if system is right, or architecture, but we have the spec being no backend and then kind of the implementation being Hudi.

So can you talk about what comes first, the chicken or the egg? So with Hudi and no backend, what was the order of operations for that? So chronologically, Hudi came first, I think. But I think in terms of goals, no backend is the bigger goal for us. If someone comes along and builds another Hudi that's way better, then that's great.

Mission accomplished. We don't have to do any more work. It's a spec driven by implementation right so you kind of proven the concept with hoodie and then you can kind of generalize it into the no back end spec to to kind of promote this sort of development that i mean that really kind of we talked about this with the um uh open karma stuff like it kind of bridges the gap between front end uh well kind of between designer front end and backend, right? Like it makes it a lot easier for people to, to, to do the whole stack or to not have to worry about the whole stack. So that's, that's good. And so this hoodie is the, the implementation that's driving no backend for you guys right now. Um, before we talk about

hoodie, is there any other, uh, do you guys know of anyone else that's kind of, that's running with the no backend stuff and, and working in kind of like competition to hoodie um there are certainly competing ideas out there um when it comes to actually implementing the specs and the ideas that we've come up with a no back-end no not really not that i'm aware of um but in terms of competing ideas back-end as a service has been around for a while now. And that's things like, I suppose, Firebase. If you're familiar with that, that's kind of a real time backend that's quite popular. The various other ones, mostly targeted at mobile. So if you're a mobile app developer, you don't really want to have to come up with a whole server just

to do a high score table or something right and so there are quite a few services that do user accounts and storage and a bunch of back-end stuff for you as a service there are very few actually open source things that you can run yourself though right and also they have they have a slight excuse me they have a slight uh slightly different approach uh in in the way they target users, I think. We're trying to make it accessible to the front-end developer. They are targeting people who already do development, but perhaps just don't want to develop the back-end this time.

That's like me. That's like me in a nutshell. I plug this. If you're a subscriber to the ChangeL Law Weekly, we mentioned that in the intro. But if you subscribe to that, we did cover this in Issue 9 about a month back. And the open source moves fast. We try to keep up with it as best as we possibly can too. But, Kaylin, you presented Hoodie not long ago too at LXJS.

And you kind of had a nice presentation there. Jan is also on your team. You mentioned team and you all were building this stuff a year ago and doing this right into the database from the front end a year ago. Who is the team behind and kind of what's the – give a shout out to the team I guess and kind of give some lay of the land of what they've done or what you all have done over the past couple of years to kind of get you to where you're at now. Sure. So, well, I've already introduced myself. Mostly a Node.js and CouchDB background. There's Jan, who was kind of one of the core people in CouchDB these days.

Lots of people will know Jan already. He goes to lots of conferences and speaks and is very good at hooking us up with the right people in the community. There's Alex, who's also in Berlin, where Jan is. He's kind of like a designer, kind of front-end developer background, which is very useful to us in the team

to have someone with that perspective. And he does a lot of work on the admin interface and kind of influencing the API. There's Gregor, who in a way kind of came up with the original idea in that it kind of grew out of a project called Minutes.io, which was a minute-taking app that Gregor wrote. And it was originally implemented as a couch app, so running on CouchDB. And he ran into some limitations and had to do some redesign,

and eventually coming up with the right way of doing that is what became Hoodie later on. There's also Lena, who is our kind of... She does all the writing for Hoodie, so the communications, the blog posts, that kind of stuff. Keeps us on track and the communication stuff. So it's great to have her on the team. That really helps.

And also we have Sven, who was in London but now has also moved to Berlin. He's just kind of turned up one day and contributed loads of code. And now he's, well, he seems to be doing everything. He's actually, Sven is also, isn't he on the bauer team as well that's right yeah and we'll be having bauer on in a few weeks um oh cool maybe next week i can't remember exactly but yeah so this is pretty neat so you have a team of six that are working on hoodie are you guys full time or um you have a a weekly sponsor for hoodie which I think it's public knowledge. It's a thousand euros a week is the rate. Is that right? Yeah, I think that's how I checked.

Yeah. So that obviously isn't enough to pay six people. So how does that work with you guys? Are you guys all full time or what's that like? Increasingly, we're working on it much much closer to full-time uh we're all kind of uh lucky in the sense that we can we can mix up our work uh we all do a bit of freelance and some other things to kind of keep things running smoothly um but increasingly we're doing just more and more hoodie work. And that has been sponsors kind of paid for so far by sponsorship. So our first sponsor was NLNet. If you look it up on the blog, we have a kind of big blog post about NLNet.

They gave us a grant that let us build the plugin architecture, which is kind of a really big thing we released recently. Perhaps we'll talk about that a little bit later. And then we have the, yeah, the commit sponsors, which is, you know, a really interesting idea. I haven't seen any other projects do this. So what you can do is you can sponsor the team for a week and we will put a banner up on the homepage saying this week is sponsored by you know whoever we will also kind of tweet your message and say you know thanks for sponsoring us but interestingly we will also put your message in our commits and so we have a system in place with all the

core committers that we will update our commit message so the first you know usually on a git commit the first line is kind of the key information and then below that you can have additional stuff yeah so inside the extended info we will put your sponsor message and so this week we are sponsored by human javascript and so they have if you look at our commits for this week, you will see the sponsor message in there and it will link to the human JavaScript book. So yeah, it's really... That's a super neat idea. I like the idea, honestly. I wonder how the rest of the community feels about that.

Like if you got any feedback on issues or whatever or line level commits or line level comments or whatever about, Oh, what's this doing here at first? But I think it's a unique, I think we have to be creative in this world because we all know open source is hard. We all know that open source doesn't exactly get, you know, in this case, um, you know, sponsored by everybody in the world, or, you know, we, we don't have the engineers to facilitate, you know, Rubinius or whatever forever, you know, that's going to end at some point. So we have to be creative in the way we, you know, kind of line up these kinds of new technologies and sponsor the people making them. So I think this is a huge thing and it's, I think it's pretty neat. Yeah.

You guys are kind of pioneering it and trying, I'm sure you're trying, I mean, you're trying a couple of different methods. So you guys can kind of, you know, you're going to prove concepts and all over the place with hoodie, with the app itself, with, you know, fundraising and fundraising and stuff like that we like to think big that's what it is so i i want to ask because i'm sure a lot of people are wondering this so what is hoodie like where does that name come from what does it mean oh well um the name kind of predates me but i've heard this story um it's uh so um jan and grego uh possibly alex i'm not sure about that time were trying to come up with a name and it was um very difficult to kind of come up with a new thing i think at the

at the time it was called couch apps the next generation or something like that yeah and we wanted something that was just a temporary name we wanted something more snappy and at some point yan got up and uh said oh you know i'm just going to get my hoodie because he's going to leave and he goes ah hoodie that's perfect um and he said okay if we can get hood.ie as a domain name then we'll have it and and it was available that's awesome yeah that's cool we have a really cool domain meshes like that it's we at a company that i've i worked at before we struggled with uh or we talked about a We, we created our own brand similar to hoodie. I mean, nothing like hoodie, but you know, same kind of idea where the, the name of our company kind of

meant nothing. And we, we kind of bumped, we ran into a lot of obstacles. Like you're trying to educate people on what your company does, uh, with a name that might not have anything to do with what you do. So there was some, um know, struggles there. Ultimately, we ended up rebranding with a name that made more sense. And we kind of found some growth there. Have you guys run into anything like that, where people are like, I don't know what hoodie is and kind of, you know, throw you out at first glance, just because of the name or anything? Well, that's, that's an interesting one. So far, the feedback I've had has been pretty positive. But then I guess if they threw out the project at first glance we would never have heard from them interestingly in the uk hoodies are um there's kind of like a political headline associated

with hoodies as petty criminals so it's uh i get interesting responses here but in most other countries no yeah that's reminds me of Canada. They got – if you're a goof in Canada, Canadians out there, you know what I'm talking about. I'm not going to mention this because it's a pretty derogatory thing. But if you're a goof, it's not good. Yeah, I don't want – I think we should move along. Yeah, move along. I don't know what we're talking about here.

I'll be quiet. Yeah. So let's talk about the news with hoodie which was the plug-in system and i think that's kind of what re-sparked i was like oh yeah i forgot about hoodie i need to reach out to him again so let's talk about the plug-in system and your path to get that done with uh what was it nl what was it called nl net nl net and let's talk about what what is the plug-in system and and how did that kind of come about um yeah so the plugin system is a way for you to extend hoodie functionality and that means extending the back end so you can kind of

hook node.js workers into our data store and you get change events on tasks and you can kick off things like sending emails or whatever um also you you can extend the front-end API. So that's not something that usually happens with plugins. Usually it's kind of back-end code or something like that in the case of a framework. But it was really important to us that the API is kind of like the first place. That's where the beginnings of all our code is. So whenever we come up with a feature, we start with the API first. We have this idea of this concept called dream code. And so we like to sit down and just write out what we want to do

in terms of perfect code in our heads, at least. And then we think really hard about how we can make that possible. And sometimes, you know, the implementation is really difficult, but it starts with a really nice, simple API. So it's important to us that plugins also extend the front end code so that you could expose these beautiful APIs. And thirdly, you can extend the admin interface, which is called Pocket. So you just drop some HTML and JavaScript and style sheets or whatever into a folder and it will get served up in our admin panel so you could also as well as being able to send emails you can also have a dashboard that says how many were sent or whatever

yeah so the nl net's kind of sponsored this this idea of plugins with you guys? Yeah, well, the thing with plugins was it's a big chunk of work to kind of rewrite a whole bunch of the backend architecture and lots of other things to make plugins happen. And the thing was we couldn't drag it out for too long because it would have invalidated a lot of other community effort on the other side. So, you know, if we're accepting pull requests on one branch of code and we're doing plugins on another, you know, they're going to get out of sync

and it just creates headaches for us. So it's important to be able to do it as quickly as possible and actually dedicate enough time to get it right and communicate it properly and write documentation, all that kind of stuff. And so the money from an Lnet meant that we could really focus on that for several weeks at a time and get it out the door. Gotcha. Did you have any kind of backlash with it getting out of sync, or did you kind of take that challenge on and beat it? I think it went fine, yeah. so no big problems to speak of awesome so i was looking for a tweet and this is one thing i think that i you you guys wrote the i think it was a blog post you

wrote about offline first and it it like sparked this this just frenzy of i mean i saw like hoodie on tweet on twitter just like blow up all of a sudden and i think that one of the first ones i read was ethan marcote wrote gushed excitedly about this whole offline first deal on like one of those blogs the kids are talking about obviously that's ethan talking like ethan but kind of the point is you you sparked this huge frenzy when you guys did offline first can talk about that what what was that like and is that kind of the biggest kind of news headline you guys have gotten so far um sure i don't know if it's the biggest yet i hope it is i mean that's great um yeah we like coming up with concepts i think we we are used to doing things in quite strange ways in our team we have we quite quite a special collection of people and um it's really fun being able to actually discuss it with the whole community at large

so it's great when we get this kind of response uh offline first is i mean it's amazing it's not a thing already that's i keep thinking this with hoodie hoodie projects you know how come people aren't doing offline first already you know every time i time I go on the tube in London and I lose connection, I say, how come people don't do offline first? That's crazy. Whereas, you know, now we have the tools available in the browser. We have local storage, we have indexed DB. In our case, you know, there's pouch so we can do catch DB replication direct from the browser i mean you could even include js git from tim caswell you could replicate um git repositories whatever so there's loads of tools available now to do really powerful offline experiences and to think of your data the same way offline as

online is a really interesting thing and that's something that we're all used to doing in the CouchDB community because we've had this idea of local apps running on Couch for a long time where you replicate data between nodes. And so, you know, the idea of treating your data the same, whether you're online or offline, is kind of amazing. It's not just, you know, we don't want it to just be some cached read-only copy of the data. It's like, oh, I'm offline, but at least I can see what I had. We want you to be able to continue to write new things, record to-do items or calendar appointments, and for it to synchronize when you get a connection back. And, you know, we have the tools to do that now. We should really be thinking in terms of offline first. And so one of the guiding principles in Hoodie is that all the APIs that we have in terms of in Hoodie are based on a very simple mechanism that means you can continue to

use them if you're offline. So obviously, if you're offline and you try to send an email, it's not going to send. But we will record in your local storage the fact that you intend to send an email. And once you get a connection, it will synchronize up to the Houdi server and Houdi will send it. Can somebody, let's say, I got a couple of questions about this.

Let's say somebody kind of wants to push into that queue when they're offline and then, and they decide, I guess it doesn't really make sense, but they decide they no longer want doesn't really make sense, but they decide they no longer want to do that. Is there any way for them to like manage that queue? Yeah. So, um, the queue is just your user database. So, uh, I should probably explain something about the architecture of hoodie at this point. Um, when you sign up, every user gets their own, own personal database. Um, and that's in couch TV. We create a database and it's just

assigned to you and no one else can read it, but you can read and write to it. Uh, And that's in CouchDB. We create a database and it's just assigned to you and no one else can read it, but you can read and write to it. And that's where we synchronize all your data to. And so when you're working offline, you can create task documents in the case of sending an email. And these are special documents that have like a prefixed ID that kind of indicate that it's a task. And they get picked up by the plugins in the back end. And so if you wanted to send an email, then cancel it, what would happen is you would create the task document in your personal offline version of your database. Then you could potentially cancel it and delete it. And it would send it up to the server but it would say by the way this was

deleted so gotcha another thing you at one of the on the blog post the the big bold aside says we can't keep building apps with a desktop mindset of permanent fast connectivity where a temporary disconnection or slow service is regarded as a problem and communicated as an error uh that's true obviously on a on a like a cell phone or something, you said you get on the tube, which I'm an ignorant American. I believe that's like the train or the metro. It's Subway. Subway, yeah.

And you lose connection, and all of a sudden your apps stop working. So let me ask you, you kind of have two different directions that both are improving, right? So you want to go offline first, but at the same time, our world is dedicated to making it so that you wouldn't lose your service when you get on the tube. So offline first is incredible and it's awesome,

but you kind of want both of those things, right? The goal is to never be offline if you don't want to be. But if you are offline to support that and not kind of not be an exceptional case. True. You know, the more connectivity we get the better but we are so far away from ubiquitous you know broadband i mean it's so far down the line as you know looking at looking at how things are right now um we've got an awful long way to go and it's not it's not good enough to just kick the can down the road and wait so um in terms of

my own background i've been consulting on offline web apps for for a couple of years and that's been in quite remote places so i've done things in the kind of far north of canada and worked with charities out in africa and obviously in those places they're quite a long way off getting reliable internet connections um uh you know in the case of the Northwest Territories, where I did a project, they have a satellite for their internet connection, which is, you know, it's pretty expensive, but it's reasonable.

If it goes down, they have to fly an engineer out. It might take a couple of days. You know, for people like that, there isn't really an alternative on the horizon anytime soon. And these people a lot and because of the offline first kind of not not really existing until you know recently or you know you've been recently saying the last few years um man these people when when things go down they just sit idle for a few days right i mean they just kind of just for lack of better words they're just kind of screwed yeah exactly i mean you know how bad it is if github goes down for an hour or two you know it's it's crazy there's no need for it cool so yeah offline first the solution is

use something like hoodie and be able to maintain state even if they're not connected and it's not exceptional case anymore exactly and i think there's there's kind of also a bigger point here um in in kind of the idea of empowering users is also tied up with the idea of being able to go offline so i like to think of being you know we have view source to look at your markup your css your javascript i would love to be able to do that with my data. And so separating your data from the kind of hosted backend is quite an empowering thing to think about. I mean, you're probably aware of unhosted and their remote storage. That's taking a very similar approach and thinking in terms of your data is a separate entity. Right. Yeah, it's a, I don't know.

I look at it and I look at services and I look at the tools that are available. But I don't know that, well, I guess you're saying there would necessarily be a good front end for that, for a user to kind of be able to look at that stuff. When you talk about view source, I mean, isn't that more targeted at the developer anyway? I mean, most people don't even know that there's such a thing as a source. Oh, sure, yeah.

I mean, I'm not necessarily saying everyone is going to be inspecting their JSON data. Right. That's not going to happen. But the more people that do, the better. Right. I used to work at a large company and it used these Lotus Notes. Are you familiar with Lotus Notes? Unfortunately, I am.

Yeah, some fairly unpopular groupware piece of software. It's often just used for email, which is a shame because it actually has this these great kind of replicating databases that you can take offline. And so I remember working in this company and you could take essentially an app it was an app with some data associated with it you could replicate it offline onto my laptop and i could just play with it i could change things around i could modify stuff and i didn't have to worry about messing with the data because it was my copy and i thought that was really empowering. And in that organization, it really worked. We had, you know, little apps running on a box under the desk in someone's cubicle that would organize the Christmas party or for booking holidays.

You know, it was great. And I would love to see increased hackability of the web. I think one of the problems that we have at the minute increased hackability of the web i think one of the problems that we have at the minute is we think of the web in terms of full stacks and so we have the back end and the front end it's all really tightly integrated and the problem with that is you can't make changes at any point in that stack without recreating the full thing and that's why you know you have these um you have to download an entire vm to run a piece of software i don't know if you've tried setting up things like git lab it you know it takes a while it's a real pain um and you know the more independent we can think of the front end from the app but also the app from the back end and the infrastructure, the more opportunity there is to play around

and have fun with it. Speaking of having fun with it, let's pause for a minute. I'm not sure that was a good transition or not, but I liked it. Yes, kind of awkward. Let's pause for a minute and give a shout out to our sponsor, TopTal. I'm not sure if you've heard of TopTal before, but they'll be sponsoring the show for the next few months, or sorry, the next few weeks. My bad, it's just a Freudian slip there. But for those of you who are freelancing, which might be everybody, I don't know who freelances out there, but

for those of you who are freelancing or would like to test out freelancing or even try out a no-risk kind of freelance-like project while maintaining your full-time position, you've got to check out TopTile. You can work on special projects with companies like Airbnb, RC, IDEO, and many others. You can work remotely or, as Andrew likes to do, work on a beach or pretty much anywhere in the world because it's the kind of opportunities they offer at TopTile. You can get started today. Head to TopTile.com slash developer. That's T-O-P-T-A-L dot com slash developer and click join the best.

And because they want to work with only the best senior engineers, they've got a well thought out four stage screening process that begins with a personal call via Skype to get to know who you are and introduce you to TopTal's mission to see if you're a fit. From end to end, the entire screening process includes an English speaking test, timed algorithm tests, technical interviews with core TopTal engineers, as well as a test project. But once you've made it through their rigorous screening process, the sky is the limit. If you think you have what it takes, head to TopTal.com slash developer. That's T-O-P-T-A-L dot com slash developer to get started. Tell them that changelog sent you. If you apply, please email me, adam at the changelog dot com. I want to hear about your experience,

but toptal.com slash developer. So no back end, no database, offline. So I wanted to, the reason i got into the asking about the uh viewing your data kind of on the front end i'm looking at your website and one of the things that i see i like the way that you guys are doing the uh the features and the who is it for kind of it's complete it's your next it's planned i think that's a neat idea it's a little i think i don't think there's anything marked as your next or we're on it it's hard for me to kind of see the light yellow from the bright yellow but anyway uh planned who is it for is designers with basic front-end skills so you guys

are already kind of completed it for node developers and front-end developers um it's planned for designers with with basic front-end. What would you say those basic front-end skills are? So we have the idea of a hypothetical jQuery developer. And so perhaps you're a designer and you can code up an interaction. You can kind of make a few basic things happen on the front end, but you're not implementing complex algorithms in JavaScript on the front end, but you're not implementing complex algorithms

in JavaScript on the front end. That's all. Gotcha. So this is increasingly what kind of the world is moving to for designers, which is you have to be able to pretty much do, you know, mock-ups and prototypes and understand a little bit of jQuery.

So essentially you're saying, like, I mean, the goal in a year, you know, a year from now, three years from now, then it could just be every designer is able to build a hoodie app. Well, that's an ideal to strive towards, right? I mean, every step we take in that direction is, is a good thing. In my opinion, the more people that get to create apps, the better apps will have. So let me ask you, I think a lot of my designer friends, so I don't know, let me rephrase a lot of my developer friends. so I don't know, let me rephrase.

A lot of my developer friends, when you don't understand something, your first inclination is, you know, RTFM, right? Read the docs, figure out what's going on, solve the problem. And I don't think there's anything wrong with my designer friends, but a lot of times that's not their first thought to read the docs. So how do you guys kind of accomplish that? How do you get the designers to go through and read the tutorials, read the docs, figure out how to solve their problem? That's an interesting question. I'm not sure I read the docs, to be honest. Nice. I think, you know, for people like that, it's more about creating and they'll learn through creating something that they want to create. That's the reason they're programming. It's more about creating and they'll learn through creating something that they want to create.

That's that's why that's the reason they're programming. It's not for the love of programming necessarily, but it's because they have a dream of this perfect app and they want to just make that happen. And so the the more closely we can align what we provide with just getting things done, I think the more successful we'll be. Right. And when you speak to is, it is so easy to get up and running with hoodie that that barrier of getting started is almost, almost gone. Now, when I say easy, like, I understand homebrew, and I understand how to install modules with NPM, right? I understand what's happening with that stuff. So is there any? Is there any desire to like, I don't know, maybe have like a standalone installer or anything that kind of makes it easier for people to get started? Um, yeah, we certainly want to make it

easier for people to get started. I mean, at the minute it's, it's what you would call a developer preview and we're, we're basically expecting you to be some kind of no JS developer or comfortable with Linux or using Homebrew or something like that. I was going to say, because you're getting started, it starts off with a brew. You've got Homebrew in place, you've got NPM in place. There's a lot of assumptions already. I mean, even for us, one of our top hit articles, I think over the last couple of months,

has been how to get Node installed. And it's like if that's like the number one search we're getting hits for, people are wanting to know how. And it's not exactly easy for what Andrew's talking about this, you know, your designer buddies. Absolutely. So in the longer term, we definitely want to tackle that. There are a few options available. One, it might be to look at offering a hosted platform or perhaps a variety of hosts offering Hudi.

That would be great too, so that you could just click and you're up and running. Another option might be that we offer things like VMs or Docker or something like that. Gotcha. And in terms of the Node developer, because we're based on CouchDB, we've actually been experimenting a little bit with the idea of running PouchDB on top of LevelDB. So if you're a Node developer, you're probably familiar with

LevelDB. It's a key value store from Google, but it has great Node.js bindings. And so what that would mean is we could potentially get to a stage where the installation process is npm install hoodie, and that would be fantastic. So there are lots of things we could look into. It's certainly not going to stay the way it is. Well, I think one good thing about the way you're doing it now, though, however, is that I think, you know, Andrew, early in the show, you touched on Bower coming on the show soon and things like that. And I think as we start to see more and more of these front end

tools becoming more accessible to, or, you know, you know, using NPM, for example, to install packages and all this different stuff, like it's becoming more and more accessible because of things like Grunt and Bower, they're pushing front-end developers or front-end designers as you say um to start to get into more developer-esque things and having homebrew in place and having npm in place is getting more and more common for the i think you're at least your initial like you said a developer preview that initial stint of people you want to have try out hoodie and and you know take on this flag and run with it yeah for for early adopters i think it's reasonable to say you you have mpm installed uh you know or you can use git or

something like that um one one other option that we discussed at one point was the idea of um so one of the workflows i really enjoyed was um google analytics So a lot of front-end developers are really comfortable with the idea of copying and pasting a snippet of code and just putting it into their site, however they host it normally, whether they FTP it to some shared hosting or whatever. And I really like the idea of offering a hoodie tag.

So you get a little snippet of hoodie code, you paste that into your site, wherever that is, wherever you're comfortable hosting it. And all of a sudden you can talk to a hoodie tag. So you get a little snippet of hoodie code, you paste that into your site, wherever that is, wherever you're comfortable hosting it. And all of a sudden you can talk to a hoodie backend. I mean, that would be, that would be really nice, um, design and with cause and various other tools that that's potentially achievable. Yeah. So we talked about, uh, you guys just kind of released plugins. That was November 3rd, so just a couple days ago. But what are you guys doing now, and what is the future? We talked about kind of some pipe, you know, not pipe dreams, but kind of like bigger picture future plans.

So what's like the immediate future look like for Hody? Well, right now we're all kind of busy off doing talks and various other workshops and things. So I'll be at QCon next week in San Francisco. So will Gregor. So if you're around there, come say hello. Jan will be up in Vancouver. So in the immediate future, we're all kind of busy doing that. The next to-do item in terms of creating Hoodie is probably going to be on the admin interface. So we really like these kind of

nice small panels that you get in admin interfaces with all the graphs and all that kind of stuff. People like numbers and whizzy graphs. And so, you know, if you can just kind of click a button, you get a backend, you start creating users and you get stats and all that kind of stuff just by default, that would be fantastic. Um, so yeah, I think, I think admin interface is the next big thing. Do you guys have your sponsors lined up for the next few weeks? Um, yeah, I think so. I don't know. I don't handle the sponsorship myself, but, uh, so I just wanted to plug,

if you're interested in sponsoring hoodie development, just go to hood.ie. Get some information and help this project grow. Yeah, absolutely. Thanks very much. So for those of you that are new, we ask the same three questions at the end of every week. We need to name these questions. We need to come up with – The common questions.

I don't know. The common questions. That is the working name. The common questions until we come up with something better. But yeah, we'll go ahead and ask them here. The first one, Kalen, is for kind of a call to arms. So something you would like to see the community kind of get involved with and help out. Sure. So I think the most useful thing you could do if you're interested in the project

is to um come along have a look at the apis discuss the whole concept of no backend and just try out the code if you're a node.js developer and you want to really get your hands dirty then please have a think about doing some plugins. So we're really nice on plugins right now. We just have like the small core things, users, email. We're working on doing data sharing between users. So there's loads of things that you could potentially implement.

All kinds of services that you might want to integrate with on the backend. So plugin developers is the big thing we need. How do you get involved with plugin development? So you can, if you go to Hoodie HQ on GitHub, there's a whole load of repositories there. You'll find a few examples. We tend to prefix everything with Hoodie-plugin. If you want to ask us questions, then we're on Freenode, so if you join hash hoodie on Freenode, we're

usually in there and someone will help you out. We're really excited when people want to write plugins, so we'll be very friendly to you. Awesome. So hoodie plugins. Yeah, that's something we didn't get into much this time, but maybe we can have you guys on when it starts to grow and kind of talk about the ecosystem a little bit more sure uh second

question is for if you weren't doing this what would you be doing i would probably be working on one of the thousand other ideas i have in my head for uh open source projects uh the great thing about working with this team is that they kind of help keep me on track with one specific thought for a long period of time, which is nice. But I'd love to give a really balanced answer, you know, like I'd be off sailing or traveling the world,

but I'm just going to be programming. I love programming. Well, maybe if you were being paid to do all of your open source ideas, you could be sailing and doing them, you know, in the middle of the ocean on a boat somewhere. Sure, yeah. Especially since you would have offline access all the time. So if anyone wants to sponsor me to sail around the world and program, then get in touch.

Yeah, it's hood.ie slash sponsoring. No, just kidding. Cool. So the last one is for a programmer hero. So somebody that has been influential in your life. That's, that's a tricky one. I meet so many great programmers every day. I think every program is better than me. So I always have something to learn. Um, but for a specific example, I think I'm going to go with, uh, Jerry Sussman. So one of the guys behind Scheme, along with Guy Steele. But also he was involved

in the SICP, the Structure and Interpretation of Computer Programs. I think programming is all about communication. And if you're able to communicate really well in terms of the clarity of designing a language like Scheme, but also if you've not seen the video lectures, the MIT videos of SICP, then you should definitely watch that. Anyone who has the gift of kind of communicating clearly in code, I'm in awe of. I think that's fantastic. Yeah, the book, Structure and Interpretation of Computer Programs,

I remember when I went through my computer science program in college, we read that book and we called it the sick book. I think that we we didn't I wish I would be able to go through and read and take all my courses again now with the appreciation and kind of education knowledge that I've gained over the years. I think I would enjoy that much more this second time around. Well, perhaps I just enjoy it because I didn't do computer science. Yeah. Yeah. Maybe it was a little bit more of a homework assignment than a, than a, you know, reading. If someone sat me down and forced me to read it, I'd probably hate it. Awesome. Yeah. So hoodie is you guys are definitely growing and I think we could talk about it for hours. I say that with most of our guests, because most of our guests are awesome, just like hoodie. But for the sake of keeping it, you know, under an hour or so, I think we could talk about it for hours. I say that with most of our guests because most of our guests are awesome, just like Hoodie.

But for the sake of keeping it under an hour or so, I think we're going to have to let you go. But, yeah, I definitely am excited to see kind of where this thing grows and to keep an eye on it. If you guys want to follow Hoodie, they do have a Hoodie Weekly, which is weekly.hood.ie. And you can find them on Twitter at HoodieHQ. Well weekly.hood.ie and you can find them on Twitter at athoodiehq Well spoken, man. Yeah, thanks so much for having me. So, Kalen,

yeah, I mean, I think the thing that's kind of neat, I think, just to kind of summarize this, is like this idea of being able to build apps pretty quickly and this front-end kind of being able to build apps pretty quickly uh you know and this front ender you know friend and kind of focus i was thinking about ender game andrew from earlier when you were mentioning in hip chat saying front ender but uh but being able to build an app in just

a few days pretty quickly and not have to think about you know the back end and servers and all this stuff i mean what you guys are doing at hoodie are super super cool and andrew you mentioned it earlier for anybody listening out there that wants to sponsor these guys you know you know definitely look into that this is a cool neat technology kaylin you're out there and yon and the rest of the team are out there giving talks at various um you know either conferences or local communities or whatever um you know user groups and whatnot i mean support these guys what they're doing it's super neat kaylin thank you for coming on the show to to kind of share with us this idea of no back end, this idea of offline first.

And for you listeners, definitely check it out. We'll have a bunch of links in the show notes. We've mentioned Jan a couple times. He's been on the show twice before, once way back in the day when Lynn and I were over there in Austin for a South by Southwest long ago. There was a NoSQL SPAC down that was a little dated, but I'm sure entertaining nonetheless. And Jan has been

on the show talking about CouchDB before as well, so I've got links out to that and a bunch of cool stuff. But, Kellen, thanks for joining us this show, for sure. And I also want to just thank our sponsors, DigitalOcean and TopTal. If you haven't used DigitalOcean and TopTal.

If you haven't used DigitalOcean yet and you want to take advantage of them, they have a $10 hosting credit with us. I mentioned earlier in the show that the code you want to use is changelogsendme. That's changelogsendme. Whenever you go through the process of creating your account and putting in your credit card information, there's a little spot there to put that code in there. Go ahead and throw them there. They'll give you a $10 hosting credit.

And if for some reason it doesn't work out or doesn't actually apply, don't worry. Don't go on Twitter and be upset. Just email their support. Their support is like super quick. I was emailing their support last night because I was setting up a slice for myself, which is awesome. And if you are a fan of what they're doing and you're going to be at Launch Hackathon

Atel is going to be there if you've read any of their tutorials Atel is likely one of the ones that's written them I know that everyone I've been reading

of their tutorials has been written by Atel so Atel is one of their main communications contacts at DigitalOcean she'll be at Launch Hackathon that's

I think that's next week wait what day is today? Today's the 7th. That's like this weekend. November 8th through 10th. And if you want stickers, email Barry at DigitalOcean.com and I'll send them to you. Just tell them your address. But I want to thank also TopTal. Join

TopTal's network of awesome engineers all around the world and go to TopTal.com slash developer to apply. That's T-O-P-T- toptal.com slash developer to apply. That's toptal.com slash developer to apply. And yeah, that's it for this show, Andrew. Thanks so much for a really awesome show

and Kalen, thank you so much for taking the time to join us today. So let's say goodbye. See you guys later. Thanks for having me.