The SitePoint Podcast: Front End Development with Mason Stewart

The SitePoint Podcast

Episode 166 of The SitePoint Podcast is now available! This week Kevin Dees (@kevindees) interviews Mason Stewart (@masondesu) of Zaarly and disusses the likes of SASS Less, jQuery and many other parts of the front end development world. Listen in Your Browser Play this episode directly in your b.

Running time
File size

Download Original File | View original post

Episode synopsis

Episode 166 of The SitePoint Podcast is now available! This week Kevin Dees (@kevindees) interviews Mason Stewart (@masondesu) of Zaarly and disusses the likes of SASS Less, jQuery and many other parts of the front end development world.

Listen in Your Browser

Play this episode directly in your browser — just click the orange “play” button below:

Download this Episode

You can download this episode as a standalone MP3 file. Here’s the link:

Subscribe to the Podcast

The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.

Episode Summary

Kevin and Mason discuss how all the frameworks and languages offer the front end developer so many ways working up great things on the web.

Browse the full list of links referenced in the show at

Interview Transcript

Kevin: Welcome to SitePoint Podcast. I’m Kevin Dees and today I’m joined by Mason Stewart from Zarlee and here at Cowork, welcome to the show.

Mason: Hey. How’s it going?

Kevin: It’s going all right. How’s has your day been going?

Mason: Uh, pretty good just code slapping so far.

Kevin: Very nice, so we are at Cowork recording in the physical location, this isn’t a Skype interview. Today we’re gonna talk about Javascript, Backbone.js, jQuery, kind of the slew of front end frame works. I know we’ve talked a little bit about Backbone in past interviews here on the site point pod cast and that was a really, really good interview. Go listen to it if you have a chance I believe it’s like episode one forty something. So, you have experience in JQuery and Backbone and a lot of cool tools so I wanna give you a chance to answer some questions around that I think the audience will find very useful. But before we do that I want you to tell me about yourself and maybe those listening, so that we can an idea of where your experience lies.

Mason: Yeah, so, hey my name’s Mason Stewart. I usually go by the monocular Mason Desu, and always the same little green avatar with a beard guy on it, that’s me. Anyway, yeah, I write a code for Zarlee. I’m a Javascripter full time. I probably write ten lines of Ruby a month, even though we’re a ruby shop we do a huge amount of Javascript as well and so I spend most of my time in Backbone js. We do everything in coffeescript. I spend a lot of time doing the architectural work for the Zarlee Javascript ecosystem. I spend a lot of time dealing with our modeling’s the way we we’re modeling our data on the front end, the way we’re displaying that through the views and the controller logic and all that stuff. But, I definitely do my fair share of DOM manipulation stuff with jQuery and things like that. It’s definitely a little bit more computer science kind of stuff ,than I’ve done in previous jobs before. It’s a lot of thinking about classes and bigger picture architecture stuff.

Kevin: You mentioned Zarlee and that you worked there, but what is it Zarlee?

Mason: Zarlee, there’s a whole lot of different ways that you can describe kind of what Zarlee was and is. Basically, it’s a hyper local market place, and what that kind of means in plain English is that we have a platform where you can say like “hey I need somebody to deliver like three dozen cupcakes to this office party we’re having and we’d like them to be homemade and, you know, peanut butter chocolate chip”, whatever. Then that sends out push notifications to everyone around and you can do it for any kind of service or thing you need. I had somebody help me haul some lumber on Zarlee, because my car isn’t big enough to move it. So I just basically got on Zarlee, said “I need this at this time”, and I pushed out a notification and a really cool dude showed up and helped me unload all kinds of stuff. We’re also coming up with some really cool seller tools to make that an easier thing for sellers too. So, you can say like “hey I’m a painter I can repaint your exterior of your house for X number of dollars” and that’s something they can almost sell. It’s a service that they’re offering to a number of people verses just a one-time thing. It’s a really fun platform, it’s a really fun platform to work on.

Kevin: Right and most of your interaction is all clients’ side right, because you’re using Backbone, so it’s very fast very slick?

Mason: Yeah, so what we do, we have like obviously very complicated modeling for all of this in the back end. Backbone allows us to replicate the parts of those models that we need. So, you can pull down your user model or a model for a listing and the listing can have all of its meta information, it’s price, it’s location, and who asked for it, and what time, and all that sort of stuff. We’re able to have a really rich kind of ecosystem of information and chunks of data locally on the client, and Backbone makes that pretty much a dream come true.

