The Changelog: Software Development, Open Source - Open Source Publishing (Interview)

Episode Date: March 11, 2010

Adam and Wynn caught up with Geoffrey Grosenbach, Brandon Mathis, and Tim Caswell to talk about publishing with open source tools, open blogging, and the back-to-the-future world of static site generators and database-less blogs.

Welcome to The Change Log, episode 0.1.7. I'm Adam Stachowiak. And I am Winn Netherland. This is The Change Log. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. If you want a real-time view of the happenings in open source, check out tail.thechangelog.com. You can also check us out on github.com forward slash explore, where you can find

some training repos, some featured repos from our blog, as well as all of our podcasts from this year's show. And if you're on Twitter, follow ChangeLogShow, not TheChangeLog. And I am Adam Stacey. That's Adam Stack. And I am Penguin, P-E-N-G-W-Y-N-N. Well, special South by Southwest edition, just in time to load it up on the iPhone before

you get on the plane. I will not be flying. I meant the listeners. Ah, well, I'll be driving, and you'll be driving as? I will not be flying. I meant the listeners. Ah, well, I'll be driving, and you'll be driving as well. I'll be driving. I can listen to the podcast while I'm in the truck. Do you listen to the Change Log when? Just for QA purposes only.

I see. Usually podcasts that I listen to are the Dev Show, all the 5x5 media. Pretty good. You? Yeah, I listen to the dev show as well. I try to listen to as much as Dan Benjamin

as I can take because their audio quality is just so pimp. Very nice. Tuneage coming out of the 5x5. We should mention some other conferences we're going to be at. Hopefully JSConf coming up. Yeah. We're hoping to be there, doing something fun there. But wait on the final green light from the curators of JSConf.

Really hope that comes through. That would be a fun conference to hit, another JavaScript conference in our own backyard. Again, in Austin, it's TXJS coming up in June. Rebecca's doing a great job. She's super stoked about the community and the conference. And if you see her online, check her out, follow her, and support the conference.

Great interview today. We're talking about open publishing with Jeffrey Grossenbach, a.k.a. Top Funky from Top Funky Corporation, proprietor of the Peep Code blog, Peep Code screencast site. Brandon Mathis, a freelance, I guess, designer from Alabama. And Tim Caswell, a local Dallas area Node.js developer.

Brandon and Tim are kind of in the thick of what's called open blogging, where the notion of forking a repo on GitHub that is a blog and the pull request becomes a contribution. That's a well-concept. I'm glad we had a chance to bring all these people together and talk about the frameworks and the idea of how it works and then also just have some back and forth about who does what and how. It was cool talking about all these static website generators.

I haven't geeked out like that since talking to Leah about APIs. I know. It was fun. You want to get to it? Yeah, sure. Let's do it. Hi, we're joined today by Jeffrey Grossenbach from Top Funky Corporation. So Jeff, you've been a big player in the Ruby on Rails scene for a few years now. For anybody that's new to Ruby on Rails, why don't you introduce yourself and a little bit about what you do? Yes, I run a, my main product is called Peep Code video training.

Initially just for Ruby on Rails programmers to help them learn the framework, but now expanding into jQuery, some iPhone development, other kinds of topics as well. And I'm fortunate enough that's been my full-time employment for a little over three, three and a half years now. You know, I'm a bit excited. I've got to say, hearing that voice come across the Skype, I got turned on to Ruby and Rails via your Ruby and Rails podcast a few years ago. How did you get involved with Ruby and Rails and that podcast? Well, I had been living in Taiwan and was about to move back to the United States and thought, hey, let's give this freelancing thing a shot. Had worked with a variety of different technologies, but just happened to learn about Rails, which was starting to become popular at that time. It had just been released. And right, you know, almost as soon as I hit the ground back in the United States, got some contracts, started using it, and then started helping out with this podcast, which has really been a great thing to help me meet a ton of people and build a lot of friendships, as I'm sure you've discovered by running the ChangeLog. Absolutely. You know, as I look at

your GitHub page, github.com forward slash topfunky, loads of open source projects out there. I got to ask, you know, how did most of those come about? Are you just scratching your own itch? Do you see yourself as a developer first and a publisher second or the other way around? A lot of people ask me that. I think it's a mix of both. I enjoy the creative side. I enjoy the visual side, but at least to some degree, I like to definitely get down in the code. I like the – the Tao of coding has a phrase in there. After you go three days without coding, life becomes meaningless.

