The Changelog: Software Development, Open Source - Haml, Sass, Compass (Interview)

Episode Date: November 19, 2009

Natalie Weizenbaum and Chris Eppstein joined the show today to discuss Haml, Sass, and Compass.

This is ChangeLog Spotlight for Wednesday, November 18th, 2009. I'm Adam Stachowiak. And I'm Winn Netherland. We've got a great show for you today. We interviewed Nathan Weisenbaum and Chris Epstein from Hamelsass and Compass fame. Since it is the first podcast, why don't we introduce ourselves, Adam?

Yeah, I'm Adam Stachowiak, as I said before. I'm a designer developer. I run a web development company called Handcrafted. You can check that out at gethandcraftcrafted.com I also produce a podcast called The Web 2.0 Show You can check that out at Web2OShow.com And I'm also on Twitter And I tweet as AdamStack

How about you, Wynn? My name's Wynn Netherland, as I said I'm a designer and developer Trying to figure out which I've been doing this, I guess, since 1996. I think the way I got into this was Netscape Composer way back in the day. So I've been at this quite a while. I blog at winnetherland.com, that's W-Y-N-N, netherland, like the country, dot com.

And a tweet at penguin, P-E-N-G-W-Y-N-N. So let's talk about Hamill, SAS, and Compass. Yes. I know you use these projects, as do I. Yeah, been using Hamill for about a year and a half now, SAS for about nine months, and Compass for about six. It's kind of hard to talk about any of them without talking about the other two.

Yeah, it sure is. Got a favorite? I kind of take them all at once you know i would use sass and compass without uh hamel as we do with you know with the wordpress compass gem but um yeah i think all three at once is good but the two independents are fine as i've told you, I came for the Hamil and stayed for the SAS. Right. Talking to Nathan, the productivity gains are linear with Hamil and the way that you can craft some HTML markup pretty quickly, but with SAS, it's really exponential in the maintenance, ease of use,

and just the performance gains you get as a developer using SAS. And then Compass kind of sits on top of that and really integrates a lot of the popular CSS frameworks. And you can even roll your own framework and bundle up your own style sheets and patterns that you take with you from project to project and get some reuse across all your projects. It's an if-you project.

Yeah, absolutely. Yeah, well, one of my favorite things with Sass really is being able to use mixins to abstract things out and not rely on presentational-based selectors inside of my markup. I think the indentation. It's kind of hard to

get excited about white space, but the indentation and not having to repeat those selectors, those parent selectors in your writing CSS, just saves a heck of a lot of time. A lot of people really get excited about dropping the curly braces and the semicolons. That's okay for me, but it's that indentation that really saves me a lot of time. It helps you organize things a lot better, I think. Absolutely.

And for Hamill, for me, like you'd mentioned, productivity, but I think really comes down to maintenance. Like as a Rubyist or a Rails guy, working with a Rails project, you jump into somebody else's ERB view and really just jump into a mess. Whereas with Hamill, you have some rules that you have to abide by. It's white space aware, indentation, provides the hierarchy. And that's what I really cling to is the maintainability it allows me to achieve. And when you hit that Command-U and View Source, it's just absolutely gorgeous. The perfect indentation. Yeah, absolutely. I guess we should probably

let Nathan and Chris tell it best, huh? Let's get to it. Alright. Chris, why don't you go ahead and say hi? Hello, everybody. Hey. Hello. And we also have Nathan.

How do I say your last name, Nathan? I'm sorry. Weisenbaum. Weisenbaum. Okay. That's right. And since this is sort of a podcast on Hamill, SAS, and Compass, I'm not really sure where we should start,

but since I guess Hamill and SAS came first prior to Compass, let's maybe intro with Nathan. Kind of tell us who you are, what you do. Give us maybe a quick 30, 40-second intro of who you are. All right. I'm a student at the University of Washington in Seattle, studying computer science and philosophy. I've been working on open source software and Ruby for a little more than three years now, and almost all of that time I've been a developer on Hamill and SAS. I was, I think, the first person to submit a patch to them when they were announced to the public in fall 2006 by Hampton Catlin, who's the original creator. Right. Definitely a big shout out to Hampton, too. He's awesome.

Yeah, Hampton's great. Although he has a little trouble following up with the stuff he starts. So that's where I came in. Once he finished with Hamel, he handed it over to me. This was three or four months after he started with Hamel. How old is Hamill? Maybe give kind of a quick timeline to when this sort of happened. Yeah, it was about three years old.

