Here I talk with my friend Charles Max Wood about, among other things, his new project, RailsClips, a series of screencasts which kind of picks up where RailsCasts left off. Enjoy.
Jason Swett:
Hello everyone. I’m Jason Swett, author of angularonrails.com. I’m here with Charles Max Wood of Devchat.tv, among a number of other things and we’re here today to talk about that stuff and also RailsClips.
Chuck, how about you introduce yourself a little bit. Tell us who you are and then we can talk a little bit about your new thing, RailsClips.
Charles Max Wood:
All right. I am the host of five different podcasts about programming. I’ve been podcasting about programming for about seven years. I started out programming in Ruby on Rails about eight and a half years ago, nine years ago. That’s kind of where I got going.
We have Ruby Rogues which is the longest running show that I have currently. It’s been going for about four years. JavaScript Jabber is the largest podcast, the most popular one that I do. Adventures in Angular is the next most popular. We kind of hit both angles, Ruby and Angular, so that’s what we talk about. My other two shows are about freelancing and iFreaks.
I guess we’ll get into what RailClips is here in a moment. I’ve got a few other projects here and there that I’ve got going on. For the most part, I do consulting for various clients, building various applications, some using Angular, some not, but all of them in Rails.
Jason:
A question you’ve probably been asked before is how the heck do you do so many podcasts? That’s a lot of podcasts, and you also do the consulting, so how do you manage all of that?
Charles:
Not well. It’s hard. I think a lot of people kind of get in their heads that there’s this steady balance that you reach, so every week is the same, the same, the same, and it really isn’t that way. As far as the podcasts go, I record 3 podcasts on Tuesdays, and then 2 on Wednesdays, and then I have pretty much the rest of the week to do the rest of everything else that I’m doing.
As far as fitting in the consulting and everything else, it just depends on the week. Some weeks, I get in a whole bunch of time for clients, and some weeks, I really don’t. It just depends on what I’ve got going on.
Just as an example, we’re recording this on April 27th, 2015. Last week was RailsComp. The week before that, I was at MicroComp and New Media Expo. Basically I spent two weeks at conferences for business, podcasting and programming, and I didn’t get a whole lot of either done those weeks. For the most part, I just have to plan it out.
I schedule the podcast, we do it the same time every week, so that’s easy to make sure that it gets done every week. The rest of everything else is just a matter of good planning and prioritizing, and sometimes working a little bit late.
Jason:
I know what you mean. When I first started freelancing, I said, “I’m going to do 20 hours of billable work and spend 20 hours on my product, and I’ll just do that every week.” I quickly learned that is very unrealistic, right? It’s different every week.
Charles:
I mean a lot of it depends to on how long I think the current project is going to last with my client or clients, how much time I need to fill, how much money I need to make, and whether or not I have prospects for the next job. That 20 hours billable a week is about what I try and hit. Some weeks I spend another 20 hours trying to find my next gig.
Jason:
That definitely is the way it goes. You’re working on transitioning eventually to more product revenue, right?
Charles:
Yes.
Jason:
That’s kind of where RailsClips is part of that picture?
Charles:
Yeah, RailsClips. About 2 years ago, Ryan Bates disappeared from the Internet. He left behind about 420 episodes of RailsCasts, which is still a resource that I think a lot of Ruby on Rails developers use. Some of them are out of date. It still kind of gives you the landscape of where you’re working, even if the exact APIs or whatever aren’t the same.
A lot of people really like having the resource, but as I talked to more and more people, it became pretty apparent that they wanted up to date stuff. Some of these other technologies, they barely got a mention. Now, they’re kind of a big deal.
React has really come out of the woodwork since RailsCasts. A lot of people are interested in that, but there’s no RailsCast for it. Angular is another technology that was kind of starting to bloom when RailsCasts quit publishing. People want more stuff on that.
The other thing is that a lot of the other technologies out there have moved ahead. As you can imagine in open source, two years is a long time. I felt that was a good option, as far as being able to fill people’s need.
The other thing is that Ruby Rogues, just to throw a number out there, last time I looked Ruby Rogues was getting just over 20,000 downloads an episode. I felt I could reach out to those 20,000-ish people who were listening, on a weekly or semiweekly basis, and let them know. “Hey, look. I’m going to put together a resource for you,” and see where things go from there.
Since Ryan had already proved out the subscription model with RailsCasts Pro, and Avdi Grimm had proved it out with Ruby Tapas, I felt that was a good way where I could continue to produce content that I really care about, and that I could do it for community that I care about, and that they could help me pay my bills at the same time.
Jason:
I found that if you’re going to do something like a Kickstarter or something like that it can be really beneficial to have been building a list of people over the last however long who care about the stuff that you are talking about. They are kind of pre-qualified and pre-interested in the thing that you are thinking about providing. That way you don’t have to start from square one when you put it out there.
You can have an audience that exists already and say, “Hey, all you guys who have been listening to me and following me for the last couple of years or whatever, there’s this other thing that you might be interested in.”
Did you find that you got a lot of your Kickstarter backers from you audience that you have on Ruby Rogues?
Chuck:
I guess I should stop and rewind. The way that I launched RailsClips was by putting together a Kickstarter campaign. I put it up there, I thought, “OK, if I can raise $5,000 then that’s enough to kind of buy some free time to be able to put out a few months’ worth of episodes.”
The base pledge people could put up was $25 and the reward was six months’ worth of RailsClips. Kickstarter doesn’t allow you to do recurring things on your campaigns. What I had to do is actually put it together and I said, “I’ll put together a video series on how to build APIs on Ruby on Rails, and those are going to be the first months’ or twos’ worth of episode that you’ll get from RailsClips.”
That’s the way I could launch it and we wound up raising $7,000. I had a stretch goal for $7,000 that basically meant that I’m going be putting together a webinar on how to test your Rails apps, which I get a lot of requests for. I’m going to put a little bit of particular focus on how to test your JavaScript.
If you are doing Rails and Angular then this is going to be pretty helpful. Especially since this is coming out of my experience doing Rails and Angular, more than anything else.
It applies to the other frameworks. It applies to regular JavaScript. Obviously you can use Jasmine, or QUnit, or whatever to test those, and Karma works nicely. You get a little bit of PhantomJS. You can do this stuff, and it works the same for all of them.
Some of the approaches are a little bit different, but for the most part it’s the same technology. As a basic primer for that stuff — I don’t have to go too deep into, “Here’s how you test your Angular,” it’s just “Here’s how you get started testing your JavaScript.”
Jason:
That’s kind of an interesting topic and I had a meandering path when I started doing that. Obviously when I’m doing an app that’s just a traditional Rails app I test my models with RSpec. I do integration tests with RSpec and Capybara. That’s how it works, and it works so great.
Once I did a Rails API and an Angular front end, it became much less clear what the best way to do it might be. There were a number of options that were possible, but it was like, “What’s best?”
Obviously you can still test your models with RSpec — that’s not a problem at all. In the in-testing is more the part where you have some different options with different pros and cons. I first tried Protractor, and did it that way, and I’m like, “Maybe I can have the Angular side, spin up a Rails server and blah hlah blah.”
I did it and I got it to work, but it felt really wrong. I’m like, “What if I need to generate some data and put that in my database?” It didn’t make sense.
Then I did it from the other way. I’m like, “Hey, maybe I can just do a build on my Angular app and put that and have it build itself into my Rails public folder.” At that point it’s almost like the fact that my JavaScript happens to be Angular is just a detail that my tests don’t need to care about. So, I did end-to-end tests with RSpec that way.
I’m ever so slightly, not super happy with the fact that I have to have RSpec know about Angular and tell Gulp to do a build. That’s the least worse thing I’ve been able to come up with.
What’s your take on the whole thing?
Chuck:
I do want to get back to your question about Kickstarter and having an existing audience, but we’ll talk about this first. My feeling is that you unit test your Rails models like you said. If you have to unit test your controllers, then you’ve probably overcomplicated your controller actions.
I like the Skinny Controller, Fat Model and then I like Skinny Model Fat Lib somewhere else to simplify things. I will test the Libs, I will test the models, I will test the controllers where I need to which is not usually very often and I will do unit tests on that. I will do some kind of end-to-end tests with Capybara on the things that are just straight up html, there is a not a lot of JavaScript interaction in the page, or for my APIs because you can get Capybara around that, you can tell it to make the requests, you parse the response with the Jason Jem and then it works.
On the JavaScript side, I usually will unit test. I try and break things, in Angular I try to break them out into services, and then I will test the services. As much as I can push the services I kind of treat that as the Lib to the models.
I also tend to treat some of the services as kind of factories for objects or repos for objects and they basically hit the APIs, so I can simulate a lot of that stuff and I can get a good unit test around them. I will do the end-to-end tests and I will do those usually with something like Karma and I will pull in PhantomJS.
I have them a little bit with Protractor. I am not as big a fan of a Selenium WebDriver but I have used it before. The thing is with end-to-end tests, they are expensive as far as time and resources go because it takes longer and they chew up more CPU, more memory when they run.
I tend to keep those to a minimum and just test kind of the happy paths or the critical paths depending on it how you look at it. Basically, the happy path, this is the most common route that people are going to take through my app. That is what I want it to do.
If it’s a social network, it’s OK, go in and post something to my wall, blah blah blah. Go and make a friend. But there are only going to be two or three of those that have to happen in order to make the app worth using.
I also usually will end-to-end test something like if I have a payment process or something in there, where then I have some kind of system that pretends to be the payment processor or, in the case of like Stripe, I just have to hit the test end point. My end-to-end test will fail if I do not have Internet or I cannot connect to the test system but for the most part I am generally not in that place and I know if I am offline then I am expecting it to go all the way down the chain and then blow up.
But what that does then is — then I know OK, I can get paid, people can use the most common features and then all of the edge cases should be covered mainly with my unit test and with some integration test if I really feel like I need them here or there.
Jason:
How does that work mechanically with making the end-to-end test happen, if it is an Angular and Rails app?
Charles:
Generally what you wind up doing is it has to spin up a Rails server and that will load the app along with all of the static, usually compiled assets from your asset pipeline. I have used the Rails asset pipeline, I have looked some other options, I have used Grunt and Gulp to compile. Depending on the app one is usually easier than the other but I have not found that one wins more often than the other.
It just depends if it is really simple the asset pipeline is not a problem. You have to configure it a little bit. For the more complicated apps, a lot of times the Gulp processes work better. It just depends on what you are after and what you are dealing with.
Jason:
OK. Why do you say that Gulp works better for the bigger ones? I usually use Gulp myself but I don’t necessarily have a great reason for having chosen that route. I would be curious to hear your perspective on that?
Charles:
With the smaller sets of Angular functionality the asset pipeline works fine because you more or less chunk it out. In other words I am not building single page apps in those cases. I have got the Angular for each page and it is mostly self-contained.
I am not too awful worried about all the processes and stuff. The way that Rails handles the assets does not affect it much.
However with the larger apps or single page apps, especially things that have a lot of logic in them, the Gulp and Grunt tools, there are more of them that deal with more cases is what I found. You have the plug in that does all the Angular stuff, is it NGAnnotate or is that…? Anyway.
Jason:
That’s one, yeah.
Charles:
You pull that in and you can pull some other tools. They are sort of made to deal with Angular and you just do not have that kind of specialization in the asset pipeline.
Jason:
OK.
Charles:
That is kind of what I found.
Jason:
OK. I originally I think started using Gulp just because I felt like I am trying to be like the Angular Rails guy and if I am going to be that guy I should probably know Grunt and Gulp at least a little bit. I started down those paths and Gulp just seems kind of neat, so I stuck with that.
How much of RailsClips do you think will involve things like Angular, React, whatever other stuff besides Rails? It seems like it is pretty common now a days that if you are going to be building any complex application, there is probably going to be more to it than just rails is kind of my perspective on that.
What do you think, how much non-Rails stuff do you think you might include?
Charles:
At this point it is going to be fairly focused on Rails. I am going to say that 75 to 80 percent of it is going to be stuff that is either Rails or you bring in a Jem to do it with Rails. I foresee that some of it is going to be stuff like DevOps or deployment, which is probably more Ruby or Bash or just general server maintenance as opposed to Rails itself.
But it’s stuff that applies to Rails, some of the caching technologies, how to setup mem cache or Redus and how to use that as a cache. Some of that is going to be DevOps and some of it is going to be Rails.
What I am kind of hoping is that I can put some stuff in that relates to the frameworks one way or another, but it is hard to know exactly what that right balance is. If you make it too Angular-centric or too Ember-centric or too Backbone-centric then it is not going to be as useful to the people who are using other systems.
What I am hoping to do is periodically just have a week which would be two episodes or maybe three episodes that are like, OK, now we are going to take all the stuff we learned and we are going to apply it to the major frameworks. I can say look, you setup device, here is how you set it up so that you can just do it in the single page app or you click on the login button and then it opens something up here, then it does the work for you in an Ember app and in Angular app.
I may throw all those in and just say look, here some shortcuts for the various options you have, but I don’t think it is going to be very focused one way or another on those. The API stuff is going to be, if you want to format it for Ember this is generally how you are going to do it, if you are going to format for Angular, this is generally how you do it.
It is not going to be super focused on that stuff because what it really is, is it is about empowering Ruby on Rails developers to do stuff with Rails and if I go another level deeper then it is not as useful for other people.
Jason:
That makes sense. I thought Ryan Bates struck a good balance with RailsCasts, and he would do an intro to such and such thing. Like, “Here is how you might plug Angluar into Rails,” but then it’s just one episode, the intro thing.
If you want to go deeper with any other of those technologies there are places for that. A big part of the value of RailsCasts and RailsClips is the fact that it is Rails. If you use Rails chances are it’s going to apply to you.
Chuck:
I do intend to treat some of the frameworks, but I don’t intend to do it for very long at a time because people can tune out an episode or two in a row, but I don’t want people tuning out more than that.
Jason:
If they’re interested in any particular technology chances are there’s a podcast that you host or co-host about that technology.
Chuck:
[laughs]
Jason:
Chuck, where should people find you, where should people find RailsClips. Where should people go on the Internet if they want more stuff from you?
Chuck:
All of my stuff is at Devchat.tv. I am probably going to start my own blog again, pretty soon. That would be at CharlesMaxWood.com.
I am trying to figure out how I want to do that exactly, but I will probably windup doing something like Avdi Grimm has done, where he has this development blog, and then he has his other blog that’s all of the other stuff.
RailsClips will be at RailsClips.com or you can find it at Devchat.tv because that’s where it’s going to live. That’s pretty much that.
I do want to address real quickly the other question you asked as far as having an audience and Kickstarter. I looked at the numbers and 90 percent of the traffic that went to the Kickstarter campaign came from Devchat.tv. It came from the podcasts.
The other 10 percent were people that found it through Kickstarter. It makes a big difference.
Jason:
If somebody is thinking of doing a Kickstarter — maybe I might do someday a Kickstarter — probably a good piece of advice would be do something to start building an audience now so when you want to pull the trigger on that you have something to prime the pump.
I imagine part of the success with Kickstarter is that initial wave of backers. People are going be more likely to back something that’s already being backed than something that’s at zero dollars. That is definitely a valuable thing to have.
Chuck:
I did an interview on building an audience on the debossified podcast. I will put a link to that here in the chat and you can share that with the people who are watching this too.
The best place to find me is Devchat.tv. I’m on Twitter @cmaxw, that’s C-M-A-X-W. People can email me, [email protected], I love talking about this stuff.
Jason:
Awesome. All right, Chuck, thanks for talking with me and we’ll put links to all that stuff on the blog post, and we’ll be talking to you soon.
Chuck:
All right. Sounds great.