The Changelog: Software Development, Open Source - Sass, Bourbon, Product Design (Interview)

Episode Date: June 12, 2013

Adam Stacoviak talks with Phil LaPier about Sass, Bourbon, Neat, sustaining open source, product design, and more.

Welcome back, everyone. This is The Change Log, where our members support a blog and podcast that covers what's fresh and what's new in open source. You can check out the blog at thechangelog.com and our past shows at 5by5.tv slash changelog. I mentioned this just before the show started, but if you're listening live or you're listening on the podcast, you can go to 5by5.tv slash changelog slash latest to kind of catch up on some show notes while the show's going on. This show is hosted by myself, Adam Stachowiak, as well as Andrew Thorpe, but today Andrew won't be joining me because he is flying back from the Aloha State, so he was on vacation.

But you can tune into this show live every Tuesday at 5 p.m. Central Standard Time right here at 5x5. And this is episode number 93, and today we're joined by Phil LaPierre. He is a product designer at ThoughtBot and the creator as well as maintainer of Bourbon, which is a simple and lightweight mix-in library for SaaS. So, Phil, welcome to the show, my friend. Hey, Adam. Thanks for having me. That's quite a little intro I just did there, man.

I don't think I've ever done one that long before. Yeah, well... I'm not really digging long intros. I feel welcomed. Well, it's... You know, I've been a fan of ThoughtBot, for one, and the work you've been doing with Bourbon, so I thought now's a good time,

since Andrew can't make the show, why not play on the side of the fence that I kind of thrive at a bit more. I have fun when we do this show and we talk a bit more dev speak, which is always enlightening for me, but let's face it. I'm still learning to be a true hacker, so I'm always playing catch up when it comes to that kind of chat. But I figured, hey, SaaS, right? Design, SaaS, product design, a lot of fun stuff you do there at ThoughtBot.

Yeah, I mean, ThoughtBot's a great place to work, and I do product design here. So what that entails for us, our role is actually, it's kind of a weird role, I think, than maybe a traditional product designer might have at, um, another, uh, tech startup. But we do, um, design as well as front end development.

So writing, uh, HTML and CSS and, uh, SAS for that matter. And, um, we also read JavaScript when,

when the time calls for it, but usually any kind of really heavy JavaScript we, we leave to the developers here. You mean on the design, on the product design side, right? Yeah, product design side. So like Backbone, for instance, we've done a bunch of Backbone apps. That's all developer-heavy stuff. So I don't necessarily touch a ton of Backbone code besides view-specific stuff.

But yeah. Cool. So for the uninitiated, not so much on ThoughtBot, but more specifically yourself, um, what's a good introduction for you for those who don't know who you are? Um, well, a good introduction for me. Um, I would call myself a hacker, a designer. Um, always kind of interested in tinkering with code, making things look pretty, work pretty, you know, making things usable on the web. So just a designer by day and, I don't know, cool guy by night. Nice. So how long have you been working at Thoughtbot? I haven't caught up on that yet. Yeah. So I've been here coming up on three years this summer. Wow.

Yep. June or was it July start date? July, late July. That's a good start date for a lot of people. I like starting new things in the summertime. I don't know about you. Yeah, certainly. I mean, it's been awesome, and I'm here in the Boston office. And Boston's such a beautiful city to live in. Yeah, certainly. I mean, it's been awesome. And I'm here in the Boston office. And Boston's like such a beautiful city to live in. Yeah. The summers here are just absolutely phenomenal. And when you say Boston, you say that because not only do you have the Boston office, but you also have San Francisco. And I believe, don't you have one in Europe now too? Yeah, we've got one in

Stockholm. Wow, man. Yeah, so we opened the Boston office last year, or sorry, the San Francisco office last year. Stockholm, I think, came after that. And we opened up a Denver office, or sorry, Boulder office, I think this past winter. So when are you guys going to Austin? Or Houston for that matter, I guess?

Yeah. Uh, I don't know. Good question. Um, it's kind of crazy to see how fast, uh, we've sort of been growing in, in various cities and it's only, it's, it's been good to see the support by the tech community, um, for us there, you know, it's, it's, it's really cool. And for those who are really interested in, uh, the history of ThoughtBot, I am planning to get Chad Pytel, the founder of ThoughtBot on Founders Talk soon. So for those who listen to Founders Talk as well as the changelog, stay tuned for that episode. I'll definitely announce, uh, announce that. I can't wait to talk to Chad. I've talked to Chad a couple of times at different Ruby and Rails meetups, everything from RailsConf to LoneStarRubyConf. I had some fajitas with him, I think, at one point in time.

He's a cool dude, man. I mean, I'm really proud of what you guys have done, not only as a business and progressing the business of software, as you guys say, but just your tenacity for open source and your commitment to the community. I mean, it's, it's, um, it's, um, there's not many else out there quite like ThoughtBot and you guys really do an awesome job. Yeah. Thanks. Well, it's, it's really awesome that we've got, uh, Fridays to really be able to do, um, what we call investment investment days. And that's really where we get to contribute to open source or work on one of the products that we're developing internally here. So I think that really helps push a bunch

of stuff out to the open source community and get pull requests taken and issues resolved for all of our open source tools. So the entire day of Friday is dedicated to that? Yeah. Wow. I mean, we can talk about maybe a bit later on, but that's touching on a subject I want to talk to you about. And I'm hoping you can share some details just around, like, it's been a trend the last few shows of The Change Law. But just talking about sustaining open source and, you know, you got a lot of people who really give their heart, blood, and soul to a project. And not really at the community's intentions, but somehow that person, that maintainer, that leader kind of gets wound down or get run down. And that's been various topics over the last couple of years. But we've been seeing a trend more and more just talking about sustaining open source. And I know that at the bottom of all

of ThoughtBot's open source projects, I'm trying to look up my notes because it says Bourbon, I guess project name entered here, blah, is maintained and funded by ThoughtBot. And it just goes to show you what you said there with dedicating entire Fridays to open source. So we've kind of gone a little bit of a preamble there, but I don't mind diving a little bit deeper into it. But what does that do for, let's say, your culture as designers, developers, makers of the web at ThoughtBot? That kind of commitment.

Okay. I mean, it's, it's really awesome in, you can feel that, that, uh, strive inside our office for wanting to contribute back to the community. Um, and I, and I think that's why we're getting such great, great stuff. Um, that's coming out of, out of a ThoughtBot. Um. Because it's something that people get to team up on Fridays and really work together to produce amazing open source tools and really improve the community. So I think it's something that transcends, I guess, sort of the standard office culture where you just go in and kind of work on your project every single day because it's, you know, it keeps you new and keeps you fresh to have a good open source project that you can contribute to on Fridays. And since there's so many different open source tools, you know, it's not like you're limited to one. You can contribute to a bunch of others. So, right. And for those who may not be too familiar