I think it was in development for a week or two before it was announced publicly. So, yeah, it was announced in, I think, September 2006 when I started submitting patches. In, I think, November, I took over the main development duties, and Hampton went into a more design role. Then I think later in 2007, at some point, Hampton came up with FAS, which I then implemented. And it's grown from there. Awesome. So when I was new to Ruby and Rails development,

and I'm not sure how many of our listeners are going to be familiar with Ruby and Rails, but when I started in Rails development, there was a lot of things that I thought were cool about Rails that I later found out were just cool about Ruby. And so I came to SaaS development through Chris's project, Compass. things that I thought were cool about Rails that I later found out were just cool about Ruby. And so I came to SaaS development through Chris's project, Compass. And so as I dug into it, I found a lot of what I thought was cool about Compass was really just SaaS underneath the hood. Chris, why don't you tell us where Compass fits in to the whole ecosystem and what it aims to do in extending SaaS. Sure. Let me just introduce myself a little bit. Yeah, I was going to say, we should probably insert Chris, because we totally went right from Nathan's intro to, hey.

That's cool. So I'm a software architect, or the software architect at Caring.com, which is a Ruby on Rails- based website for people who are taking care of their parents or loved ones who are sick and um came to find hamil and sass um when they were at the basically 2.0 mark um and so i've been using them for about a year and a half now. And as I was, we were a Blueprint site before we switched over to Hamel and SAS. And so it was very natural for me to want to port Blueprint to SAS once we got over there. And Wynn's acknowledgement or recognition

that everything cool about Compass is SAS is absolutely true. I don't see Compass as being anything terribly special. I was the first one to basically see the value that SAS provided to a development approach and to a certain way of thinking about design that was new and unique. And I decided to lead the charge in that direction. If I can butt in, I think you're being a little too modest, Chris, because a lot of what makes Sass so cool, the new features in 2.2, were driven by what Compass wanted to do. So while that cool stuff is part of Sass now,

Compass was a major force in causing that to happen. It's definitely been this really interesting co-evolution. I will admit that. The concept for mixins already existed. I think that was a 2.0 feature. And so when I saw mixins, it just blew my mind because all of a sudden I have this new way of encapsulating patterns that I see in design all the time but i don't have but i hated

the way that like blueprint especially would force me to put my presentation in my markup i thought i just felt that gave me such a fragile application that was hard to change and hard to manage right that wasn't uh wasn't blueprint sort of what kicked it off for you to start Compass? Yes. I mean, so I started – I ported Blueprint over, and you can kind of find an evolution of my thinking and my work. If you just look online, you can see there's a Blueprint SAS project, which was just a simple port of Blueprint to SAS, and that definitely drove SAS to have some new language features

and iteration and variables. It had variables already, but you couldn't put them anywhere for building your own selectors and things like that. And so I worked with Nathan to kind of develop some new syntax for expressing frameworks in SAS instead of just CSS in SAS. So when did you actually step into the mix with Nathan in kind of co-developing the SAS part of, I guess, the Ham1SAS gem? When did you step into the mix? It's hard to say.

It was kind of over time. I just kept submitting patches for things. But Nathan still does a good majority of the development on SaaS. I have my hands quite full with Compass. But definitely we work together on every new language feature that comes out um and talking about what the syntax should be and what the apis should be and things like that gotcha so um go ahead nathan if you got something to say please go ahead i was just going to say that I think you officially became a member of the core team at the end of summer 2008. Does that sound right?

Yeah, it's probably been about a year. Compass had been going for a while, that's for sure. I'd been working on Compass in one form or another for probably six months. And now how many CSS frameworks are you guys supporting in the compass project? In addition to blueprint. Oh, geez.

Um, there's blueprint. Y U I and nine 60 UGS. And, um, those are the ones that I've ported myself. And then there's a few more that have come out that have been ported. I think the most notable one is the SUSE framework by the Meyer brothers,

and they've done a great job building a very nice framework from the ground up using thinking about Compass and about SAS and the features that are provided there. I still don't think we've done a good job at describing what Compass is. I always have a hard time trying to describe it myself. I don't really know. I'm not really sure where SAS starts and Compass ends. I guess in some cases you do, but I often forget that a mix-in was a natural feature of SAS. But I would just describe it as a feature of Compass.

Because I'm sort of late to this game. I've been using SAS maybe, i don't know maybe maybe six months nine months maybe i would say that sass ends where the project begins so the sass encapsulates the concepts that are that are within one file um and you know it does definitely allows you to import other sass files and things like that but um compass tries to give you a whole project management set of tools things that understand that you're not working on just css you're you have images and you have javascripts and you have html files and all these things have to work together and the other big aspect of compass is you know it's exactly what i saw in the very beginning when i started working on