Kevin: Pretty cool, so, get into kind of the grass roots with where you started with all this because every person’s story that I’ve ever heard is always has some interesting detail of how they got into the web because it’s so young and it’s so new and it’s so exciting and it’s rapidly changing. I was wondering if you could tell us a little bit about how you got into the front end inside of development. Did you go through school?
What was that whole process for you?

Mason: Yeah, for me I’m 28 years old and I think when I was probably 14 or 15 I started writing HTML.

Kevin: So, he’s got 14 years’ experience at this point.

Mason: Well, sort of but.

Kevin: If you count those early years, right?

Mason: If you count using the blink tag as experience.

Kevin: That’s experience, I put that in my resume.

Mason: Yeah I have used the blink the flame tag and the Marquee tag. So, I started out doing HTML and doing like python scripting and pearl scripting back in the days when we had like CGI bins.

Kevin: Yeah, no big deal. I’m 14 just writing this awesome code.

Mason: Real dorky stuff. Loved computers, had a lot of fun, had some cool jobs, but basically when I was like 20 I was like I don’t want to use a computer anymore. I’m done sitting behind a screen so I just quite cold turkey for about 5 year, didn’t write a single line of code.

Kevin: Not at all?

Mason: I moved to Japan, hung out, worked in an orphanage, did a lot of stuff, and then I came back and I was like you know what, I might write a little code. I kind of stumbled into a little job writing code at this shop. A really tiny shop, and kind of caught back up on like 5 years of web development over the course of a couple weekends. From there I kind of jumped in after jQuery was already in full swing, after CSS was everywhere. When I left, CSS was just kind of a twinkle in everyone’s eye. Then when I come back it’s everywhere. It was really kind of a cool time. I felt that was a cool time to jump into to web development. Now, I look at the resources that we have available now, and I’m just like gosh. This is literally the best time for anyone to be. I look back at the bozo stuff we did 10 years ago, and I’m just like, you know, that was horrible what we we’re having to try to pull off with tables and stuff. Now, web development is such an incredible experience.

Kevin: Yeah, absolutely, it’s really nice to see all these tools like you’re mentioning and Backbone being one of them jQuery being another. Some of the kind of questions that people will ask is, I’m just getting started like you did and now that all these tools are available should I approach it from the language first or should I go for the framework first and just kind of learn the language off of that. What would be your advice for somebody in that situation? Should they go for Javascript the rudimentary fundamentals? Obviously you have to understand loops and statements and that kind of thing but like to learn Javascript as like reading a DOM or should you go for jQuery or Backbone if you’re doing an app? What should you do?

Mason: For people just learning Javascript or even just like just coming to development it’s kind of a wild world because now we have all these dialects, I guess, of which I’ll describe it’s really more like languages that compile the Javascript. If you were coming to development form the get-go you wouldn’t know like should I be doing Javascript with closure scrip, or should I be using coffeescript, or iced coffeescript, or.

Kevin: What are those things that you just mentioned, those three?

Mason: All of those languages are, they’re languages that compile down to Javascript.

Kevin: Right. Sort of like PHP will compile down to HTML. In a way they’re pre-processors right?

Mason: Yeah, well, it’s I’m sure there’s some super neck beard computer science term for what they do. Basically coffeescript is a language that going to generate Javascript. And coffeescript has some syntactic sugar and some things that really make it fun to write. You don’t have to deal with semi colons and as many curly braces. coffeescript is very powerful. So, yeah, it’s a great tool but as far as getting started I would say if you don’t get Javascript you ultimately won’t get coffeescript either. There are some basic things in the language that you can’t escape no matter how much you abstract it. I think really if I had to say oh you’re gonna start from Javascript, with Javascript you know nothing. I would say there’s a book called “Eloquent Javascript” you can read it for free online.

It’s fantastic. It has this approach that says let’s look at Javascript as computer science. Because so many people make the mistake of thinking that Javascript is just a bunch of moving the DOM around and if you’re really new to development the DOM is basically document object model, nerdy acronym. But it basically means all your HTML. So, if you’ve got a red box over here on the right and you move it to the left, you can use Javascript and say when I click this thing move it over here. That’s an important thing that Javascript can do is interacting and moving HTML and CSS around and rendering HTML and CSS but that’s ultimately a very small part of Javascript. I think starting with something like Eloquent Javascript, which focuses on the language itself and doesn’t really get to the DOM until like chapter 10 the last chapter I think, is a really great place to start.

