The Changelog: Software Development, Open Source - Blogging for Hackers (Interview)

Episode Date: July 16, 2014

Parker Moore joined the show to talk with Adam about blogging for hackers with Jekyll and GitHub Pages.

Welcome back everyone. This is the change log where a member supported blog podcast and weekly email conference fresh and what's new in open source. Check out the blog at the change log.com. Our past shows at five by five dot TV slash change log. And you're listening to episode 125 i talked with parker moore about all things jekyll and how he got started in open source today's show is sponsored by rackspace snapci and top towel we'll tell you a bit more about top towel

and snapci later in the show but our friends at rackspace continue to dedicate themselves to support the open source and developer community with their developer discount. And now you can go make something awesome on them. You're the makers. Each day you get up thinking about new, awesome, amazing stuff. And they just want to give back and help you put your imagination and skills to work. And Rackspace wants to give you something special just to say thank you. Send out today for their developer discount and get $300 in free cloud services on your Rackspace cloud account.

This discount applies to new products like their performance cloud service as well as their cloud queues. And you're even eligible for early access to new features and products they roll out. So make something awesome. Get started today. Developer.rackspace.com slash devtrial. And now on to the show. We're joined today by Parker Moore. Parker, you're a developer. You're doing all sorts of cool stuff. You're young. You're still going to school. You're interning at GitHub. You have a pretty fantastic story.

So I wanted to have you on the show cause I've been a fan of what you've been doing with Jekyll. So I wanted to kind of hear from the horse's mouth, so to speak about who this man is and what y'all are, what you're doing, um, in open source and what you're doing for, uh, for coding and stuff like that. So let's, uh, let's kick off the show by, I guess the easiest way possible, maybe to give the listeners a peek into who you are. So when you introduce yourself to a crowd of people, how do you do it? Well, I guess I've never had to introduce myself to a crowd of people of a technology or high technology background, but I'll give it a shot. As you

said, I'm Parker. I'm a student at Cornell University, about to graduate in August with a degree in information science. I've been programming for a really long time since maybe seventh grade and have loved it. I found Ruby in maybe 2011 and have loved it ever since. It's a fantastic language. I have a lot of fun. And in 2012, I found myself conversing with Tom Preston Warner and I asked to take over the Project Jekyll and the rest is sort of history. Yeah, that is, I want to tell that history as best we can. So let's maybe rewind a little further back in the day then. So you said you've been programming for a while. How early? Seventh grade is when I started. My math teacher in seventh grade, with whom I spent a lot of time because that was the year that I wanted to get ahead in math. And so I was taking

two math courses simultaneously. I forget what they were, but like geometry, probability, that sort of thing. And then also moving up to sort of more of the pre-calculus stuff. So I was spending a lot of time with this, this math teacher and he was a huge Mac geek and he had a bunch of Apple 2Es in his, in his room, as well as a couple old Macintoshes. And this was right before the Mac G5 came out. So this is, you know, when is this actually? 2003, four? I'm guessing based on math around 2000. Well, I'm 21 now and I'm just graduating from college. And I remember that September 11th, the tax were in fourth grade. So it was three years after that. So I think it was,

I think it was closer to 2004. But anyway, year is not that important. So I learned how to program in BASIC with a group of friends. We would take our lunch period, and we would go to this teacher's room, Mr. Martin, his room, and we would all leap onto an Apple IIe, and we would program for the entire period if we weren't watching Monty Python or whatever. So we had a grand old time and I learned a lot of the basics of procedural programming. In basic, if you don't know, you have to give every line that you type of code has its own line number. So you type one and that's

your first line and then you print high or something. And then 10 or 2, you could say 2 if you wanted to, get variable or something. So I learned a lot about how to think like a computer and sort of the basis of my computer science lessons or any formal computer science until 10th grade when I took CS1 and 2 at my high school. And we learned Java with Carol the robot. We would program to go around a grid and collect like buttons or something. So it was an amazing experience. Um, and I ended up doing, um, advanced placement in computer science my senior year in high school. Um, and I sort of diverged a little bit in college. I went to McGill university for my first year and studied linguistics and philosophy, um, with an, with an, a hint of political science. Um, and then transferred to

Cornell and decided, you know, computers are amazing. Let's study them. Let's study the sociological, the psychological, the economic impact of information and the information technologies that we have available to us. And so that's sort of what I've been doing since I transferred to Cornell. Wow. That's quite a history, man. I mean, I'm not really even sure where to dive deeper into except for, I guess, Java is one maybe sort of somewhat fun thing to begin learning with, but maybe, you're contributing heavily to open source. You look at your, your punch card on, on your GitHub profile and it's just like straight up green. So I don't even know how you actually do it and do school and do a lot of the stuff you do. You say in your free time, you help maintain Jekyll. I'm not sure if your free time is all the time or what, but maybe we can clear that up.

So, well, so I will say I can give GitHub a little bit of credit. They will mark a box green even if you only have one commit or you open one issue. So my minimum in terms of the GitHub punch card is one thing a day, one contribution a day. So that's not too substantial. But certainly that punch card keeps me active and keeps me busy and keeps me motivated, which is an interesting, um, element of that particular feature. Um, but I got into open source in 2010. Um, do you remember the iPhone tracker? Um, which tracker? Um, I forgot exactly what it, what it did specifically i it it would track you track where you were and an app that you could install on your phone it would track where you were um

and send that information to a server and there was some element of of subversion within this like there was some subversive element to this app such that you didn't necessarily know that you were being tracked. Maybe it was based on wifi address or something like that. So the, it was in a news story and maybe in the New York times that I was reading often. And so I found GitHub because the source code for this particular app was on GitHub. And my very first pull request was a pull request to this Objective-C app. I'd never touched Objective-C in my whole life. But there was a problem with closing, I forget exactly what it was, but with closing down a piece of the app when the app was, when the user went back to the

home screen or switched to a different app. So that was my very first pull request in Objective-C. And that was, I guess, my very first pull request being in the fall of 2010, right after I had started at McGill. And I was just getting into a friend of mine, well, an acquaintance rather, from Rochester, where I'm from. It works at Apple now and was a huge buff. He used, he was part of the, uh, the team that made cloud, the cloud app. Um, Nick Paulson, he's sort of been one of my like programming heroes, um, over the last several years in that he is just like a prodigy, um, exceptional at what he does. Um, so I sort of got to know him

a little bit through a mutual friend and got to know his work and was interested in Mac and iPhone programming thought, you know, this will be great, but then was a little bit worried because it was so tied to, to particular products. It wasn't something that I could run anywhere. It was, if the iPhone doesn't exist, then my job doesn't exist. So I sort of moved away from that. Platform centric. Right. All right. But yeah, so I found open source to this iPhone tracker project and in a way got hooked.