this stuff which was hey here's a here's a thing that's a language that lets me share css basically and lets me share my style with other people and so the vision of compass from the very beginning was not just a framework for building your style sheets, but a framework for building frameworks for building your style sheets and to create and foster an open source community within the design community. And so the feature sets that I've been working on and I'm most excited about are coming out in subsequent releases to really make it simple for designers to share their styles with each other and create plugins that are very simple to use and to share. That's actually what got me really excited about it. I didn't quite think about the whole packaging, the framework part of it up with Compass, but it's really cool because something that Wynn and I actually recently worked on, which was called Compass WordPress.

It's essentially just a simple gem that allows you to easily use Compass with WordPress. And the simplest way, I guess, it does – Wynn, why don't you – since you're more of the writer of it, I kind of hate a lot of the SAS porting and stuff like that, but you really wrote those nitty gritty pieces of the gem. Maybe just kind of quickly talk about that. It's really just a simple project template that you get out of the box with Compass. The SUSE framework that you mentioned earlier was a great model for us to base it off of, but essentially we have a like for the thematic WordPress framework. And so when we tend to do WordPress development,

we look at extending WordPress by writing thematic child themes. And we thought, you know, there's some repetition that we're doing project to project, not only with unfolding these themes, but unfolding the same basic styles. And Compass was just a great fit because it plugged naturally into our workflow to be able to generate these new themes

and then have Compass run in the background and compile our SaaS style sheet. So it just worked out great. And the cool thing about it, you know, there's no Ruby in the WordPress project. Yeah, and the Compass watch was a really a big win. Sorry, not the, yeah, the compass watch feature was really a big win there because you know,

you can have, like, I think it was just awesome to, to kind of decouple away from a Ruby based project and actually not have to have compass, you know, auto compiling, I guess that's,

that's kind of a different thing, but the fact that it can actually work with just plain old standard HTML, that's ingenious, to be honest with you. Yeah, that was definitely another goal of the Compass project, which I identified quite early on there that SAS was awesome and it deserved to live in any kind of project, not just work with Ruby projects. Of course, if you're using a Ruby project, you're going to get better integration than you would have otherwise. But since Sass is a build time compiled kind of approach to building CSS, it can work with.NET, it can work with Python, it can work with WordPress, whatever it is that you're doing,

you can build your style sheets using this new, more powerful syntax. I love that flexibility. That's awesome. So we have both you and Nathan on here, and we had a little side call earlier with Nathan, but I want to kind of pull that into the mix. And the question I asked Nathan, and he was really, really passionate about talking about it, was how you guys sort of worked together.

I wondered how much you and Nathan actually have to interact to keep the SAS Compass engine development, all that good stuff, rolling. Well, as Chris mentioned earlier, for any of the language features, we talk about them, figure out what the syntax should look like, what the API should be, that sort of thing. We both have a lot of input into how the language evolves because as part of developing SAS, we want to make it so that Compass can do

what it does as easily as possible. And also, I mean, we spend a lot of time talking about, well, how can we make stuff easy enough to use for designers? And I don't mean that in any sort of derogatory way, but designers aren't programmers, and we shouldn't think of them as such. And so we spend a lot of time wondering, you know, how do designers approach certain problems and thinking about them and try to make the APIs meet them where they are

instead of make them think like programmers. Yeah, and to that effect, also, we try to make the tools for dealing with Compass and Sass accessible to people who aren't programmers, who may not be using anything related to Ruby. There's been sort of a struggle to convince people, no, you don't really have to have Ruby know how to program in Ruby or be using Rails to deal with Confidence Sass. A lot of people present it as a Ruby CSS compiler, or Ruby CSS framework, and that's not really accurate, because it's a CSS compiler that's implemented in Ruby,

but it can be used anywhere. So we talk about how to make that use easier, how to sort of get the word out that it doesn't have to involve Ruby. Well, at the heart of SAS you have, what is the SAS script, I guess? That's probably the closest you get to delving into some programmatic kind of, I guess, philosophies in the SAS part of it. Well, so I mean, so SAS does have some ability to do some programming built into the language, but it's not Ruby. The syntax actually has very little to do with Ruby at all. So it's just there. I think we actually consider JavaScript more of the, at least I do,