So I definitely subscribe to that. Most of those projects that I have – that I've put out there for You know, most of them are things that I actually use, solved a problem for myself. Others are ones, but definitely I try to put other features that people have contributed or are asked for. And inevitably, you know, a project is there and gets a little stale and I'm not really using it. But there's a whole mix.

How does open source drive your business today? I think that the big thing is just, I started these video tutorials because I wanted to learn about a lot of these different open source projects and they weren't very well documented. Sometimes it's even two or three years until a book comes out on a particular topic, but people want to know about it. And often a blog post is just, you know, just not long enough to really dig your teeth into it. So I think for me, I'd like, you know, I'd like to think that I'm helping open source, even though it's a commercial product, by putting the time in to spend a good couple of weeks digging into these open source projects that aren't very well documented, coming up with a great demo project and tutorial, and then getting it out there so that people can learn some of these different open source things. to me that some things I've published on, people have actually started to become interested in them after seeing that now there's some more in-depth documentation. And so that's encouraging to be

able to kind of give back by helping people learn this stuff and use it. The only reason I know as much as I know about Git is because of your tenacious ability to go deep into a subject and just really pull out all the meaningful nuances and clearly communicate that through an awesome screencast. I know that Git's a big part of, and GitHub is a big part of this open source movement that's happened over the past few years and this gigantic community that's just thriving around this. And it's just wild to see how someone like you can put their passion into what you do and then outcomes uh everything that comes from that so it's pretty awesome that get one was fun because

it was kind of a risk as is anything but when i i published it people were starting to kind of talk about get i mean of course the the lin Linux kernel had used it for two years or something already. So it's not like it was this secret thing. But at least in the Ruby world and a lot of other developers, people just weren't really using that much. But I thought, wow, this looks good. I sent it off to the maintainer of Git, actually, Junio Hamano. And I said, hey, I'll pay you some money. Look at this. Tell me if it's any good. And he said, well, it's pretty good, but six pages of notes. So I just scrapped it, started over, refilmed the whole thing. And that's now been my top seller. And people actually, actually, when I launched it, very few people bought it. But then a couple months later, interest kicked off. And it's, yeah, people have definitely loved that one.

Well, for me, anytime I meet anybody who's not a Git user, let's say they're using Subversion or something else. But as soon as I know that they're not using Git, I'm like, okay, step one is do a Google search for Scott Chacon and then go to peepco.com and buy the Git screencast. Nine bucks is what it's worth. So, I mean, pretty much every time I meet somebody who doesn't use Git, that's my first recommendation to them. Yeah, definitely appreciate that. And the good thing is now there are many more resources on Git, but still it's nice to have one spot, sit down for an hour, learn the thing, and then you can go off. Yeah, Scott Chacon has, well, he did a PDF for me,

and then he did a whole printed book for A-Press. There are a bunch of different blogs. I think Git Ready with Nick Caranto, I think, goes into some good depth. You know, one of the things that I really admired about Peep Code, Jeff, is one of the things that we try to do with the changelog is go a little deeper. I just know as a consumer of podcasts, it seems like I'm always left just wanting to go a little bit deeper on most topics than most podcasts tend to cover. And that's one of the great things about PeepCode and the screencast is just how well they cover a subject. How do you balance covering a subject deeply and letting it have legs as

opposed to having content that has a shelf life? That's a great question and something that I've actually been kind of adjusting to as far as I've learned about the business. First, you're right about the shelf life. I mean, open source software, especially Rails, it's going to change every six months or every year. There's going to be a big release that's going to change a lot of things. So things do tend to get, you know, you got to keep updating them or they're going to be little things here and there that aren't, uh, aren't super relevant. The other thing is I do try to hit kind of a higher level of developer. I don't really have that much.

That's just kind of get started from, you know, if you don't know programming at all, or if you have never done any programming, I don't really have much of that content, which actually I'm i'm learning that's why most publishers do cover that kind of content because it does sell really well but i still think you know there's got to be something out there for the more you know intermediate advanced developer who wants to go learn stuff um see something to where it's not just trying to hold their hand all the way but but to say, okay, let's assume that you have this level of knowledge right here, and then let's take off from there.

You know, we should mention that all of your content on Peep Code is paid. You have some free content on the Peep Code blog, and I think that's one of the things that attracted us to put this particular podcast together is just your take on how you do the Peep Code blog, and you even have an About This blog post that was popular recently, a couple of weeks ago. So it's a good opportunity to bring in and introduce Brandon Mathis and Tim Caswell, a couple of guys that are kind of involved in this, I guess, movement we would call open blogging. Brandon, why don't you introduce yourself to the audience and let the folks know who you are. Hey, everybody. I'm Brandon Mathis, and I live in Birmingham, Alabama. I've done some work on Compass, and I use SaaS like crazy,

