The Changelog: Software Development, Open Source - Middleman and Static Site Generators (Interview)

Episode Date: August 15, 2015

Thomas Reynolds, the creator of Middleman, joined the show to talk about the history of static site generators, how he got into open-source, his love for Go, and what's to come in Middleman v4.

Welcome back everyone, this is the Change Log and I'm your host, Adam Stachowiak. This is episode 169 and on today's show we're talking to Thomas Reynolds, the maker of Middleman. We've wanted to have this conversation for quite a while. We're Rubyists at our core here at the ChangeLog. We use Middleman every single week to ship ChangeLog Weekly. We built that in Middleman. We're also building another site for

BeyondCode in Middleman. Check that out at beyondcode.tv. That's our brief interview series we shoot at conferences after parties. But Rubyists at our core here at the changelog we love middleman great conversation today with Thomas we have three awesome sponsors

CodeShip, TopTile and DigitalOcean our first sponsor for the show is CodeShip they've launched a brand new feature called Organizations and I've talked to several teams who love this new feature because now you can create teams, set permissions for specific team members, and improve collaboration in your continuous delivery workflows. You can maintain centralized control of your organization's projects and teams with this brand new feature.

Save 20% off any premium plan you choose for three months by using the code THECHANGELOGEPODCAST. Again, that code is THECHANGELOGEPODCAST. You'll save 20% off any premium plan you choose for three months. Head to codeship.com slash THECHANGELOG to get started. And now on to the show. All right, we're back we got a great show lineup for you today we have been wanting to talk about middleman forever and when i say forever it's like the sandlot forever uh i've been using middleman for a long time jared how about you have you been using middleman for a

while actually my first time with middleman was when you brought me in on Change Log Weekly. Okay, so that was... Which was, you know, maybe six or seven months ago. Well, luckily it was a Ruby thing. But I've been using it a lot lately, yeah. So we got Thomas Reynolds on the line here. He is the creator of Middleman. Thomas, hey, what's up? Hey, how you doing, Al? So you're the technical director at Instrument. It's an independent digital creative agency.

Is that your thing or is that somebody else's thing? That's someone else's thing. We're a company of about 100, 110 people in Portland, Oregon. We're all centrally located. No remote workers and we just do really high-end digital marketing. Nice, man. Also the creator of Middleman

and a foodie, book nerd, writer and obviously a Rubius because you couldn't be the creator of Middleman without being a Rubyist first, right? Yeah, it doesn't happen accidentally. So for those listening, Middleman is a Ruby gem. It's a static site generator. And how long has it been around, Thomas?

In its current stable form, it's been out for three years. I just checked on GitHub. Time since first commit in the repo is just a little over seven years. Wow. I was going to say, it feels like so long. Ancient open source roots at this point. Yeah, definitely. If you get past five, it's getting into the... It's like the cart, you're suddenly a classic.

Yeah, no, it's like marriage. Like, it's just I wake up every day and I do it, and I keep doing it every single day, and it'll always probably be here with me. There you go. So before we kick off the full-on show and dive deep into Middleman, let's figure out who you are a bit. Kind of give us a bit about who you are. You already mentioned Instrument and the things you do there.

So kind of give us a bit about your history and who you are as a software developer. Yeah, so I've been in software development and mostly agency stuff for about 16 years now. I got started really young, kind of grew up with the Internet and was able to, you know, be a kid in high school and actually contribute to open source and also, you know, to just fan sites and stuff. So I got my start programming, making levels for TIE Fighter, the flight sim video game for the PC way back in the day. And then I moved from there to fan sites for that. And eventually it was like, oh, hey, I need to learn this SQL thing. Hey, I need to learn this HTML whatever, 3, or whatever it was back then.

And so, yeah, I got my start just doing super nerdy stuff on the internet. Did that for a couple of years and went off to school for a CS degree and then realized I was writing less code at school than I had been in my own free time. So I kind of dropped out, switched to a more liberal degree and just with a lot of reading, which was a lot more fun for me, and then put all my passion back into software development on the open source side. Since becoming a full-grown adult, I've been doing agency stuff now.

Oh boy, probably like eight to 10 years, pretty much nonstop. So I've never really done any product stuff. I've never really done any startup stuff. I just kind of like the heavy churn and like frequent new kinds of ideas that you have to do like in an agency lifestyle. Have you ever got the itch, the startup itch? Uh, no, not really. I moved to Portland to get away from that stuff. So I'm happy. I'm happy just, uh, I don't know. I like doing new things. I probably get a little bit bored other than middleman. I tend to like discard side projects. So, um, yeah. But,

uh, yeah. Slightly off topic since you're living in Portland. Um, I'm a huge fan of Portlandia. I absolutely love that show. Are you, do you watch the show since you sort of live it every day or do you just skip it?

I don't really watch it. Um, but people, yeah, that's like exactly the question people have. Uh, actually no, I think it's,

um, the way I try to phrase this to people is a lot of people would see those caricatures as an insult, and we take them as a point of pride, and that's just because we're weird. Like, if we could get more people on weird bikes, that would be perfectly cool for us. That's why a lot of us moved here.

Love Portland, man. Yeah, it's a great show. And they're well-meaning. And I know Carrie grew up somewhere here in the Northwest, so I'm pretty sure she's well-meaning about it all, too. I think it's the first time, Jared, on this show I heard somebody say they quit their CS degree to go and code more. Mm-hmm.

Yeah. Yeah, so I went to Arizona State, which is not necessarily known for its computer science degree. But it was cheap. They launched a rocket once to Mars and it deactivated as soon as it landed. So that pretty much tells you what you need to know about the program there.

So I think Java, Sun, or I guess it was still Sun then, poured a ton of money into the school, so I wrote two years of Java, which was not terribly exciting projects. And given your career... Sorry, Jared, go ahead. I was going to say, what turned you on originally to the

open source world? That's a good question. I'm trying to think back. It was probably... Actually, I honestly don't remember. Since I got into agency stuff after college, I did a lot of PHP,

which is always kind of like a vaguely open source community i don't know the actual structure but they were pretty open um and there was pretty uh a large amount of community involvement like as that language grew so i did a lot of that and this is all pre-github so open source was like this thing that took place on mailing lists and maybe someone hosted a site, you could download a tarball or something and install it. But it didn't feel like there was as big a community as there is now. There were IRC channels that we could communicate, but it was probably something PHP-based. One of the database wrappers or something like that I probably contributed stuff to early.

So yeah, basically did a lot of PHP for years and years. Discovered Ruby right as the great Rails explosion happened. Fell in love with it, especially since PHP was basically Perl at the time. Got to use some things from CS that I hadn't used in a little while, like objects and classes and all the core object-oriented stuff that that's in ruby and yeah it's pretty much it i started using ruby rake specifically um for a lot of tooling stuff for my front front end work so you know every time you know i was a okay agency but we did mostly email templates and it got to the point where it was like four to six email templates a day was