I would keep going back to GitHub of Agriculture and Life Sciences Communications Department. Not the academic department, but in the sort of college communications department. And we were rebuilding our site. And I had used Jekyll a little bit, heard about it, and said, why don't we use Jekyll for this site? It'll be great. It's all of the, uh, the information that they needed or, you know, the requirements for the site, um, the cows.cornell.edu, which is still running Jekyll at the moment. Um, all of the requirements were, were perfect. They, they fit the bill perfectly for a static site generator. So I was like, let's use Jekyll. And we use Jekyll and it was kind of painful. And I was writing a lot of plugins and hacking around and going through the source code and sort of learn the ins and outs of how Jekyll worked through that experience. And also the annoyance of their string encoding errors and, you know, the file system watcher was, directory watcher was still really old.

And so there was a lot to be done. And I recognized this. And in December, I said, you know, I really like this project and I really want to see it succeed. And so I emailed Tom Preston Warner and he eventually got back to me around Christmas time and was like, let's Skype. And so we chatted on Skype and he was like, all right, I And so we had chatted on Skype and, um, he was like, all right, I'm going to give you a contributor access to the repo. Um, you seem to know what you're doing. Um, just don't merge any pull requests. Don't change anything in master yet. Great. So like, just go through the issues. And so I spent my entire winter break going through

the issues on Majumbo Jekyll, um, and went through like 300 or 400 in the first week, um, just sort of going through and closing the ones that were, um, that we, you know, had to close because they were past done or, um, it was a quick fix or whatever. And, um, and actually one day, so I was in Rochester for that time and Nick Coranto, Qrush, Crush, on Twitter and GitHub was also a contributor to Jekyll. He had access from early on and he's in Buffalo

and Buffalo is only about an hour away, drive from Rochester. So I went one night to a Buffalo open hack night and he and I hacked on Jekyll, which was awesome. And we closed a lot of issues as a result of that one night. So just sort of got more and more involved and became more and more obsessed with this product and the potential of static sites and sort of continued on. And I went in January, late January of 2013, I decided to take a semester off from school altogether and went to go work for, um, sex in Berlin. They make wonder list. Right. And, um,

and I loved wonder list and I love the people that were, that worked there. Um, so I was like, Hey, you know, is there a possibility that I could intern with you? And they interviewed me and they were like, you should come intern. Um, and so of course, yes, we'll have you. And so I, I went to go intern, um, and learned a lot there. Um, which, you know, which was, and it was an absolutely amazing experience. So were you actually in Germany or just, did you intern from here in the States? I was actually living in Berlin. I lived on Charles Seychelles, just off of, no, on Charles Seychelles, right there in Mitte. Wow.

So I had a lot of free time because in college I didn't, I don't have a lot of free time when I'm in classes. But I have a lot of free time when I'm working nine to five. So, which is surprising to me. So I was, I was, you know, hacking on Jekyll more and more and we released 1.0 by May. And so this is what about, I guess, May of 2013, right? Yep. Just about a year ago. So you've kind of had this pattern of impressing people and getting the right connections, I guess, pretty much early on. And then using that as a way to bootstrap your skill set and bootstrap your abilities and kind of get in the right places. So how much, I guess, maybe to rewind maybe a tiny bit,

how much do you know about the earlier days of Jekyll and kind of where it came from and its philosophy? And then I guess now, as of this past May, which would be one year since 1.0, basically, right? So you got 2.0 that just came out. Yeah. So I don't actually know very much about the early days. I know it used to be called auto blog. So it was originally very focused on blogging and originally very more blog centric than blog aware as it now states. I states. Um, I'm not sure what, what Tom's original wishes for it were. I think he just wanted to write a static blog and didn't like any of the products that were available. And so he wrote it, um, along with, along with Nick.

So I'm not really sure about the early days, but the philosophy was, was in the read me, um, a blog aware and, and in the, um, GitHub description readme, a blog aware, and in the GitHub description as well, a blog aware static site generator. So I sort of took that and based on the issues and how people were using it, molded it into something that I thought people would like. Yeah. Let's talk about that a little bit then, because it almost seems like you've said a couple times a product. You kind of act even – you probably would agree with this, but like a product manager. Like you listen to the crowd or you kind of – you go through the – like you had mentioned earlier in your history with Jekyll that you kind of went through several hundred issues in a weekend to kind of get a heartbeat of where it's at. What kind of telltale signs, I guess, did you use that are inherent in issues with Jekyll that helped you understand where it was coming from or where it needed to go to be successful for

the people that were using it? That's a really awesome question. I think when I was going through the issues, the biggest, of course, indicator of a problem or a feature that should be implemented is the sheer number of comments on the issue. If there's an issue, like for right now, there's an issue that stands open for incremental regeneration. Basically, taking a site that's already been built, understanding the current state, and then only changing or rebuilding the pieces that need to be rebuilt, which is an NP-hard problem. Yeah, it's probably a huge saving, too, for the disk you're on and just in general, it's the speed. Exactly, exactly. It would be a huge win.

And there are a lot of people who've said, this would be amazing, this would be amazing. And of course, we've just both agreed it would be an amazing feature. Um, the, as I was going through the, you know, several hundred issues, I think there were like 623 or something, uh, open issues when I took, when I came onto the project, um, as I was going through them, depending upon the number of comments and the sort of logic of each argument, um, I sort of weighed them in a certain way. Um, if there was a, and, and sort of got to know how people were using it based on their comments in the issues and the, you know, occasional site that I would come across, um, on some repository on GitHub. Um, and as that, as I sort of got to know a little

bit more about how people were using the product, um, I said, you know, this, we should support this or, or this is not really how we envision this product to be used. But maybe we can make a compromise and just make it easily extensible so they can build it on their server without having to do all this crazy monkey patching, etc. And so sort of weighing what are Jekyll's primary objectives based on what was in the readme versus how are people using it versus how do people want to be using it what is the best sort of middle ground between those three elements um and i've i've that that took a lot of thought and when you first take over a project or first enter into a project

like jekyll that has been around for five years um and it successful. It took me probably six months to figure out exactly what the trajectory for this product should be. I'd imagine even your methodology had to be pretty methodical too, to kind of go through comments. And I mean, maybe you're weighing them based on, is there a code sample? You know, how passionate is this person? Is it, you know, is this person commenting on several other issues as well or kicking up issues? I got to imagine that was a pretty tough job to triage. And like you said, six months to even get a heartbeat. That's a lot.

Yeah. And part of it is because there are so many people using it. And as well, it was still being used on GitHub Pages. So I sort of had to weigh in, well, how would this change GitHub Pages? Is this still secure for GitHub Pages? And one of the things that Tom said to me during our initial chat was basically like instill the fear in me of change, which is very interesting. That said, Jekyll is good as it is. It is good at present.