with Thoughtbot, shame on you if you're not, um, you guys mainly are, uh, a Ruby in Rails. Uh, I guess I don't even know if shop really applies to you guys anymore. It's more like, uh, I mean, cause you, when you span four to five offices or potentially five offices soon, hopefully, you know, I don't know if you're considered software shop. But you guys are mainly on the Ruby Rails stack. Obviously, you do some stuff in JavaScript as well, though, right? Yeah, we do some stuff in JavaScript as far as branching into Backbone.js. But we've also started a venture into iOS, and so we've hired on some iOS-specific developers

who are phenomenal at what they do. So, yeah, we're starting to take on more clients since we're a consultancy that are iOS-specific. Yeah. Let's talk about Bourbon. Let's talk about SAS. Um, I can't imagine anyone listening to this show that isn't at least a little familiar with bourbon. Um, definitely interested in and familiar with SAS because I think for a while there,

we had a drinking contest on the show that every time we said SAS or compass or something like that, it was time to drink. And I don't do that anymore, obviously, but nonetheless. So for those who may not know SAS, Bourbon, what is SAS? Yeah. Well, SAS is a preprocessor that sort of a level of abstraction on top of CSS. So it allows you to do things that you wouldn't normally otherwise be able to do in CSS, like nest declaration blocks, do loops, if statements, that sort of thing, and compiles all out to standard CSS. And then I guess Bourbon on top of that is... Yeah, so Bourbon on top of that is... Is like a SAS on crack or SAS on steroids or, you know, SAS supercharged. Yeah, you know, I see that like Bourbon is something that really is like an API

that helps designers and developers to be able to write their CSS faster and better. Specifically, it started out mostly with specifics for vendor prefix properties for the different browsers like Chrome, Opera, Mozilla, Firefox, that sort of thing. And so it was just a wrapper so that it made it so that you could write just faster code and it would just output what you basically wanted it to for all those specific browsers. So you are like unencumbered by the browser.

I guess even the staticness of CSS itself, right? Because if you can loop through or do some programmatic-like things in Sass, you can, with one line, I guess, maybe a crazy high-powered mix-in and one line of Sass, you can probably write 100-plus lines of CSS. Yeah, absolutely. I've done some really cool stuff with that, like just some really cool for loops that just run through and just generate like animations are pretty good for that. So like if you want to output, let's see, like an nth child that that sort of animates or sorry, iterates through, say, 20 children and say add a a duration to every child that it increments up to.

So like the first one might get animated in at like one second. The second one might animate in at two seconds. Third one at three seconds. Rather than having to write all those out, you can just wrap that into a nice loop in SAS and it stays really compact code and it outputs what you're looking for. When we talk about Bourbon, I know that for those listening that are familiar with SAS, there's also maybe even you got introduced to SAS because of Compass. So there's this other, I guess, mix-in framework very similar to Bourbon that kind of was even the inspiration for Bourbon.

Some know SaaS because of Compass. For you, what was it that kind of got you into SaaS? What was it that got you excited to even attempt to do Bourbon? Was it something that, you know, it was a ThoughtBot thing and you kind of took it over, or where did this come from? Well, it initially started when I first joined ThoughtBot, they, uh, they were using SAS on other projects and, uh, each of the designers that we had here, you know, we, um, like the way we structure our projects is that, um, each project

gets one designer and there might be multiple projects going on at the same time at the company. But the problem that I ran into was that I would write mix-ins in SAS to do something like, at the time, generate a border radius for all the different browsers. And I might call it border radius. Someone else, another designer might call it rounded corners, that mix-in. And so it became this huge pain to jump on different projects and have consistent language when you're writing the SAS to call those different mix-ins. And so I was like, this needs to be fixed. And so I released a gem with the help of a thought bot, um, that basically took all those things that we are writing and using across all of our projects and

wrapped it up into, um, one gem called bourbon. And so then we started using that and, you know, we had done, um, an exploration in compass, taking a look at that. But unfortunately, you know, I think like it's, it's an awesome project and the stuff that Chris has done with it is just phenomenal where he, you know, has built it to where it is to this, to this point. But I know when I first, first tried using it, I ran into a ton of issues just trying to get it installed. There was like a configuration file that I just kind of didn't want to have to deal with. Um, it was, it was kind of wrapped up in with a blueprint at the same time. And so it just felt like this big sort of cumbersome thing that I was throwing into my like nice, fresh, clean, lean project, um, that I was just getting started. And it just, it felt like it just did way too much than, than what i wanted it

to do and so i wanted something i desired something just slim and just really easy something that i could totally understand and um took you know took the um kind of was opinionated in a way and said like these are what these are the defaults that you're going to want when you start this projects so um take it and run with it. So Burban was originally, at least from what I understand, was originally championed by Chad Mazzola, right? And that was originally called SAS Mixins. I mean, you know, I think that, like, we were all sort of at the same time had our own Mixin libraries that we were using.

And so I think it was under his repo or something we were contributing into it. But then I think it was just sort of under his repo that we sort of started and transferred it over to the ThoughtBot repo. But yeah, I mean, his contribution to it were pretty huge. Like he did the button mix-in, which is basically generates, you know, with one line of code you can generate an entire, I don't know,

probably like 50 line buttons, you know, like super quick. So it's easy for like prototyping and stuff. So I guess on that note, then when we think about not only SaaS, but when we think about what Bourbon provides to someone who's using SaaS to write their CSS, I know this is a lot of inceptions potentially here for some listeners, if you're not, if you're just catching up, but you know, what is the aim? What is the purpose of Bourbon? I know you said a unified API, but I don't know, you even said the button example there. Can you give another example of how, you know, what it makes, what makes sense to put something into bourbon? What, what gives it the ability to be part of the, part of the

library? Yeah. So there's sort of these principles that I have defined kind of loosely about, you know, what belongs in bourbon and what bourbon is and what it should be. And, you know, I think that it should be, you know, everything contained in bourbon should be as close to this actual CSS spec syntax as possible. So when you're calling, when you create a mix in for something like a linear gradient, you know, we want to call it, we've got a, like the way you define it in CSS, you'd use the background image property, and then your value, you'd pass a linear gradient, and then your colors. And so we've got this, in Bourbon, we've got this background image mix-in, and that calls a linear gradient function, and in there you pass your colors.

Same with something like transition mixin. In CSS, you traditionally have a transition value, and then you'd pass the arguments to it. Same thing with Bourbon. We want to call that same transition mixin. And so another thing that I see, I want it to be pure be pure SAS. So bourbon is a completely pure SAS library. And what that means is that you can, um, take bourbon, the project directory, and you can dump it into, um, any SAS project and it's going to work, um, without any hitch. So it's not tied into Ruby, which something like compass is tied to Ruby. Um, cause it has all these external functions and, um, directives that, uh, use Ruby, um,

to compile, to like output the CSS. So rather than just using straight SAS, it makes a little bit less, I guess um i guess fluid to to not have any issues i mean i have to say myself i've been using bourbon as well as need on our project recently but sadly i haven't gotten deep enough into the design yet of that project to really appreciate and enjoy the things about bourbon so that's was perfect for this call just to kind of get the the lay of the land from the maker himself. But what I did notice was that there was no issues. It's a Rails project, asset pipeline, the whole deal. And there's been issues in the past, which I haven't been closely following. So if these

