The Changelog: Software Development, Open Source - Your Huginn Agents Are Standing By (Interview)

Episode Date: April 15, 2016

Andrew Cantino joined the show to talk with Jerod about Huginn, a system for building agents that perform automated tasks for you online. They can read the web, watch for events, and take actions on your behalf. Think of it as a hackable Yahoo! Pipes plus IFTTT on your own server.

I'm Andrew Cantino, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 199. Long time in the making. I know, you've been waiting for the next episode. I'm sorry. I was on paternity leave got behind we're back on schedule so no worries jerry went solo on this show with andrew contino about hugen and now hugen is a system for building agents that perform automated tasks for you online they can read the web watch for events and take actions on your behalf. Think of it as a hackable Yahoo pipes plus if on your own server.

We have three sponsors for the show today, CodeShip, DigitalOcean, and Truesight Pulse. Our first sponsor today is our friends at CodeShip. They have a new platform called CodeShip Jet, and they've got this webinar coming up to talk about managing test environments with Docker and this new platform called CodeChip Jet. CodeChip's engineer, Brendan Fosbury, is going to show you how to use Docker to simplify managing your application across different environments by using Docker and CodeChip's continuous integration platform, Jet.

This is a free webinar, April 28th, 2016 at noon Eastern Standard Time. I'm going to put a link in the show notes, but in the meantime, go to CodeChip.com slash ChangeLog to learn more about CodeChip Jet. And now on to the show. Welcome back, everyone. Jared here. I want to start this show out with a shout-out to a brand-new member of the Changelog family. That's the baby Stachowiak. So congratulations to Adam and Heather, and welcoming Eli to the world.

Adam not here on the show today, taking care of more important things, but we are excited nonetheless to be joined by Andrew Cantino to talk about his project, Hugin. Andrew, welcome to the show. Thank you. So, Andrew, as we like to get started, it helps out and it's fun to understand who the guest is, where you're coming from, how you got to the point where you built Hugin, which is a system for building agents that perform automated tasks for you online. We're going to dig deep into that.

But first of all, I'd like to learn a little bit about you. So can you tell us a little bit about yourself? Sure. I've been doing programming for probably about 20 years. I started when I was, I think I was about 12, and I took a summer class on robotics. And I actually didn't particularly like the robots because they tended to break a lot, hardware, but I really enjoyed programming for them in BASIC. And so after that summer, I convinced my parents to buy me a Pascal compiler, which I don't think I ever actually used.

I just kept using BASIC, and I learned Microsoft QuickBASIC, and then I learned something called RealBASIC for Mac. And then I got into Perl. This was before college, and I did a bunch of Perl scripts, some of which I sold. And then in college, I majored in physics, but I kept doing computer science as well. I took a bunch of classes and ended up

minoring in computational science, applying it to physics. And I think I learned Java and Python and kept using a lot of Perl for web-based projects in college. And then after college, I went to grad school and I switched from physics to pure computer science, and I studied machine learning in grad school for a couple years. Then I came out to Silicon Valley, and I've been at a bunch of startups and companies out here since then. Go back to your Perl scripts. You said you sold some of those. What kind of scripts were you selling that they were valuable enough people want to pay money for them this was like before the dot-com boom and people would buy these cgi scripts for very what would we would now consider very primitive websites um i had pearl scripts i had a guest book that you could leave notes for each other nice on a website um

i had a chat script which actually got pretty popular i ran a network of um chat servers that were you could run them with no JavaScript at all. It was better if you had JavaScript, but they were pure HTML and CSS if you wanted. So we had a lot of users on WebTV, which was a thing. And like these really primitive clients that couldn't run JavaScript. And it got popular in these sort of strange niche communities for, I think I ran it for almost 10 years. Closed it down sort of right after college. Web TV, was that that thing where it's kind of like what smart TVs are now, but it was way before its time and you could get on the web from your television?

Is that what that was? Yeah, I think you had a device that had a modem, I believe. And you plugged it into your TV and it was a very poor quality screen because TVs were really low resolution. And you could very slowly browse the web. And some of them, I don't think even ran JavaScript at all. Right, right. So on your website, you say that you're an experimentalist. What does that mean? I like building things and tinkering with things and experimenting with new ideas. I sort of like building systems from scratch

to see how they work. I built a web browser in high school just for fun to sort of learn what the primitives were, although back then they were a lot simpler. And then playing with algorithms algorithms playing with toys there what's some other stuff if you've uh experimental i mean i think perhaps when we get to hugen we'll find out that that's probably coming out of that tinker mindset but do you have any other examples uh of things that you just kind of experimented with? I've had a couple fun projects.

I had a project in college. It might have been before college, actually, where I was trying to evolve CSS styling for websites. So you could look at a website, and it would take the style sheet and mutate it, and then make a couple potential offspring, kind of like Blind Watchmaker. And it would display them over a proxied version of potential offspring, kind of like Blind Watchmaker.

And it would display them over a proxied version of the site and you pick the one you like. Or if you wanted, you could pick multiple offspring and pick the ones that you like. And then it would combine them and basically treat lines of CSS as genes that it could flip back and forth. And so it would do both mutation and combination with the offspring and then you

could evolve a style sheet that you liked for that site very cool um anything else uh well selector gadget is a project that i did a while ago um that still gets some use it's a tool for building css selectors for websites it's a Chrome extension or a bookmarklet. And you can click on a region of the page that you're interested in. And it highlights, it sort of does a best guess of what selector would make sense there. So it'll prefer an ID. And then if there's no ID, it'll fall back to a class. And it'll highlight everything on the page that matches that. And then usually it's not right on the first try. So then you click on something that you don't want in your selection and it turns red and then it tries to figure out the sort of minimal selector that matches everything you do want and nothing that you don't yeah let me just give you props on selector gadget

in fact when i was when i was on your website preparing for this call i saw that you made selector gadget and i was like yes that awesome. Because I use that back in the day. And it was kind of a revelation because I don't know exactly why, but it was so impressive to see it like just, you know, drill down on a specific section and grab the selector for you. Because back then we were all kind of learning about CSS selection and how to do it best and how not to do it. And at least for me, it was like it was helping me realize other ways of selecting things um that i previously would have never known so very cool people people are still using that today yeah it still gets some use um i turned it into a chrome extension maybe a year ago and it's it's getting some use it's never sort of taken off it's hard to know you know it's because people just use it i don't have any great metrics on how much it gets used but um sometimes it shows up on twitter periodically right right right that leads to

me one question i've been asking people recently because i'm kind of becoming uh transfixed on this idea of longevity with software projects and really having a lot of respect for things that are um well what people might consider legacy, but are just like older, but actually had value and still work today. And so looking back at myself and my own software development career, I look back at stuff that I wrote back in the, I mean, I can only go back about 10 or 12 years because that's how long I've been doing development. But I look at things that I wrote, you know, 10 years ago and ask myself, what's still