and I decided to write a little blogging framework on top of Jekyll. Since it's file-based, it makes it easy to keep all your source on GitHub, and people can fork and publish. So that's the whole reason I'm here, I guess. And you run an awesome design blog at imathos.com, is that it? You can get to it at imathos.com, but brandonmathos.com is the forward URL you'll get to. Awesome. And then you recently wrote a blog on open blogging and the whole work with that project you just mentioned.

Where did that come about with open blogging and where did this sort of affirm in your mind really come out as into a blog published? Okay, so I was working with Ryan Daigle to release a new version of Edge Rails, which is a blog that he's been running for about four years,

just keeping up on the latest stuff. And he spends tons of time reading through what's coming up and what people are working on on the Edge Rails and writing about it. So really adopters can get the real deal. Anyway, he kind of felt like he was being the bottleneck having to author all this. And if you've spent much time blogging, you know how hard it is to just get the post out there, especially for geeks who are used to mostly writing in code. So he decided that he'd like to take a look at Octopress for Edge Rails. And that site is edgerails.info, by edge rails. And, uh, that site is edge rails.info by the way. Uh, anyway, so he liked the idea that it was file-based and we talked about what kind of flexibility that gives us. And so one of the things that we do, um, is, uh, it's all hosted on GitHub,

the source for it is, and anybody can fork it and, um, and contribute changes to an article if there's errors or things like that, or even write their own articles. And then they can use the fork queue to Ryan Kan or any of the other authors with commit rights to pull in what they've done and then actually just publish it right to the blog. And the cool thing about that is that instead of being stuck behind this database of – it's hard to give – like what are you going to give people keys to sign into WordPress or something and post directly? It's a little bit nastier that way. You start dealing with like the whole user management and all that.

Oh, yeah. Giving someone a certain access and stuff like that. All the privilege issues are weird. But with GitHub, since it's all open and, you know, a fork isn't like access to the core or anything, and it's all managed by people who have commit access, it's a whole different, it's like GitHub is taking care of that for us. And so we're able to accept submissions for articles and things like that really easily from a wide variety of people.

Let's introduce Tim real quick here. So Tim Caswell is waiting in the wings as well. They're doing that with howtoknow.org. Is that sort of the same stem that you went down, Tim? Let's introduce yourself, I suppose, first. Then you can answer my question. Sorry about that. I'm Tim Caswell. I'm from Richardson, Texas, just north of Dallas area. And I got involved with Node sometime last summer because I was looking for a cool server-side JavaScript. And one of the problems with it being a young project

is there's not a lot of documentation. And since it's async JavaScript, the programming style is very hard for people to pick up. And the mailing list was just constantly covered with questions, the same questions over and over. How do I do this? How do I do things in parallel? How do things serial? And so we said, well, you know what, we should start a blog, where people can write articles about how to do these various things. And the node community, especially the core people, are very hardcore programmers. And we don't want to go start up a WordPress and start typing up a bunch of fluffy content.

We needed something that was high tech. So we got inspired by these programs like Jekyll and said, hey, let's write something like that in Node. So I hacked together a real quick program. It's on GitHub. It's creationx slash node blog. And it's just an engine. You upload your markdown to a GitHub repository and it calls some hook and then it generates all your HTML, just static HTML generator. But just like we were talking about, since it's on GitHub, if anyone wants to send me an article for the blog, they just need to fork it, write their article,

and send me a pull request. And I'll review it and say, it's great and push it and it goes live, or I'll say, hey, could you change these things and give me back another pull request? And I think I've had quite a few contributors. I think about a half of it wasn't written by me. So it's done fairly well.

You've got a partner in crime there, don't you, with How to Node? Yeah. Michael, he did the site design, and he helped me with the concept, and he's been helping me manage these pull requests. Because when it first started out, it was hugely popular. And I mean, I couldn't get my day job done because I was busy reviewing all these requests.

And so he would help out. And especially since he's in Australia, then we can take turns being available. Right, doing the whole time shifting thing. Yeah. Yeah, I know that Michael's a fan of the show. He always retweets our tweets and helps us raise awareness about the changelog and what we're trying to do with putting the spotlight on new and open source – fresh and new open source projects and how we can leverage this tool that we all use anyways called GitHub. And, you know, at the heart of that is Git to publish our blogs.