issues are non-issues now, then I apologize. But there had been in the past issues with getting Compass going with asset pipeline. They were trying to do some of the same things and different stuff like that but what i noticed with bourbon was that you know your your readme install directions were simple you know just add the gem bundle install and pretty much good to go no issues with getting started at all yeah i mean that's the cool thing about having a mixin library is that it's just pure SAS. So like anywhere SAS works, Berman's ready to go. And so it makes it platform agnostic as well. So like for something like, um, so the creator of SAS, uh, Hampton Catlin. Yeah. So he, um, and, uh, Aaron, uh, Loong just created, um, this recent project called Sass C. Have you heard about this?

I sure have, yeah. Okay. So Sass C is basically a lib Sass wrapper that compiles Sass using C++. And so this is good for people who either don't have Ruby or just want to use like SAS on a C++ project. And so you can install that and optionally install your or compile your SAS files using the SAS C library. But it's cool that like you can take Bourbon and you don't have to, it's not like you have to port it because things are written in a language like Ruby. It's like, it's just anywhere SaaS works, so does bourbon. Yeah. I never really thought about that. I mean, I guess that was one of the original things because if we rewind back a bit, the change has been around for a while.

We've been around since 2009 and I was pretty excited about this project. And I think I even wrote a pretty lengthy article on it. I'll put it in the show notes back, looks like July 7th of 2011. It was a couple days after you guys first released this. And it was pretty lengthy about what you guys are doing and what's up with it. capture the necessity, I guess, or this being a feature, I guess, of Burpin that no matter where SaaS works, it works. I guess because I was so tied to what Compass had done, I was really excited about some other things it was doing. I think even things that Bower now does, Twitter's Bower, are you familiar with that?

It's kind of like a package manager for the web in general? Sort of. I've kind of briefly checked it out. It's kind of like cargo-culting HTML, CSS, and JavaScript around and being able to easily put it into a project. In this case, in Bower's case, it's Git-powered, so it's super powerful just to put it in a repo and then suck it into your project and it wouldn't drive away a. But I was kind of excited about these other features that Compass had, and I feel like

Compass was really great for a lot of things, but this one downfall of kind of like having to have Ruby, and that's kind of the starting issue for a lot of people using SAS. So I guess as a designer, when you talk to other designers, they're like, you know, Hey, Phil, I want to get into what you're doing more or, you know, how do I get started here? Like one of the biggest hurdles is, you know, how do I use SAS? How do I use that in general? How do I get set up? And, um, just, it doesn't really help, you know,

bourbon doesn't really help getting started with SAS easier, but it makes it a lot easier to get involved with a mix-in library because of its focus on being sass purists yeah exactly um and i think there's you know people have come out with um like gooey wrappers right that compile sass um some of the big names are uh code kit uh hammer for mac yeah um so it's been like, those are pretty cool projects too, for anybody out there listening, those hammer, I just recently checked out. I've known about code kit for a while. And there's one other one, I think that is on your list of ones you support. I can't recall the name of it though.

Uh, there is. And that one is, um, live reload. Live reload. Yes, of course. Yeah, so those are great. And Bourbon is integrated into all those projects. But it was easy for me to work with the developers to get that implemented because it's not like there was any executables that needed to be run because they all compile SAS.

So they just were able to throw Bourbon really in there and it was good to go. So this might be somewhat of a flame war of a topic, but I'm just kind of curious. You've been using SAS long enough to know that there's been two different syntaxes. I'm just curious for those who are still kind of hanging out in the SAS, S-A-S-S world and not the S-C-S-S world. And I'm

not even sure if you call it Sassy CSS or S-C-S-S and next thing you know, you're tongue twisting and nobody knows what you're talking about. But, you know, what are your thoughts on just that SAS versus S-C-S-S? You know, what do you say to people when they're like, oh, um, you know, what are your thoughts on just that, uh, SAS versus SCSS? Um, you know, what do you say to people when they're like, Oh, I'm still using the old way. Yeah. Um, so we use, uh, the SCSS syntax. And so that's the more verbose, um, curly brackets, all that kind of thing. Um, so I was recently, recently talking to, um, rita lambden who's a designer here at thoughtbot and he came up with this uh great idea of trying to use the sass syntax for um working on things like neat or bourbon neat is our grid framework that sort of ties in with bourbon.

So when we work on client projects, we're writing actual CSS that outputs. I think that's where SCSS really shines is because then you get the traditional logical hierarchy of things using the curly brackets and the colons and all that sort of thing. But when it comes to when you're actually doing like what I would call programming in SAS, I think that's where S, SAS can actually really be useful. So if you think of something like, if you think of in comparison of CoffeeScript to JavaScript, I love CoffeeScript because it just takes away a lot of that pain of opening and closing curly brackets and all that. So I would sort of put it in that sort of perspective. But I will say that I actually haven't tried to use Sass in Bourbon yet, but I think that's something that I would love to try in

the future and see if that actually works out as we've sort of hypothesized. So what you're saying is you kind of got one little toe into the proverbial SAS pool. Yeah, exactly. I was surprised to hear that, honestly. I thought you would be a lot more pro-SCSS. Not to say that you're not, but I kind of expected this kind of stern opinion. Well, I mean, I think if I'm writing CSS that's going to output just like your CSS would, I think SCSS, I prefer to use that, but in the same way that I love coffee script, I could, and, and if you look at, um, Oh God, in bourbon, there's like

the linear gradient mix in, there's some mix-ins that are just so insanely huge, right? It's so hard to follow. And so I could totally imagine myself using SAS to just basically do all the logic and all that kind of stuff in a much more concise and clear manner. I'm going to your source code now to pull that up because you're absolutely right. I mean, in this case, I can see – and I think I've done this too in my past where I've kind of teed in the line of – I don't want to spend a ton of time on this because I think that people talk about this quite a bit. It's been discussed on the Sass Way. It's been discussed on other blogs. I don't want to bring up the can of worms again. This is not the intention.

I just kind of wanted to get your opinion on – for those who are still hanging out in what might be considered the old world. Because if you talk to Hampton, he's not really for it. If I recall correctly, sorry Hampton if I'm wrong, but I'm pretty sure that he's kind of against the older SaaS way and kind of focusing on one syntax. And that way the communities are fractured and there's not two ways to do things. And it makes it a little easier to provide long-term support and so on and so forth. Right. Are they planning on killing the old syntax? No. Nathan Weisenbaum, he took over the maintaining of SAS when Hampton, I think when Hampton went to Wikipedia and had less time to be involved, I'm pretty sure that Nathan took over.

Chris kind of co-piloted with Nathan and they've committed to not deprecating the old syntax. I know it's here to say, but I just know there's differing opinions. Nathan has done a fantastic job with Sass and has done a great job

leading it and maintaining it and progressing over the years. The inventor, Hampton, and progressing over the years. But, you know, the inventor, uh, Hampton and him have differing opinions from what I understand on some things. And that's going to happen. Like creative developers. I mean, you kidding me? And then you're going to have some different opinions. It's going to happen. Yeah. So, yeah, I'd be curious to see what, uh, to hear what, uh, Rita Lambden says, because he's working on neat and his, one of his goals for launching neat 2.0 was to actually convert neat to use entirely the S S A S S syntax. So I don't know. I'd like to try it out too and see kind of what the pros and cons are. Admittedly, I haven't really used that syntax. Um, I've just been sticking to SCSS for a while.