useful? And so thinking about it like that, and you have a longer history than I do, does anything go past Selector Gadget going back? You said you had these Perl scripts that ran for quite a long time. What's the oldest piece of software that you wrote that's still being used in some capacity today? That's a good question. Well, older than Selector Gadget,

I was on the Gmail team at Google for a summer internship, and I'm pretty sure that code I wrote to generate filters in Gmail is still in use, as well as possibly some of the code in the search bar that does autocomplete. I don't know how much it's evolved since I was there, but that's about eight years old. And then older still, there was a project called Absurdly Cool Freebie Finder,

which was this search engine for finding free stuff. Nice. And that's still online, but unfortunately I sold it, which that's not unfortunate. That was great. Unfortunately, the new owner has which was not unfortunate. That was great. Unfortunately, the new owner has just sort of let it die,

which has actually been my experience in general of stuff that I've sold. I've sold it, and then the next person doesn't care as much as I did. So it sort of goes away. The site's technically still up, but it's not aggregating anymore. But I ran that since uh see since about 2005 older than that i'm sure there's still some pearl scripts running somewhere i mean i had like a hundred thousand downloads of that guest book there's no way they're all gone but it was you know super insecure terribly written untested pearl so i kind of hope they're all gone so you told us how you got into software what about open source specific can you go back software. What about open source specific?

Can you go back? Do you remember your open source roots and where the idea of open source kind of sprung up in you and you got excited about it? That's a good question. Well, so the Perl scripts that I mentioned, most of those were open. There was no real realistic way to make them closed source because you just have to provide the script for someone to run. So some of those I think got changed

and most of them were free. Many of them were free. So that was in high school 20 years ago. Before that, a really sort of formative experience for me was this Macintosh application called Hotline. And it was this network of, it was peer-to-peer, and it had trackers and it had servers that would register to the trackers. And each server could have a chat room and a forum and file exchange. And I was probably 13 or something when I found these.

And I stumbled on this community of other children, roughly my age. Some were older, some were younger, but we're all sort of teenagers who are learning real basic together. And that was the language that I was playing with at that time. And that was really cool because people would just upload examples of something they made and someone else would download them and sort of riff on it and upload a new one and that's that was really sort of formative for me to get into real programming and because there were people there who were more experienced than me and i could learn from their tricks um that's where i sort of mentioned that i wrote a simple web browser it was there and shared it people thought you know you get props you know people like this is awesome how did you do this and it was really it was like a fun game um so that's sort of proto

open source like i don't think many things came out of that that became real products i'm sure some did um but it was really important for me to sort of work with a community of other programmers just thinking about that and the even the open nature of the Pearl scripts that you were selling makes me wonder, cause it was so back so far back. Um, how did you go about like, what was the transaction like when you sold a Pearl script back then?

Was it a mail me some cash? Was it, was it, I think so. I think it was like, mail me, mail me a check. Um,

that's probably cash sometimes. Yeah. And we're not talking, you know, this was like a hundred bucks and I was in high school and that was that was great 100 bucks is awesome when you're in high school yeah i mean i think i had a few that might have been a couple grand like it was it was certainly a great great spending money in high school very cool well we are going to talk about hugen let's take a quick break and we will dive into what that is and why it's awesome.

We'll be right back. architect about the idea of dev teams out there rolling their own monitoring system using something that's open source or building their own from scratch. And he had this to say. I think if you want to roll your own and spend the dev effort of having to build that internally, that's great. My only question to you is if you spend your time doing that, are you providing value to your customer? and are you actually moving your product forward or are you holding your product back? I think a lot of what something like TrueSight Pulse offers you is we take a lot of that on for you so you can provide that value to your customer on your product instead. So we have plugins for, I think there's 30 plugins for different parts of

your infrastructure. We have an agent that's been running for three years written in C that takes a very small amount of your resources. As you add more servers, you're not going to have to worry about the scalability as much. And we've written the chef and the puppet scripts for you. So that's all taken care of. It's letting us worry about it so you can focus on your customers. That's kind of the value that TruSight Pulse adds, as opposed to you having to do it yourself. We've all been in organizations where we've joined and had to rewrite the entire monitoring stack.

And that's just something we didn't want to have to do. We want to come in. We want that taken care of. And then that way we can focus on the things that are going to matter to our customers. That was Mike Moran, Senior Architect at Truesight Pulse. To learn more about Truesight Pulse and how it helps you deliver more value to your customers, head to bmc.com slash Truesight Pulse, all one word, and tell them Adam from the Chainslog sent you. All right, we are back with Andrew Cantino, and we want to talk about this really cool project called Hugin that has caught traction, probably more so than Selector Gadget.

I think you got 13,000 stars, 1,300 plus forks, 110 contributors, which is quite an accomplishment. We're going to talk about what Hugin does, but let's first get the name out of the way. Because it's one of these things where, as I was saying before the call, as programmers, we tend to write things all the time, and we read words, and we all kind of live on our terminals, you know, reading text. And it's not until shows like these where we get together and actually have to talk about concepts. And many things,

we just pronounce them differently. And so I thought it was Huggin, ever since I've heard about it, which was a couple years ago now, until until you sent me your audio clip and I found out you pronounce it Hugin. So can you first give us the inspiration for the name and then kind of describe the pronunciation? Sure. So Hugin is named after one of the ravens of the Norse god Odin. In mythology, they flew around the world and reported back on what they saw. So the two ravens were Hugin and Munin, thought and memory. And I've always pronounced it Hugin.

When I've looked online for someone who might actually know what they're talking about, I've heard Hugin. I've never actually heard Hugin, which is what a lot of people say in the open source community. And I think it's kind of cute, so it doesn't bother me. Yeah, it's kind of funny because when you come across the name like i did just reading it saying hmm and you just kind of sound it out and i don't know anything about that mythology i think it's a cool name based on that makes lots of sense you're like oh it's trying to hug you like it's gonna like i'm not really sure why i named it hugging but there it isgin. So it's just funny how we kind of construct these things in our minds to fill in the gaps. But that's such a great name based on that mythology.

Was it something where you already knew the story and you said, well, this makes tons of sense because this is an agent getting information for you, just like in the mythology? Or were you digging for a name and you came across that and you thought, oh, I can use this? How did that come about? That's a really good question, and I honestly can't remember. I think that I was looking around for a name and sort of looking for inspiration in mythology,

but that may not be right. I can't remember. Have you ever thought about starting a Munin project? I would, but there is one. Yes, there is. It's a monitoring tool. That's right. Well, so you're in San Francisco, and you said you worked at some startups, so you're very familiar with the elevator pitch, right?