more of the influencer for that language than anything else. So what are some of the, I guess, core things that Sasscript allows you to do? Well, I mean, if you want to be very technical about it, Sass Script is only the portion of Sass that gets evaluated when you have like an equal sign or you're assigning a variable to something. So it's really just a way of concatenating together variables and modifying colors and stuff like that. So, I mean, that in itself can be reasonably powerful, especially, like, with Chris's Compass Colors plugin that allows you to do color theoretic manipulation

to the color object you have. And so, say, like, make this color lighter or more saturated, you know, make it change the hue just this amount, that sort of thing. That's going to be merged into SAS for version 2.4. And that's really powerful. It allows you to do themes and all sorts of color-related things that you couldn't do otherwise. I think there's another SaaS plug-in that uses that, something about buttons that allows you to create all sorts of cool-looking buttons easily because it uses these colors. So that's powerful.

Brandon Mathis made a project called Fancy Buttons. It's on GitHub. Yeah, that's it. Yeah, I had a chance when I was out at Les Conf in Jacksonville, Florida, which was awesome, by the way. If you get a chance to go next year or even go on the Les Cruise, I would encourage you because my good friends at Les Everything, Alan Branch and Steven Bristol, really knocked it out of the park.

But I was there, and I ran into Brandon, like really accidentally, actually Alan introduced me to him and, uh, and I was, uh, just sort of got stuck talking to him about, I guess stuck is a bad word to use, but, uh, we just sort of, you know, we sat there for probably an hour and a half, just literally chit-chatting about how excited we were about SAS and Compass. Like literally, it was insane. So yeah, Brent is a – he's a really smart guy. I like what he's done. I feel kind of like we've gone a little farther into this podcast without really properly introducing Hamill, SAS, and Compass.

Do you feel like we haven't really properly introduced all of them? I'm not sure. It's a little hard to explain without sort of putting them up in front of people because so much of what they're about, especially for Hamill, is the aesthetic, what they look like and how it feels to work with them. But, yeah, I'm not sure what a better way to introduce them would be. One thing to point out, I guess, is that they're all white space aware languages or syntaxes. And so the amount of indentation you've given your code matters uh so in haml when

you indent a tag under another tag that's like that tag is is embedded within the other tag and out denting um will close the tag automatically so you can't generate invalid HTML that way. And Sass has the same concept. When you indent a selector within another selector, what you get is a nested selector. Now, CSS doesn't have such a concept, so Sass bridges that gap by generating another selector that includes the previous selector in its context. One thing that I like to do is show rather than tell, especially with my designer friends that may not be that into the programming side of what Compass can bring to the table. And I think a lot of the success of Compass is what it's also done for the CSS frameworks that it supports.

So CSS frameworks came onto the scene within the last 18 months to two years ago. And there was initial excitement about them, but some backlash that I saw was the fact that a lot of people didn't like, as you mentioned earlier, Chris, of having to litter your market with presentation details for things like, you know, grid 8, grid 9, or span 8, span 9, column 8, column 9, whatever your CSS classes happen to be. So what I like to do is just show my designer friends what Compass does and the fact that now you can take this grid framework, use it in a semantic way because now you just mix those properties into your semantic selector.

And it removes a lot of the barrier to entry for folks to really jump into a CSS framework and begin to reuse some of their styles. And then as we progress through the discussion, I usually show them that that's all powered by SAS under the hood. So perhaps you can talk about that, if that's usually the number one selling feature of your framework. I hope it is. What I like to imagine is that I think one of the biggest critiques that I hear over and over again about SaaS and about Compass is They're like, well, CSS is so simple. Why would you need to make it more complicated?

You're just doing it because you're a programmer and you don't get it. And the problem is I do get it. I've maintained huge websites with huge amounts of CSS, and it's a pain in the ass. Well, caring.com, can you talk about how many just quickly, how are you allowed to share how many visitors you guys get in a month? Even estimates?

I can't share that, but it's considerable. A lot, right? A lot. Enough. Okay. And, I mean, but the thing about startups especially, I think, is your design changes style bleed, which is because you create some class and you tend to share a style sheet across many different templates. And now all of a sudden, that class name, you didn't quite mean it for it to be reused between two pages. But it was natural to use that class name. And now you've got styles mixing into other classes incorrectly. And SAS just makes it as easy to keep those things separate as it should be because you just indent, and now you're fine.