the job and um most of that stuff can just be automated you know like mailchimp will automate all that stuff right now you just kind of upload a couple things to them right so started using rake and started uh you know building out uh just little helpers little tooling bits for myself interesting it might make uh some sense to rewind a little bit, though. Given your agency experience, I do have a couple thoughts here, Mark, for that, getting closer to that subject. But it might make sense since the, you know, in terms of the Git history, I think you said it was seven years Git history you've got for middleman so we're definitely talking about quite a bit of space and you know and time in there in terms of the space that middleman occupies which is the static site generator space there's been lots out there in every kind of language you can think of um jared and i we both have ruby roots

so we kind of go back with with all of that but at the same time i think a lot of the at least what i can tell from my perspective is a lot of the static site generators came from the review world and sort of, you know, spread out to other languages. So what do you know of the history of these generators and where did middleman come from and what problems was it solving when it first became for you? Totally. So yeah, kind of when I was like doing that email template work, template work, the other thing you wanted to automate at the same time was HTML and CSS. And this was right about the time that Haml had come out, and so that just took a lot of the work out of doing just incredible amounts of tables

and all the stuff we had to do for emails back in the day. So I started looking around for some tools at the time. I think Nanoc existed. Yeah, I remember that one. Staticmatic existed. I'm not entirely sure if Jekyll existed publicly yet, but it was all about that time. Looking back, Jekyll looks like their initial launch was like end of 2008.

It was probably out there. Yeah, it was probably being talked about on the blogosphere or whatever we called it. Yeah, so I liked Staticmatic personally. It was already open source. You could already check out all the code, and it was pretty easy to get code back upstream with that team. So I started using Staticmatic for myself and got into the forums and kind of got involved with that community. And basically, slowly over time, I committed a larger and larger share of the pull requests until the point where the original creator didn't have the time for it as much anymore. So we basically, the 1.0 of Middleman is somewhat of a fork of Staticmatic.

So we just kind of renamed it, moved the repos, and moved a lot of the community stuff over into my name. I did not know that part, that it was sort of a fork, because I feel like Staticmatic is where it all began. And it sounds like that's what you said too, is that right? Yeah, at least for me. I mean, I know Nanak existed, and it seemed at a glance to be more complicated than I wanted to get into.

I never really went all the way down that road, so I can't actually say if that's true. But Staticmatic kind of matched up a little bit more to how I wanted to use the tool. Adam, I don't know if you remember, a little bit of my roots was in the Perl community in college. And my first kind of exposure to blogging at all was because basically my professor told us we exposure to blogging at all was because basically my

professor told us we had to blog and they gave us this Pearl thing. I think it was called like blog some, something like that. And it was a static site generator in Pearl. This is like 2005, 2006. And I thought it was super lame. And then I found WordPress and I was like,

why would I want to have static sites when I can have dynamic, changing, database-driven WordPress sites and then there's obviously reasons why you would want to have a static site we can get into all that but it was kind of funny because once Jekyll dropped and Staticmatic, I started seeing this rise of these static site generators and I was like like what is wrong

with these people like why are we like wordpressing these things are cool like static files like that's i had a similar thought when i i don't think i've ever shared this story publicly but when win and i first so when i started this show together way back in 2009 and the first time i met win was at a ruby meet up here in hou, and he was doing a presentation on something new they had done, and they had just rebuilt the Squeegee website, which was Wynn's original consultancy before he sort of went independent and then ultimately went to GitHub. He loved Static Matic, and he was giving a presentation on it, and I was like, same thing. And I was a WordPress guy at the time. I was using that stuff. Why would I learn and write Ruby only to create static sites?

I don't get it. But it was a big, big thing then. Yeah. I think, like I said, I got into it to make HTML email. There was no option other than static, right? You just throw this thing over the wire, and it's got to all be self-contained. But yeah, I think it's kind of really interesting over the years. And as middleman has gained popularity, there's something happened.

And I don't know if it was, you know, we got tired of the complexity. We got tired of like the stack churn or the security issues around like full like back end apps. But there's definitely now, you know, you see all these blog posts coming around that are just like, there's no reason not to do static. I mean, almost everything you can accomplish other than like a form and maybe

e-commerce, you know, you can do statically and then you never have to worry about, you know, any security implications. I remember my tunes started to change when I would consistently see different WordPress sites get taken down by, I think it was dig back then. Yes. Um, you know, the dig effect or something like that. And it would just crush

under a little bit of load. And that's when I started saying, okay, you know, static HTML files makes a lot of sense in that regard. Yeah. Also, I mean, just because I come from an agency background before, you know, like the modern age um that's what we deliver that's what our contracts say we deliver we deliver like this static packet of a website and if you want to throw it into a rails app or if you want to just like drag ftp it to some you know godaddy server that's up to you um so there's also a lot of that kind of work is self-contained in that way that's that's kind of leading into guess, the slightly a good segue into the next step, which is given your agency experience now at Instrument, I got to imagine that a lot of what you've done with Middleman over the years with the contributors and your core team and contributors who've helped get Middleman to where it is now today, I got to imagine a lot of that's playing back into your full time. A little bit. I pretty much do nothing but JavaScript on my day job

I manage a team of people as well but for the most part I had tried to keep the two separate I didn't want to like I made this thing therefore we should use it especially before it got enough popularity to justify that kind of stuff so I've always just kind of left it on the side if people ask about it in like slack or something i'll be like oh yeah i know how that thing works um but yeah maybe in the last year we've actually been hiring people and they've come in the door knowing it so now we do tend to use it on a lot more projects and i am a little more hands-on with like actually

adding features or you know fixing specific bugs from people in-house. So you said the original crux that was sort of, originally somewhat of a fork of staticmatic, the problems initially were HTML, email-driven. Is that when it was, that was obviously Middleman version one. How has Middleman changed over the years in terms of the problems it's been solving and the the problems it's been solving and and the evolving problem it's been solving yeah so i just looked um you know one and two were these kind of small releases that uh i don't know how many people were actually using it probably people who moved

on from static matic um there's also a period of time there where jekyll went completely unmaintained other than like the octopress work that was happening. So I think we've got a lot of people from there, but I just looked it up and we've been on the stable current stable branch since 2012. I think that's when it really kind of took off. And that's when I was also doing rail stuff on the side and I wanted to align the two kind of workflows. So rather than just being like, it's a whole separate tool,

I wanted it to be like conceptually, you could come directly over from Rails. And then, you know, you can just make a static site, or you can put a static site in your Rails if you want to like, keep, you know, one piece separate or a little more secure. So yeah, I think version three was like the big leap forward, built it on top of some of the Merb stuff, which eventually became into Rails, but I used a lot of their tooling. We still use internally for a lot of our code, the Padrino library. That's like a Sinatra alike for Rails. And then whenever we have like a discussion on API, we try to go check out Rails API and make sure we're keeping things as similar as possible so we can bring people over from the rest of the Ruby community.

Do you mean things like rendering parcels, different helpers that are available in Rails so people can essentially copy and paste views to a degree, potentially, back into a Rails app? Yeah, I mean, we still have a huge reliance on YAML for configuration. We have all the helpers like you said like your normal link helpers your localization helpers we bring over directly um most of it we