So if you had to describe Hugin to somebody in a paragraph or two, and you had to do the elevator pitch, what would that sound like? So if you're aware of products like IFTTT, which is IFTTT this, then that, or Zapier, then Hugin is really easy to describe because it's basically an open source, self-hosted clone of IFTTT or Zapier or a little bit like Yahoo Pipes. And then the more pure elevator pitch would be use Hugin to monitor the world for you to take data in from interesting sources on the Internet and then react to it, filter it, aggregate it, and then take actions on your behalf.

Which is often as simple as sending you an email, but it could be more complicated, too, like posting something or taking some more interesting action. We might have to take a moment to pause for pouring out a drink for Yahoo Pipes. Isn't that dead now? It is. I was sad to see it go. It was a great product. Yeah, it really was. It was such an interesting idea and so many uses.

I think a lot of the open sourcers were sad to see that one finally get closed down. There's been an influx of users after Yahoo! Pipes closed down to, I'd say, a sort of varying degree of success. Like, some of them, Hugin really does meet their needs, and some of them want to use Hugin for sort of very deep feed recombination and filtering, which it can do if you sort of squint, but it's not sort of perfect for that at the moment.

So perhaps some more of your disgruntled users or your feature requesters are the people coming from the Yahoo! Pipe site. First commit March 3rd, 2013. So it's three years old now. Was, you said you describe it as if you understand if this, then that, and, or Zapier, then you can describe Hugin as a clone of those things or an open source version of those things was, uh, if this, then that, or Zapier, the actual inspiration for it, was it a clone or it just happened to be like mutual, uh, invention or how did it, how did it start?

No, it wasn't a clone. I started it a little earlier than that. I think it was December, around Christmas of 2012. I was at home visiting my family and needed a project to tinker on and had this idea for basically just a GUI for CronJobs and sort of reusable components that could be wired together because I end up writing so many little scripts in Perl or Ruby just a GUI for CronJobs and sort of reusable components that could be wired together. Because I end up writing so many little scripts in Perl or Ruby to automate things.

And I tend to rewrite them all the time. And I don't have a shared library. And so it started as a shared library of stuff that I wanted to wire together inside of a Rails app. I think my first use case, which I still actually use, was it would be really cool if I got an email in the morning or push notification if it was going to rain that day so that I actually remember to take my umbrella because I'm terrible at this. So I have a network of Hugin agents that does that for me. And it did that very early on. I think it was the first thing I implemented. I also played with a bunch of location based stuff early early on um so yeah it wasn't really i don't think it was inspired by any existing

product that i was aware of it was just sort of the result of tinkering so as you became aware of those products did you ever think uh they perhaps they ripped you off or that uh you could compete with them or like, what was your, what was your reaction as you, I think Zapier is probably newer. I don't know. I actually don't know the history.

I feel like it's newer than IFTTT in the marketplace. And so maybe they cloned them, but what do you, what were your thoughts as you see these other things come out and they're like, you know, pretty successful small businesses or startups at this point that are basically providing very similar functionality to what you've been doing in the open source space i think it's great um they're good products and

i have nothing against them and if you don't want to host you know something on your own or you're not trying to extend it they're really good solutions they have a lot of connectors they're monitored by you know professional people who know how to run services. Right. And that's awesome because then I don't need to build a hosting platform. And I, my interest was always in controlling my own data. I didn't really want to have my data be in someone else's hands.

And I, it doesn't really bother me sort of in an abstract sense, but mostly in sort of the longevity that you mentioned, you know, startups come and go. And I want to have, I would love if I have, you know, 20, 30 years of history at some point of all this data that I can play with. And that seems unlikely if I'm giving it all to a startup. So my motivation was sort of twofold one to control the data, not so much out of paranoia, but just sort of to keep my hands on it. And the second was really that I'm a programmer.

It's satisfying to write things. And Kugan is a library of reusable components, and often I find myself needing to add just one more to make something complicated work. So it's really satisfying as a developer because you can go in there use a simple api write another agent and wire it all together and that's just not something you can easily do in these hosted solutions you can't just go write arbitrary code and run it yeah you have to fit it inside of whatever framework they provide which is usually limiting um and all things are

all interfaces are limiting so what are some of the cool things that you can do with Hugen? You mentioned the first one, which seems like was your primary use case at first, which was let me know when I need to remember my umbrella. That's right. What are some other ones? There's a bunch. And frankly, I think that I am one of the more boring users of Hugen. It has mostly met my needs for a while.

And some of the stuff that people are using it for now are much more complicated than any of my personal use cases. One of my favorite uses that I do use it for routinely is to monitor Twitter. So Hugon can run a Twitter agent, it follows the Twitter filtered feed, you can give it a bunch of terms that you'd like to hear about. And then Hugin can either just emit an event for every term. So for something rare, I do that. For example, the word Hugin, not particularly common, so I just see all of them. Or my last name is actually pretty rare, so I just see all of those.

But for anything frequent, I don't want to get an email for every time it's mentioned I just want to know when it's changed in an interesting way. And so in that case I use the Hugin mode that has two modes either events or counts and if you do counts and it's basically emitting a histogram bucketed by whatever check frequency you set. So you say to check every five minutes and roll up the number of times that a certain term has occurred. And then I send those to a peak detector agent, which can filter,

basically watches for a high standard deviation spike in that time series, and then triggers its own event if that occurs. And then that I either send to either, you know, a push notification or an email or something else. So I can give you two examples for the push notification case. That's something I want to know right now.

So I have a couple agents that watch for like the terms, San Francisco tsunami or bomb threat or something like that. And I want to know, like, tell me right away if this happens. And so I could find out in a couple, you know, in about a minute, if there's a sudden spike in conversation about those terms on Twitter. That's really cool. And then luckily those haven't triggered very often. And then the more useful day-to-day ones are the slightly less

frequent, but interesting terms where I basically use hugen to watch for interesting stuff to happen on twitter that i think might happen eventually and just tell me if it does so i don't have to check myself so for example if i'm waiting for you know a call for a call for papers at a conference i'll put i'll put the conference name in twitter and it'll spike when they announce something um i'm waiting for mass effect 4 to be released, so I just have Mass Effect 4. And if there's some announcement, I get an email. NASA announcement, Ruby vulnerability. A recent one I started using is if there's a movie I'm waiting for on Netflix, I do just movie name Netflix, and that will spike when it gets released and I'll get an email.

It's basically like a sort of fuzzy natural language API to the world. Like Twitter, you know, people are going to say things in their own words when something happens and it has such volume that if you just keep an eye on it, almost any term that you pick is going to increase proportionally to the amount of interest in it. And so if you just look for spikes in that, it works surprisingly well. I love that. It's kind of like, you know, the google news search alert type of a thing only i'm not sure how much they put into

it but i love how its proportionality are based on trends because you tend to get so many false positives or you know i used to have one out for my name and uh because my name is pretty unique at least when the first and last combined and unique enough that there weren't false positives but all i would get alerts on is whenever i publish my own a blog post and i'd be like oh yeah well i already knew that one because i just hit you know the publish button a couple hours ago um but then if you get more specific on every then if you try to generalize more you get overflow you know you get tons of results. Um, I used to have that problem. So one of the ways that I bootstrapped my consultancy back in, I don't know, it was