And you can go overboard on this because there is some CSS bloat and performance penalties to being too selective in your selectors. But it's made our website, and I would hope that other people agree, just easier to maintain on a long time frame than it would have been otherwise. So a sure sign of success by both of these projects is the rise of alternatives out there. So in a civil way, I'd like to discuss maybe some distinctives between Compass and SAS and other frameworks like less CSS and XCSS, if you guys want to speak to that for a moment. Sure. Well, so SAS is white space aware syntax, which is rather different from the CSS syntax on the surface, arose because it was the sister project to Haml, which was white space aware and which was focused on improving the aesthetics of writing HTML. So originally, SAS was focused on the same thing for CSS,

making it prettier. And it was focused on a certain sort of people who found this indented, white-face-aware syntax prettier, and that was fine. But as SAS grew, it became focused more and more on these ideas of abstraction, of making it easier to generate more complicated CSS without having to make the source complicated. And I think the fact that other CFS generators are popping up all over the place now, I think there are maybe a dozen of them at this point that I've heard of, it speaks to the power and the utility of the idea of abstracting your style sheets because what these other compilers offer is the same sort of abstraction that TAS does

without the syntax because a lot of people don't like the syntax. In fact, I think the less about page states that explicitly. It has a section, why not SAS? And the answer is the syntax. So I think the fact that there are so many other, I suppose, competitors out there says that the idea of making abstractions for style sheets is important and useful. They almost to a one use curly braces and semicolons rather than indentation, suggests that a lot of people prefer it that way, which is why in SAS 2.4 we're going to support a syntax that is a superset of CSS for people who are more comfortable with that. I think another important thing that these other compilers have to offer is different takes on this idea of CSS inheritance,

which I think Chris knows more about than I do. And that's a segue, I guess. Go, Chris. Well, I wrote a blog post about it on my blog, chrissepstein.github.com, where I talk about how inheritance, what it is, how it works. It's basically this concept that you can have a CSS class that inherits from another CSS class, and wherever you would refer to that class,

it would kind of automatically adjust your style sheet selectors to match. And it's a really obvious idea if you see it, and there's some great examples in my post, and I don't think this is a good place to explain it, but Nicole Sullivan of the OOCSS project is leading the charge on trying to get people to adopt this object-oriented approach to CSS.

And the thing that she and I both agree on is that it really needs to be in the browser for it to be effective. It's just, there are too many edge cases where it falls apart, either by forcing leaky abstraction. If you don't, without the browser support, you have what I consider to be a leaky abstraction, because everywhere you put the class, you also have to put all of the base classes in your markup, and that's just really awkward. All right. Sorry. Go ahead.

It's all right. But I wanted to go back a little bit to the syntax issue. So I want to tell a little story. Let's rewind about four years ago maybe four and a half um i was in the market for a new programming language and i wanted to learn a new scripting language i've been mostly programming in java at the time and i knew that python and ruby were these two languages that were hot on the market and um and that were probably i was gonna i was really trying to decide between one and the other um and i so python was weird because it was white space aware and that was like

ridiculous um and ruby was horrible because it used begin and end um all over the place and i hated seeing all the that verbosity. And in the end of the day, what I ended up deciding to do was learn Python, but I was going to write a pre-compiler so I could write all my Python with curly braces and then translate it into Python with whitespace. So me and a buddy worked on that project for a while and then we gave up because what we found out was in like a day of programming in Python that it didn't matter the white space actually was nice because i was indenting anyway and

but the end of the other interesting thing that i wanted to point out about that whole thing was i ended up picking python over ruby and the reason was like, well, if there's two things I don't like about a syntax, I should at least fix the one that had less typing. But these are just completely inane reasons for picking languages. Ruby offers like crazy concepts that Python doesn't offer. And I just didn't even think about that when I was picking my language. I looked at these aesthetic issues and I made a decision based on those, not based on the power that the language provided. And I get it. I've been there, I've made that mistake. And the reason that you see SAS moving in the direction of allowing other syntax options is that it shouldn't be an issue for people, that if people want to use a better

syntax i still think that the white space aware syntax of sass is better it's less typing and it's more readable um then you should be allowed to do that but we don't want it to be a stumbling block for people um we want them to discover the power of abstraction and see how it can make their life simpler. So you're saying that this more CSS-like syntax is not going to use the whole white space aware indented model? Is that what I heard? What we're thinking right now, and this isn't what we thought originally, but Chris was pushing for this pretty hard, and I think it's probably the right way to go at this point,

is that we'll have two separate syntaxes, one of which is a superset of CSS and one of which is whitespace-aware, although we may make the whitespace-aware one a little more CSS-like in a few certain ways. And the reason for that is that, well, partly it's just that there are some serious problems with ambiguities once you start having a syntax that's supposed to be both whitespace-aware