Then I think you know there’s nothing wrong with messing around with jQuery or any other library or frame work. JQuery is an incredibly powerful tool set and extremely useful. You don’t have to know every little detail of Javascript to use jQuery. Ultimately if you never do anything other than copy and paste jQuery from other people’s sites I don’t think you’ll understand the power of Javascript. I don’t think you’ll be able to deal with real world problems. I thinks it’s kind of a mix of both. Interspersing, actually training yourself in the language, with doing some of the stuff that is pretty highly abstractive like jQuery or coffeescript, that’s my take on it at least.

Kevin: Right. To further your point about this topic. Whenever I approach the situation I kind of tend to advise designers that yeah can probably just use the plug-ins and do a little with jQuery and you’ll be OK. So, if you’re like Marco, right you don’t know about code, well you know enough about code to be dangerous right but you don’t, you’re not an engineer. And, there’s a difference. I think there’s a line being drawn these days, between two different types of front end developers. You have your front end designer who interacts with the design mostly and the CSS and maybe some jQuery effect and you have your front end engineer who can do all that stuff and all of the modeling and view and like abstracting like you’re talking about and doing more with Javascript then just DOM manipulation.

Mason: Yeah, I think so, also, sorry to Marco, Marco Suarez, we love you.

Kevin: You got to call him out man.

Mason: Marco really does know how to code. He actually writes some pretty good deal code for Zarlee, but he’s one of our designers and we pick on him sometimes. But he is a good coder. Marco is a great example. Marco is an incredible designer he knows his way around HTML and CSS really, really well, and can certainly get stuff done in jQuery. Is Marco gonna sit down and write like an epic Backbone controller, no, but that’s fine.

Kevin: That is when you don’t even have to know what that means.

Mason: Yeah, that is definitely a good distinction and it really just depends like where you want to take things. If you’re the kind of person who loves to take apart watches and look at all the gears and see how things work then you’re probably the sort of person who’s going to want to build strong jQuery plug-ins. If you’re the kind of person who really loves the exterior of the watch and the sleekness of the watch and how it moves and all that stuff, then you may be still be a good Javascripter, but you may be the kind of person who’s much more interested in just making the user interface work right. There’s room to kind of explore both of those. I think it’s only been in that last year that I’ve been really really deep into Javascript Architecting verses doing a lot of HTML and CSS with some fun Javascript stuff but it wasn’t stuff that was validating data and sending it up to the server and parsing the response.

Kevin: Very utilitarian. Yeah, mostly just effects and that kind of thing.

Mason: Yeah. Because of – at Zarlee, I’ve by necessity had to get much more deep into the inner workings of Javascript ecosystem, but, so far it’s been a lot of fun.

Kevin: So, to kind of sum it up really quickly, designer, you can start with jQuery right?

Mason: Mm-hmm.

Kevin: And then if you want to go more development route, then you probably need to start with Javascript first.

Mason: Yeah, I think those are great places to start and either one of those will overlap ultimately. If you give it more than a couple of day. I find that for any new thing I really want to learn about three weeks of constantly working on it if I can pass the three week mark I’m probably gonna stick with it. So, sticking with Javascript even when it seems confusing and sticking with jQuery even when you have no idea what you’re doing ultimately you’ll get through it.

Kevin: Yeah, it’s about putting the pedal to the metal by not running out of gas to quickly right.

Mason: Yeah.

Kevin: You want to have a little balance there. Now, were you focused a lot on jQuery and just the basic Javascript and like kind of the encouragement side of things it’s get out there and try it because it is fun? It’s really exciting to use that use that stuff to get to see your page change. I tend to do this all the time. I have to admit I’ll make like a little sweet effect using jQuery something and I’ll take that button like 50 times once you get going and out, you know what I mean.

Mason: Exactly.

Kevin: There’s like that side of the reward and then there’s the side of like I’ve used this framework and I’ve gotten to know it. I’ve gotten to know Javascript. What’s the next level? Then you start running into things like templating, right, for kind of using Backbone if you will. So, you have like Mustache and Underscore and you have things like Ember which is another NVC kind of based thing. Then you have Backbone and you have Twitter Bootstrap which is kind of like more design centric. They have some Javascript elements in there. All these little frame works is what I’m getting at. What do you do? It’s not just jQuery that’s out there. Where do you kind of go from there? Is it project based like how do you decide what framework to use?