support i think every templating language that could possibly exist in some fashion so definitely all the ruby stuff most of the javascript stuff you know pretty much any language that can be you know shelled out to and come back, we support that. Very cool. So there have been tons of these tools over the years. We've mentioned a few here. I think there was one called Stasis. There's been a lot of them.

Webby was one. I think I used Webby back in the day. All Ruby tools. And yet Middleman. What's that? Serve? Serve serve i don't know that one it's it's not being maintained now but it was one that was it was one that john long had mentioned we talked about that on the octopress show with the yeah with brennan mathis very cool so middleman has stood out from the crowd it's it's kind of been more successful it's gotten more uh it's obviously been sustained longer but it has more excitement around it more people using it uh big players like

uh thought bot and um there's a couple more on your website that i can't think of off the top of my head mailchimp thank you so can you attribute that to anything in particular was it you know pure luck or is there something about middleman that stands out from the crowd? Yeah, I actually think I have a kind of different opinion about open source from the rest, or at least the modern kind of JavaScript crowd, which I don't think things should be throwaway. I think there's a responsibility attached to saying,

I want you to spend your days and hopefully not your nights coding with my thing. And that, you know, it kind of sucks when you have to maintain that for years and years and years. But that's like the bargain you're making by publicly saying, hey, go use my thing. I put it on GitHub. So I think what I contribute most of middleman success to is basically stability and like respect for people's time. So we've been at 3.0 stable for a little over three years now. The APIs are pretty much the same. If you go make a site a year ago, it's going to be exactly the same now.

Things aren't going to change under your feet, and you're just going to have a stable platform. It's not that complicated. The things we do are pretty self-contained. So we just do those things well and get out of your way as quickly as possible and we've done it for three years so you know there wasn't like oh i gotta switch i mean there will be soon but there wasn't like i gotta switch to the rails for rewrite like what am i gonna do with myself right um i'm glad you said that because that's actually an issue i've had with the static generators over the years is that i would build something let's say a one-off simple static site for somebody and then have to go back and make an update or something like that to it.

And then building it locally or something like that becomes an issue because the latest version breaks things. And then I got to spend another hour or so trying to fix things or link to helpers or just weird things that have changed in the apis of like the little things and the stability to me was a big thing for middleman because i'd gone through static matic and several others and then finally you know i'm using something like middleman you know almost every time i do something static unless it's actually really static um and and never having to deal with those those issues where i don't touch it for six months and it's still the same you I can just run it. Yeah, we want to fight that whole hype churn cycle. There's no reason for that. There are so few really revolutionary ideas. And you know what?

Maybe take the Ember community's stance on it. If they're really revolutionary, we'll fold it in and we'll do it stably, slowly over time and we'll document it well. But I'm not going to jump on the hype train and break your site from a year ago. It's great we have tools like Bundler now that can protect us from a lot of that kind of, you know, come back to a thing six months later and it's not working anymore. But, you know, you should also be able to do bundle update and not have your entire world explode. I like that.

So you have this commitment to reliability and stability, and you've been doing that over the years. That's pretty rare in open source. Very. And so I wonder, like, what, why? Like, what do you get out of it? I don't know what I get out of it. Okay. Inertia. Inertia? inertia inertia um i like doing it i um i don't know i so we have a couple community like outlets for middleman so there's like public chat channels there's a public forum um

what else is there uh i don't remember there was an email group at some point but basically i don't go there like i set up these systems for the community to self-help, and then I only respond on GitHub pull requests or Twitter harassment. I think that's also another thing. If you're just in the trenches there, managing the forum day in and day out, you get to see people telling you that you kind of ruined their weekend because you wrote some bad bug.

I think it maybe drags on you a little bit more, but I try to keep myself completely separate from that. And people in the community have stepped up and been those kind of like community leaders. And it all works out for everyone. I looked at the forum now. It's pretty active. I mean, a lot of people in there. I mean, I'm not diving into a lot of these notes here, but I'm just scrolling this endless scroll. A lot of stuff happened. Yeah, a lot of that is just holes in documentation where all of our documentation is on GitHub. It's all community contributed to. So I did a bunch

of the big chunks of initial writing, but it's all kind of maintained itself through people not quite being able to parse a sentence or, you know, I'm not making the right point that they're trying to get to, or I, you know, put something on the wrong page, but you're never going to be able to document everything. Again, kind of like the Ember model, I went with like a plain text tutorial style for my documentation, as opposed to API docs, which are a little more,

provide better coverage, but are kind of harder to understand if you don't know what's going on inside the system. So yeah, so that just leaves like narratively, like a feature missing, just because I couldn't fit it onto any of the pages. And I think the forum is really good about that. Just being like, hey, there's this thing, why isn't it documented? Well, like four people use it. But, you know, here it is on the forums for you. So if a doc needs updated, someone could go to GitHub, ForkIt, and let's say like a misspelling or something to change someone from the community, whether they're in the core team or not, could step in and help out as needed. And there's a pull request button at the bottom of every page on the documentation site. So we make that as easy as possible.

So we talked a little bit about, you know, its makeup. Can we talk a little bit about, let's say, like a file structure? You said it's a lot like the Rails view layer. Was that on purpose? Did you look at the Rails view layer and say, this is how it should be? This is how a middleman site should be structured and how it should be laid out? Is it really meant to be on a plug and play between that and Rails?

Kind of. I don't think we follow the file layout of Rails because they've got a pretty deep named structure. The way our philosophy works is you have a source directory and conceptually you look at everything in there and that's what you get on the way out. You can do some metaprogram. You can do all these fancy configuration options,

but we try to do a one-to-one from that folder to your build folder. So if I have index.html.erb, I'm going to get an index.html out. So for most people's sites, you shouldn't have all this magic happening. You should just be able to say, you know, it's a pipeline. You come in as SASH, you come out as CSS. So it matches, the structure of source but however you want to structure your code so if you want a fonts directory have at it if you want to put it inside your css that's fine with us too and the reason

why i ask is because i i think what and i could be wrong here but it's at least happened to me several times is that you know i'm a rubyist only to a certain point or i'm a back-end developer only to a certain point that i don't do it because there's people who are better than it than me at it and i may want to go buck wild on the view and build out a site but i don't have you know all the routes in place and all these different things that sort of stay in your way when you work in a rails team and it felt always a lot easier to sort of like build out something statically you know with all the urls and all these different things that i think of as a ux or designer standpoint or a front-end builder standpoint and build you know a good portion of my prototype or even my

prototypes to prove to the business team like hey we can build this or this is the direction we should go i'll build that middleman with almost zero resistance and really not a lot of Ruby knowledge beyond what the docs can easily provide in terms of middleman routing and stuff. And then give that over to my Rails team or demonstrate that and be able to take a lot of what I've done already and just pull it right into the Rails app with almost no issues. Yeah, I mean, I kind of like we map to the way it used to be on the front end. You pop open a new folder, you open Notepad or whatever, and you just start making files, your static files. You wrote all your HTML, you wrote all your CSS,