It's good. It can be great, but it shouldn't be. But the way to get to greatness is not through completely rewriting everything that you have. Basically to say, add on to what you have, change the things that absolutely must be changed, but don't go too crazy, basically. So in terms of accepting pull requests, that made me very skeptical. Originally, I was like, oh, you want this feature? Let's merge it in. It'll be great. But as long as the CI passed. But after some amount of time, even the general idea, not even just the code, I would scrutinize significantly.

Is this something that is useful to the majority of Jekyll users, for example? Is this something that is safe to run on GitHub pages? Is this something, et cetera, et cetera? So it has taken a long time, but yeah, I think that's a really key part to taking over a project and to making something cool. So what, I guess maybe playing off of, if I'm tracking with you, early on Tom said, you know, hey, kind of toe the line, so to speak, when you first took over. How is that contrast against how you are now with the project and what changed? So when we, when I initially took over, Tom was still very much present, you know,

quote unquote. So I could, I had a tag on, on the issues that was at Majumbo and I would email him if that got too high, maybe 35 issues or something like that. And it just needed a decision by him. It just needed, you know, hey, what do you think about this? Is this a good idea, a bad idea? So I sort of at the beginning was really chatting with him a lot as much as possible and getting his idea about what the product and where it should go. And as a contrast to now, I have complete control. I can't imagine. So I have complete control in the literal sense in that I can change anything, but there's still some philosophical constraints, of course, in that I want it to be something that people like to use,

et cetera. And something that continues on with the tradition of what Jekyll has been. Um, if you take a product and you completely modify what it's like completely change everything, then it's no longer the same thing. So existing Jekyll sites, for example, I don't want someone to write a site and then for it to immediately break. Um, we've with the 2.0 release, we did our best to, to maximize the number of backwards compatible changes. I think there was like maybe one backwards incompatible change and it was, we still had a way to work around it. So, yeah. Not to mention too, you also had GitHub as, I guess, a customer, so to speak. Right.

Because they're using it for pages and they obviously have a trajectory where they're taking pages and what they're using it for pages and they obviously have a trajectory where they're taking pages and what they're doing with it. It's obviously a large part of the open source ecosystem where people host their docs on there or they host their single page, kind of here's my repo kind of thing, or even just simple sites. It was a part of what GitHub was doing. So how did, I guess maybe to break the seal on this,

right now you're an intern also at GitHub. So that kind of had to blossom into even new opportunities for you. Can you talk a little about that? Yeah, so my exact title is a GitHub Pages contractor. And so I, as a contractor, am working on GitHub pages and trying to make it an even better platform. Some of the changes that we've released, like the site.github namespace, there's been a complete rewrite behind the scenes in the back since I've joined the team. And basically what that's done is allowed me to gain new insights into how Jekyll's being used. In particular, I'm working with Ben Balter, who's an amazing guy, really brilliant.

He graduated from law school, was a WordPress core contributor, was a White House presidential innovation fellow. He's just a crazy cool guy. He's sort of been my mentor on that project. Um, the guy watching over me and making sure I don't mess up too many things. And, uh, and because he's focused on government, I've gotten a huge, uh, I've, I've gleaned a new or gained a huge appreciation in how, um, how Jekyll is being used on, on the massive scale or larger scale. Um, so if you're, if you're a government institution that wants to publish data, how can, how are they using Jekyll to publish data? For example, um, they're using WordPress and Jekyll in many, many occasions

to publish open data, to, um, publish process, um, project open data is a Jekyll site. Um, and they're using that to write policy around open data. If you're, you know, the city of Chicago, how should your, how should your data be released? And what are the, what are the guidelines surrounding that, that entire project that, um, every, everything within that, all the content is written as a Jekyll site. That's funny that you mention Ben because also just being a core contributor to WordPress, for those who know about Jekyll, or maybe you're a listener, this is the first time you're hearing about it. I don't know where you've been, but WordPress and Jekyll tend to fall into the same conversation because it tends to be a fork, a choice of left or right, Jekyll or WordPress. And a lot of the reasons why developers like it is, one, because it's just developer-centric, I think, far more than maybe WordPress is, but not in a bad way.

WordPress is kind of designed and delivered as a product for different types of people and different types of developers. But the separation of the database and stuff like that. So does Ben get involved with the product? Is he involved with Jekyll now or is he just kind of an advisor to you? He's definitely involved in the product. Not as much as I am. He's not around day to day. But when I have sweeping questions or large questions that would have sweeping effects on the product I tend to run them by him

he actually was kind enough to invite me out to San Francisco or out to the GitHub headquarters I was interning for a visual supply company at the time out to the GitHub headquarters one Saturday to sort of host a Jekyll Nano Summit there's a GitHub issue with all of the on Jekyll Jekyll, with all of the details of that summit. And we sat in the Situation Room in the GitHub office, and it was Ben and me and Mislav, who's a great guy,

and Tom came for about an hour and, or an hour and a half, and then Garen as well, GJ Tar tarikian i think um i'm not sure about your name sorry garen uh your last name rather um and so we sat around and matt matt uh rogers of course my co-maintainer um he was in he wasn't able to come physically but but he was he was beamed in via blue jeans um and so we we sort of chatted about the future of Jekyll, what we wanted for 2.0, what we wanted for 3.0, sort of what the future would be. So Ben has been a significant advisor and has sort of opened up or suggested things like a nano summit where we would all meet and chat about it in Meetspace that I would never have thought to do.

And he scheduled all of that. He flew out from D.C. to San Francisco just for this. And it was a really cool experience. So he's been a very serious advisor of this project, partly because I think he sees the potential of static site generators and because Jekyll's already on GitHub pages, the amazing potential for open data, for open source websites in general, the Bootstrap website, the Ratchet websites are both open source and on GitHub pages.

And so it's an alternative to, to WordPress in many ways, because it is very content focused though. It's less focused about how does my theme look? It's more focused on what are the words that I'm putting out there to, for the world to see. It, he's sort of been an evangelist in many ways of Jekyll and a wonderful supporter of it. Let's pause the show for a minute and give a shout out to our sponsor, Snap. Snap is a hosted CI and continuous delivery service that goes far beyond letting you do continuous deployment. Don't waste your time and set up your own CI box under your desk.

Use Snap. Snap has first class support for deployment pipelines. With Snap, you can push any healthy build to multiple environments automatically or on demand. This means with Snap, you can do things like deploy to your staging environment today, verify it works, and later deploy the exact same build to production. Snap integrates deep into GitHub, has great support for lots of languages, databases, and testing frameworks. Snap deploys your application to cloud services like DigitalOcean, Heroku, OpenShift, AWS, and many more.