Mason: Basically, my attitude is use anything that comes out. Give it a shot. It’s not gonna kill you for one website or one smaller project to just pick some random tools. Back when Paul Irish came out with HTML5 boiler plate, he and Divya, I just said OK. I’m gonna build a site off this. I had a couple of sites to build and did it and it was great. I loved it. I learned a huge amount from that project. I built a few things with Twitter Bootstrap and learned a ton from it. Would I use either of the projects in every project I do? No. I don’t think Zarlee is actually using either of them right now. But, if we needed whip up something brand new, a brand new little micro site with Zarlee, yeah, those might be great tools. Really it’s just giving stuff a shot. For instance at Zarlee we use, for our Javascript templates, we use haml coffee, which isn’t super popular which I don’t know why because it really fantastic it’s basically haml with inline coffeescript, instead of inline ruby which is super powerful and just great syntax. But, we just kind of went with it on a whim, we said this looks really neat let’s give it a shot and if it sucks we’ll rip it out and do something else. Let’s build a few things with it and we did. So really the best I can recommend is just try stuff. It won’t kill you to get into a framework for a few weeks. It won’t kill you to mess around with a plug-in or a library, give it a shot.

Kevin: Right. Definitely we’re past the days of do it from scratch. That used to be kind of back when jQuery was still sort of in its infancy. You had prototype and all these other things but people were still kind of rolling their own sets from scratch.

Mason: Sure.

Kevin: Mostly to deal with browser compatibility. But we’ve kind of moved past those days and we’re in the like the century or the decade of frameworks and Javascript frameworks in particular. I would definitely say and agree with you, just pick it up and try it because you have nothing to lose. If you don’t like it go try another one. Try templating some frameworks, Underscore Mustache like you can pick underscore you don’t like Underscore use Mustache right. If you didn’t like Backbone go use ember.

Mason: Exactly, yeah. You’ll know pretty quickly if it’s either not appropriate for your situation or if it’s just a piece of junk. Just scrap it and especially because we have such a modular kind of approach to web design. If you’re building something with rails just include the Gem and if you don’t like it remove the gem and if you’re building something with Node bring it in with a package manager if you don’t like it get rid of it. Obviously I’m not advocating just frivolously adding all of this junk on your project. You don’t need every, you don’t need to be using 60 different templating systems in your Javascript, but if you feel like you might gain something or even learns something give it a shot, definitely.

Kevin: Yeah. I think that’s really sound advice, when you’re talking about experimenting. A kind of an experimental physique or facade about you, right. You just want to get out here and kind of play with the play dough and see what happens.

Mason: Sure.

Kevin: That’s a little bit about frame works and I wish we could dive more into those but they’re so unique and so different. It really just comes down to using them. You’ve really hinted a lot at things like coffeescript Sass and I know LESS is another one and there have been some people who have been kind of adverse to that and I don’t necessarily want to do something that’s taking the control away from them to kind of use these tools. It some context that’s true, right, because you don’t always want to use these pre-processors in some cases, especially like smaller projects like a plug-in for jQuery. You don’t want to integrate a bunch of the frameworks into a plug-in that needs to be small, or, like a script that you want to just kind of share. Where do those things come into play and are they good or bad or it’s it kind of circumstantial?

Mason: With Sass, Compass, SCSS I can safely say by time I only got to write like four lines of CSS I’d really prefer to use the Sass pre-processor for all style sheet stuff because it’s still ultimately CSS. It’s CSS just with the missing stuff. Some things that really would have made of made our CSS great five years ago. There’s really, in my mind, as long as you have a set-up that allows for that pre-processing to happen, whether you’re pre-processing locally and then push it to the server as it’s already processed into CSS or you’re doing it on the fly either way, I would say definitely yes to that. As far as coffeescript goes I would say the threshold is a little bit bigger. If you’re going to probably write 100 lines of some really simple Javascript, probably don’t bother with coffeescript. coffeescript is great and it’s great for even a few lines but keep it simple. Like I’m rebuilding my website with closure and Noir as the framework and I’m only gonna have like 30 lines Javascript on it so rather than do it in Closurescript, which is kind of the normal Javascript language in that environment, I’m probably just gonna do regular Javascript. There’s no need of for me to have like as cool as Closurescript is I just don’t need it for that small of a situation. So, really all of this stuff comes down to are you going to use it and what would your development process look like if you didn’t use it. Because there’s no shame in using raw HTML or raw CSS and raw Javascript. In some cases that’s preferred.