Normally when we talk about blogging statically, I think what first comes to mind are just single user blogs. I think this open blogging trend, hopefully it will catch on and it's more of open publishing than anything else. But let's talk briefly about the tools that are in the landscape for open blogging. We mentioned Jekyll a couple of times, and I know Webby is one that I've used in the past. Both of these are Ruby-based. Adam, I know you're a big fan of Staticmatic. There's a lot of these, I guess, a crop of tools that are rising that are more or less hacker CMSs where you don't have to have a database behind the scenes. And so it makes it very easy to have multiple environments without having to send data along with your markup and your content lives right there in your version control.

Jeff, you're using one called Nesta or I guess a forked version, a hacked up version of Nesta. You want to talk a bit about your setup and what you found and moving to the static-ish type publishing tool? Yeah. Basically, this is just a Ruby Sinatra application and it just happens to cache everything. So it actually does run dynamically on the server. But the first hit, it caches uh you know html images javascript whatever it even does some generation of uh different graphics or resizing things sometimes but after about you know 60 or 90 seconds of being up then everything is cached and it's just works

like a static blog so personally i like thinking that way. I like thinking about URLs and handlers and stuff like that. Definitely things like Jekyll or Webby or some of these others are fantastic. But I chose just to use a dynamic framework to generate it but save it all to disk on the first hit. I think it's a great setup for a hacker that's also writing, someone that is just as familiar with the code as the article that they're writing. Did you have any reservations about moving to a setup like this, thinking, okay, I may be boxing myself in long-term around not having contributors that maybe not be this familiar with this low-level type of publishing? Actually, it's great to hear about these other ways that you guys are doing it. And I think that's fantastic because then you can use the commenting and other features at GitHub then

so that you don't have to implement all that editorial process. I haven't done anything like that yet, but I have thought about bringing on other authors to actually do creative designs and and uh you know write the content and stuff too and so i may use a situation like that one thing you know just a little history it's funny how all these things keep rolling back it's not the first time that the web community has hit on this idea of a static blog. I remember back in like, what, 99 or 2000, there was like the Blossom. It was like a Perl-based thing.

And I forget if it actually ran on a server or if it generated it all dynamically. But when I saw that, I mean, that was like a couple of years ago, it was like, wow, what a great idea. I can just work with files and I can edit code in my text editor and it just works the way that I would be writing normally. It seems like a lot of these tools have, in some of them, they're called YAML front matter. I'm not sure in Nesta, it does have a metadata block up front, but is that

pure YAML or is it YAML-like? I mean, it's just keys and values separated by colons, so I don't think it... Basically, if you add properties that aren't supported out of the box, I guess you have to add those to your model. Right, so it could be a lot more flexible. I think there is a way that you can just dig in and say, okay, give me a key that's named by this string. But usually you build a model and add an actual method to pull that out. So beyond just regular static blogging, where you've got a stream of articles

and archives and details of articles, have you hit any challenges that this type of approach you think might be hard to work around well i mean the initial challenge was just that i didn't see anything out there that it was exactly what i wanted and of course you know that's what open source is all about you you don't see the one or two little features you want so you start from scratch and rewrite a whole new software product but you know i did nesta was a great it had most of what i wanted and i actually i was on a trip uh down to australia for rails camp which is a awesome thing they just like rent out a summer camp for a weekend and guys people come and uh you know

write code and and talk and stuff but um that's totally away from the internets? Yeah, no internet either. They build their own network. I think the guy who wrote Tweety, Lauren Brichter, actually gave them a special version that they can use locally. So they actually have a Twitter clone up and people are all talking and IMing

and stuff like that, but it's not connected to the outside internet, which is kind of fun. So you were in Australia? Yeah. So I'd known for even a year or something that I wanted to do something like this. And so I'd cloned a bunch of different products

and I started looking at them and I thought, oh, okay, this is nearly what I want, but I want each post to be different. I want it to use Sass. I want a bunch of these different things. So I found it really easy just to work those in. All right. You mentioned Haml and Sass.

Adam's and myself's favorite technologies, even episode one, was Ham, SAS, and Compass. So when I read about this blog post on Peep Code, I was excited that you were trumpeting that because I love what Hamill does for markup. And I think if I could pull up the exact quote, I love what you said about Hamill. And it says it decreases the mental distance between HTML and CSS. You want to expand on that a little bit? Yeah. You know, another fun thing about doing it this way is then you can have a draft that's just there for a couple of weeks and you get to kind of mull it over and you don't feel the pressure of having typed something into this little, you know, text area on a web form that you feel like