So you mentioned the linear gradient, which is if you're looking at the, by any chance, if you're listening to this live or on the podcast feed, you can go to github.com slash thoughtbot slash bourbon, dive into the asset style sheet CSS3 folder, there's a linear gradients, or sorry, a linear gradient partial there that is, you know, quite programmatic too. I mean, so we're coming from the world, we open up the call by saying that you're, you know, a designer primarily, but you're also kind of getting into hacking and stuff like that. And you have been over the past years. And why wouldn't you? You work at ThoughtBot. so you definitely have to put your hacker hat on at some point to truly thrive there and have fun too, right? But one thing that for me with SaaS, whenever I started to do a lot more with it. So if you're coming from the CSS world where it's static, what you type is what you get basically.

And then you come to the SaaS world, whether regardless of syntax, the functions are all still the same. You still have access to all the same SAS functions and APIs and, you know, different abilities. But one thing that was pretty cool was, like, you know, you can start to use variables, right? And you can start to do things like returning values. Like, for example, in line 10 of this particular file we're talking about, you have type of

in there, right? And you can kind of determine what you pass into it as an argument. What comes back, you can determine if it's a list or if it's a color, if it's a color with pixels, you know, all these different things is like pretty cool. So all that to say is that it seems like, you know, if you get into SAS and you really kind of dig in and really have fun with it, that you can learn if you're not a program, you can kind of learn some of the programming basics by, by using it and, you know, enjoying it. Yeah. That's one thing where, you know, I started, uh, you know, working on bourbon. I don't think I realized the like impact that it would have on my,

I guess the outcome of like hacking on this and just how much I learned and what that translated into my learning of programming. Just deep diving right into the SAS documentation and, you know, learning about interpolation and type of, and, and then just all these different things and creating different functions. Um, it just really like gave me a much better understanding of these basics of programming. Um, and what that turned into is now I've started to, uh, learn CoffeeScript and, and learn CoffeeScript pretty well. Um, and so now, you know, I'm kind of working on a hacking

on my own side project right now. That's completely, um, written in coffee script. It's actually using meteor JS, which I know you were talking to, uh, such a grief just a few weeks ago, um, about, and, you know, I absolutely love meteor, but like just from the past, like two years, two years, yeah, maybe two years working on bourbon. It's like, I think helped me grow to the point where I can work entirely on a Meteor project because of like the basics that I've learned from SAS. Yeah, absolutely. I mean, conditionals, I mean, that's like the, you know, programming 101 is if this, then, you know, those types of things and confirming if a value is true or false or all these different things.

I mean, that's pretty wild. And one of the, I think, not so much the most complex mix-in inside of bourbon to kind of key off of some of this conversation, but one of them is the add-on for position. And I mean, like, even that one there, I mean, if you think about position in css it's it's not a really complex um you know property and value it's it's pretty cut and dry

right it's either position relative absolute fixed and you've got some you know places it can be for example on the page and whatnot but this particular mix in in sass well, the SCSS syntax is 42 lines. I mean, it's like you said earlier that the SCSS syntax kind of makes it a bit more verbose, but it's a little easier to read in this case. But nonetheless, I mean, you have a pretty simple thing in CSS to do, but you've got this 42-line mixin that uses typeof and uses the list, and you're confirming what you passed into position, if it's a list or not, and kind of returning the thing way early on, and you're doing things with top and nth. That's a really pretty neat thing.

So if you're just a CSS hacker and you're doing it really well, and you're picking up Sass and you're picking up SAS and you're kind of getting into it. This is a particularly cool mix-in I would say to, to like learn all the different things that are in SAS that happened in this mix-in. Yeah. I would say one of the, like the, probably the most advanced mix-in is probably the background and background image mix-in because those have to take the linear gradient and radial gradient functions. But with recent changes that happened to, um, the spec of linear and radial gradients, you'll know that the position changed. So like if you used to call, uh, let's, if you used to call top comma, um, red comma orange, that would be a gradient that went from the top to the bottom, vertically red to orange.

But then the spec just recently changed to you have to add two to the position. So now two top, red, orange. orange and they also flipped the way the browser renders that or something. There was something little, uh, wishy-washy about that. So I think, I think that was the case where they flipped the actual gradient or something. Um, and so I had to figure out in order to, in order to keep backwards compatibility, I had to figure out the position. I had to flip the position for the like new browser. Um, and still like when you, when you give a gradient, you can also give it color stops. Um, so there's actually a lot going on in something like the background image mix in where I call external functions. And so on line 31, you'll see gradient position parser. Well, that's going to parse the actual

position to be, you know, is it top? Is it bottom? If it is top, flip it to bottom. Um, and then things like render gradients. And so that's passing in all those things and passing the vendors. And basically it's like all these different files that it's sort of passing these arguments to, and it's returning back and it's just basically compiling the like gradients and i you know it's just like it's kind of crazy to see this like programming in sass because you wouldn't really expect like all like this to be possible to do this in something that's not a programming language right it's you know you're mentioned too of the, of the spec changing and how you mentioned earlier, you know, what bourbon is to SAS basically is this common API to,

you know, CSS that you're going to actually end up not having to write because it, you know, SAS is basically outputting it for you. But, you know, what you just mentioned there though, is a really good reason to use SAS and specifically use Bourbon or even Compass in this case to not have to go back. I mean imagine if you had to go back to all your projects and update that thing. But if all you had to do was install the latest version of Bourbon, keep calling the same – the function with the same amount of arguments or whatever. And somehow with inside of Bourbon, inside inside those functions, you handle that for them. I mean, you kind of maintain forward compatibility with a little bit, a little bit less work, and I guess a lot more time on your hands. Yeah, absolutely. I think that's one of the benefits of something like bourbon is when you, you sort of like outsource your, um, vendor

prefixes and stuff. It's like, you know, people, you no longer have to worry about, you know, keeping that code up to date when specs change, because I'm going to take care of that for you. You know, like all you have to do is update bourbon and it's just, you know, as it should, it should output the latest spec and the backwards compatibility as the way that you initially put it in maybe a year ago. Yeah. I guess since we're keying off this a little bit further, what are some of the biggest things? I mean, we touched on it a little bit, but I'm kind of curious to a more specific answer. But what are some of the biggest things you've learned with creating as well as

maintaining bourbon? Not so much just in, you know, about SAS or CSS, but just kind of in general as a, as a person who makes things on the web. Yeah. Um, I think open source stuff is in touching upon what we talked about a little bit about earlier is that it's kind of a pain in the ass to maintain. Um, just because there's, there's always pull requests and those issues and it's finding time to get around to it. And, um, who was it that did that talk? Um, was it fat that that was like, yeah, just that sort of, um, why do I hate open source or some, some kind of title like that. And, you know, after maintaining this for two years, it's, it's a lot of work,