Kevin: The big issue that I would really like to talk to you about here is the integration of these pre-processors into things like IE’s and like for example Fire bug, if you’re using Sass or LESS you can’t exactly just inspect them and say this line is code and get that precisely. There are a lot of tools that have been built around the static flat file and then on top of that you have to be able to compile those pre-processors. So, you have to be able to compile Sass, LESS compile Coffeescript and for those people I do want to point out that there are like apps out there specifically for Mac. I’m not too familiar with the Windows side of things but you can get things like code kit or I think there are some other ones out there. So, don’t be threatened by the compiling of this stuff it’s super easy to just find the app, download it, it’s worth the cash. Usually there about $20 so do be afraid of that. But, I want to focus more on like the application side of right the IDE not picking up on this kind of thing or you know. What’s your take on that like is that big enough of a down-side to not using these things?

Mason: No. I honestly don’t feel the pain at all. The reason is, at Zarlee we use SCSS, and in development mode I write some styles for something and then I hit inspect element. I see the generated CSS, but if I hit, it will say at line 500 of main.css if I click right there it will show me in the comments right above that block exactly where it came from in the Sass.

Kevin: Which is awesome.

Mason: So to me, that may sound or even confusing being spoken, but once you see it, it makes total sense. It basically gives you a very clear place to go back to. A lot of people are really starting to look at source maps now. Source maps allow you when you inspect elements to see where it really actually was in the original pre-processed coffeescript or SCSS or closure script. Basically whatever you’re trying to use if you look up the source map availability there may be really great resources there. But ultimately, I think it comes down this. If I write something in coffeescript and I get an error in the generated Javascript it’s never going to be something so different from what I originally wrote that I can’t tell where it was. coffeescript is going to add a few extra little bits of syntax, it’s gonna maybe do a little of magic to fix scoping issues, but ultimately I’ll still know where it is. If your familiar with your code and you’re writing your own code and not just copy and pasting a bunch of plug-ins it’s gonna be pretty obvious where it was even if the compiled source is very different form your pre-compiled source.

Kevin: I like how this conversation has been kind of leaning more towards Sass because I have used LESS in the past and the more and more I use Sass the more and more I understand why it’s kind of superior to LESS. LESS is appropriate, don’t get me wrong, but, it’s more appropriate for smaller kind of projects. When you use Sass like you’re mix-ins don’t actually become like a class that’s just empty in your style sheet that kind of thing. There’s a lot of little tid-bits that happen because of that. Like you were talking about compiling and like the comments like all that stuff, if you were to state the differences between LESS and Sass, LESS is easier to write and it’s kind of nice to start there but eventually you want to go over to Sass I think.

Mason: Yeah. I think that’s a fair approach.

Kevin: So that’s kind of pre-procesors and I think we’ve the technical no no’s out right so you can definitely use these tools and not run into really big issues. There’s gonna be like an extra step but not like ten extra steps and leave you clueless when you’re using these things. I think personally that they just remove so much cruft out of your coding to begin with. Like you were saying you can kind of just go and look an know. When your writing coffeescript you may write 50 lines of coffeescript and you have 200 lines of Javascript so it’s easier to go through 50 lines of coffeescript than 200 lines of Javascript. It’s good in that way. But, then there’s the other problem with these pre-processors. This has a lot to do with front end development, as things move along I think we’re going to be seeing more and more of this so I really want to touch on this. Which is, getting those tools to a team, so, let’s say you’re the new guy on the block and you’ve just come into a company or the start-up like you’re at, and they’re using one tool and it’s just the flat files and you’re like hey guys we should really use Sass it’s gonna help us. How do you get people to buy into that because when you have a bunch of people everyone has to use it, right, because if they start editing your compiled CSS if you compile over the top of that their stuff is deleted, big problems there. How do you get people to come into this or is it one of those where you just hope and pray that it’s already there and somebody else is using it.

Mason: We’re really lucky at Zarlee, because everyone has an attitude of let’s use the best thing for the job, even if that means switch out major technology for this other technology. Again, within reason, we’re not constantly switching from closure to ruby to .net. We’ve never switched to .net sorry.

Kevin: You might.