is just kind of this immediate thing. Although, I guess you could do a draft there too. But that specific quote was like from a separate article that I haven't published yet. Just thinking about, you know, as a programmer, especially, you know, a web programmer now, you're thinking in all these different languages and different formats. And so anything that can just kind of reduce that without being too much of an abstraction helps me to focus and think about the problem I, and then I jump right over to Sass or straight CSS. And then again, you're thinking about CSS selectors. And then you jump over to jQuery. And again, you're thinking about CSS selectors as you dial in some element to handle a behavior or something on it.

So that's where it's at for me. Well, I was jumping over to Brandon's Octopress project page on GitHub just now to double-check that Haml was one of the opinions kind of baked in on top of Jekyll. And I noticed the last push is 16 minutes ago, and I think we've been on the air for like 30 minutes or so. Guilty. So, Brandon, are you pushing updates during the podcast, buddy? Actually, yeah, I was just finishing up some stuff.

There's a really cool expandable code window that I wanted to get up there, and I was just starting it right before you guys called. It's one of the things that frustrates me on fixed-width blogs is you get this code window, and sometimes you have to scroll around to read things or copy them and paste them somewhere else. So I wrote a little JavaScript that would find the code windows and add these expanders that collapses the sidebar and gives you the full width of the site such a hacker so that's a quite a design decision of are you going to allow people to write long lines of code or are you going to implement something like that which is a great way to to go? I know the Marcel Molina in there a couple years ago, although it's still going with the Projectionist blog, they restricted themselves to something ridiculous like 40 characters wide or something.

And they just wouldn't write any code samples that were more than 40 characters wide. That's nice. So, Brandon, you chose Octopress. And primarily, let's set the premise here. It's not that you're not a developer, but you're primarily a front-end designer closely in the Rails and Ruby world. And you're a fan of Haml,

and you're a fan of Sass, and obviously Compass. So that's sort of the premise of your skill set when you approach projects. But why did you choose Octopress? Or why did you choose to chisel out Octopress, and why Jekyll? So I was working on, I guess last summer or something, I was working on redoing my website to get some work. I'm a freelance designer, so that's kind of one of those things.

And I was just looking at WordPress and saying, not again. I'm not going through this again. And I'd been paying attention to what people were doing with Jekyll and GitHub Pages were doing that. It was kind of the hotness at the time. And I think it was the only blog-aware static site generator I could find that you didn't have to like do a bunch of tricks to make it happen the problem was that all it did was generate um uh like markdown or textile or something to html and uh heinrich did a fork that let me use hamill so i was like okay this is you know the gods have spoken. This is definitely something I got to use.

And then I found out that all it was is a generator. Like it didn't have any kind of a starting point framework. There was nothing – like it was really hard to figure out. I had read through all these docs. Hard to use. So I said, well, I might as well build something that is a little more abstract and kind of you have a couple places where you put in your configurations and you've got these rake tasks that do all kinds of terrific things for you. So right now, if you wanted to create a new post, you have to have like the date in the post name and some weird things that as a static site generator, you just have to learn to deal with. So I wrote a rake task that lets you do all that.

You can deploy through rsync with a rake task or use GitHub pages. And you just change some configurations around. And so one of the problems with static site generators that you guys didn't talk about earlier is that when you're generating a huge site, they can be really slow. So when I was working with Ryan, he's got all these posts on edgerails.info, and we came up with a way to create a stash directory. And so while you're working on a post or a design,

you can stash all the posts but one of them so that it'll only be generating that one post and it'll ignore the other stuff. And then you can reintegrate them right before deploy. So that kind of stuff just makes it nicer. And then of course, you know, all these hackers out there that want to blog. And then when they start, they're like, well, now I have to find a design or have to use these ugly default designs or whatever. I wanted to come up with something that had the beauty of Compass and Sass in it so that I could make the layout configurable. You just change some variables.

You've got a different size sidebar, and everything works. Or you can get rid of it, and it doesn't break on you. Colors are actually in a theme file, so you just go in there and change everything. And I think I'm even doing some stuff with gradients through CSS three that are based on base colors. So it's all like very, you know, you don't have to be a designer to go in there and make it look good. So you've had a lot of design magic in there as well as some of the niceties. Right. It's, it's something that I use for my site and, uh, there are some other sites out there that are using it too, but it's not really that big yet. Still kind of, still got some work to do. We just added partial support through Haml. And that's, I think I pushed that up this morning.

But when I was working with Ryan on it, one of the problems is that in the default layout you have like all this code. Like, so I wanted to do conditionals so I could integrate third party stuff. So all you have to do is say, this is my Twitter name, and all of a sudden you've got a JavaScript Twitter widget in your sidebar. And if you don't have it, I didn't want to output all this stuff. So all these conditionals are hidden behind partials now, which was pretty hard to do earlier.