but it's like the rewards are beneficial to have a project that like, like when I install bourbon on a new project, I'm like, this is just the way that it should work. Like, I'm so happy that I created this and that I don't have to worry about all this other extraneous stuff that traditionally we did have to handle a few years ago. Um, so, I mean, it's nice. And, and plus like having the community be able to contribute to it and make suggestions and bring up issues. It's, it's, you know, extremely helpful because it might, they might not be issues that I would run across. So, so it's awesome to have the community there and helping, but it's also like, oh man, like there's just so much going on that sometimes I don't have time to get to the pull requests or issues as soon as I would like to. So you touched on sustaining open source there.

I mean, that's not exactly what you said, but it's this topic that's kind of, like I said, trending on the changelog at least. And we've definitely talked about it. I think every show since we've relaunched the show, I don't know if you know, but we had this little hiatus tail end of last year. We relaunched the blog in January and relaunched the show, I believe, in April, I think it was. We had this little hiatus, so we definitely aren't back. But nonetheless. It's good to have you back. Yeah, thank you.

I mean, we've really enjoyed doing this show, and it's fun having these kinds of conversations with you and others. I mean, because I think that people think this, and maybe other podcasts cover this, I don't know. But it's nice to hear the benefits and rewards of open source, even though, like you said, like a better term, it's a pain in the ass it can be sometimes, you know? Yeah. I always love the times when people like tweet at me or, you know, tweet like, oh, I'm like, love Verbin, just discovered it. It's just helped my process so much.

Those are like inspirational and things that sort of keep me going on this project is to hear people's successes with it. And when people use it on their new projects, like it feels good. It feels like this is a valuable, um, like my time is valuable here and people are, are getting use out of it. So cool. Yeah. So it's good to work on. So if you're listening to this live or on the podcast, at this very moment, go to Twitter, tweet at Phil LaPierre. We'll have it in the show notes if you can't spell it, but I can spell it. No problem. Tweet at him, and if you're using bourbon and you love it, tell him right away because that's going to give him such motivation so um but so talking on sustaining open source uh it says the bottom

bourbon is maintained and funded by thoughtbot inc we talked about uh you know thoughtbot fridays open source fridays and the fact that you guys are committing to that um i guess what do you think is happening in helping sustain open source? So your company helps you by paying for your time. What do you think are other creative ways that you see open source being sustained since you're familiar with Fat and his conversation around why he hates open source or whatever his topic was? I can't recall the title either, but pretty cool talk. I think a lot of these things are coming out of, um, projects that people like products that people are working on. So even if someone's company doesn't pay them to work on open source, it's like, if you are working on a product at your company and you find something that you can extract out something that

other people use, I think that's where we can, you know, that's where a lot of this open source tools are coming from these days and can be maintained because as long as you keep sort of updating your project and, you know, keep developing whatever open source tool it is that you've created, I think that's where we can see a lot of great stuff, um, coming to the open source community. Um, and I see, um, it looks, I think I saw recently that, recently that Chris Epstein got a job at LinkedIn. Yeah. And he's going to be working on SaaS, like entirely.

I don't mean to catch up with him because I've kind of been in my own little hole, but, and considering, you know, I run the changelog, I should be a bit more up to date on some of these things. But that's, I knew he went to LinkedIn, but I didn't know that they were giving him freedom to do a lot more SaaS and compass. Yeah. I think it's a lot of, I think he's going to be working on SaaS, uh, entirely. I mean, correct me if I'm wrong, Chris, but I think that's just phenomenal because, you know, SaaS is sort of like this, uh, amazing tool that the industry is adopting and continues to adopt. And it's just really, I think, changing the way that we write CSS and architect our projects and share code. It's really phenomenal. So kudos to him for keeping up on top of SaaS. And he is such the right person to, mean together with nathan of course but i mean

chris is so smart i mean uh talk circles around me when it comes to just css architectures you know not not sass itself because i mean that's a means to an end i mean it's a good means to an end obviously but at the end of the day sass compiles down to css so it's not like anybody who's got their their sass jerk hat on for example like i i know uh on the sass way a good friend of mine um canary mason is what he used to be on um on twitter but i think now he goes by coding designer um his name's mason he wrote a blog post about being a sass jerk because he's just so excited about sass and he wants to tell everybody about sass right it's like you know this thing has changed SaaS jerk because he's just so excited about SaaS and he wants to tell everybody about SaaS, right? It's like, you know, this thing has changed my life.

And he's like, you know, I just realized I was a SaaS jerk. It's a little topic on there. But, you know, Chris is, you know, we get so passionate about it, but Chris is super smart when it comes to all this stuff. But at the end, like I said, at the end of the day, it does just compile down the CSS. So we're still writing and still touting the awesomeness of CSS. We're just making it a little easier to get there faster. And like you said earlier, with a more consistent API from project to project and getting started a lot easier.

Like I said earlier, with my project, it was so easy to get Bourbon in place. It was just way too easy. I mean, maybe not way too easy, but definitely good. Let's talk about, if you don't mind, I want to talk about one more thing around what you've done in bourbon that may go a little unnoticed, but it's kind of neat, at least from what I saw of it, was that not only did you provide this SAS mixing library called Bourbon,

but if you install it as a Ruby gem and not just move the SAS into your project, you kind of get access to these command line tools, and they're powered by Thor, and kind of diving it a bit more to open source and just coming from the design side to the developer side and kind of straddling that line a bit more. I thought it was pretty neat how you guys used Thor. I guess it's pretty rudimentary to do it for other hackers, but it's really cool how you can do bourbon install and it runs a Thor script. And for those who don't know about Thor, Yehuda Katz wrote this thing, I guess, kind of accidentally.

And then it kind of became this thing. And I've loved Thor. You've probably heard Wynn say it on past shows if you're a long-time listener of The Change Log that I was always stoked by Thor. I thought it was pretty cool. It's like Rake, but it's not Rake. It's Thor. So it's straight Ruby, but you're doing some really cool copying and stuff, and you're also providing some command line there. What part did you play in, I guess, just introducing that to Bourbon?

The part I think I played was there was a thorn in my side of I have to copy and paste this project to every single – this folder to every single project that I want. Developers help. And so that's when Mike Burns really came to my rescue. And, uh, you know, I sort of said, this is what I want out of bourbon. This is what I want it to do to make it easy so that you can update bourbon and install it really easy from the command line. And Mike Burns, the rescue comes out and, uh, you know, writes Thor and, or, you know, the, the script that, that runs the Thor. So. Yeah. The file we're mentioning, uh, he's talking about. So Mike

Burns, I think I actually met Mike, uh, when I met Chad at, uh, Lone Star Ruby Conf a couple of years ago, but, uh, the file, it might be a little bit melodramatic to, or not melodramatic, but just kind of verbose to mention the file name, but I'll put it in the show notes. But if you go into the lib folder inside of the bourbon folder, in that folder, there's a file called generator. And inside there, you open up a class to Thor. And it's just really, like if you want to learn like a really simple but very useful way to use Thor,