You can also use Snap to push your Ruby gem to Ruby gems. And Snap is always free for open source projects. Try Snap for free for 30 days today. Sign up at snapci.com slash the changelog. I never really thought about the, I mean, I guess it seems kind of obvious and logical, but I never really thought about the impact to increase the level of open source,

whether it's code, content, or whatnot, that Jekyll's actually had the impact of. I always kind of, I guess I really just never thought about it like that because, I mean, we covered Chicago's open data about a year ago when they first started to publish a lot of their open data and whatnot. And they're leading the way in a lot of ways for local governments to do that kind of stuff. And then what you mentioned too about just documentation and then Twitter Bootstrap and other sites that are kind of put out there and they're open, right? Like even, even your site, your, your blog is open on GitHub. It's, you know, it's, it's kind of like, it just seems like a

natural thing and it only helps, uh, bootstrap and bolster this open, open source ecosystem. We all kind of desire to be in. Exactly. And one of the main tenants of, of Jekyll, um, has always been to, to as much possible, and GitHub pages helps with this tremendously, as much as possible, open source your website. Let other people learn from it. There's a great page on the Jekyll wiki called Sites. And we have this one rule. You post the link to your site, but you must post the source for your site as well so if your sort if your site isn't open source it can't be on the sites page and there's something like a thousand almost a thousand um sites with their sources linked directly next to the to where the page is

so if you go to see a site that you really like then the source is right there for you to look at um so it's a great learning learning tool and who has a site, anyone who has a GitHub account can edit it. So the Jekyll community has been a huge proponent, I guess, of open source and making sure that they can learn from each other the way that open source champions. Before we, I guess, before we turn away from, I guess, maybe newer topics, more topics, I want to ask you a bit more detail, if you can share it, about the conversation that Ben had with you when he kind of enlightened you about the overarching ecosystem of Jekyll. What was that conversation? What were some of the things he kind of fed you to help you really get the aha moment and kind of be able to tackle what you've done? So it's been sort of an ongoing conversation. It's comments here and there in the GitHub pages,

repo and on Jekyll, as well as at that Nano Summit. But the overarch or sort of the aha moment that I had was when Ben said two things, two things that I really cared about. One was be the pull request that you want to see in the world, which is really cliche, but really awesome, and goes along with the let's make Jekyll the coolest thing that it can be, not because we want it, but because everyone wants it and because everyone can contribute to it if they wish. And the second thing is make it as simple as possible. Absorb complexity as much as possible. That is the way to a good product.

And that I've sort of, you know, GitHub itself, the organization and all of its employees champion that concept. If you don't make your user interface simple, if you don't make the process simple, then people aren't going to use it. People aren't going to do what you're asking them to do. So he's really molded this product into something that is as simple as possible. And that's sort of where it's been an ongoing conversation,

but sort of where we get that, that, that heightened sense of simplicity from, I guess, since, uh, this might be a good time to talk about, um, you know, I guess earlier, um, I'm almost forgetting which month it is sometimes, but I guess it's earlier this month. Cause it's, it's the last day of the month we're recording on May 30th, by the way. Um, cause the show doesn't always come out the same day we we actually record it but earlier this month um you released um Jekyll 2.0 but you know kind of flipping that on its head last year you were releasing 1.0 a lot's changed you got a lot of newfound vision because of this history and all that. What are some of the core things that changed from Jekyll 1.0 to Jekyll 2.0? And then also, I guess, to maybe make sure that those who have been using Jekyll for the last five years don't have breaking sites.

Right. So to answer the first half of the question, what has changed? We introduced a lot of things that, a lot of new concepts and a lot of support for technologies that people were using. So the two main concepts that I really enjoyed working on and really enjoyed releasing, I was really excited to release, were collections and YAML front matter defaults. So collections allow you to define a series of documents, all collected into one entity, as it were. So one of the reasons, or the reason that we originally wrote this feature was actually because during the Jekyll Nano Summit,

Mislav said, I'm writing for Zepto the API documentation. I want to have one page per document, or rather one page per method or function in the API, and I don't want to have to mangle, jekyll, monkey patch it up the wazoo, in order to actually write out individual pages for the API. And I don't want to, mixing up the pages or posts, then I don't want to use posts for it, et cetera, et cetera.

So he wanted a lot more customization. He wanted to be able to take the documents and import them into collection or into pages as well, so include them and write them out. So he needed them to be to some insurance to make sure that they were processed beforehand, etc. He wanted them to be to be custom. He didn't want to necessarily have to have them write out as a file. So collections natively or in the most basic sense, you have a series of documents that contain data, YAML front matter, and content, and that's it.

You can optionally set up each individual document to have an output file that just goes into forward slash collection name, forward slash document name. And that will output an individual file if you want that. But the idea is sort of data plus content mixed together in a nice way that isn't just YAML. Can you give an example of it? I'm thinking, is it like if I were publishing a podcast, so to speak, would it be like a podcast? Is that what you mean?

Where it acts like a page or acts like a post does by normal traits, but you kind of give it its own namespace and its own kind of model, so to speak? Right. So you use collections for anything that isn't necessarily date sensitive, although you can use dates and collections if you want to. When we were first setting up the Jekyll site, for example, we had each docs page set up as a post. It was just like 2010, 01, 01, here's my post, or here's my docs page, and we set it up as a post because we wanted to make sure it was processed before the pages, write them out into pages, et cetera,

and have an individual HTML file generated for each docs page as well so when we were doing that it it was creating a collection of items but in the only only collection that we had which was posts um you can think of posts as a date centric collection okay um of of documents and each document is called a post in that case um so what we wanted to do is take that idea and generalize it, not make it so date-centric. People kept asking, hey, can we remove the dates from our posts? Of course, in a blog, every post should have a date. That's the point of a blog. It's a chronologically ordered series of content. So we said, well, we're not going to take dates out of posts. Let's create some more generalized concept that's based on posts, but allows you to

collect various items and write them out to individual files or just have that data. So an example is if we were to rewrite, if Jekyll 2.0 were up on GitHub pages, I would take all the docs pages that we have for Jekyll at the moment in site docs, and I would move them into a collection called docs. They would probably exist the same way that they do right now, but they would exist within this site.docs collection. This would allow me to iterate over them if there were maybe two pages that I wanted to have on the same output page, so two or two documents that I want to have on the same page, or if I wanted to list all the pages in like a sitemap, then I don't have to say, okay, site.pages, like four page and site.pages in Liquid, and then explicitly remove