You know, one of these tools that we haven't talked about yet is Nanoc from Denis Dufresne. And it's one of my favorite of the static breed. But something interesting that Denis is doing is he has a rack app that fires up. And most of these static generators have a preview mode that runs WebRick or something internally. But I think the holy grail for me is I'd like to see it develop along the line of being able to fire up that Rack app and have the best of both worlds. Have a static compilation up front so that you could have the built-in caching, but also to be able to compile one page on the fly. And I think that's what turned me on to Nesta, even though you don't have to do the compilation up front.

There's no pre-compilation required. Yeah, I'm definitely keeping my eyes on Nanook. Hopefully at some point I'll be able to have Octopress. You'll be able to pick your flavor. So if Nanook does blog stuff really well. Right now my focus is blogs, not just static sites. So yeah, if that happens, I'd love to get my hands on some Nanook. Well put. So Tim, if that happens, I'd love to get my hands on some Nanook. Well put. So Tim, what's going on with Node?

I guess specifically how to Node.org. What's going on there? You wrote your own engine on top of Node. What is this about? Yeah, I had already made a port of Hamil for Node a while back because I like using Haml for structure. And right now it's using Showdown for the markdown. And so the whole backend, if you go to the repository for howdonoed.org,

it's just, there's a skin folder, it's just a bunch of Haml files. And then there's an articles folder that's just a bunch of markdown files. And then there's an authors folder, and that's just a bunch of markdown files. And that's the content. There's a little CSS in the static image, but that's pretty much it. So it's pretty light then. How do you handle layouts? Well, the Haml supports partials, and so the engine just looks for the

articles, and it looks for a Hamilfeld called article, and that's basically the way it renders that article. And then there's a little bit of metadata in the top of the markdown files so it knows which author to link this article to when it was published and various things like that.

And this Hamil.js, is this what we covered a while ago? I believe so. I have two Hamil projects for JavaScript, and people often get them confused. One of them is a jQuery plugin that runs in the browser that's a DOM building engine using a JSON expression syntax.

And then the Hamil.js is targeted for Node, but it really works anywhere. It just takes a Hamil file and translates it into a JavaScript file that then takes variables, just like any other Vue template engine. So when we really spread it across, we've got a static blogging engine built on top of Node. We've got something sitting on top of Sinatra, which is a dynamic. It's called Nest. And then we've got Jekyll, which is just all behind the scenes, no dynamicness at all.

It's just statically generated one time, and then you upload that to the site. So we've got a pretty wide spectrum on here. Anybody have any opinions on best of breed here? Just curious on what the consensus is so far. I guess maybe the first question is trend or fad. Yeah. I think a key part of deciding what you want to use has a lot to do with the constraints. And the nice thing about having something that generates locally and that you just push is that you have a whole range of server options to choose from.

You don't have to worry about getting anything set up really anywhere. And also, you can host on GitHub pages if you want to, if it's all static. And then with things like Google Search and Discus Comments and things like that, it's really easy to make it feel a lot richer than a typical static site. That's one piece we didn't touch on, which I wanted to ask you about search and stuff like that. Jeff, how are you handling search? I know that with Brandon, you're lynching out to Google Search

and you're returning those results via AJAX and stuff like that. But Jeff, how are you handling it? And Tim, how are you handling search? You know, I've started out very small and I tend to just build things as I go, as I need them. I kind of wait until I have too much content to wade through and then I'll make a search. So, you know, right now, now I think I have like seven articles on there and there's a good little archive page.

You know, maybe in a couple of months I build search, and I'll probably just do it dynamically because Sinatra is right there on the server. How about you, Tim? Well, HowToNode is just a plain static generator, and then it uses Discus for comments. So I guess the only search I have there is Google will index it and find things. But another project I'm working on, we're updating Node's API docs, and it's using a similar engine where it just takes a Markdown readme file and generates this interactive page where you can go through the API docs. And for that one, it's actually doing all the searching in JavaScript in the browser. It'll AJAX in the data and then search over that data

and then give you your relevant results. So for an API site, you can search for any method or whatever. One thing, you know, if someone else was going to ask me, oh, I'm going to start a blog, how should I do it? I'm not sure I would even recommend the way that I do it unless it was a code-based blog. And for me, this is where it's perfect, is when I want to throw in a little snippet of Ruby or Haml or whatever,

I'm editing a.rb file or I'm editing a.haml file, and I can use all those snippets and syntax highlighting and all the features of my text editor right there and then it just gets slurped into the proper place in the prose. How do you guys do it? Are you just typing stuff