seven Oh eight, whenever Twitter was first out there. Um, and I started realizing that a lot of people would, they, when they turn, when they needed the technical help, it was a lot of work to post a job listing, right? Or to put an ad in the paper or whatever your traditional means were to post for help. And it was really easy to just put something out on Twitter. I noticed a lot of people were starting to do that with specific programming needs. And so I wrote a little monitor,

similar to the one that you just mentioned, looking for specific keywords and then paired those with phrases. And mine turned into an RSS feed because I was just consuming RSS in the morning anyways. And I used that as ways of finding job leads, using freelance type stuff. But there was tons.

That's a great idea. It was super useful and it ended up being a way that I did get a lot of business that way. but there was a ton that's a great idea it was super useful and it ended up being a way that i i did get a lot of business that way um but it was full of false positives especially because like the word ruby is also a girl's name and you know you run into stuff like that and uh it seems like your way of doing trends or waiting for a certain proportional change probably flakes out a lot of the false positives so So it's just higher signal, less noise.

Is that what you found? Yeah, it does pretty well. It's not perfect, but it's low enough noise that it's useful. And for those, I just have it send me a digest email once a day. So I skim through them and it formats them so each one's a link to the search results on Twitter.

So I can pretty quickly see like, oh, no, that's totally unrelated. I can see why it triggered it. But most of them are actually relevant. And so I keep using it. I love how many ideas you have about ways of using that one single feature. I feel like I wouldn't have, I've never even figured if I put Netflix plus a word that I'll know when the movie's available.

Like my brain doesn't connect those dots on its own. Um, I'm sure there's a place for at least Hugin agents where you guys have a list of like, here's different ways that you could use it. But what about your, your specific Twitter stuff? Is there anywhere where that lives online where somebody could go for

inspiration of ways of, you know, being notified of an earthquake and Molly? I've, uh, I've written a couple of blog posts about it. There's some tutorials, and I know other people are doing it too. But I don't know of the user base of Kugan how many people are using Twitter. A number of people have said they are. And a bunch of people are using it in different ways than me. They use it for posting or for following a small group of people and rolling it up into an RSS feed. I also, I'm not sure that we've really sort of explained at a higher level how Hugin is wired together.

If you think that would be useful to talk about. Well, first, just give us a couple more use cases. I think we'll definitely do that. Sure. And we would like to, when we hear about that architecture, we'll probably talk about the specific bits because I think technically it's interesting. There's lots of moving pieces and you put together into a holistic system.

We want to hear about that. Just to continue to whet our appetites, you have let me know when it's raining. You have Twitter-based aggregation notifications. What are some of these? Those are your main use cases. What are some of the crazier ones that other people have done

that you're like, wow, that's really cool? Well, one of my favorites, mostly because it's just a big name, is that the New York Times used it to monitor some of their internal Olympics coverage a couple years ago. So I believe they were using it for sort of fairly traditional monitoring

where it was watching their own website and looking at their own output and then alerting if it didn't match expectations. But that resulted also, that was neat. It's cool to see that use case. And also got some contributions from them in terms of additional code.

It's nice when people stay involved and keep adding to it. There was another use case I heard about where someone was using it to download civic data releases. Like if governments released interesting data sets, they would watch those fairly hard-to-follow feeds and let them know in a more useful way if it happened. I've seen a lot. There's home automation stuff,

like turn on my porch light at my actual local sunset stuff like that you have listed on the readme just different things you can do with it one is create amazon mechanical turk workflows as the inputs or outputs of agents for example once a day ask five people for a funny cat photo send the results to five more people to be rated send the top rated five to people five other people for a funny caption send to five final people to rate for funniest caption finally post the best caption photo on my blog i don't know no one's doing that right that's great i mean i i tried it once and it mostly worked and then i decided i didn't need to personally run a funny cat blog, but it did work. Awesome.

Amazon Turk, if you know anybody using that to great advantage in any way that's not one of these fun kind of like, that would be cool. I think it's being used a lot in the machine learning and AI community to build data sets. I think that's the sort of most valuable use case is building a data set of human labeled information. You're labeling photos or annotating sentiment onto tweets or noting down the text regions of documents, of photos of documents, stuff like that. Where you just need to build these really large data sets for deep learning. Yeah, that makes tons of sense. Well, I think this is a natural place to break. We do want to talk all about the nitty-gritty details

of how Hugin works, the agents, the peak. What do you call that, a peak adapter, peak monitor? I don't know. You have a peak detector. You've got a nice agent event flow document. So some graph is fun coming up. Let's take a quick break break and we will dive into that on the other side if you're like me or most people out there you want to attach highly

available expandable block storage to your droplets on digital ocean and guess what the feature is here you've asked for it they've delivered kind of right now you can request early access the feature is coming in the summer of 2016 so i heard that the earlier you get on the list the earlier you get the feature so head to digitalocean.com slash features slash storage get early access do it today all right we are back and i don't know about everybody else but i've been my appetite has been sufficiently wetted i'm very interested hugen sounds really cool it can do lots of different things things that i would never even imagine to even want to be done until i hear about them and i think oh yeah that would be pretty cool um which is kind of the beauty of these

types of system is that they really are just a bunch of tools and ways that you can do things and you have to bring your ideas to them and make them do cool things. So, Andrew, talk to us about specifics, how it was built, how it works. You have agents. It appears to be a Ruby on Rails application. Can you break it apart for us and tell us how it all is wired together? Sure.

So it is a Rails application. It's actually a pretty traditional Rails application. We're not doing anything particularly unusual. Sort of my focus has always been on ease of use and ease of deployment and ease of development. And so it's not really intended for high throughput. You know, I wouldn't use Rails for a really high throughput application for data processing. But it holds up totally fine for sort of personal and business use. It's like small business use.

The basic wiring is that we have these models called agents they're the core object in the system there's many types of agents you know there's the some of the ones i've mentioned like the one that can talk to twitter and the peak detector and the mechanical turk agent there's a lot of other agents that sort of focus on outputting to systems like push bullet or push over rss or slack and then there's things like webhook agents that can both send and receive posts to remote systems. And then one of the more complicated ones is the website agent that can sort of scrape arbitrary websites in.

I think at this point, RSS and HTML and JSON and XML, it's gotten a little bloated, but it's very powerful. You can give it a set of CSS selectors or XPath selectors, and it can grab all the regions of a page that match and emit those as events. So that brings us to events.

Agents are connected together in an event flow graph. So agents can receive and emit events. Events just flow to all the receivers and they propagate down until they stop propagating. So you should avoid making loops. In theory, you could get yourself into a situation where you had an infinite loop. Although in reality, it doesn't happen.