all of the CSS pages or the index.html pages that aren't docs. I have this one subset of the site in this underscore docs folder that I can iterate over, that I can output, that I can, et cetera, as its own entity. So i guess you can think of collections as a subset of the content of a of a site in a way and this is just one of the many changes and also i guess it's probably smart to drop a caveat in there that uh the collections is kind of unstable it's in it's it's out there but it's not finalized it may change right right um and the other thing that we that we did or the major major feature was It's out there, but it's not finalized. It may change. Right, right. And the other thing that we did, or the major feature, was YAML front matter defaults. So if you kept writing that you wanted the layout to be article or layout to be post in all of your posts or all of your pages in a specific subdirectory,

now all that you have to do is add a few lines to your configuration file, and you have layout post set for all of the posts or pages that you specify. Right now, YAML formatter defaults don't work with collections, which is a bummer. But we're working on getting it for the 2.1 release, which should happen soon. So I'm trying to think of where we can go next. I know I got a couple of things on my list that I want to mention, but I guess maybe I don't exactly struggle to really – I guess maybe to some degree I do. But what's the sweet spot for Jekyll? You mentioned earlier with Cornell working there and how you had this list of requirements and Jekyll was perfect, but that was way back, you know, several years ago, at least it seems to be, you know, what is the sweet spot for Jekyll? I know we talked a little

bit about documentation, but for those who are listening out there that aren't using Jekyll, what would make them want to use it? Why should they use Jekyll? Like it's not a CMS, it's not a blog, it's evolved. Right, right. I would say for two reasons, I always stick with Jekyll. The first reason is that I can use Git. I can use my lovely version control system to version my content, not just the theme or whatever that I have, but I can version my content, which is amazing. I can submit a pull request for my content, and that's hugely powerful. The second reason I'd say is because it's a static site generator,

and this is true of any static site generator, the sweet spot is really in page load time. There have been a couple people who run Jekyll sites on their own servers, maybe like a T1 small or something on AWS. And their server never goes down. Whereas if you have WordPress, you run into problems with memory or you run into problems with the database load being too high. And so your database just cancels connections or you can't connect to it when someone loads your site. So by stripping all of this out and just having an HTML file that Nginx or Apache says, oh, here's your static file.

Here's the content that you need. Amazing. It reduces any problems you would have with scalability to a ridiculous degree. So I know I'm kind of hopping on one of those things you mentioned there, because the changelog is actually a WordPress site, and we're on DigitalOcean. We have a pretty beefy server at DigitalOcean, so we like it. I mean, it's great. But for a bit there, we had issues with our site toppling over and getting database connection issues, because basically MySQL would bubble up to the point where it would take all the memory and then Apache couldn't run anymore so it couldn't connect to MySQL because – or something to that degree.

It was just a mess. And essentially we kind of did – essentially what I would probably consider a reversal, right? We kind of did what would eventually just become cached files right but you know we used uh wp cache to to cache all of our files which essentially is exactly what jekyll helps you produce in the first place which is a static site essentially take this dynamic site and make it static based on cache times and you know um timestamps and stuff like that so it's that's the one that i can actually really kick myself in the butt for but at at the same time, I love a lot of what WordPress gives, but you know, I never really moved over to Jekyll because of like multi-author support

and stuff like that. What do you say to people when they talk about multi-authoring and just, I guess, publishing tools that make the job a little easier? So one thing that I followed intensely and actually that I think Ben originally told me about was Prose, and I'm sure you've heard of this. But Prose is sort of the silver bullet, or is intended to be at least, the silver bullet publisher for Jekyll sites online.

I've seen this, yeah. You connect to your GitHub account, you go to a repository that you have, a site, and you make edits and you commit them and it's great. Unfortunately, sort of development on pros has slowed down significantly as it's not being used as much by the development seed team. These amazing guys down in DC

were the ones who originally created it. I think. were the ones who originally created it. I think they were the ones who originally created the landing page for healthcare.gov using Jekyll. And so they've created a replacement basically for the authoring tools that WordPress gives you. So one of the things that I've always loved about WordPress is that it's super simple to go in and make a change. And then, you know, you click, you hit save, it puts it in the database and you're done. What pros aims to do is, is emulate that process, but for Jekyll sites using version control. So when you, instead of hitting save, you hit commit instead of, of, you know, going to a specific, instead of going to your site slash WP dash admin, you go to pros.io slash, you know, your, your site, uh, repo slash the path, and then you

edit it, commit it. You're done. You said it's, is it a slowing down on development right now? Is that what you said? At the moment? It's, it's not really, it's under active development, but it's but it's a little bit slow at the moment. And that's just because there's no immediate pressure. If there's anyone who's really interested in having it continue to be developed and to see it grow,

I'm sure that the development seed guys would be interested in hearing from you. It's all in JavaScript, and it all runs on GitHub pages with the exception of something called Gatekeeper, which is the Heroku app that does all of the OAuth with GitHub. We'll have to either get them on a show or find a way to, I guess, put some light on that. I mean, I'm glad you mentioned that because it's under development, but maybe they're just not feeling like, oh, it's really needed because it's not being used by a lot of people? Is that the, is that the concern now? It's being used by, by a pretty good chunk of people, but it's, it's because it doesn't, they, they originally

developed it so that they could write healthcare.gov in a way, you know, the majority of healthcare.gov, the content based piece of healthcare.gov, the content-based piece of healthcare.gov, the things that don't need to be dynamic, basically. The marketplace, for example, would have to be dynamic, but, you know, just, you know, FAQs and that sort of thing don't have to be dynamic. So they originally wrote it so that anyone could have this wonderful interface for changing files. And so people aren't using it as much and the development is slow because they aren't using it anymore. Yeah, I feel like, I almost feel like there's, I know you're in school and you've got a busy life and maybe this isn't, you know, the only thing you wanted to do in your

development career, but I kind of feel like maybe you might inherit not so much another project, but at least kind of bring that into the fold, so to speak, because it's so closely aligned with this publishing way for Jekyll that makes it a little easier. Because one of the concerns that I think we tend to have is it's okay for us as developers to use Git and push via the command line. We're very comfortable with those kinds of things, but it's when we start to invite our business analysts and other people that are not always so fluent with it who may just want to go in, make the change, like you said,

and click save. They want that experience. They don't want to have a certain Ruby installed or do I use RVM? Should I use – how do I version my – how should I use my Ruby? And then you start to bring all these questions in to somebody like, forget it. Can we just use WordPress? WordPress works. Or that might be an example of the conversation you might have. questions sent to somebody like, forget it. Can we just use WordPress? WordPress works. Or, you know,