inline? Find that works well for you? I know TextMate has pretty good support for little islands of different content. For me, I think a code blog that you want to look good, this is a perfect way to do it. Well, I think that Will and I were breaking some rules, actually. Because of our constraints with the change log and getting started, we're using Tumblr, which isn't that bad, like you said, but we are inserting code snippets.

And when we read your blog post on how you're actually leveraging a standalone.rb file for Ruby snippets or something like that, that just makes sense. And so we are eyeballing the Sinatra and Nesta scenario. We've eyeballed a few of these scenarios. That's why we wanted to kind of share this talk to kind of go over different ideas of what's out there and what's successful and what makes the most sense for us long term.

Yeah, when I read your post, Jeff, about how you're linking to external files, it seems so painfully obvious to do that. Because what do we do normally? We include a pre-encode nested block in your page, and then via JavaScript, you wire that up to be a separate download in a pop-up window or a copy of the clipboard or something like that. It seems to be the common approach.

Another approach that turned me on was RAC. There's a RAC appliance for everything nowadays, and there's a few of these out there that will do syntax highlighting on the way out. So it looks for certain rules. You can have even markdown for indented space code blocks in your markdown markup or just regular HTML pre-encode blocks. And it will find those and run them through pigments, which is a Python syntax highlighter or something on the way out, which is pretty cool. But actually, your approach about doing the external files, I think, is something to take a look at. Brandon, Tim, you guys using any special approach? I'll probably be snagging that external file approach at some point.

Right now, I'm doing a pre-code thing. But yeah, I was going to say, I don't know if you were asking this, but I definitely think that this static blogging thing makes a whole lot of sense for programmers, but no sense for my mom or anything. I can't imagine anyone wanting to do this who wasn't in a text editor all the time and wanted

to stay in their same environment. Yeah, we definitely want to pull in that feature in the NodeBlog engine where we can use external files. One of the problems we had initially was I would put up these code snippets in my Markdown because they're easy to see in Markdown. They're just over to the side, but there's no syntax check-in. There's no highlighting. And after I'd post an article, people would say, you got a syntax error here.

I'd be like, oh, yeah, I didn't test that code because I was just typing it along with the rest of my text. And so what I switched to is I started creating subfolders under my articles where I would write the code, I would test the code. And then in my last step, I would copy paste it back into the markdown. But occasionally I would forget to copy paste something. So it was better better but still not ideal so I think the next step we want to take is have some sort of flag in there where it can dynamically pull in the text

from the external file and link to the external file so people can download it if they want so I think that's a great idea I think that's the direction we're going so Jeff, at the close of your article, you actually which saddened me for a moment there. I actually started to hear taps play and everything, but

you said that you haven't open sourced your code base yet or don't really have plans to. What are your feelings now that you've sat in a conversation like this and you hear other people wanting to adopt more of the top funky goodness that's out there how do you feel about uh releasing that code source now you know i'm not opposed to

uh putting the source code out there it's just a little bit of extra work trying to clean up stuff and you know all those little hacks that you do just to get something to work and then uh you know you don't want people to people to see that so you have to spend time making it look good but um honestly i just wanted to put these ideas out there and this whole conversation just now i think has encouraged me that there are many great blogging uh engines out there you know it sounds like you guys are doing a fantastic job and doing something that other people are contributing to so i don't know if there's even a need for me to put the code out there. Hopefully, maybe just the ideas are good enough. One last question before we jump over to the radar. So one of the things that you're doing, Jeff, is styling each blog post for the most part with its own style sheet. And I think

someone that does this extremely well is Jason Santamaria in his blog. I mean, it's amazing. Every time you hit one of his articles to even realize that this is the same blog. How much overhead does that add to your blogging workflow? Well, I do, you know, it adds overhead, definitely. You know, I'd probably say it takes me a full day of eight hours or something to do a full blog post, but that's not counting, you know, the

week before where I'm just kind of brainstorming in my free time or, uh, you know, any other little tweaks. But for me, it was two things. One, okay. I'll admit it drives traffic to the site. People love to see something that looks great and people come in and they buy my products. And I don't have to, you know, shove advertising down their throat. I can just write this, you know, good looking article and interestingly at design and at the code behind it. And I just don't have that many opportunities to start something from scratch. So with this, every other week, it's almost like I'm starting a brand new project and I can get different inspirations and ideas and try out CSS3 gradients and all kinds of stuff. So to me, it's a great learning experience and just a lot of fun to do. Your own little sandbox. So what's out there on your radar?