I've never really had it happen. And then, so you have agents, you have events that they emit and receive, and they just propagate along. And then agents are modeled after sort of a simple reaction agent. So they have state, they have memory that they get to use however they want. You can have many instances of an agent and they each have their own memory. Then they just receive and emit events and events are immutable. So that's sufficient to build most types of systems where I need to store some state, I need to react to things. And then it means that there's a pretty simple API for developers to add new agents because it's just basically a simple active record model that you extend. You wire in, if you want to receive events, then you define a receive method.

If you want to check for events on a schedule, sorry, if you want to do something on a schedule, you define a check method, and the user can pick what schedule should run. And then you can use your memory if you need it, and you can emit events if you need to. Obviously, there's some more complexities. We have types of agents that can run continuously in a background thread and some other stuff like that but at a basic level it's really pretty simple yeah so you your your main user interface is the creation and the editing and the hooking up of the different agents to do what you want and then it shows you kind of the status of those agents and what they've done recently.

How does the scheduling system work? How does the backgrounding work? So we're running a background. We have two versions. It can either run multiprocessor or multithread. By default, these days, it runs multithread. We use Rufus Scheduler, which a ruby gem that does a good job of simulating both cron style scheduling as well as pure um sort of exact time scheduling is basically

cron um and we use it to trigger any set of registered agents on a certain schedule so when you make a new agent that has a check method defined, you can say, I want this to run at midnight every day or every five minutes, et cetera. And it will do whatever its check method does and do whatever this agent is designed to do. And then we just, in the background, use Rufus Schedule to make sure those run. I imagine, like we said earlier, you have 110 contributors.

Most projects will have a lot of kind of long tail contributors but only a few you know core people that that work on it seems to be pretty typical in that sense but is the majority of your contributors besides typos and minor bug fixes are they adding agents to the system is that the main way that people contribute to the project yeah I'd say that's the primary way. We do get a lot of small bug fixes too for the core system. But there's

probably the bulk of the contributors have shown up, added one agent that they needed for their use case in a pull request, and then they've sort of disappeared. Some of them show up again a year later with another agent or a bug fix because they've started to push the system. So yeah, I think that's pretty much true.

And one thing you mentioned is that you want to keep it as vanilla or as well as a person who's ran many websites and many services over the years I'm almost allergic to some of these systems because of the maintenance and I would almost always use a provided service even though I'm completely well aware that most of these startups disappear and I've definitely had them disappear right out from under me and so everything's a trade-off but maintenance is a burden um one that i still run to this day for my business is airbit which is a self-hosted version of like airbrake um for error reporting and it's just on heroku and it's they they do their best and it's a great project and i i love it but i still have to like update it.

And I'm always afraid it's on MongoDB, which I'm not as familiar with from a maintenance perspective. And I'm just always afraid that this next time when they do a release and I, you know, pull that tag down and push it out to Heroku, all hell's going to break loose. And now my reporting system's broken um what what measures have you taken to make deployment easy and just like that idea of not letting it die on the vine like keeping up with the hugen joneses as a user have you guys struggled with that and what have you done to make it so that people can deploy and and and not feel like it's a huge burden that's a great question it's it's a hard problem because you know most people haven't deployed a rails application before and that's not trivial um until fairly

recently we didn't have a great solution um we had tutorials on how to deploy a rails app with capistrano and we had example capistrano scripts, and example Nginx proxy scripts, but it was really for a pretty small set of people who were comfortable doing that. Recently, we've wrapped it in a Docker container, and that's definitely helped. So now you can use Hugin with Docker. As long as you link it to an external data source,

either Postgres or MySQL, in another Docker container, then it's trivial to just sort of re-download the new one and launch it, and it should be fine. We definitely make an effort to not break agents in a backwards incompatible way. So when you upgrade, we really try to make sure that the options that your agent has will still work, and we write migrations if necessary

to make sure that happens. I don't think we've ever broken people in a backwards incompatible way except for you know i don't think we've ever like had data loss issues where we've really broken people with an upgrade obviously there have been bugs that have been introduced um it is you know an open source project it's all volunteer it does break sometimes but overall it's it's been pretty stable um and i've tried to make very conservative technical choices you know we we haven't gone very far from traditional rails um we you know i've resisted pulling in new dependencies like redis or mongo even though especially with redis i'm a fan but i just don't want people to have to deploy

another component. It works with Postgres or MySQL, and we want to just keep it stable with whatever you have running. And the trade-off is that it's then a little hard to make it high throughput and really performant if someone's trying to build a system around it. We have a few users who have really pushed it to its limits with tens of thousands of agents running really, really frequently and monitoring very complicated flows. I've never had a need to push it that far. They start to run into issues where they're extending their database, which is too small, or the system isn't high throughput enough. But

for the most part, for the types of tasks that I've always wanted to use it for, which is personal automation or sort of small-scale business automation, it holds up pretty well, and it's not too difficult to deploy. You can also push it to Heroku. Deploy button. I think, yeah, and that works.

Last time I checked. So a bunch of people run it there as well. Yeah, Heroku's restructuring of their pricing strategy has limited the way people deploy hobby tooling to Heroku, right? Because it can only be on for 18 hours. That's right, and Hugin is intended to run all the time, so that did affect a lot of our users and um but if you upgrade to the first plan it's not too expensive and it does run it runs fine at the

base plan also runs fine on a you know five dollar digital ocean image or something like that so i mentioned keeping up with the joneses and i was just checking out your gem file uh previous to the call and you appear to be on the most recent version of rails 4 um all projects that have lived multiple years you know go through different versions of rails all your dependencies it is a complicated enough application that your gem files you know got 100 plus lines in it i'm not sure exactly how many gems are loaded on a regular basis but you do have a even though you're trying to keep it simple you still have a pretty rich dependency graph can you explain any trials and tribulations over the years of just

maintaining it keeping it up to date security patches has that been a struggle for you or has it been pretty smooth it's i, I mean, it's not trivial, but because we're fairly traditional Rails, the Rails upgrades themselves have not been particularly hard. Sometimes the dependencies are a little more complicated and we've always toyed with the idea of pulling agents into gems so that you can pick and choose exactly which ones you want. About two years ago, we refactored the gem files so you can turn a bunch of gems off and the agents gracefully just sort of disable themselves.

So if you're trying to run this on like a Raspberry Pi, which sort of barely works, you can turn a bunch of stuff off that you don't need just to reduce your overhead. And that works fairly well. It's always been this trade-off between, I really have resisted pulling everything into gems, even though it has a sort of structural elegance,

because right now it's sort of the polished monolith where if we make a change to the system, we could update all the agents simultaneously in one commit, and it's going to work. If everything's in gems, then we end up in sort of version management hell where we need to either own all the gems and update them all ourselves. Or if they're owned by third parties, we have to send them a pull request or ask nicely. And I think it's just,