just file copying and stuff like that, this is a really neat way to make your own command line for lack of better terms. So just hop on into terminal and do your own thing. And in this case, you know, everything begins with bourbon because that's the module, that's the Thor module that you're, you're making. But I just thought this was such a neat addition to it because you're right. If you're in a, uh, you know, if you're in a non-rails project or whatever, then like you had said, you have to go and copy and paste. And not only that, but you can even do bourbon update, which pulls back from the gem.

If you've updated the gem and pulls that new bourbon style sheets down into your project, I think it's pretty awesome. Yeah, it is great. I have got to give all the credit to the developers because I just stated my problem and they came up with a solution. So, yeah. To the rescue. You know, let's maybe one feature request on that would be, or a question. Maybe you don't know this answer, but we talked about it a little earlier when we had our sound check. But I'm curious, with all the awesome command line tools you shipped with that as powered by Thor,

but why no Bourbon watch? In your readme and documentation stuff, you still are suggesting people to use SAS watch. Yeah. Well, in honesty, there's really no need for a Bourbon watch. When Bourbon was released initially, we did have one dependency on a Ruby file. And that's where a Bourbon watch would have really come in handy. Because, you know, you had to

actually when you pass a SAS watch, you had to pass, pass a flag, which called that particular Ruby file. So that was kind of a pain. But now that we've done away with that Ruby file, and it's all complete, purely SAS, really, you know, you just run SAS watch and then point it to your directory where your SAS files are and it just runs. So really the bourbon, if we did create a bourbon watch, it would just be a wrapper for SAS watch. So, and honestly, it's, it's not, uh, that important. I think, you know, it's, I don't want to create another level of abstraction for using these tools when there's already so much going on that I think a SAS watch just gives you a better understanding of the tools you're using. Gotcha. Yeah. I figured that might've been the reason I was thinking

maybe sort of bourbon watch, it could be like Bourbon Mix or something on this name, this bourbon. And as you mentioned earlier, Neat is part of the ecosystem too. So we got through this entire show so far without even mentioning how cool the name is and maybe even a backstory on where the name came from. Yeah. Let's see. What's the backstory on bourbon? I think it was, I mean, I love bourbon. So just drinking it is amazing on the palate. So I think that's where one of the strong ties for the name came from. The other was, I think we just were looking for something that sort of tied into the fact that it's, we wanted to make like the philosophy behind bourbon,

which is a pure SAS library, something that was close to the actual CSS syntax. And so initially I think I had proposed bourbon vanilla because bourbon vanilla is a type of vanilla that's actually the most popular type of vanilla out there that's sold in the market. So initially, it was that. And then we were just like, well, let's just call it bourbon because we love bourbon. And it just has a great ring to it. And plus, I mean, let's face it.

ThoughtBot is not bad at naming things i mean from like suspenders to clearance yeah cocaine i thought that was actually kind of comical uh although i'm not a fan of cocaine but it was pretty cool yeah you think that we're just a bunch of like druggies over here or something but yeah well it's just a it's a cool i like how in the in the parentheses it says uh command lines you know for yeah this is i'll put that in the show notes too so those listening if you haven't seen cocaine yet uh not that cocaine thoughtbox cocaine check out the show notes we'll put it in there it'll be uh this is episode 93 so if you're listening you can go to five by five

dot tv slash changelove slash 93 if you're listening on the podcast it'll it'll already be live um yeah i mean so what's what's next for the bourbon ecosystem so you've got neat you've got bourbon itself are you going to keep pushing the boundaries what's next yeah so well we recently came up with neat um, which Rita Lambden has been doing an amazing job on, which is our grid framework. That's a semantic grid framework that is for building fluid grids. Extraordinarily easy and doing it all in your SAS as opposed to polluting your HTML with classes and stuff. So that's just a phenomenal library and tons of praise on that. Um, we're sort of,

we, I'm not sure if we officially launched it yet, but I wanted to this summer when we sort of do our company retreat is get, um, the designers together to really, uh, launch, um,

this thing we're called, we're calling bitters. Um, I think it might be public somewhere on our, uh, ThoughtBot, uh, repo. Yeah. It's on your GitHub for sure. Yeah. So I think, yeah. So that's really basically a starting point that we're using on all of our projects now, uh, which gives you, um, basic variables, basic form styling, things that really you can, you know, you can just copy the folder right in and it sort of does these things that you, uh, you know, normally set up on every single project. So it saves time and effort. Um, that's meant for prototyping, right? And it's not meant to be the end all starting point for your styles. Um,, it's something that we want you to put into your project and change.

So not necessarily like a gem, you wouldn't be able to change those. You'd have those variables set by default. Like these, we want you to actually just be changing. So yeah, so it's usually it's start with like when you start a project from scratch, throw that in there and change and modify those as your project evolves. And I think that's that turns into a good set for a final project. So just for those who are thinking, boilerplates, frameworks, whatever you want to call them, this isn't meant to be like a Twitter bootstrap or a Zurb foundation, it's meant to, it's meant to be like a Twitter bootstrap or a Zurb foundation. It's meant to, it's meant to be like a decent starting point for default prototyping, but

you're encouraged to change them to make it your own and be a good starting point. Yeah, absolutely. We had sort of did some prototyping on this thing called UI smash. Maybe I'm overstepping my boundaries here, but we were exploring something that would be sort of like, um, UI components that you could use in, um, your project. So something like a dropdown mix in where you could just call that and you'd have a simple dropdown, um, the CSS generated anyways, and you just pair that with some HTML. Um, so there was, I'm not exactly sure what happens that happened to that library. I think we're still developing it. And I, like I

said, when we do the company retreat, I think we need to hash this out and figure out, is this something we want to continue to push forward? Um, because you know, I still use the components. I copy them into my new projects and they they're just phenomenal starting points to get modules just built extraordinarily fast and easy. Well, so bourbon, neat, and bitters, and potentially something else. Or is that something else? Bitters. I think bitters we've extracted out, and bitters is its own thing now. So the other thing would be UI smash or smash.

So yeah. Smash. I guess that stems from giant robots smashing into other giant robots. Well, so if you, yeah, I think so. You guys are too cool, man. Honestly. Yeah. We've got the naming down on some, on some cool things.

I like that bourbon is sort of turning into, um, shooting off into like, you can like neat, right? The name of neat is you can ask for, you know, your bourbon neat or whiskey neat, which is just simply whiskey in a glass. Um, and then bitters is an ingredient that they add to, if you get like a, um, uh, whiskey smash, they'll add bitters to that to give it some flavor and so i think smash really comes from like you can get a whiskey smash or like a temple smash i think is a popular drink so it's all cool cool plays on drinks that's no that's super neat i mean i think it's i mean that's what makes i think Wynn has said this a ton of times when he hosted the show back in the day, but we'd give cool points, pluses to projects we'd feature on the Change Law because of their readme.

I think – I can't recall what it was, but somebody somehow got the DeLorean in there. And if you want to get Wynn's interest, man, do an 80s throwback um and put it in your readme somehow um as a matter of fact just speaking of win and and some things he is doing recently um you know github just released their octokit um both their c library as well as their ruby wrapper uh for their api and early you know early in the development of octokit was actually called octopussy because and it wasn't meant to be dirty development of OctoKid, it was actually called OctoPussy because, and it wasn't meant to be dirty. I mean, not, not one little bit. It was a throwback to James Bond and, you know, that OctoPussy from way back when. And it was also,