What open source projects? I guess at some point Nesta was on your radar. What is exciting you now that you'd like to work in to peep code at some point? Oh, Node.js is definitely interesting. I feel like in the last three or four months, I've just kind of chomped down on a lot of different JavaScript and really started to learn more, be a lot more comfortable with it. I also love Raphael.js, SVG graphing library. Fun to be able to just actually do some drawing in the browser,

whether it's visualizations or graphs or whatever, or even custom widgets. Beyond that, Rails 3 is very exciting. Sinatra 1.0 is coming out. All kinds of stuff, yeah, all the time. How about you brennan man i you just can't get me to stop talking about compass i am thrilled with the way that's going and uh pulling the pre-releases as soon as they come out so um that's really my bread and butter right now so just compass that's that's the only on your radar? On my radar? Well, I mean, that's, I guess.

That is your radar. I mean. Yeah, pretty much. I'm mostly a designer. So that's really the key part that I'm paying attention to. Obviously, I work with JavaScript frameworks and other things like that. But if I just had one thing to push to people right now, I'd say check out Compass because it is changing my life. Well, you've got fancy buttons out there.

Any other plug-ins that you've got for Compass coming out? Yeah, let's see. I'm working on – well, I have a whole lot of different things. Octopress is actually chocked full of little things here and there, libraries that I'm working on. So like I have a typography module and things like that that I'm doing. So it's, I think, I think what I really want to get is a good flexible layout. You know, everybody is releasing these grids and things like that. And for me, a grid is just useful for layout.

So definitely I'll be releasing some stuff soon. I can't say a whole lot because I don't want to commit to anything. We'll see where it goes. But yeah, Fancy Buttons has been awesome. If you don't know what that is, it is a great way to easily style buttons without having a ton of markup. It uses like a – you can style a button or a link. That's all there is to it. No adding spans or weirdness.

And it uses CSS3 gradients to make them look really clickable. And it has a bunch of options and things and very flexible, but also it has a backup image that it uses in case the browser can't render through its CSS gradients. And Tim, what's on your radar, Tim? Well, I won't lie to you. I've been completely buried in Node for the last six months. But there's a lot of new stuff there. One of the projects I find interesting is Felix has been working on something called Node Dirty.

And it's just a really simple, handmade NoSQL engine written in pure Node. And he kept it simple on purpose. It has no network interface. It just does append-only writes and simple queries, and it goes along with the rest of the Node philosophy of keeping it simple and just tie things together. Well, I think it's, you know, for this entire subject of static blogging, open blogging, open source publishing, whatever term you want to apply to it, I think it's a pretty wild thing. I think as programmers, as developers, as people who pretty much live on the command line or live in your text editor, embracing these tools can certainly do some fun stuff.

Like Jeff had mentioned, it's a sandbox for him. It's a playground for him. And, Brian, it sounds like it's the same thing for you. And, Tim, it sounds like the same thing for you, that you're just etching out your areas of your craft through blogging and through this type of blogging. So I think it's a pretty wild thing. Wynn, you got anything to say about it? I'll say it again. I'm waiting for that NoSQL stash the hash engine in my browser

that everybody's so excited about server-side. I'd like to, when we get done playing with JavaScript back on the server, to put it back in the client. I'd love to have that type of engine in the browser. But, yeah, thanks for taking the time, everyone, to talk about this particular topic. It's definitely on our radar as we look to grow the Changelog blog

beyond Tumblr and look to kind of remove the distance between writing and coding. Anybody have any fun conferences coming up that you want to plug or mention before we head off? Texas JS is coming up this summer, and they actually got me speaking in that, so I got a ticket. Absolutely. And we're actually the changelog is going to be a media partner with Texas JS too, so we'll be working with

Rebecca on promoting it so the audience don't get upset when we talk about it because it's a cool thing. It's all JS all day in big old Texas. Anybody else? I'll be going to LesConf on May 21st. So come there. We can hang out. Yeah, LesConf. I can definitely speak against LesConf.

That's an awesome conference. It was the first last year and again this year. I look forward to going there myself. Well, cool. All right. Well, guys, thanks again for taking the time to speak with me and Wynn and the audience of The Change Log. We certainly respect each of you in your own rights

and everything you guys are doing. Keep doing it. Don't stop. Love this open source world and thanks for taking the time to come on the show. Appreciate it. All right, thanks. Awesome.

Thanks for having me. Thank you for listening to this edition of The Change Log. Point your browser to tail.thechangelog.com to find out what's going on right now in open source. Also, be sure to head to github.com forward slash explore to catch up on trending and feature repos, as well as the latest episodes of The Change Log. Outro Music