I've been resistant to having to manage that. It's a little bit like my experience in the DevOps world between Chef and Ansible, where Ansible shifts with this really rich standard library. My experience has been that when we moved to Ansible, we got to stop using all these community-supported things that didn't work super well from Chef and just use the core library that was updated in lockstep with Ansible itself. And it was just much more stable.

So that's sort of where I'm trying to keep it. It does limit people's ability if I don't accept a pull request because the agent brings in a lot of new dependencies that I don't think most of the population isn't going to want. It makes it hard for people to get that. They could obviously use a fork, but if it were in gems, it would be really easy for people to just add exactly which they want. So there's a real tradeoff there. You call it a polished monolith. You might even call it a majestic monolith.

I heard that term recently. I think we all heard it. Let me pose this question to you because I'm looking at the MIT license. I'm seeing the years of work that's gone into this. And it obviously is working quite well. You have many people using it. And you mentioned that some people have come around and pushed it to certain limits,

whether it's the number of agents they run or how often they check or the types of things that they are doing. Have you ever considered the possibility of somebody coming by and saying, this is really nice as a basis for my new company, and I'm going to take Hugin, I'm going to wrap it with a new shiny new UI,

and I'm going to start, you know, some new company Inc. Is that something that you've thought about? Is that something that scares you? What are your thoughts on that? I would be totally fine with that. I kind of hope it happens.

Yeah. I think that it would be great if with that. I kind of hope it happens. Yeah, I think that it would be great if there's a population of my users who grudgingly run a Rails app, but don't really want to. But they love the power of Hugin because it is, in a lot of ways, more powerful than if this and that or Zapier. Because both of those,

you can't chain multiple agents together through a deep flow, as far as I know know I haven't used either in about six months but so Hugin can do some very powerful sort of flows of agents that you can't necessarily do somewhere else and you also can extend it so there's a population of people who would love to use it but don't really know how to run a Rails app and don't really want to use Docker and just want to use Hugin. And I've been hesitant to start a business around it because I don't think it's a huge business. And I don't particularly want to be in the hosting business myself. So although I am still slowly considering it.

But if someone wants to take Hugin and build a product around it, and I'm aware of a couple people who have been doing that, I'm totally fine with that. That's great. More users, more contributions. I mean, it would be awesome if they contribute back some of their work, which is likely if they want to get the goodwill of the community. So I think that would be great. Awesome. Let's talk about your community. There's lots of open source projects out there, and there's only so much limelight.

You have Selector Gadget, which had a little bit of limelight, but like you said, never gained major traction. Hugen seems like it's got the traction. It's a lot of people active, 110 contributors, like I said, 13,000 stars. People are using it. New York Times is using it or has used it. Take us back to the launch

and the initial reception, or if you had any delusions of grandeur, or if you had a marketing idea. How did it get traction? Very similar to other projects that I've launched that eventually got attention. Huguen

didn't get any attention when I initially released it. I wrote it and I put it, I think I posted on Hacker News in March of 2013, or a little earlier, actually. I think it was in like December of 2013, maybe, or of 2012. And, you know, it got like two stars or something like that on Hacker News. It wasn't, no one cared. But that's the exact same pattern that I followed on other projects.

My freebie finder site that I built in high school, I posted it at that point. I don't think Hacker News existed. It was Dig. Dig was what everyone cared about. Yeah. So I posted on Dig and it didn't go anywhere. And then I'm like, well, that sucks.

And then a month or two later, I reposted on Dig, talked some friends into voting it up. And it got thousands of Diggs, I guess, and got really popular. So Hugin had a somewhat similar trajectory where I posted it. No one cared. I posted it again. I don't think I vote-schemed in this case. I think I just posted it again in March of 2013.

That time, for whatever reason, it got to the front page, stayed there for a while, got some users at that point. And then I may have reposted it. I know it was on Hacker News again in 2014, and I don't remember whether I posted it or if someone else did. And then it actually was on Hacker News again to the front page last month, and I definitely didn't post it then. Someone else did.

So, you know, it keeps, I feel like every couple of years, it gets rediscovered and another wave of users and contributors shows up. Again, also with Yahoo Pipes closing down, there was a blog post that talked about it. And, you know, I've always made a real effort to write good read me's and to sort of invite people in and say hey this is every everyone's welcome and here's all the cool things you can do with this project and we'd love to see what you do with it and to have a an approachable read me um and that's always served me well just like making it approachable yeah I would just say I think this last round of Hacker News coverage was probably what spawned this show, because you can head across my radar previously.

And actually, 2012 was probably peak Hacker News for me, so I may have been one of your two upvotes there. I was living on the website back then. Don't check it quite so often nowadays, but people do. And I think it started getting tweeted about again and somebody mentioned it on our ping repo and another person emailed us. And so it was kind of like, these things just kind of bubble up.

And I guess if you're interesting enough and you stick with it because you have been working on it, it seems like maybe not non-stop but in a committed way um for a few years is you just kind of get these different rounds of attention yeah that's that's exactly what i've observed and that's been true on multiple projects you know it's a little hard to predict when when people are going to care and that as soon as a few people care and start talking about it, suddenly everyone notices and everyone suddenly cares. And it also needed a certain critical mass of agents and scale, I think, before it met enough use cases that people found it interesting. What does success look like for Hugin? If you

can look five years down the road and said, wow, that was a huge success, what would happen between now and then that would make that the case that's a good question um you know i've thought about trying to start a business around it but i'm not moving in that direction right now you don't want to be in the hosting business i don't really want to be on the hosting business and maybe i sort of have a blind spot but i'm having trouble seeing a large enough business around it. You know, it's conceivable that there could be a pro version of Hugin that's worked well for like other open source projects. Right. So I'm thinking about that. So that might

be one definition of success, but I certainly haven't committed to that yet. I think a more general definition would be it still exists and it's still getting used and it works. I really, you know, you mentioned longevity earlier, and I really care about sort of survivable software. One of the things I want to build systems that I can build and slowly extend for many years and into something that meets my needs. So I would be content if Fugan is just continuing to get used and it's continuing to solve problems for people. Yeah, I like that. Survivable software. You can go into marketing with that term. So I think business-wise, just looking at it,

Metabase rings a bell with the recent show that we had in the open source slash product business. And similar in certain ways, they're doing business intelligence or, you know, exposing data to more people in enterprises and small businesses. And it seems like what Hugin provides is an opportunity at so much information that people just don't even know that they need it but if you show that to them they really they immediately see the value even myself i look at this and think oh there's probably 10 things that i'm doing manually every week or that i'm not even doing at all because they require too much of my time um that a product like this could could solve for me and then you take that times all the small businesses and people who actually can't write things themselves because i tend to be the kind