and you put 50 script tags into your HTML. And the reason we don't do some of those things now is because Sass is faster. Templating is faster. We want to compress things smaller for the end user, but none of those are changing the flow. So middleman steps in and says, I'll handle concatenating all your JavaScript. I'll handle your shortcuts in SAS. Just keep writing the same kind of straightforward, completely backend-free approach to front-end coding.

The cool thing about long-term projects is there's lots of things that change over the years, and then there's lots of things that stay the same. And it seems like when you strike a chord early on in architecture or those big decision-making, you can just kind of refine over the years. And Thomas, you recently wrote a post on your blog, which I believe is award winning Fjords which that's correct right I think the best website name

I think I've ever heard I'm pretty jealous of it I also have the Fjords Twitter account but I haven't figured out what to do with it yeah just hold on to that baby and just wait for the check there's a Norwegian hardcore band who I always get subtweeted by.

She's pretty cool. Completely off topic, but kind of related is whoever the guy who had the Alphabet account on Twitter. Yeah, I saw that. Oh, man. He's sitting on a gold mine there after Google renamed. So, yeah, maybe Fjord. Maybe someday you'll have some large company rename themselves to Fjord and you'll just be sitting on it. I like it.

But you've had – over the years, you refine your thoughts. You refine even the way you write code. And it seems like that is something that's happened to you in kind of dramatic ways. You recently published a post back in March called My Weird Ruby, where you go through kind of how you write Ruby code today and how that's way different from probably back in 2010 when you started middleman. So I'm going to tee that up. We need to take a break, hear from a sponsor. But on the other side of the sponsor break, I want to hear your thoughts on why your Ruby is weird and how that has affected middleman four so we'll be right back you've heard me talk about top towel several times on this podcast but today is different i've got a special treat for you i

went out and spoke with a listener who a year ago had never heard of top towel he listened to the show just like you're doing right here right now now, today, and heard us talk about TopTile and what they're all about. And he decided to get in touch. And now he's living the dream as a freelance software developer with TopTile. His name is Daniel Elzon. And I sat down and I talked with him. I said, hey, what is it that you love most about TopTile? Take a listen. Well, for me, the thing about TopTal, which I thought would be very hard for me personally, as I transitioned to a more consulting role, was the way I would have access to new clients and what quality those would be. So I found that I've had access to

awesome clients through TopTal and it hasn't been that hard to find because they have a lot of choice. And even more than that, there's enough choice and I can actually be a little selective about what kinds of things I want to be working on. So I use that as a way to sort of hone my skills and go towards the technologies I think are worth investing in for the future. So whether it's including new front-end frameworks or doing a little DevOps work on the side, I usually am able to find clients who have the needs of the things I want to get better at. So that's been truly useful. All right, that was Daniel LaZond, a listener of The Change Log and also a freelance software developer with TopTal. If you want to follow in Daniel's footsteps,

go to toptal.com slash developers. That's T-O-P-T-A-L dot com slash developers to learn more about what TopTal's all about and tell them the changelog sent you. All right, everybody, we're back speaking with Thomas Reynolds about Middleman. And Thomas, you've been working on Middleman 4 for a while now. You've recently published a blog post entitled My Weird Ruby, wherein you state,

Over the past year, I've been rewriting large portions of the Middleman code base to better reflect how i like to write code as opposed to the silly version of of mine oh typo typos exposed breaking news here on the change log is a typo in a blog post uh as opposed to the silly version of the old person six years ago so you've been rewriting a lot since you You've learned things. You've changed your style. And that's kind of dramatically affected the middleman code base. Can you speak to that? Yeah, totally.

So kind of like I said, I do a lot of JavaScript at work. I do Ruby for middleman. I have done Clojure. I have done Java and got into some Haskell. And I like to try as many different languages as possible.

And there's always good ideas. You can bring them all back. So I can write another post later got into some Haskell, and I like to try as many different languages as possible. There's always good ideas. You can bring them all back. I can write another post later called Migrate JavaScript because it's equally silly, but it's kind of got the same gist. When I started Middleman, Ruby was getting popular, but Ruby is also kind of a minefield of features. Some great stuff in there. There's some stuff you should never, ever use. I think Rails 2 had a bunch of these,

like just mix-ins forever, or duck typing, and all these kind of very famously Ruby features that you probably wouldn't want to use in production. Alias method changing, yeah. Alias method changing, yeah. That was a good one. Yeah, so that's how middleman

two looked like that's what middleman three pretty much looked like with some more inspiration um from rails three which has a lot more of uh it's kind of i don't know they have a completely crazy uh mix in inheritance chain thing that's still in there that i don't understand but um so that's what it looks a lot like Rails. But, you know, it's been two, three years since that stable version. I've just been making bug fixes on there, and then I spend most of my day doing other languages. So

I've just come up with a bunch of things, seen a bunch of things in other languages that I like, and I want to bring them back. So I don't, every time I would fix a bug in the stable branch of middleman, I would realize that this could have been solved. Like, I would have, if I had just used something from Haskell, if I just used something from Clojure, this would never have been a problem. So I think the biggest one for me is maturing as a developer and deciding that I actually

do like static typing. And, you know, all the loose typing of Ruby was a really big selling point when it was first coming out because people are coming out of the Java world and such. But you know what? Those things caught bugs. They caught bugs without writing tests. And I think being able to type your code, especially public code that other people are going to want to interact with as a public API is a really good approach. So I discovered this library about a year ago called Contracts, which uses a lot of metaprotogramming magic to wrap every single variable and every single method with a little wrapper,

and then you define what kind of things should go into the function and what kind of things are allowed to come out of the function, and this little wrapper will check them and throw exceptions if you're in dev mode or test mode. And so that just allows you to say, you know, there's a lot of places where in middleman and in Ruby, you say, here's a method, it's called, you know, I'm looking at one here, find, it could take a symbol, it could take a string, it could try to like turn those two into the same thing.

I could take a regex, you never know. And there's a lot of these kind of like open magical apis throughout rails in the ruby world uh i decided i didn't like that very much so i went whole hog with this contracts library and i added type information to every single um variable and definition uh inside of my middleman code and what that gave me was an insane number of uh reports that my test suite, my test suite of, you know, something like 4,200 tests didn't catch. Just like, then people were probably saying, oh yeah, like I know to put a symbol here,

they don't know to put a symbol here. And the amount of documentation they need to figure that out, it's just, they're never going to look it up. So that was like the first big refactor to Middleman 4. And it's completely, completely you know opaque to the user that's just for me so i can catch bugs earlier and so i feel a little safer when i'm working with this relatively large code base so that just begs the question uh you know you're basically adding like static type checking to ruby i guess why not just you know try a different

language yeah i mean that's just back to my stability thing. I mean, the roots are in the community. My contributors speak Ruby. The big rewrite is always a terrible idea, especially if you're switching languages. You might as well just start a whole new thing. That would have been a lot of work. It's not a tiny code base.

Doing a lot of weird stuff. I feel like if I could, I would maybe have rewritten it in Clojure, but then at the time getting Clojure up and running was kind of a pain. Nowadays, I think you can just run it right through Node, which is pretty cool. At the time, it wasn't the best