Mason: Sorry with a jab. But, we’re not constantly switching everything out but we’re more than willing to say like “hey this gem sucks we’re gonna swap this out” or “hey this templating system is causing so many problems” or “hey this jQuery plug-in is a complete joke, so we’re just going to rewrite it ourselves.” We have, that’s a really good culture to have but you don’t always run into that when you’re working on different teams with people. I think the best the thing that you can do is the proof is in the pudding. You can tell people look I accomplished so much here in these 20 lines of coffeescript. underscore.js kept me from having to write these inefficient silly methods that it already did so much better than I could do. There’s all sorts of, actually just looking at what comes out there’s honestly times that coffeescript generates better Javascript then I would have written on my own. I think that’s one thing and I think you know there’s always kind of the hipster factor of what’s popular and not. I do think that there are really specific reasons that people are using things like underscore.js. David Nolan from New York Times was telling me that they start all their Javascript projects at New York Times with jQuery and underscore and there’s a reason for that. It’s because both of those tools are tried and tested and they’re fantastic. I don’t know if there’s any one way to like pick the best tool or for everybody to agree on the best tool but what I think is very helpful is even if you can’t use it globally if you can’t use it in the whole group use it yourself. You can set-up Sass to run locally and just compile everything locally then you can just take the generated CSS and use that. Obviously that has its problems ultimately but there are a lot of small tools you can use on your own and it just depends but honestly I think the best thing is this, if you go to an organization or a group of people and they’re using a bunch of bozo tools that don’t do anything helpful and they’re not willing to budge on using some cool new tech then probably you should just go somewhere else anyway. There’s a lot of companies that get stuck on very rigid ways of thinking about their tech and I think it’s very damaging to the quality of products when you’re not willing to say hey this was cool two years ago but now this tool isn’t really that great at all.

Kevin: Dang that jQuery, I hate it.

Mason: Well, we actually, really interesting at Zarlee we did actually swap out jQuery for Zepto for a few months.

Kevin: What?

Mason: Except for IE obviously.

Kevin: That’s crazy.

Mason: Yeah. We just.

Kevin: But you did it.

Mason: We did it we tried it. I respect Thomas Fuchs and the whole Zepto team they’re super smart and the source is really great and I respect the hell out of jQuery team too. Ultimately we switched back for a number of different reasons, but that was a great experiment. I love Zepto and would use it in some other projects but as far as dealing with some of the extenuating circumstances that Zarlee with supporting IE and everything we ultimately just said we’re going back to jQuery. That kind of attitude as long as it’s not completely out of control is, you know, just test it and see. Give it a shot.

Kevin: I think you’re absolutely right there the proof is in the pudding. The best thing do is if, I think, if there’s like an internal project that’s really small or maybe you’re throwing together like a word press site that’s gonna be fairly simple and straight forward, I think you can probably get buy-in on one of those projects, probably not the bigger ones because people are kind of adverse to change to begin with. So kind of turning into a fun kind of thing verses a do it my way kind of approach so I think that can help as well. We’re running low on time. We actually did get through all the good questions. So, this is absolutely awesome. I have a few questions for you and then we can wrap up.

Mason: Sure.

Kevin: Number one how did you grow that awesome beard? That is amazing. Is there like Miracle Grow or something.

Mason: No, it’s just a fast growing beard.

Kevin: It’s a fast growing beard.

Mason: Yeah.

Kevin: Very nice. Where can people find you or can they get in contact with Mason and find all of his awesome creative ideas?

Mason: Sure. Best ways to find me generally is on Twitter @masondesu, M-A-
S-O-N-D-E-S-U, just like it sounds. You can go to my site at I haven’t updated it in quite a while in fact I think some parts of it are actually pretty broken but there is a cool pixel art version of my face with a rainbow beard that you can click on. Just click view best feature on the top left and my head will pop with a rainbow beard.

Kevin: That’s very cool man.

Mason: That and Twitter I think are the best places to find me.

Kevin: Great so there’s your inspiration, rainbow beards. All right, well, Mason thank you so much for coming on this show. It’s been an absolute pleasure.

Mason: Yeah, no problem.

Kevin: Really smart guy and I think you’ve proved to the world that you’ve got the chops.

And thanks for listening to the SitePoint Podcast. If you have any questions or thoughts about today’s show please feel free to get in touch. You can find SitePoint on Twitter @sitepointdotcom, that’s sitepoint d-o-t-c-o-m. You can find me on Twitter @kevindees, and if you’d like to leave comments about today’s show check out the podcast at, you can subscribe to the show there as well. This episode of the SitePoint Podcast was produced by Karn Broad, and I’m Kevin Dees, bye for now.

Audio Transcription by Speechpad.

Theme music by Mike Mella.

Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.

You might also like...



Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“The difference between theory and practice is smaller in theory than in practice.”