of guy that's like oh just write this little one-off script each time you know to my to my shame um but many people don't even have that ability and it seems like unless you want to take over the world it seems like there'd be enough room for a, at least a small business. And I think there's a huge education side of that, which is expensive. Um, but maybe your, your Zapier's and your if are doing some of the education for, for you.

Um, and so, yeah, I think there's a possibility. I think that's right. Yeah. Um, and I'm definitely thinking about it.

That would be, that would certainly be an exciting outcome. And I know some of my other, um other core committers are definitely interested in that. So we'll see. Yeah, tell me real quick. We're going to take a break. But tell me about your other core committers. One thing that leads to survivable software or longevity or sustainability in a project is not having to do all the work yourself.

And it seems like you have some people who are right up there in fact one fella has more commits than you nowadays or total yep even though i think you have more lines of code committed but how did you get these other contributors and how much have they meant to you they've been incredibly important i mean it's been a team effort dominic and akinori have been written a huge amount of code um especially dominic. He did all of the Docker work, and he's been contributing really important changes around how we handle files, which are upcoming. In his case, I'm not entirely sure how Dominic first found Hugin.

He definitely sent some early pull requests and clearly knew what he was doing, and I invited him to be a committer if he would like to be and and he joined and then the same with akinori um he made some really important early changes it's been a little less active recently i think he's busy on his own projects but he's certainly around um and then we have a couple other less active committers who show up occasionally and do documentation or help with some Docker stuff

and we're always looking for more I'm just sort of keeping an eye on pull requests and if I start to see the same person submit a few well-tested, well-written pull requests, I make an offer because the more the merrier I completely agree with you that we need to spread out the load Cool, let's pause here for our final break and we will be right back here at the change law we have two emails we'd love for you to subscribe to the first

is change law weekly now we've been shipping this email for several years now we ship it every single saturday morning it's everything that hits our open source radar. It's our editorialized take on what happened this week in open source and software development. Go to changelog.com slash weekly to subscribe. And our second email is changelog nightly. Every single night we ship this email out covering all the top new and top star repos on GitHub at 10 p.m. Central Time. It's all the latest stuff on GitHub before it blows up. It's often our own radar. We're often creating shows and finding new people,

finding new projects, putting things on our own radar based on what we find in there. So we'd love for you to subscribe to that. Head to changelog.com slash nightly. And now back to the show. All right, we are back with Andrew Cantino talking about Hugin. Let's talk about the roadmap. What's in the immediate future?

You mentioned you've had a lot of help with one of your contributors working on how you're going to deal with files, which I imagine is tricky and a large feature. Can you tell us about that and about other things that are coming down the pipeline? Sure. So the file stuff has been entirely Dominic. He's been figuring out sort of how he wants to handle it. The current plan is to use sort of the concept of a file pointer. So events are JSON objects that flow between agents, and they're basically schema-less. So he's introducing, you know, a little bit of schema where if you annotate your agent as emitting file pointers,

then we can look in the event for, I think that's just called file pointer, which will be a reference to either a remote S3 object or a local file object, or I think there's a third case. I think you could just put the raw binary or text data if it's small, in the event. And then agents that know how to receive that, like a CSV parsing agent or a file appending agent, can receive that and do things with it. So reading files and writing files, kind of two separate things, but they interplay.

Would that play into an import and export type of an idea as well? Are you referring to between systems? Yeah, I was thinking between systems, but I guess you're thinking between agents? Yeah, well, or between systems because a lot of people use Hugin to, you know, when I post on Facebook, post on Twitter,

that kind of thing. There's often a request for, and please move my photos, and that's not something request for and please move my move my photos and that's not something we really can do very well right now um also often people are running you get an environment where they can't write files locally you know heroku or docker um and so we need to make sure that you can do things like f3 or remote uh blob stores so then you could even do like timed or event-based backups or something like that yeah that would be interesting you certainly could fetch a photo on a on a schedule and do

something with it you know make a i don't know make a time lapse or something would be cool yeah what else you got so files i think that sounds like it opens up a world of possibilities um anything else that you guys definitely want to get done in the next you know six months a year that um that you're thinking about i think the two most important next steps for us are um extending this concept what's called a scenario i haven't mentioned it yet but you can take your agents and basically tag them with a label we call it a scenario and then you can export them and hand someone else a JSON file, which has a set of configured agents in it, and they can import it and use it. And then one of the cool things is you can actually peer-to-peer subscribe to their scenario from your Hugin

instance. And if you click the update button, it'll go fetch the embedded URL for their scenario on their system, assuming it's public, and do a diff and merge it into yours. So you can actually sort of subscribe to other people's agents and scenarios, which are basically just collections of agents. The next step for that to really make it much more powerful would be to variabilize it so that you can have a set of options that you fill out when you first subscribe to a scenario, such as your API key for something that isn't embedded already in the options of those agents, or your personal location preference or something like that.

Right now, you could do it by editing the options of the agents once they've come in, and that mostly works, but it would be really cool to make a library of these, which leads to the second thing that we really need, which is a community site to share these scenarios. Yeah, that was where I was just waiting for my turn to talk because I would have said, where's your HQ or your place where people can just share their agents?

And I love that you'd be able to just merge your own fields into one you're subscribed to. It'd be super powerful and actually kind of necessary if you're going to have that kind of sharing going on. Here's a random question that may seem off topic, but here we go anyways. How do you guys deal with expiring

auth tokens when you're doing background-based tasks? Lots of times an OAuth token will expire and then usually a user would have to get involved and refresh their browser or do the redirect flow again. What does it do in those situations?

It depends on the system. We use OmniAuth embedded in Rails to manage the actual request for the OAuth2 token. And then it depends on the system. So for example, Twitter and Dropbox, I've never seen them expire

i think they have perpetual access tokens facebook definitely expires after it might be a month it might be a couple months and they don't offer refresh tokens so you do need to get involved it will just break agents have a concept of whether or not they're working so they'll turn red if whatever that whatever that means for the agent. Often it means they've successfully received an event or successfully created an event in a certain time window. They'll turn red and then you can update them. They also have a log of their own errors. Are there agents that watch the agents? Yeah, there's agents that can control other agents. Either reconfiguring them

or checking if they're working. Or notify you that you need to come back and fix this thing? Yeah. Cool. So that's roadmap. You got files, you got the community stuff, anything else you want to mention before we move on?

I think the community sites, the really big one where we certainly could use help if someone wanted to get involved. It's its own chunk of work and it'd be really exciting if it was tied back in some way to the core human system so that you could either preview the networks of agents or, you know, have conversations about them and how they work. And it would be even more interesting if it was distributed so that, you know,

if I run much like hotline, which I mentioned earlier, if I run a tracker and it knows about a bunch of scenarios, someone else could replicate it with a feed and run their own. And it would be decentralized at least a little bit so that we don't have to run a core one. Or you could set up a commerce system. You could sell your agents and it'd take you all the way back to the days of your Perl scripts. And you could build a business around selling little scripts. That'd be awesome. But open source wins