and completely compatible with a non-whitespace-aware syntax. Because we would want to be both backwards compatible, both with SAS and CSS. And that just presented too many parsing difficulties, figuring out what the comment and where the comment ends and where the selector ends and stuff like that. I mean, it wasn't possible to do it completely accurately all the time, which meant we would have had to guess. And then inevitably that guess would have not been what someone was expecting at some point. You know, that's a good segue into talking a bit about how, as community leaders, you guys take feedback from your users because I assume, Nathan,

you've got a community that exists outside of the Compass project, and Chris, you've got feedback coming from users of your framework. How do those get called into lists of features that ultimately make it into the project? Well, I mean, in general, if anyone suggests a feature to me on the mailing list or where I am or even in person if I'm going to a conference or something. You know, if it makes sense and, well,

I'll give it a good chance to get it right. There are a lot of times when people suggest features, especially for Hamill but also sometimes for Sass, that are sort of additions to the syntax for very specific issues, like rendering in a certain way. And most of the time for that I say, make it a helper. Because, I mean, making the syntax more complicated is just adds stuff for people to learn. So whenever possible, I try to let things be implemented as helpers. For SAS, that doesn't happen quite as much, possibly because the people coming into it aren't programmers.

I mean, often people will just ask, like, can I have this extra option or, you know, can this behavior be tweaked? And sometimes it's not backwards compatible, so I have to say no. Even if it might have made sense at the beginning, there have been a few times like that. But I think most of the time when someone wants a feature, it gets in because I mean, most of the time it's just not very hard to add. I think I'm tooting my own horn here a little, but I think the code bases are my own horn here a little, but I think the code bases are reasonably well organized, or at least I know where everything is. So making small behavior changes when they make sense is pretty straightforward.

Yeah, I would agree. I would say that Nathan and I are both pretty obsessive about our user support habits. And I think that's pretty important to having a successful project. um you know i'm i'm relentless about checking for people talking about it on twitter and i um i really want people to to give me feedback all the time and um and i think it's important to respond quickly um and i think nathan nathan is actually a bit of my my idol in this respect um because uh i have a day job um and he he just has to go to school i just have to go to school um but you know the other day i think someone asked for a feature for hamill and he had it built and shipped and on the master branch within like a few hours or something um so that's the kind of like superior user support user support that you can get from great projects like Hamill and SAS and Compass. You also have a family too, right, Chris?

Yeah, I have a wife and a daughter who's four years old. So that must mean that you have even less time for – it takes more of your time away from them having to be this relentless person and obsessive, as you mentioned. Yeah, it's a real balancing act. I kind of tend to balance it through a cyclical aspect where sometimes one of the three or four aspects of my life is getting starved. But not for very long and then I move to the next one. As opposed to trying to keep everybody happy all the time. So both projects have a fairly active mailing list and those are hosted on Google Groups. What's your experiences with

using that and how does it help you maintain the community? Is that sort of the core area where the community is maintained or is it kind of spread across various social networks and the lists? Well, as far as the actual, you know, very active communities for Hamill and staff and Compass, too. I think they mostly revolve around the mailing list. I mean, there's also the IRC channel, and it's where people tend to come for help. There are all sorts of avenues where people will ask for help. And part of the difficulty of trying to keep up this good user responsiveness is paying attention to the blogs and Twitter and Stack Overflow and the IRC and just anywhere people might say, ah, Hamill's being bad or Sassy's being bad.

But the Google group is where most of the development takes place, or the community interaction. And that works pretty well. I think John Refig had a blog post a couple weeks back about problems with Google groups with spam and stuff like that. That's definitely an issue. Chris and I have to go through and clean up spam from the pending list every day or so. That's kind of an odd problem for Google groups to have, right?

Because Gmail, Google Apps, the whole mailing thing has such awesome support for spam. Yeah, it's ridiculous. You have no idea how much spam if you're on either of those mailing lists I keep you from seeing. Well, thank you very much for answering that. I think that even with a blog, too, if you see spam comments,

it's just a sign of a bad maintainer. And really, it should be a software that solves that problem, and it's really sad to see that as an issue. Yeah. Another thing about building community, it's actually still a work in progress, I would say.

I think SaaS especially is still quite young as a technology and is still maturing in this respect. And in many of these projects i see form especially ruby projects because the ruby community is so great at using and contributing back to open source i see them you know one developer gets out ahead and builds something great and then 50 developers contribute and you have this awesome project with tons of features in like no time flat um that it's been a more of a challenge for me with compass because my target users are not the programmers who can um actively contribute and so uh i i've been just doing most of the work