that might be an example of the conversation you might have. So I feel like there's an opportunity here maybe to bring that into the fold and make it part of your work with Jekyll and GitHub Pages. Absolutely. And I, you know, we need a couple more things, for example, previews. For a pull request, I've always wanted for GitHub pages to build pull requests. If you can build a pull request, then you can see the resulting site on GitHub servers immediately. You don't have to wait or you don't have to clone it down and deal with Ruby installation. One of the pain points for Jekyll is definitely installing Ruby. It's not supported technically on Windows, but it's not too hard to get it up and running,

but it's still a bit difficult. So there are a couple more elements that have to come into the fold here. But once those are in place, if they do come to fruition, then it would be a pretty easy fix. I think Proz is trying to take the intimidating, somewhat intimidating interface that GitHub has

with issues and discussions and all of this business and make it as simple as possible and as friendly as possible. And because it's Jekyll-specific, they make ready-amble front matter, for example, a piece of cake. So they just have individual form items that you can specify. So your date should be a date and your title should always be, you know, they give you a text box for your title and a dropdown for your layouts and all of that stuff. So, so, you know, there are just a couple more pieces and then, and then I think we can make a bit, we can make the switch. So a mutual, I guess a mutual friend of ours had two questions,

I guess one of you, you've kind of mostly answered, but if there's anything that maybe you left out that you want to mention, you're welcome to. But so to the questions, Brandon Mathis is the mutual friend I'm talking about. And we'll talk a bit more about your involvement with him and, and Octopress and that kind of stuff.

But one of the things he wanted me to ask you, but I think we've already answered this to some degree. So feel free to riff as needed, but he said, you know, this is verbatim what he said, Parker came out of nowhere and impressed Tom and I both enough to become significant parts of both of our projects, Jekyll and Octopress as the projects get him to talk about how, so I think you've kind of answered that,

but is there anything of the how that he's talking about that maybe you didn't leak? So the, that's, that's a great question. The, the way that I got involved with Jekyll is that I emailed Tom. Tom was this, is this, was at the time the CEO of GitHub, um, someone that I didn't think I was actually going to be in contact with ever. He was not replying to issues. Um, but I emailed him and I emailed him three times, um, over the course of like eight, eight or nine months. Um, and finally in December he replied. So I think the key is to, um, sort of take that leap of faith as well as, and I, I got in contact with, with Brandon because

I was following him because I loved Octopress and I was using Octopress for my blog. Um, so I was following him and I was like, Hey, do you need any help with Octopress? I tweeted at him and he was like, yeah, I would love some help with Octopress. And then we just sort of kept going with that. Um, and, uh, so, so it's, you know, reach out if you're interested is sort of the key. Um, I think that the main bottleneck for finding, uh, added maintainers is the, is to see their interest. Um, are you interested in interested in devoting the time to maintain something and to make it better in a more meaningful way than just submitting a pull request here and there? So I'd say persistence and just make that initial step. Okay. So maybe dovetailing off of that, then his second part of that question was,

and I had the same question, so it's just kind of from both myself and Brandon. And we'll talk, you know, for those listening and thinking, what the heck is OctoPress? We'll was, and I had the same question, so it's just kind of from both myself and Brandon. And we'll talk, you know, for those listening and thinking, what the heck is Octopress? We'll talk about that here in just a second. But the second part of that question, a series of questions is, do you have any, and I think you kind of touched a little bit just now on this, but do you have any advice for those out there who are, you know, similar to you, you know, interested in technology, but want to get started with open source software and don't really know where to start or really how to break through, I suppose? I think the main barrier to entry is to know how to contribute, right? So from my perspective,

go to the project that you're using the most. Maybe you're using Rails. Rails is a very intimidating project to first start off with. Maybe go to Jekyll. Go to Jekyll, find an issue that you care about. And find an issue that you care about or that you think might be a relatively quick fix, even if you don't know the code. It doesn't matter whether you've looked at the code or not. See that, then clone down the repo

and look through the code a little bit. Try to familiarize yourself with how this particular product does what it does. Once you've done that, then try to pinpoint exactly where the issue is happening, or at least where the issue might be occurring. Change that, submit your pull request as best as possible add tests do your do's as it were in order to see that that would be merged and submit an issue

or submit a pull request for that sometimes even that is too much to pick an issue that you might be able to handle and change it up or fix you know, fix it. So maybe what you should do instead is find an issue that you think might be easy enough to do, look through the code a little bit, and just write a comment and say, like, hey, I'm interested,

you know, I'd love to help fix this. I'm not really sure where to start. Maybe here, here, or here. And sort of indicate that you're thinking about it and not really sure where to start. Um, maybe here, here, here, um, and sort of, sort of indicate that you're thinking about it and that you'd love to help. Um, I'm, I can, I write way more comments that I, that I, you know, then commits that I write. Um, so I'm happy to, to help someone through, through that process. Um, I love, I love to see newcomers to Jekyll. It's the best thing in the world. Um, who have never submitted a pull request or who made their GitHub profile yesterday only to write an issue or to submit a pull request. So for people to find that repository or that project that you're interested in, find an issue that you think you might be able to handle, write a comment or just fix it and submit a pull request. If the pull request isn't the way that they want that they want to handle it, the maintainers will say, this isn't really how we want to handle it, but here's how we would prefer. And then you can implement that switch and switch things around.

So it's, it's more a matter of like just throwing yourself into the process and, and at every turn offering your help and the time. Let's pause the show for just a minute and give a shout out to our sponsor, TopTile. Now, we've been working with TopTile for about a year now, almost a year now. And we thought it would make sense to circle back and talk to some of our listeners who have applied to TopTile and have been accepted. Because only about 2-3% of the engineers who apply make it past their strict elite engineering process and Daniel Lauzon a long time listener and fan of the changelog is now

living the dream. He's an elite engineer at TopTal and I say living the dream because he's now able to have 100% control of the types of projects and technologies he's working on as well as the rate he wants to charge. Daniel earns 100% of his income as a TopTal engineer, and he wanted me to pass on his seal of approval of the TopTal experience.

For those of you out there who are freelancing or would like to test out freelancing, you've got to check out TopTal. If you think you have what it takes, head to TopTal.com slash developers. That's T-O-P-T-A-L.com slash developers to get started. Tell them that ChangeLog sent you. I know a lot of the times when folks come on the show, when we ask them, which we'll ask you here in a bit, like the call to arms is usually just help us triage issues, especially a lot of high traffic projects with issues that have just lots.

Sometimes it's just, can you comment back to somebody? Can you just help me, you know, keep the heartbeat alive so that they don't think we're a bunch of jerks because we're busy writing code or busy with day jobs. And this is like you in your spare time or your free time. So you say, you know, so it's like, it's kind of like that. And then even, I like what you said too, about, um, not just saying, Hey, how can I can i help it's i've got an idea about this particular problem i've got a couple ideas on how i can solve it or what i think might work can you give me some guidance because they'll respond easier to to at least you know some leg