you know, you had, you know, GitHub has, you know, the, the Octo thing, you know, so it's got like legs. I mean, so that was Wynn's humor, but nobody got it. Right. And so like, yeah, that's not such a good name. And I forget who it was that helped rename it to Octokit, but at first I was like, what? That's a cool name. And then in the readme was this old James Bond poster with Octopussy and all that good stuff.

And I think in the end, it just probably wasn't the best name. But it was meant, it was no harm, no foul, right? It wasn't meant to be derogatory or dirty or crass. It was just humor. And so that was kind of cool. But anyways, so I want to ask you – there's a couple more questions I want to ask you before we tail off the show. But specifically because you've kind of – you kind of came, from what I understand, you came into ThoughtBot more on the designer side of the line,

and now you kind of straddle, if not totally stand across both designer and developer pretty easily nowadays. Is that about right? Well, I would say that's partially right. I don't really know Ruby, So, you know, since we are Ruby on rail shop, I have no experience really writing much Ruby. So I can't really jump in, um, that sort of backend development stuff. But if we're talking front end stuff and writing JavaScript, uh, coffee script, that's more what, where I sort of straddle the line of like front

end developer slash designer. Gotcha. But, you know, my role at ThoughtBot as a designer is to sort of be that. Like I do write code as well as design versus other, you know, agencies are like a designer role would just be doing like Photoshop mockups and doing design. And then you'd have your front end development development role, which they do front-end development. So sort of combining the one, but I think it makes for better design, better interaction design. And just the whole process, I think is much more fluid and you get better results when you sort of have a designer who can do front-end development. So I guess on that note, then what would some suggestions be from you to those out there

who are trying to better straddle that line, trying to get to go from their designer side to teetering on the developer side a bit more, maybe not learning Ruby, but you know, learning more about JavaScript, CoffeeScript, and, you know, kind of diving a little bit more into development, what kind of suggestions could you give to those that are listening to the show? Yeah, I'd say, I mean, for me, my knowledge about programming sort of extended from being in SAS and trying to really use the features that SAS has. So I'd say explore SAS and those advanced features

and try and look at your code and write some more advanced loops and try and look at your code and, and, uh, write that, um, some more advanced, um, loops and if statements and that sort of thing where you think they, uh, could be useful. Um, and then I would say start a side project. Um, I, I recently started a Meteor JS project and that's just helped me grow so much for, uh, you know, learning JavaScript and CoffeeScript, um, and doing it all on my own and asking the developers that I have here, any questions that I have. Um, so I mean, I think side projects like I learned by doing, so anytime I've got a cool side project, I'm always learning. So, you know, I just encourage anyone else to pick something up and start doing.

Gotcha. Yeah, definitely learn by doing. That's, you know, to just key off that a little bit. That's exactly what I'm doing. You know, I kind of surprised myself recently. I didn't know I knew as much Ruby as I did until I was like hanging out at code school, just randomly just watching some of their some of their stuff and and i'm like in the code challenges and they're like uh refactor this and i'm like i refactor it and i'm just messing around like just totally not trying to like learn or act as if i know ruby because i've always said and i'm self-deprecating when it comes to this i'm always like yeah i can read ruby but i can't write it you know and i don't know why but i would give myself less credit than i deserved uh but anyways i'm refactoring the code and i hit return i'm like and they're like congrats you're right and i'm like whoa and then i go to

the next one it's uh you know conditional logic or whatever and it's like refactor this and i'm like all right i feel a bit better about this one i'll try it and i'm like i'll move to this there this there and i'm like and i hit return and i have no idea if it's going to be right and i totally surprised myself and it's right and i'm like whoa so you know recently i've kind of gotten that same learn by doing stint myself where you know people that that uh that maybe want to learn more about programming i I think programming is super liberating, man. You can learn how to build anything if you want it, but some people, they just think, oh, that's some super smart nerd.

Only nerds can learn that, or only super geeks or whatever. Anybody can learn it. You just kind of put your mind to it and learn by doing. I think you're right on the side of projects, though, is having something super passionate that you like and you want to build. And just, you know, no holes, no bars.

Just doing what it takes to try and figure out how to learn to make it. And ask somebody. I know we had Avdi Grim recently on the show, and the topic was, you know, pair it with me and paired programming and, you know, that whole thing. And, you know, reach out to somebody like like phil said he loves to get uh you know mentions maybe maybe phil you can pair with somebody and give them some of some guidance some assistance i don't want to hold you to that but maybe maybe we'll see yeah absolutely i'd love to give any kind of feedback that that someone wants on a project they're working on or try and help someone sort of up their game for whatever it is. So totally open to working with the community.

So I got a couple of rapid fire questions and we'll tail into the final two, uh, two ending, uh, questions we have here that are, that are, uh, traditional for the Chinese law.

But, uh, so a couple of rapid fire questions, Hamill or HTML, HTML, Vim or Sublime Text? Definitely Vim. Definitely Vim.

So I'm surprised by that one. I guess maybe Thoughtbot is more pro-Vim than Sublime Text? Yeah. So all the developers, when I joined, were using Vim, and I was the first designer to adopt Vim. Nice. At the time, I was the first designer to adopt Vim. Nice. At the time I was using Coda and I reached this point where Coda wasn't doing, it just didn't have the power I was looking for.

Just, I was just felt like I was being limited, limited so hard by what Coda's capabilities were that it, the only thing that was left to do was really just move to Vim. And since I had all these, you know, Vim nerds in my office, it was like any question I did have, they were right there, like helping me with. So yeah, I absolutely love Vim. It's so powerful and I can't imagine going back to any other text editor. Nice. Are there any resources that you use besides, I guess, your comrades to learn Vim? Are there any learning resources you really thought were pretty good you could mention? I mean, I think I just really Googled for the basics of learning Vim, how to jump between

words, that sort of thing, and navigate around is probably really important. But I would say there's a lot of plugins, like there's thing and navigate around is really probably really important. But I would say there's a lot of plugins, like there's a SAS syntax plugins, which really help you. And like autocomplete ones, which help you just write CSS faster in Vim. And I don't know, I don't really have anything in particular besides Ben Ornstein. This guy's a Vim master. Um, he's got some, some, uh, pod, uh, I think there's a screencast that he recently released. Um, we've got learn prime, which is awesome for any developer that's looking to get better at Ruby. Um, I think that's, uh, learn.thoughtbot.com forward slash prime.

In that, we've got screencasts for Vim. And I think we definitely have more coming that are in the works right now. So check it out. Yeah, and I guess to pay homage to Dan Benjamin, the founder of 5x5, I just was reminded by this whenever you were talking, that he actually done a peep code called SmashIntoVim.

And if you're interested, that's a little dated, but I'm sure it's all still the same. Like Vim has changed not tons. I mean, it's, I mean, VI, Vim, it's been on Unix systems. And that's kind of one of the pluses too, to using Vim too. I know that Win has always been a huge text mode slash Vim proponent.