myself um you know i a lot of the style changes I leave the style sheets for the most part to the community because that's what they're great at. And frankly, it's not my strongest suit. I understand CSS and browser quirks and things like that. But building, I'm not a designer, I'm a programmer. And so, you know, I'm always open for new suggestions about how Compass and SaaS can grow as a community. And I hope that the listeners of this podcast will jump onto the mailing list and make suggestions for how we can do a better job at fostering community. Yeah, absolutely. We'll definitely include links in what we'll call show notes, essentially.

So we'll have links out to both your guys' blogs. Nathan, do you run a blog? If you do, I don't think I read it. Yeah, it's next-3.com. Okay, all right. So yeah, that's kind of crappy that I don't even read your blog. My bad. But we'll definitely have links to the groups and also the – we link out everywhere. We need to put it that way.

Twitter, all that good stuff. So we were talking about community, I guess then in what ways do you guys work together to, to kind of foster community? And what ways do you reach out and try to grow the community? Twitter and get hub have really been the two most important technologies for me, I think. I've been relentless about checking Twitter and replying to people on Twitter

and trying to make it easy for people to contact me and get feedback about stuff. But GitHub was critical in the very, very early days of Compass, where I didn't actually set out to build what I built. I started out to build a little simple set of SAS files. I just wanted to share some SAS files. And I didn't have a good way of doing that, and so everything just evolved out of that. But I didn't even know, you know,

I wouldn't have put all the time and effort into it if it wasn't for the really easy feedback mechanisms that GitHub provided. First and foremost, I think I had 20 watchers of Blueprint Sass, which is the first kind of iteration of Compass, within like a week. And I probably released 20 projects before that, and none of them had ever topped 10 watchers. And so the very nature of the demand from users was able to kind of give me that immediate feedback

about, hey, this is maybe where I should spend some of my efforts if I really want to have an open source project that's successful. Yeah, I think the ability to get feedback from the users is really important because a lot of what drives, at least for me, what drives my desire to contribute to open source is the idea that I'm helping people and I'm making people happy with the stuff I do. And early on when I was just beginning to contribute to HamlineFast and I was just beginning to be the lead developer on them, the fact that people kept saying, this is really cool, I'm glad you're doing this,

that sort of made it so much fun to work on these things, rewarding. And I think, as Chris said, GitHub and Twitter do a good job of helping you see people who are using your code and enjoying it. I think one thing, going back to your original question about what we're doing to help the community, I think

one thing that helped a good deal was creating a SaaS website. Before 2.0 was released, sorry, 2.2 was released, all there was was a Hamill website that, if you dug deep enough,

mentioned some things about SAS. And that was not a good way to be in terms of making SAS visible. So for 2.2, I put up a SAS website which mirrors the Hamill website with different colors and the logo, that sort of thing. And I think that's helped put TAP out there more in the public eye and as something that distinks from Hamill as well.

And that gives people something to link to. It gives them a place that says, here's where different aspects of the community are. Here's the mailing list where you can talk to the IRC where you can ask for help, that sort of thing. I think that's helpful. Yeah, speaking of websites, the Compass website is atrocious. We need to change that. Well, here's what gets me.

We had some chat on the mail list. Jeez, like summertime? Yeah. And we had screencasts being prepared. We had a website being designed. Forgive me if I sound like I'm yelling about it because I actually haven't stepped up and said, hey, I'll help too, but I certainly would.

But what's going on? I'll take some blame as a failure to lead. Frankly, the next big release of Compass is going to be so different. The command line tools are dramatically easier to use and have different syntax options and things like that. And even some of the main libraries have been reorganized. And so I haven't been eager to push for documenting and building out websites that before I felt like the tool was quite up to snuff.

And so, and this release has just taken a little bit longer than I would have liked. So I think what you'll see is I'll step up and start really pushing that development in the coming months after I get this next release out. And then I'll have more time to devote to the website as opposed to the code. And, you know, again, it's just simply because I'm just time limited. I don't have enough resources. Of course, yeah. I mean, you have a day job.

You have a family. I mean – If people were to step up and start, you know, building websites for me, I wouldn't stop them. For those of you that are new to the project, the website is compass-style.org. And if you click the Learn link, it takes you to the wiki over on GitHub, and that's the primary resource for the project right now. And you might want to mark off a couple of days on your calendar and just peruse those documents because it's a lot of good stuff in there. Not only that, but I also pulled on the gem and just do something I didn't do, which is what you immediately do, which is just dive right into the actual gem code