work versus just hey i'm here to help what can i do right pick up a broom, you know. Exactly. Exactly. So let's talk about your involvement, not only with Jekyll, but then Octopress. This is like, we've gotten through this pretty much, you know, this whole show without really mentioning the relationship between these two. And I don't want to do it any ill justice because I haven't kind of riffed with Brandon much lately about the project and where it's going, but I know you're involved in both now. Can you kind of give the listeners kind of a mention of how these two projects align and where you see them fitting? So Octopress at the moment in its current form in iMath is slash Octopress is sort of a framework around Jekyll, a series of rake tasks generally, that makes it easier to work with Jekyll. It comes with a built-in classic theme that allows you to just go rake install, and it installs this theme, which is beautiful. I'm sure you've seen it on a lot of sites um and it's the idea of of octopress is really to

make it as easy as possible to get started blogging with jekyll um when you run gem install jekyll you have nothing available to you um you have now um since 1.0 i think or maybe 1.2 um you have jekyll new and jekyll new and and then you give it a path. We'll install some, you know, very basic, very, very run of the mill or, you know, bare bones, skeleton sort of site. But if you're, if you're looking for like, if you're some Erlang programmer or something and you just, you don't have the time to set up a UI, you don't want to write any HTML. You just want to write what, like write a blog post about something, then all that you have to do is clone down the repo, run rake install, run rake new posts,

and then give it a title, and then boom, you're off. And it's the coolest thing. It handles new posts, new pages, deployments, previewing, generation, all of that stuff. One of the key points as well is that it has this one task called Req Isolate. And one of the points that you mentioned earlier about Jekyll is, or I guess that we talked about briefly, was this idea of incremental regeneration. Right now, Jekyll just says, when you run Jekyll generate or Jekyll build, rather,

it just takes your whole site and rebuilds it. And that's not that efficient, especially if it's the same in 98% of the files. So if you have a massive site, maybe of like 1,200 posts or something, you've been writing for a long time. I know Matt Gemmel uses Octopress and he has, I think, close to close to a thousand posts or he did, you know, a couple of months ago. I'm sure he has over a thousand posts now. He's a great writer, but it just took so long for those posts for that site to regenerate that he said, you know, I can't do this. So Octopress gives him the tool called Rake Isolate, which gets rid of all the posts except for the one that he's working on. And it just regenerates that one, the entire site, but just with that one post. So it removes the 999 other posts that he doesn't need to be looking at

because he's not working on it right now. And then you run rake integrate and it puts all the posts back and then you run rake gen deploy and he deploys a whole new thing once it's done. So is that using Git magic to do that, or how's that working? Rake isolate basically just takes all the posts except for the one that you're working on, moves it into a separate directory that Jekyll won't look at, and then runs Jekyll build or Jekyll serve, depending on what you're doing. So all that it does is it just moves the files and then moves it back when you integrate. Right, right.

It's an amazing idea. And it's so dead simple that it's surprising that no one else has done it. But that's sort of a unique piece to Octopress. So Octopress is sort of this framework that makes blogging with Jekyll or writing sites with Jekyll as easy as possible and gives you the UI or the site theme and all of this stuff to work with immediately.

Did the projects, so it's almost, even still now, even after hearing that, it's still hard to really see where they, you know, where they separate. I understand that it's kind of built on top of Jekyll, but is it a point that they'll ever merge, they'll ever share the same functionality or essentially tackle the same kinds of problems? Or is that the reason why you're involved in both projects to kind of help keep them in parallel and keep them kind of working together well? I'm definitely, I'm definitely involved with both in order to make sure that they're going along in parallel. I'm way more involved in Jekyll just because Jekyll has no,

I mean, Matt's working on it as well, but Matt's really busy. So I'm the one that's sort of taking care of the immediate day-to-day sort of stuff with Jekyll. And because no one else is doing that, I'm sort of taking more of a backseat or more of an advisory role, I guess. I look over pull requests that Brandon puts up on Octopress repos and help them with problems as needed.

But in terms of the future, there's definitely the possibility that they would merge. The Octopress as we know it today would not be the Octopress of tomorrow in any sense. Brandon's doing amazing work on the Octopress organization on GitHub, and you can take a look at where he's taking Octopress and splitting it off into a gem. And this gem is just about functionality. It's just about sort of extending the basic Jekyll generation stuff into generating new posts based on like ERV templates, that sort of thing. And he also created something which I'm really excited about called Octopress Inc. And Octopress Inc. is an extension to Jekyll that allows you to write isolated themes.

So I have a gem, for example, called, I don't know, Parker's Site or Parker's Theme or something. And I can publish that on RubyGems. And you can say gem install Parker's Site or Parker's Theme or whatever. And it uses Octopress Inc. such that when Jekyll says, all right, I'm going to go build this site, it uses the CSS, the JavaScript that I've written, and it's all separate from my own content files. So what Octopress Inc. has done is basically taken the concept of WordPress themes, where the theme and the content are completely separate, and applied that to static site generation as Jekyll knows it. So I'm sort of there to make sure that everything's going along

at the same time and to help with the Jekyll 2.0 major a while now. And I know that a lot of the listeners and a lot of the readers of our weekly email and the blog, and anytime we publish any sort of teaser of the upcoming Octa press 3.0, they're always like all over it. You know, everybody's like waiting with bated breath kind of, so to speak. So I'm sure that that was a perfect teaser for to tee it up for Brandon when he comes on the, on the show. Um, I guess let, let's go ahead and tail off the call that I know there's probably, you've got to do, and we could talk probably for days because you do a lot of cool stuff. But let's talk about the future of Jekyll.

Let's tail into that, and I think you kind of know where I'm going with it. But where is Jekyll going? How does it align with GitHub Pages? How does it align with GitHub Pages? How does it align with GitHub Pages API? What can you tell us about not just Jekyll 2.0, which came out early this month, but the future and beyond? That's a really awesome question. The future of Jekyll is the simplest but also simultaneously most powerful static site generator that you can find for anyone. Isolating it from the expectation that you must know Ruby is paramount to that objective.

The Jekyll of tomorrow is a Jekyll that is easy to install, is really easy to use, hopefully has as few bugs as possible, if not none. And does the really amazing things like incremental regeneration and has themes the way that Octopress Inc. displays them. And in order to get there, we just need a lot more manpower. We just need people who are interested in taking a stake in Jekyll and saying, this is a really cool project. Let's make it what I want it to be. And when they hit a pain point to say, yeah, I could write a plugin for this, that monkey patches Jekyll to how, you know, how I want it, but why don't I take that change and contribute it upstream and see if they're interested. Um, and to, to sort of have that constant conversation with how am I using Jekyll and how is Jekyll right now? Um,