so let's talk about roads to getting involved from two angles first of all what's the happiest path to becoming a Hugin user so deploying my own instance and then setting it up and then secondly from the development side if I want to get involved from

that angle where do I start and where do I go so start with as a user so if you're a user and you're not planning to develop on Hugin, I would recommend either Docker or Heroku. They both work quite well. If you are planning to develop on it, then you're going to want to make sure you have a local checkout and a fork. And it's not particularly hard to run locally. And then you're probably going to want to push your updates either with Capistrano or just pulling from your public or private fork of Hugin. And we have a pretty good tutorial that Dominic wrote

about how to take any sort of base Linux system. I think Ubuntu and one or two others that he supports and just full instructions on how to get it set up to run hugen as a rails app including monitoring and backups and stuff like that but that's obviously fairly involved and i wouldn't do that unless you're planning to also develop and want to make it really easy to push to your own instance so what about once i get up and running now i'm going back to my thoughts on managing a an install and i'm on the docker

version um do you guys have like specific releases that you do like when do i when do i update my stuff like how does that work once i'm running but i want to get your latest features so we use the docker hub automatic builds so whenever master gets updated, it updates the Docker build. And so you would just have to reprovision it. We don't really have a great versioning system. I've been meaning to figure out a good way to do versioning

on top of a Rails application, but I don't feel like we have a good answer right now. We try really hard to keep master green and correct, and I think we, 90% of the time at least, that's true. We have automated builds and automated Docker builds.

But I think what most of our community does is just pull when they see a new interesting feature go across the changelog, so to speak, of our releases. And either they saw a pull request get merged or I update the changes file, and they want that change. Very good. Well, I guess that would probably lead us directly into our closing questions. And I'll just start with this one because it seems like you have a lot of needs. You're an open source project with a good group of contributors, but there's lots of fun things coming down the pipeline and lots of places where people can contribute in big ways.

So with that in mind and with how you get going on development, if you were going to have a call to action for the open source community, if you're speaking directly to the community and they could help out in some way, what would you say to them? Well, I'd say welcome. We would love to have you. Hugin is really easy to get involved with because you can always add new agents,

which are very modular. We just expect you to write one Ruby file for the agent and one Ruby file for the spec. And we're happy to help if you haven't done testing before to help you write your RSpec. Beyond that, documentation and tutorials and updates to the wiki are very much appreciated. I think they're as important as code.

And a bunch of issues have been tagged with Help Wanted. So if you're looking for an interesting project to work on, and we've had a number of people just show up not convinced they'd ever used Hugin before and just pick a Help Wanted issue and start working on it. That's great too. I like that. So actually, you guys use GitHub issues, right?

So in there, you actually have a label called Help Wanted, and you will tag specific issues with Help Wanted. That's right. And any issue, people are welcome to get involved with. These are just ones that are... Like explicitly waiting for someone to pick them up. I think that's a good idea. Yeah.

Ideally approachable, too. I try to tag ones that i feel like a fairly new user could sort of make progress on right i think that's a great path to getting involved is to go out there check out you know the issues and look for the help wanted label start picking them off and then eventually you'll probably be ready to move past those into the more you know complex things very good well let's move on to our second closing question and this one is programming hero so if you had to name somebody who has inspired you or mentored you um or you look up to in the software community who would that be and why i think i would pick jeremy ashkenaz ganas um he created backbone underscore coffee script um he's just super prolific and has sort

of built the the backbone perhaps of uh sort of modern web modern javascript development you know backbone itself is great and it's fun if you want to sort of have a small scale component that's really stable and that you can rely on and build on and then it's informed um much of more modern uh deeper applications like ember um and then coffee script as well had a huge influence on new javascript and was really formative i'm very impressed with basically everything he's built i'll get my aim in on that one i'm a big fan of his as well and he also seems to be like traveling the world on a on a bike or something which uh which is what i heard inspiring as well uh and you know makes makes me quite envious um but very as you said prolific guy very interesting stuff and uh actually interested in getting him on the show let's do the next one so

hugen came across our open source radar again recently um we like to ask our guests what's on their open source radar so what's something that either you haven't played with yet and you want to or maybe you got a taste of it and you want some more if you had a free weekend and you weren't working on hugen what was a project or a couple of them if you have them that are on your radar that you'd like to tell us about uh well so i've started tinkering with rust um just starting it's been interesting and very different than many languages i've used um so i've been enjoying that and then be a lot more than a weekend but i'm starting to think about sort of conversational interfaces

like Siri and Cortana and Google Now. And I really feel like there's the opportunity here for an open source project to be innovative there. Because I think Siri and Cortana and those tools are a lot like AOL before the internet. Like it's one company trying to catalog all the world's information, trying to catalog all the things a user might want to do. And that's a ridiculously long tail, and it's just never seemed realistic.

And I feel like AOL was replaced by HTTP and the open internet because it's the obvious answer to distribute the problem. And it seems like something like Siri would be better replaced by an open protocol where you route requests to appropriate agents on the open internet that can meet your needs and take actions for you. I don't think Hugin will evolve into that. I think it's a pretty different type of architecture,

but it certainly got me thinking about it. I think there's something there. I feel like it's not going to be single company systems in 10 years. Yeah, I think that's interesting. I hadn't considered an open version of that. I feel like the barrier there is probably integration into the operating system and the devices out there, which are things that you can work around

but would make it a challenge. Challenges are always good to get people using it. Yeah, I agree. I think somebody, I just, something that was either in our weekly newsletter last week or we put it on Twitter, had an API into Alexa, which I think is Amazon's tool that drives the Echo and such products. And I think they at least are exposing that as an available API now. You can't actually decide how it responds, so it's still a black box.

But I imagine some interesting open source will be built around those kind of things. Yeah, it's a really interesting problem space. I think that more and more interaction with computers is going to be conversational. Because for many types of things, you just want to talk to it the way you would talk to a person. Go solve this for me. Absolutely. Well, Andrew, thanks so much for joining us. This was a blast. You've piqued my interest. I might actually go and get this thing set up and put a few things in there and see how it goes despite my deployment fears um good luck i'm expecting some pull requests i only do pull requests in anger so uh so you might have some

of that going as well but uh all feedback excellent i guess uh but thanks so much for listening stay tuned we have a bunch of great shows in the works. As we've been talking about, we are having Matt's on soon to talk 20 years of Ruby. Also Raquel Velez and Sarah Chips of Jewelbots are all coming soon. So if you haven't subscribed yet, what's your problem? Hit that button and

come back next week. I want to thank our sponsors this week. CodeChip, DigitalOcean, Rollbar, and Truesight Pulse. And, of course, we want to thank you, the listener, for sticking with us. We appreciate everybody who listens to our show. And until next time, we'll say goodbye. Outro Music