Personally, I use Sublime Text. I think it's pretty awesome. I like it. I mean, it works. Everybody has their own taste, though, right? That's why I love those rapid-fire questions. So a couple more. Chrome or Safari?

Chrome. rapid fire question so a couple more uh chrome or safari chrome though i wish chrome had safari's animation like smoothness and rendering because safari is like super smooth i wish they would like just have a baby right like i like i'm like you i like there's something i feel like about safari and something i feel about chrome and know, you just can't have both. And then now that, you know, I was going to ask you a bit about this, but it's I don't want to go too deep into the show. But maybe we can talk about this in the after dark. But any thoughts you might have on Blink and just the fact they, you know, they went their own way and what their plans are there. So I know you with using and doing bourbon, you've kind of got into spec a lot more.

So maybe we can talk about that in the after dark though. But next rapid fire is Photoshop or fireworks? Sketch. Sketch. Oh, there you go. But if I were to truly answer that question, I would say fireworks because that's what I used before sketch. Gotcha. And so you recently moved to sketch?

Yeah, I recently moved to sketch because I don't do a lot of heavy sort of graphical work a lot of it is is stuff that sketch can handle that's like vector-based um web sort of mock-ups yeah um yeah i'm using sketch myself and the only reason that i kind of get perturbed with it with one little interface bug if you do command option three it kind of highs the left and right panels to kind of go like a more full screen. The same concept of being in Photoshop and clicking F.

That kind of thing. When you bring them back and you kind of move your canvas around, the right hand pane is kind of jacked up. I didn't submit a bug to it, but I'm sure it's easy to fix. I like Stitch too. Yeah, they've been doing an awesome job, uh, squashing bugs recently. So yeah, I'm sure they'll get that worked

out, but I didn't know command option three did that. I've been like wanting that feature. So I wish there was a way to like go really full screen, but it just takes your current window and just gets rid of the left and right hand panel. You're still top bar is still there, but if you're listening to this, Developers of Sketch, make something that goes full screen and does that. I like getting all the interface away and focusing on the design and then being able to toggle back

and forth from tools to no tools. I agree with you there. Let's wrap up then. One thing we like to ask on the show is a call to arms it's you know what areas of bourbon and i guess even this ecosystem of bourbon so neat bitters uh smash in the future whatever comes from that you know what areas of bourbon maybe even you know just other things you might have in mind where would you like to see the community kind of help uh step in and

kind of help is it uh helping mitigate issues or just, you know, what is it that, that, uh, bourbon and what you're working on could really use in the community? Yeah, I think it's definitely issues and pull requests. Um, because there's some, I've got some pull requests right now that I just don't have a clear answer to, and I don't want to, I don't want to, you know, take the pull request and implement it into bourbon if it's, I don't know if it just doesn't feel right. So I think take a look at the pull requests and provide feedback because that's really going to help me get a better understanding of what the community wants, um, and how I can, you know, get that integrated into bourbon and same with issues. There's some issues that are sort of outstanding. Um, that would be nice. Um, one particular place, um, that's already in bourbon that that would be

nice to get some help with is the button mix in because it's a little bit, you know, it could use more button styles and, uh, it could use some cleanup too. So that'd be pretty awesome to get someone to, you know, submit a pull request to that. Yeah, absolutely. Well, we'll definitely have links to Bourbon, both Bourbon.io as well as on GitHub. So if you're listening to this, help. Squash some pull requests, or not so much pull requests,

but give some feedback to issues. And I know how helpful that can be for sure. So another cool question we like to ask as the tail end usually is, and you can answer either of these. I guess I'm going to ask you two questions technically in one just because you're a designer primarily and straight on the line of hacker and developer. So normally the question is, who is your programming hero?

But I'll ask you both, who is your programming hero and who is your design hero? So I'll start with design hero. Recently, I think Brett Victor has been doing some amazing stuff. Just those Vimeo videos that he's released about, you know, really how like, you know, he seems like this interdisciplinary designer that really steps into the line of developer, but also understands like so much more, like, you know, he has all these like crazy math equations in these demos that he's showing and just really shows how like, you know, as a, as a user, you can have, get a much better understanding of a system when you can directly input and manipulate that system

in like a visual way. So his stuff is just kind of blown, blowing my mind lately. And I think blowing the design industry's mind lately. Um, and I would also say for design hero, I think Drew Wilson, I know you, you, you mentioned him earlier, I think he does an awesome job straddling that same line of being designer developer because he had released, what is it, Spacebox? Spacebox, yeah. Yeah. So I think I'm always really inspired by designers who can actually develop applications and write code as well. So he is definitely on the list of someone I always keep an eye on for

projects. He releases, um, programming dev hero. Um, I would say probably everyone who's contributed to SAS. Um, SAS is just,

you know, my sort of, it feels like it's a good saving grace for CSS. So, you know, that's like Chris Epstein, Nathan Weisenbaum, all the way, you know, back to Hampton, like just anyone who's had their hands in contributing to SAS. Thank you. That's awesome, man. And speaking of Hampton, June 25th, we're actually going to be joined here on the Change Law, June 25th. Hampton was going to come on this week, but due to some travel stuff, he wasn't able to tie it up. So I thought it would kind of be cool to have you on, Phil, as kind of a preamble before Hampton, just maybe to tee off our little SAS fiesta for the next couple of weeks.

So we'll have you on this week, obviously, which we're doing. And then not next week, but the week after Hampton will be on the show. So if you're a listener of the Change Law, Phil, you should tune in. I actually met Phil. I also want to give a shout out to one of the coworkers that you work with, Joe Oliveira. He's a super neat dude man i met him at um at less conf and i also met hampton and super rad dude both of them and uh um yeah joel does a really good job of representing who you guys are as a community and who you guys are

is uh as a team there at thought he does a great job and then well thanks And then, well, thanks Adam. Yeah, man. And Hampton, dude's crazy, man. I love Hampton. He's awesome. I can't wait to have him on the show. He's going to be such a, such,

such fun, but yeah, for sure. All right. Well, that's, that's pretty much the show. You know,

Phil, I want to thank you for, for joining us today, man. It's really fun talking about SaaS, bourbon, neat design, CSS,

and everything in between, sustaining open source. You know, I want to personally thank you for, from the rest of the SaaS community for your work on Bourbon and your support, and just kind of being knee-deep in the specs sometimes and kind of being in the trenches, for lack of a better term. I mean, it's really awesome to have you on the show, man. Yeah, well, thanks, Adam. It's been a pleasure.

Thanks for having me. Absolutely. And so having me. Absolutely. And so follow Phil on Twitter. He is Phil LaPierre, full name, L-A-P-I-E-R, if you don't know how to say LaPierre. This has been episode number 93. I did mention that we'll be joined by Hampton in a couple weeks. We're not sure of who next week's guest is.

Andrew, I think he's taking care of that. So next week's guest has got a question mark next to it if it's you can't wait to talk to you uh show notes for this show will be available at 5x5.tv slash changelog slash 93 thanks for tuning in to this show We'll see you next time.