and look at all the various frameworks that come as part of Compass and learn what mix-ins are naturally there and available to you. I was an idiot and I went and recreated the float mix-in. I went and recreated stuff that was already part of compass because i was i didn't do my due diligence what i'm trying to say yeah and it's and it's hard because i think compass is is um woefully under documented um and so it's it's hard for you to know that that stuff isn't there. And I really hold the prototype website up as far as a beacon of great documentation because they have a lot of the same audience target.

And so I think we can definitely do better there. And I hope that we will soon. I've been thinking about how to approach that problem. It's hard to document SAS. For the prototype project, they had to build their own source code documentation tool just so they could document JavaScript. And so we've been thinking whether or not

we have to do something like that for SAS as well. Yeah. Well, something that comes along with the website too is this whole notion of sharing extensions. And so I guess the the dreamer in me uh you know wants to see you know shared extensions like i when i gave a small presentation at um at uh bar camp jacks in jacksonville just after les conf and you know i had this idea that that well it wasn't my idea of course but i had this notion of saying much like Apple says there's an app for that, that there will be an extension for that.

Like if you have a need for a certain kind of navigation system or navigation styles that you'll see an extension for that and possibly even, like you said before, touch on delivering HTML files too or any other necessary files. Much like the extension site for Radiant CMS or the Spree e-commerce project, it'd be nice to be able to pull down these extensions and have some sort of repository to pull them from. Definitely, my plan is to build

an extension repository on the Compass website and allow it as the central kind of place to get a list of what's available and how to make sure you can download it and things like that. And the Compass command line tool

will interface with that seamlessly. Gotcha. Is there anything else you guys want to make sure we hit before we wrap? I guess there's a lot of cool stuff coming in SAS 2.4. Not just new syntax stuff, but we're hoping to get optimization in there so that the produced CSS will be a little less bloated. Okay.

Chris? Definitely just would love to see more community. I think the thing that gets me excited about Compass and SaaS is just that I think we're approaching an open source ecosystem for design. And I've never seen that before. Maybe else, maybe someone else has seen it, but, um, that's, you know, I'm, I'm an open source geek through and through. And I love, I would love to see that, um, the, the huge wins that come from having that ability to stand on the shoulders of giants and open source, um, come to

design. So one, one last question for you both, and this is to put you on the spot, but other than your own projects, and I'm going to pick on Nathan first, what open source project out there excites you the most? Oh, gee, excites me the most. I'm really excited by what's going on with LLVM. The idea of a standard compiler back-end strikes me as very cool. A lot of the front-ends that are being developed for that promise to make working on compilers easier than it was with GPP, which I think is also a great piece of software,

but is getting old and somewhat scruffy. Yeah, I like a lot of what's been going on with the open source browsers, Chrome, Firefox, just towards making

the web better, supporting HTML5, making JavaScript faster, that sort of thing. That's really exciting, just in a sort of broad sense. Awesome. Both good ones. Chris? The one project that has had me most excited lately is the C testing framework which for people who aren't familiar with it allows you to write kind of text files that describe how your project should work and then map those to code that runs to make sure your project works that way and you know, for people who are into test driven design of their software, um,

you know, they've been singing the praises for years and years of that. You should be testing your code before you write it. And I'll just be real honest with you. I found it cumbersome and painful. Um, and, and so I just have never been able to get behind test first, even though I wanted to do it. I just couldn't get my head quite into the right frame of mind. But with Cucumber, finally, I'm in this great place where I can write. I can describe what I want my project to do without needing the level of detail that the code forces me into. So it's a really great project. And I would encourage you guys if you can

add a link in the show notes to that one yeah definitely all right i uh uh you know me and win are both big fans of of what you guys are doing we use your software every day we're huge huge huge evangelists of it so i will personally and i'm sure when we'll echo the same thing that we'll we'll do everything we possibly can to continue to evangelize about Hamill, SAS, and Compass and what they're doing for front-end development. I think that for me, moving from as a Rails front-end guy for a little while there, working with ERB, moving to Hamill, it was night and day difference. Jumping from CSS to sass and then obviously putting compass on top of that and the features that come with that was just amazing it's like literally changed the way i design so i'm really thankful for all the time and effort

that you guys put into the projects and whatever we can do will help awesome thank you well thank you guys for coming on the show thank you for having us thank you for listening to this edition of changelog be sure to tune in weekly for what's fresh and new in open source also visit changelogshow.com for links in the shows

or to leave a comment on the show. Thank you for listening.