it's sort of what's going to, what's going to push Jekyll forward. That might, uh, that might lead us right into the call to arms, I guess, for, for Jekyll. Cause one of the things we ask on this show is some decent questions at the end that are common questions, I guess. But we always ask, you know, what's the call to arms? How can the community step up and help out? So maybe you kind of mentioned it, but maybe you can kind of go a little deeper. Yeah. So the way that we would love for you to get involved is to be involved in the conversation.

The issues, there's an IRC channel, pound Jekyll. There's so much available. There's also a Jekyll-help repo. So if you find that you have an extra even 10 minutes a day to watch that repo and answer questions to help with the ecosystem or the users who are struggling with this or, you know, hey, I installed Jekyll, but I can't seem to get this to work. Can you help me? Yeah, sure.

Let me just take a quick look at your repo. Most Jekyll problems are diagnosable, you know, in five minutes, unless it's some crazy issue with, you know, your gem environment or something. So to be involved and to do what you can to, um, either contribute code, um, or contribute ideas, just open an issue. That's like, Hey, this is a really cool idea that I had when I was just writing my site. What do you think about it? Um, and then

we can discuss it, um, to, you know, involve your friends. Maybe, uh, if you have a, if you have a pal who's also using Jekyll or a colleague to have have them get a GitHub profile if they don't already and contribute their ideas to be part of the conversation. There's obviously no way that you're going to be involved if you aren't a part of it, but it's relatively easy to just watch the repo. I promise maybe 12 to 15 notifications a day. I try to stay busy, but not too overwhelming. So, you know, just sort of contribute where you want to, where you can. Of course, triaging issues is super helpful, but I handle every issue that comes through. I know you're pretty active on that. When I was just kind of prepping for this conversation, I was like, wow, you are on the ball.

And not just like, hey, thanks, like maybe a text expander or something like that or some sort of snippet that you kind of put in. It's like you really look and you re-quote and you ask for clarification. You kind of give more feedback. I really wonder when you say you do this in your free time like you must have a lot of free time so are you really going to school or are you two people that kind of thing i've definitely slacked off on my on my classwork enough uh to to make sure that that the amount of time that i have on github is substantial so i will uh apologize to my professors on behalf of my time on jekyll um but that i, it's taken a long time to get there.

But I find that if you're kind and if you give constructive feedback, then people will be kind in return. And there's so much animosity in the open source community that to yell at people is not useful. And it's sort of counterproductive to the idea of let's build something awesome together.

We've talked about that a little bit on the on the show before just kind of like the not so nice responses from people and just the attitudes because it i mean we talked about burnout on the show before with lee hamley and capistrano and some other projects that have come on and people who lead those projects have expressed just burnout and you can't always help your attitude sometimes. Let's maybe talk to you in two years and see if you feel the same way. But, I mean, it does happen. Regarding the future of Jekyll, there's one question I do have as a dovetail off of what you said before.

You said you need more people. You need more manpower, so to say. How does that play into GitHub? That's what I keep coming back to because it's obviously a part of Pages. They obviously have the money to employ people. Are they a part of these conversations to make sure that Jekyll thrives and Jekyll grows and Jekyll is awesome? They aren't as much, I will say. At the moment, it's sort of in maintenance mode, Pages is.

I'm certainly building new features and making it as great as I can. But they aren't building as many new features into Pages, certainly. And what they primarily want is to see Pages be something that makes documentation really great, software documentation. So if I'm bootstrap, how can we make sure that Jekyll and that pages are well-suited to your needs for that particular project. So to make sure that Jekyll is as general as possible is sort of what, and not too complicated, of course, is sort of what Ben's been doing as a part of, sort of as an acting entity of GitHub and also in his own wishes. He'd like to see something that's simple and easy to use

rather than something that's super complicated or super specific. So they aren't that heavily involved in Jekyll, but they've certainly supported me in huge ways, whether it's just like random boxes of goodies or, you know, hey, we want this feature added to Jekyll. Can you write it for us? We'll pay you. Well, I guess the last question is a fun one that I think you may have touched on at least one hero, right?

But who are your – you can name one. You can name a few. We don't really have any sort of rules here. But if you had to name some programming heroes, who would they be? I definitely have a bunch. Um, and they've, I, I'm, I tend to take to heroes pretty quickly, um, because there's someone that I can look up to and, and it sort of gives me a goal, um, to set. So, um, starting off in, in middle school when I was learning basic, um, the guy's name was Dan LaVoy. Um, later it was Nick Rau, um, who now works at ModCloth as a software engineer. Um, later it was Nick Rao, um, who now works at ModCloth as a software engineer.

Um, really brilliant guy who, he was the one who originally taught me how to use Rails, um, and got me interested in Ruby. So he's the reason that I, I know Ruby at all. Um, Leif Walsh was, uh, um, an acquaintance in, in high school who is just ridiculously brilliant. Um, he got a joint degree at Stony Brook, SUNY Stony Brook, um, in like theoretical mathematics and computer science. And then, of course, there are the, I guess, more general or more normal answers of people like Tom and Chris Wonstroth and PJ, who wrote GitHub initially and just sort of wrote it in their spare time. People like Ben, who are amazing product people, but also, or sort of product managers

and can develop vision in addition to writing amazing code. And people from my time at Sex Wonderkinder as well, Hans Hasseberg, Ryan Levick, Chus or Josep Bach, who's a great guy, and Chad Fowler as well um they're all like just amazing people that i've i have looked up to um and have tried to try to be more like yeah

several uh in there i definitely share similar remarks but uh this has um this has been i guess probably one of our longer shows than the last several shows. I think we just kind of got on some rifts there, and I didn't want to pull you off. And I'm glad that you were such a good trooper for the show, Parker. Thanks so much for having me. I know we wanted to get you on the show for a while, and I'm just very excited about what you're doing. So keep up the great work, however we can be of support to you and to help you and Matt kind of keep this project at the forefront. And just knowing that it is the next generation and the way to be when it comes to static site generation and the future of it.

And Octopress, we hope to have Brain on the show in the near future about that. So I want to just – you got our support got our support, however we can give it. Great, thank you so much. Same to you. As we close out the show, I want to give another shout out to our awesome sponsors, Rackspace, SnapCI, and TopTow for supporting the show. They do an awesome job to help make sure we stay around

as part of just helping Parker do his awesome work and help him stay around so i also want to plug our new partner to div shot uh who's helping pave the way for really awesome static web hosting for developers uh and they're hosting jekyll too so we'll give you more information about that for the members and if you're not a member yet you should check it out but uh that's it for this week we'll be back next week and until then uh parker and i will say goodbye so bye-bye bye We'll see you next time.