fit. There has been rumors of gradual typing being added to future versions of Ruby, so this may be a feature that I just switch to the official support if that comes down the road. I've never heard of this contracts library. Can you tell me where it's at or talk about it a bit? It's just called contracts.ruby.

It's a little hard to find, but it's, I think... It's got such a general name, it's really hard to search for. Yeah, so it's not really typing typing it's just designed by contract concept which is basically um lightly enforced types like things will still work it'll just be able to complain about it uh so i don't know where it came from but um the gentleman who runs it has started uh updating it a lot more recently and there's third-party contributors adding code to it now. So it seems like it's kind of getting a little popularity. I would never use it in production. The whole point of this thing is

it throws an exception during your test suite, not when someone's actually trying to use your code. Is this something that you've heard of, Jared? Well, I heard of it in March when I read his blog post, but I haven't heard of it elsewhere. Okay, gotcha. Yeah, so it's active. That's great.

When I was using it, it actually was inactive. It had just been like an experiment that someone had put together, so a little bit risky, but it's pretty easy to comment out. It's just every single one of these definitions starts with the word contract. It's a pretty easy search and replace to go back to the old buggy version.

I found I really enjoy it. I'm looking to decorators in JavaScript to add some more functionality on the JavaScript side so I can add some type information and have it copied to TestSuite. So Adam and I are in a bit of a unique position because we have a site which we use to generate our weekly newsletter,

Changelog Weekly, which is a Middleman 3 site. And we've also been working on a new site for our video series, Beyond Code, which is a Middleman 4 site, because I hopped on the beta because I like pain, I guess. It hasn't been too painful. A few things. And I can definitely attest to the fact

that this contracts piece is completely invisible to an end user, because I would have never even known about it had it not been for this post. One thing I have felt as an end user is you've also introduced a lot of immutable data structures. Can you speak about that? And then maybe I can give you a little bit of feedback from my perspective. Yeah, totally. Yeah, that also just comes from my experience in these kind of more functional languages. They tend to prevent a large class of bugs,

just because you're not doing weird loops and messing with your stuff. One bug we got a lot back in the day was we have this directory of data files, and there's YAML information in it. And so from the templating side, you can go ahead and say, you know, grab the first five people from this YAML file. And people would then go add another person to that array and then expect it to persist and also expect it to somehow sync back to the data side, to the actual file structure. And so one of the main reasons for going with, it's still kind of an experiment. I put in hamster, which is one of these kind of wrapper libraries. And so you talk about a hamster hash instead of like a native Ruby hash.

And what it basically does is it just doesn't give you methods to alter data that's not allowed to be altered, like this kind of static YAML data. I put like a lot of things in version four. I think I tried to refactor without touching the API to tools that I like a little bit more. That one is definitely the newest, and I've also run into surprises around it,

especially if you don't even know it's there, and suddenly it's throwing these crazy errors at you. So yeah, I would love to hear some stuff about that. I think that's trying to get people on the beta so we can flush this out, but that's going to be day one, 4.0 stable. There'll be probably 30 bug reports and try to get the messaging right around it, I think. Yeah, I think my experience is mostly around what you said when you don't even know that that's what you're working with. And it's kind

of like the uncanny valley where it's like it's almost an array or it's almost a hash until you find out that it's not. And the specific thing that I hit quite often is probably difficult to explain on air like this. But I am using the data directory. And basically what we have is a bunch of seasons of the show. And then each season has some episodes kind of nested inside of it. And in certain cases, I was trying to just flatten, so I was mapping over the seasons to get the episodes, and then flatten that into a single

array of episodes. And you can't flatten a hamster dataset, probably because it's immutable, right? Although with the flatten call column, I was trying to return a new one. Yeah, I should have just returned a new one. It really should have worked.

But yeah, that's a great callout. If it's not one-to-one with the native Ruby stuff, then that's definitely a problem. Unfortunately, the native Ruby API is expansive and editable. Yeah, so I'll take a look at that and see if they just got some missing...

It might just be an alias, right? Half the things on the Ruby hash and array libraries are aliases for three other things. It's kind of crazy. Right. Yeah, I guess it turns out we brought you on air just to bug report for you. The only thing more exciting than live coding is live bug reporting. Live bug reports everybody's here facts please yeah exactly now it has to get fixed right because it's on air yeah totally so you have okay so you got contracts um you know you're you're playing with uh

immutability and i think that's just a great point that you know when you have a beta and even yours has been in beta for a while now like you the point of a beta is for people to hop on and do the bug reporting but you actually don't get very many until you announce that you know that official release and then all of a sudden everything kind of just swarms in i wonder if there's like is there any way we can make that stuff can we fix that problem is there any way i don't know uh i don't know so uh this is kind of a tangent but there's a pretty good blog post i'll dig up the url for you later but it was you know always use uh simple tools and it kind of has this philosophy it's like you know shouldn't surprise you it should just be simple and get out of the way its way and do

its job and then you should go home so i don't know if i want to ask people to spend their weekends or their extra time sure making their work stuff work for my beta. And actually, I'm not entirely sure how smooth the upgrade process is going to be. We removed a lot of features. We removed redundant features. So we didn't remove functionality, but there might be a little bit of editing. So we'll try to figure out, you know, Ember, again, does a really great job with these upgrade guides. We're going to try to figure out a way to document and say, like, we expect this to take you an hour or two hours

so you don't just go down a rabbit hole trying to upgrade to this. So I find, just back to the conversation about kind of the weird Ruby style, and a related question around that is, you know, you have years and years of writing Ruby, you're obviously a JavaScript developer as well. And it sounds like you have some exposure to Clojure and a few other languages. So here we are, you know, mid 2015. And there's a lot of new and exciting languages kind of out there. Ones that are kind of capturing the hearts of many developers are things like Go. I think Rust is pretty exciting to a lot of people. Of course, the functional

languages like Clojure as well. Are you still bullish on Ruby after all these years, or are your eyes starting to wander into these other camps? You know, it just depends what kind of project you want to build. I would never, you know, Go and, you know, if you just want a straight, fast API to just crank out some JSON, Go is really good for that. If you want to build a web server, you know, Rust is probably really good for that. I would probably never build a web server in Ruby. That would be crazy.

So I think everything's got its place. I think Ruby still reigns supreme for mostly because of Rails. It's like I need a website. I need a traditional front and back end. And this is the most stable, most secure one you can probably get other than maybe some PHP stuff. But it's definitely the most fun to work in for that tradeoff. So I think it'll be in that space for a while. We still use it at work.

So, you know, it's not going anywhere. Yeah. All right. while um we still use it at work so you know it's not going anywhere uh yeah all right i i am i am opposite was the opposite of bullish bearish yeah i am bearish on javascript still so are you really yeah so i mean uh you know i don't i don't i dread the day when you know i just remember like you're on the plane and like the kiosk crashes with a Windows warning. I dread the day when I see JavaScript crashed and Chrome is my airplane warning. I think it's probably one of the worst languages we have to use on a reasonable basis. So I would go to Ruby for JavaScript in a lot of cases for similar tasks, like task running or exactly something like middleman.

So that leads me into the question about the front-end frameworks. So middleman seems like it could be a decent generator for an app that is an Ember or an Angular-based FAT client. Is that the case, or should you use their tools directly for these kind of things? That's a good question. I would probably just say use their tools. The Ember command line tool is really, really good. It's really, really focused.

And, you know, if you're not writing a ton of HTML, you know, we don't solve a lot of problems for you. And if you're all client-side, then we're not solving your routing or your file structure problems for you either. So probably use their tools. But where we succeed now and where we're seeing a lot of heavy usage is blogs, is large documentation sites, a lot of this kind of generated content from some other source. So you have a pile of markdown files

and you want a full localized documentation site. So people like Basho and Nest and a bunch of all these MailChimp build these large documentation portals kind of on middleman because they can just do a couple loops, do a couple templates and get these large, large sites out the side.

That said, I'm still trying to use it for my frontend work as well. So version four, probably the biggest feature that I use on a daily basis is this ability to run sub-processes inside of middleman. So basically what you say is, I want you to boot up the Ember CLI web server, and I want you to proxy from middleman to that. So if two-thirds of your site and all of your CSS is in middleman, then you at Ember return to JavaScript, and then we all just build this one cohesive whole.

So I've been using Webpack a lot, just because Webpack and Babel give me some nice tools on the front end to use modern JavaScript, and then that just fills kind of like the sprockets role in my middleman stack, and then everything else is still middleman. So we're experimenting with that. It seems to be working pretty smoothly. Any other major middleman 4 features?

I know a lot of it has been pulling out old cruft. Is there anything else that you're excited about for the new version? There's some light stuff. We switched to a Rails-style environment split. So before you just had, you know, are you building, are you devving? Now it's like, do you want to build for staging? Do you want to build for hotfix branch? Do you want to build for production?

So that gives a little bit more control for multiple environments, for testing environments, and, you know, using stuff like Travis to deploy builds that may be not ready to go into production. The other big one, I think, is moving all of our base templating stuff to GitHub. So before, you'd have to install RubyGem outside of Bundler, hope it's there globally, and then initialize it through Middleman. Now you just give it a GitHub path or any Git path,

and it'll just pull down that whole repo as your starter template for a new project, and then it'll just pull down that whole repo as your starter template for a new project, and then it'll run your custom code. So it's a lot more similar to something like Yeoman, where we let everyone manage their own stuff rather than having to go through our RubyGem pipeline. Do you think it's an issue, since you mentioned who might be using Middleman and what languages, we talked about languages and choices and whatnot.

Is the fact that Middleman is a Ruby gem, does that stop people from using it, those who care about languages? Is there competitors to Middleman and other languages that sort of make you think, man, they're stealing my thunder here? Yeah, I mean, the install setup story for Ruby has always been pretty hard. It's still really, really bad on Windows.

So, yeah, it kind of sucks. The tradeoff is this is a tool you use for work. It's important. It's going to save you time. So spend the 30 minutes necessary to get your RubyGems set up. But, yeah, that's not great. There's one in Go. What was that called, Jared?

We just talked about that. It's like a Hugo. It's like a Hugo, yeah. Yeah, big call, yeah. Super jealous of that because Go gets compiled to a single, or not single, but it compiles some multi-platform binaries. So you just drag this file on your hard drive and everything's perfect. Not going to rewrite for that, but that's a pretty cool feature.

And then now the ubiquity of Node gives something like Metalsmith or a couple of the other Node ones. It feels more natural for a front-end person to install those libraries now, or they probably already have Node installed. Because if your audience is a designer or a front-end person, then if you're coming from NPM, you're already in their world, basically. You're already in their tool set. There's no change there. I always wondered if Ruby would hurt you over time, considering that the people that are writing Rails apps typically aren't building middleman sites. I guess Jared's an anomaly, potentially, but it's typically somebody that's more of a front-end player than a back-end player. Right.

Yeah, I mean, anecdotally, I think a lot of people do come from Rails. And then we also have a lot of people who classify themselves as designers, but they can obviously code. And for them, they didn't pick a side on the language war, so they don't really care if they're installing NPM or Node or Ruby. I think just on the Windows side, I think Node's first class support for Windows from the very beginning was a huge boon for its adoption. I think that that served it really well. And I think Ruby's always had issues on Windows.

And, you know, there's been huge efforts to improve that, but it's always after the fact. It's kind of like a security practice. You can't just bolt security on afterwards onto your software. It has to be something that you think of from day one. And it seems like cross-platform support is another one of those things

that once you don't prioritize it early on, it's just really hard to get it right later. I think the Ruby community has probably suffered a bit from that. Yeah, as an aside, I just built a gaming PC for myself and I haven't been using Windows for about a decade now. I'm recently back in

the flow of everything on the Windows side. I can actually test bugs now. It's amazing. But everything sucks over here. I just try to install simple things and it's taking me like 15 clicks and I can't find the links. And like, I get why,

you know, it's just brew install. Node is so easy. And like that, unless without some support from Microsoft, that'll never be, you know, a thing you can do on windows.

So there's always going to be, I think a barrier, uh, just kind of unfortunate, but I would love to see better windows support from Ruby. That's a hard job. Sure it is, yeah. So I got some questions about the core team and

just how you formed the people that helped make Middleman possible. But to take a note from Jerry, we do have to take a quick sponsor break. So let's take that break real quick. When we come back, we'll talk a bit about the core team and start tailing into some of our closing questions which i'm sure that the internet is just dying to hear so we'll take a break we'll be right back i have yet to meet a single person who doesn't love digital ocean if you've tried

digital ocean you know how awesome it is and here at Changelog, everything we have runs on blazing fast SSD cloud servers from DigitalOcean. And I want you to use the code CHANGELOG when you sign up today to get a free month. Run a server with 1GB of RAM and 30GB of SSD drive space totally for free on DigitalOcean. Use the code CHANGELOG. Again, that code is CHANGELOG. Use that when you sign up for a new account. Head to DigitalOcean.com to sign up and tell them that Changelog sent you.

Alright, we're back with Thomas Reynolds, maker of Middleman. Been talking through quite a bit of history of static state generators, a bit of, you know, go love there where you're, I was trying to figure out a good way, you know, go love there. I was trying to figure out a good way to say that, but just like some impressedness, if that's a thing to say,

from you towards the Go community about the way they're doing things too. And I'm kind of curious on that note, before we go into the core team thoughts and whatnot but i'm curious if um if you were building a middleman today and it was ground zero what would you build it in that's a great question i would probably go is probably uh where i would build it and i actually i have some negative thoughts about go such as their dependency management requiring git which is a little weird but uh other than that, it's a really slim language, and their whole goal is to have one way of doing everything, and that kind of aligns with a lot of the frustration from Ruby of having three ways to

do everything. So I think it's a nice slim language, and its compile story to different targets is pretty nice. I also, as just a joy in coding, I really, really love Clojure. Clojure has always been this close to working on Node. I think it's actually done now. So the idea of just being able to, you know, npm install middleman or something, I get to write it in the language with the features I like.

Everyone else gets to use JavaScript for their configuration. I think that'd be pretty cool too. So I was thinking of a name while you were talking there. Go man could be kind of cool. Go man, go. Middle go. There's no good.

You're always trying to name things, Adam. I know, I know. So go man, go. I like that actually. So with a seven year history, I got to imagine that over these years, you've made some friends, those friends have become core team members, contributors. Can you talk a bit about the history or even highlight some people over the years that have helped make middleman possible that may not have gotten

recognition elsewhere? Totally. I have about four core team members now. I'm always looking for more, but it's a responsibility and it's not the funnest job to just be fielding bug reports or triaging. So Ben Hollis has been my partner for three or four years now. He is an engineer up at Amazon and his cycle basically works so that when he's on a middleman project, we're getting great support and great features and we're working together. When he's not, that's cool. I'm probably on one, so I'm also contributing features. But I don't expect year-round or even month-round contributions from people. Just having a little bit of backup and someone else to check my code and make sure I'm not making a huge mistake is completely amazing. Carl Freeman has also helped

out a lot. He's pretty big in the Node community, or sorry, not the Node community, the Ember community over in Europe as well. So he keeps me legit on making sure JavaScript doesn't get broken too badly. Let's see. Elliot Appelford has recently jumped in and he's also in the United Kingdom. He's a much better Rubyist than I. So he's able to answer with all these years back and experience a lot of my Ruby questions

to keep me again from suiting myself into foot. And he's doing a great job managing the GitHub and, you know, closing out things, reporting things as duplicates, all that kind of squishy stuff that can eat up a lot of time. And then recently we've had another contributor, Dennis Guntwig, don't test my German. He is a beast, and the pull requests coming out of him are amazing.

It's just like, holy cow, he did this in a weekend. So having actual large feature development done by someone other than me has been really, really great. And then everyone who's ever contributed to the documentation site is absolutely amazing. Let's see, there's been 113 contributors to core. And let's see, there have been... I'm not going to make this come up. There's just been hundreds and hundreds.

How many? 265 on middleman guides. Yeah, 265 people who helped with the documentation made everyone's lives easier. So they're all amazing and couldn't do it without them. So is everyone listed under org slash middleman slash people? Are all those contributors then or just only a few? Those are all people who have the commit bit. Yep.

Okay. So we don't have like, we don't have, we have a couple of email threads. We don't have like a core, you know, email group or anything like that. It's pretty light, but all those people have been making, you know, invaluable contributions over the seven years. Awesome. I want to make sure we link up to that page. So we'll, if you're listening to this, we'll link that link up as well as the

other individuals that, that Thomas has mentioned in the show notes. So the show notes would be, I think what what, changelaw.com slash 169. This is episode 169, Jared. I can't believe it, man. It's real. It's crazy, man. Believe it. But I guess, you know,

when we're talking about the people that have stepped up to help out and you'd mentioned your forum earlier to allow the community to sort of step in and you not be burnt out. You know, Jared, we've talked about sustaining open source on this show with Mike Perrin before and several other times in other episodes. But, Thomas, what kind of insights can you share that you've done over the years to guard yourself against burnout?

And maybe even a touch on that could be how you've fostered this community that's whether you've tried to or not, has come up around middleman. It's just, for me, I think just be nice to people. There was a whole raft of public GitHub spats on bug reports for

maintainers are yelling at contributors and just not. You can shut that stuff down. Same old normal people, soft skills. I get to use them. I'm a manager. I do it all day. So this is just managing random people on the internet, which is a little harder, but you know, be nice. Everyone will be nice to you. The Ruby community has always been nice. So I think that's mostly like, and once you have a, once you have this backup, once you have this community behind you, you know, you're not going to get mean emails in the middle of the night.

You're not going to feel as much stress, I think, about having to like, I don't know, constantly be working on this thing. For me, I check in like 9am first thing at work, do a little bug triaging. If there's anything horrible, I try to fix it on the spot, but then I don't think about it until the next day or until I get inspiration I find a new language feature I want to do then I'll do that on my own free time but it hasn't been 7 years of continuous

development, there's definitely these, like I said we've been stable for 3 years so it's just been little bug fixes and me exploring on my own, I think that exploring also helps me avoid getting burnt out or avoid just having this fear that I don't even want to look at my own. I think that exploring also helps me avoid getting burnt out or avoid just having this fear that I don't even want to look at my own code anymore. You have to nip that in the bud. You have to refactor

as soon as you start hating your own code. You can't just let it be there forever because it'll never go back. That's interesting. Like I said, we've talked about burnout several times on the show and it just seemed to me during the show that whether you've tried to purposefully or not, you've found something to avoid the burnout. And, Jared, we had that call on Curl, 17 years of Curl. I mean, that guy was like two hours a day, and there's a commitment there. On average. There's a commitment.

Yeah, on average, two hours a day for 17 years. That's like a long time. Yeah, it's incredible. And it seems like somehow you've found the secret to not getting burnt out. Yeah, that might just be my personality. I've also been at the same job for like almost five or six years now too just i don't know walk away you can always walk away you can come back just don't burn any bridges and just know i've always known that i intend to support this for the long term so you know again keeping myself from burning out is super important to that right

and when i said that guy meant daniel stenberg i always forget people's names i gotta go back on the list and look them up and not be offensive to people, but Daniel's pretty awesome. Shout out to Daniel. There was just that article going around by I forget what library he was a developer of, but he's giving up active development because there's no money in it

and try this evil eight. People are getting rich off his work and he's not able to work this as a full-time job. But I think it frustrates anyone at a high level in open source. So people are able to have such a crucial piece that they can monetize it through support or contracting or even these special feature levels. Kind of like Sidekick is a really good example. But yeah, so I like working. i do agency work because i like to

work so i like to be on the beach while people use middleman but i'm also probably just gonna go back to work the next weekend well now it's about the uh the time we turned it over to our super awesome ending show questions um the first question uh going to, do you want to take it or let me take it? Go for it, bro. So this is the easy one. Uh, maybe, maybe not. Easy one to answer or easy one to ask? Easy one to ask. It's always, it's always easy to ask, right?

Yeah. Uh, so Thomas, you've, you've been doing what you've been doing for quite a while. I can't imagine that over these years, you've, you've, uh, got a list of people, whether you've made it purposely or not, they're your heroes. Who out there in the programming world is your hero? Yeah, I think I mentioned, I mean, as a group, I think the Ember team has been spectacular. I think I really respect all those folks for, you know,

having a commitment to stability, having a commitment to documentation, and really guiding their community as like there's other bunch of shiny things around, just basically saying, you know, we're going to keep getting better and we're not going anywhere. Their documentation has been an example that I've tried to follow

and their community management is even way, way better than mine. So that whole team is absolutely amazing. Hudocats is a, you know, he's a Ruby master. They use middleman over there at Tilda, and I've just kindly asked that he never look at my Ruby for fear of the look of, yeah, I should probably just give up Ruby now and never do it again.

But that whole group is awesome. Very cool. Next up, we mentioned contracts. We mentioned Hamster. These are some Ruby gems that have kind of been not just on your radar, but in your toolkit lately. But if you had a free weekend and you were going to go hack on some stuff, what projects have you excited?

What's on your radar of cool open source projects that you want to check out? So I've been using Pixie.js which is a front-end library for doing 2D graphics in WebGL. I've been using that at work, been using it on the side and it's just this kind of flash-like layer that allows you to get back all kinds of amazing interaction and effects on the front end.

So I would definitely go throw together some kind of crazy 3D experiment. That whole project is open source, and that whole team is also doing a great job of moving their project forward. Very interesting. Pixie is the fastest kid in town, as they say. Yeah, it's amazing. Every single time I have to fight with a browser to animate like a square, I get super angry. I just want to throw the whole DOM and the whole browser out the window.

So if I can find refuge in WebGL or find refuge in a tool like that and pretend Flash still exists, that comforts me at night. Awesome. So for those out there that have listened to the show, you know, maybe they're like me and they've been following middleman for years or they're new and they just met you for the first time here on the show and they want to help out. They want to kind of dig in a little bit to middleman. What's what's a call to arms to the community, whether they're new to middleman or not new to middleman in ways they can step in and either look at version four or help out on the community? What are some ways to step in as the community can at version four or help out on the community? What are some ways to step in as the community can do, can do, uh, to help out middleman? Yeah. So I've always recommended, um, that people just write about it or talk about it, you know, tweet about it, write about, talk about it. Um, everyone's going to have a unique use case. They're going to have

a unique perspective and that all doesn't fit into the core documentation. So the more people, you know, I try to retweet, retweet, can't even say that word, retweet, as many blog posts as I can with these really interesting use cases. I'm always surprised. Sometimes I see like middleman extensions that I would have never ever imagined could be written. And it's really awesome to see.

So the more you can just Google your question and you get an actual answer or even like a Stack Overflow answer, the better it is for everyone. You mentioned mentioned extensions that's something we didn't really dive too deeply into the show about because this isn't a comprehensive show like here's what middleman is but maybe we could take a minute to mention the extensions the project templates and the different deployment options you you have i mean you've got tons of extensions there made by the community.

Some, I can imagine, are commissioned, some that are just there because somebody needed it. And then you can also search those extensions as well. So it's pretty easy to sort of limit down to some things you want. Like, let's say you want to deploy onto AWS, there's an extension for that. Yeah, absolutely. That was something, you know, even in the Rails days, like the ability

to have these plugins, these extensions was super powerful to take the load off the core team. So I tried to follow that example. One of my philosophies with middleman, which is pretty different from most static generators is we want you to write code. It may not be very complicated, Ruby, but at least you have all the tools and the power that code gives you to make your dreams real. We don't want to be like one of these generators that all you have is one config file or one JSON file and try to fit your entire stack, your entire pipeline to that really rigorous structure. So as part of that, we farm out as much information, as much API stuff as we can to the extension API. And that lets people do pretty much whatever they want.

They can hook into most parts of the process. They can replace parts of the process. They can hook into new project template generation. They can hook in and just, you know, add a single file to the page or to the site that doesn't exist. Like, you know, do an API request, get that bundled back, make that a static API resource here. There's all kinds of really good extensions because we've opened up as much Ruby access as possible to the extension libraries. Cool.

So yeah, some of the great ones, deploy, middleman deploy, which one of the core team members is actually the lead on. It will deploy to everything. You want to go to GitHub pages, you want to go to AWS, you want to go to any CDN, it's all built into that one package. But you don't have to worry about that. You don't even have to talk to an ops guy. You can just get your website on the line.

Very cool. I'm hoping that one's middleman4 compatible at this point. Yeah, so that's me slowly realizing that I'll go look at third-party extensions and be like, why did that break? In my mind, I made no breaking API changes. So Ruby makes it relatively hard

to keep certain things out of scope. So it's like, oh, I didn't realize that was a public method people were using. So I got to go through and either reopen a couple of those APIs for people and make them stable in public or work with the extension authors to figure out why they're not using what I see to be the canonical way to do the same thing.

Speaking of deployed, Jared, we mentioned a little earlier in the show when we were talking about Middleman 4 and, Jared, you were ranting a bit about immutable data structures and Hamster and some of the things you've hit with Middleman 4 in the efforts of building out our new site beyond code.tv um so for those out there listening now it's a brand new thing we're launching but we've been producing beyond code for a while it's a brief interview series we produce at conferences at the after parties and so the first one was at keeper be weird uh the second one was at space city js the third one was at gopher con and the first one was at Keeper Be Weird. The second one was at Space City GS.

The third one was at GopherCon. And the fourth one, Season 4, most recently was at your conference, Jared, NEGS. They're in Omaha, Nebraska, which was super awesome. So we've got four seasons in the can. We're about to launch BeyondCode.tv, which if you're listening to this right now, you can go there now, beyondcode.tv, check it out. It's probably days launched. So if there's any issues you see, report them on GitHub. It's open source on GitHub. Find a link on the site. I'm sure we'll link out to the GitHub repo because it'll be there. So if you find bugs, let us know. And as Jared mentioned also, we have been producing Chained All Weekly,

our weekly email, using Middleman for quite a while. And Thomas, you mentioned your affinity for Rake, and that's how you kind of got into Ruby early on. A lot of ChangeLog Weekly is a big old Rake task that works with the Trello API to allow us to use Trello as a CMS. So we've been using Middleman in some unique ways and obviously Reagan in some unique ways as well to boost both those sites. That's cool. But I wanted to say that before we close the show. So Thomas, thanks so much for coming on the show.

I mean, whether you know it or not, we've wanted to have you on the show for quite a while because we've had this love affair with your software for a bit. And it just would've wanted to have you on the show for quite a while because we've had this love affair with your software for a bit. It would make sense to get you on the show and talk about what you've been doing and version 4 coming out and a bit of your history in software development and open source. Is there anything that we missed, anything you want to say in closing before we wrap up the show? No, it's been great. Thanks for having me. I'm glad I haven't given you too many heartaches that's my number one fear is someone out there is cursing my name at all points in time as you

get popular so i'm glad it's been good for you guys and um hit me up if you have any main things well thomas thanks so much for joining us on the show to everyone listening thanks so much i mentioned beyondcode.tv check that out you find any bugs or anything like that let us know hit us up on get up for that uh also change law weekly that's a weekly email we ship out every saturday it it covers everything that jared and i and the rest of the team finds in open source every week everything from our latest episodes to the most cool headlines and links and repos that we find ourselves as well as our ping repo so Jared we have a ping repo as you know on github that we tell everybody to submit things

to so if you find something cool check out our ping repo it's slash the changelog slash ping submit something there to the issues we'll link it up in the weekly email and boom we'll go with the dynamite so changelog.com

slash weekly until Until next week, we will say goodbye for now, and I won't step on my foot today because not knowing who the guest is next week, I'm just not going to say it at all. We'll leave the show there. We'll say goodbye now. See ya. Thanks, Thomas.

Take care. We'll see you next time.