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

Episode Date: June 21, 2011

Adam and Wynn caught up with the developers behind CDNJS, a community-powered CDN for JavaScript libraries.

This week's episode is sponsored by TweetBot, a full-featured iPhone Twitter client with a lot of personality. Whether it's a meticulously crafted interface, sounds, and animation, or features like multiple timelines and smart gestures, there's a lot to love about TweetBot. You can find TweetBot in the App Store, or head to tap.3. I'm Adam Stachowiak. And I'm Winn Netherland. This is the ChangeLog. We cover what's fresh and new in open source. If you found us on iTunes, we're also on the web at changelog.com. We're also up on GitHub. Head to github.com slash explore.

You'll find some trending repos, some feature repos from the blog, as well as our audio podcast. And if you're on Twitter, follow ChangeLogShow and me, Adam Stack. And I'm Penguin, P-E-N-G-W-I-N-N. Fun episode this week. Talk to the guys at CDNJS, more Aussie JavaScripters from down under. Yeah, apparently they don't do much with sports, so they dig deep into JavaScript. That's kind of a national pastime, so we're gathering down there.

The CDNJS project's pretty interesting. It's a way to put, I think, maybe I won't say B team, but the second tier JavaScript frameworks up on a CDN for the world to share. Absolutely. They also announced some good brand new sponsorships. So stay tuned for that in the show. Absolutely. Speaking of sponsors, we're glad to be part of Fusion Podcast Network now.

That's right. So our second episode up on that and excited to be part of that excellent network. Where can folks catch up with us? Well, on the blog, thechangelog.com, and on Twitter, Changelog Show. What about in person, to come up and say hi and get a Changelog sticker? Oh, yeah, that's right, Big D. Big D Conference, Design Conference, is one of the better design conferences that I've attended right here in Dallas.

You'll be up for that. I'll be up for that as well, yeah. It's in July. And then we've got Lone Star RubyConf in August. Looking forward to that. Always. Always. It's a fun episode this week.

Should we get to it? Let's do it. We're chatting today with the folks behind CDNJS, Ryan Kirkman and Thomas Davis. So Thomas, why don't you go first and introduce yourself a little bit about your day job, and then we'll let Ryan introduce himself. No problem. Thanks for that. So I'm a 21-year-old from Australia and a heavy JavaScript developer at the moment. I did a computer science degree at a university,

and I've been freelancing web development for the last three to four years. But I started when I was 14, so it'll be my eighth year of web developing so far. How long do you usually speak for, sorry? That's fine, Ryan. I'm still in shock about the eight years of experience at 21. Yeah, no, that's great. Yeah, so I'm a little bit like Thomas in that regard. I did a software engineering degree at UQ,

University of Queensland in Australia. So I guess I've been making websites not as long as Thomas here, but for quite a few years now. So previously, I've been doing JavaScript development, much like Thomas. We've been working together for the last six months. And yeah, so we started CDN.js one fine day when we decided the web needed to be a faster

and easier place for web developers. So we'll get into CDNJS in just a moment. Our buddy Michael Smith from Down Under is a JavaScript child prodigy himself. Is he even 20 yet, Adam? I don't think he is. I don't think he's even able to drink.

I want to know what it is about the Australian culture that just breeds JavaScript developers. Do you guys just not have basketball or rugby or something else to occupy your time these days? Well, I guess we don't have as big sports advertising budgets, so we have to turn to the internet for our entertainment down under. So CDNJS, for the folks that don't know,

give a little background around this project and what it aims to solve. All right, so yeah, basically we started CDNJS one day when we were just pumping out websites and we were finding that we had to copy these scripts over and over to all of these different websites. And we were using the Google API CDM, and that was a fantastic resource. If you want jQuery, it's fast. It's the latest version, and it's probably on a server pretty close

to your location. So it's perfect. And we thought, you know, we're using things like backbone.js, underscore JS. Wouldn't it be cool if these were on a CDN? Now, the Google CDN, you really have no avenue for adding a script to that. So we thought, you know, why isn't there a place where you can add your favorite script or a popular script? We also went on the Google forums to suggest scripts, such as Backman and Underscore and other pop-up JS. But the actual Google forums, even though they have 500 upgrades to upload a script,

they weren't very receptive in that manner, which was fair enough. They are each company, but it seemed like something that was required. So we basically wanted to build a service that was community-driven and that responded much more quickly than anything else that's out there. So CDNJS is the result of that. Since you talk about quickness, what is the response time for, say, me forking and adding my favorite script and or library and it being live and available?

I mean, assuming we deem it appropriate for CDNJS, as in it's got significant community backing and it's popular and well-respected, I mean, turnaround time is 24 to 48 hours. Do you... In terms of being well-respected and popular,

is that your say, or who gives the final cut on that? Well, we do have quite a bit of say at the moment because the community isn't really large enough to show the real numbers behind how popular a script is. But eventually we have a user voice account where people suggest scripts they want to upload, and we would prefer in the future not uploading a script

unless it has over 1,000 or 2,000 votes to be included on the CDN. The more scripts we upload that are possibly obscure or not even quality means there's a lot more maintenance as far as keeping CDN.js a worthy tool. So basically you have a prerequisite for okay, if your project has this much reach or this kind of community behind it, then it's probably a good fit for CDNJS.

Yeah, that's exactly what we're aiming for. So right now, it's kind of like we're aiming for a meritocracy, but at the moment we basically have two benevolent dictators for life, but we prefer to move more towards the meritocracy type approach as we gain more traction. And from what I understand, you guys are a nonprofit. So this is a nonprofit initiative.

It's something you guys started. Is this something that's – I mean, Thomas, you said you're 21. And Ryan, I didn't catch your age, but you're probably just as old, right? I mean, this is kind of new to you guys. What got you into this nonprofit scene? Is it just about CDNJS or is it, where do you plan on taking this particular initiative? I mean, CDNJS from our perspective was just about sort of helping the web developer community and sort of making the web faster by serving these scripts on a CDN.

The nonprofit thing was just, I don't know, I don't really think that a resource like this should be for profit. And it seems like it has much more benefit for everybody, especially the community, if it is a sort of community-driven thing and they have the ability to sort of review anything that we put out there. At the very least, it was an attempt at innovating the web or getting a collection of scripts into a CDN. It didn't really, we weren't overly concerned as to where we took it.

Like we didn't expect to go global. But I think everyone that's in this audience should know what a CDN is. In case we have some folks that stumbled across the podcast and don't know, what is a CDN? A content delivery network. So basically, if you have a JavaScript library, let's say jQuery, everyone should have an idea of what jQuery is. And you have your servers, let's say are in America, but you have some poor souls like us living in Australia. Your website is probably going to load a bit slower. So what a content delivery network does is they might have some servers in Sydney, which is much closer for us kangaroo riding people.

And so our scripts are going to load much faster if we have servers in our country than us having to go all the way across the ocean to grab the scripts from American servers, things like that. It also adds in fast-safes to file loading. Like if your server can't find a file, if it fails at one location, it will choose another location to serve it from. And, yeah. So typically in the past,

these things have been for private assets that are kind of on an application-specific basis, right? So I guess what makes CDN.js unique is that you guys are offloading shared resources. Yeah, so I guess things like, if I understand you correctly, things like CloudFront have opened up that previously sort of private CDN type thing. And, of course, our sponsoring company, CloudFi.

Yeah, so traditionally, Akamai, I guess probably the pioneers of the space, provided their servers and bandwidth for fees to put assets closer to users for applications, but it was pretty much everybody had to rent that space and rent that bandwidth, and it was just much everybody had to rent that space and rent that bandwidth. And it was just a matter of serving up your own assets. But I guess what makes this unique is that you're serving up assets that, since they're common frameworks, multiple applications can take advantage of those. Yeah, definitely. So Cloudflare, our new partnership, they aim at improving the web and they synchronize

a lot of common resources across websites. And so it only made sense to synchronize these common shared JavaScript libraries and make them load much faster for all users, which takes a lot of strain off developers also. Now you put JS right there in the name, but are you going to look at any other types of assets other than JavaScript, maybe CSS or other frameworks? I mean, that's a possibility in the future,

but right now we'd sort of like to focus on the JavaScript side of things. I guess the service is still quite young. It's only sort of, you know, half a year old at this point in time, so it's still in its infancy. So we're just sort of trying to find a fit for it in the open source world type of thing.

There aren't particularly too many shared CSS resources either. I could probably only count two myself. So we're just sort of trying to find a fit for it in the open source world type of thing. There aren't particularly too many shared CSS resources either. I could probably only count two myself. Well, you start talking about some of those shared other ones besides JavaScript. You've got Cached Commons, which does things like Swift files as well. And I think it's mostly JavaScript, but they seem to have a couple additional libraries beyond fonts and markup and text editors. It's not just JavaScript. How is this different than, say, Cache Commons?

Essentially, Cache Commons and CDN and JS aren't so much different in their vision or their goal. It's just that Cache Commons was originally, and I think it still is, hosted on GitHub, which means it's probably not leveraging a content distribution network, and if it is, maybe not as effectively as we're able to because we actually sort of control the content delivery network that we're using. And I think one of the things that we aim to try to solve too is we're trying to sort of move

quite quickly in terms of keeping our libraries updated and sort of accepting new pull requests. So I think that was a problem that people have found in the past with other solutions. I think we've also, we also try to involve the community much more. We like to make it as community-involved as possible. And we actually have quite a lot of people who do support CDNJS, and I guess we'll have a shout-out to everyone that thanks us for helping out with Fork Request. On the note of Cash Commons, too, I've chat with, in the back channel about a week back with Lance, the guy behind Cash Commons. And he is actually discontinuing that project.

He said he's been focused on his company, getting it off the ground for the past eight or so months. So he hasn't had much time to dedicate to Cash Commons. And you can probably guys validate this, but he said he's talked to you guys about CDNJS and where it's going, and he's hoping to possibly lend his contributions when he has time opened up. But pretty much he thinks you guys have a solid plan, and he says whatever is 100% free, clean, up-to-date, and user-driven is awesome, so he's all for it. Yeah, it's been fantastic talking to icons in the community like Lance, and we're really

looking forward to working together with these big names in the community just to push this forward, as you say. And everyone seems to be pretty excited about where this is going. So yeah, we're pretty excited as well. Do you have any standardization on uh minification or packaging formats for these javascripts so currently we're using uh common js package formats it's a initiative that someone started i couldn't credit it sorry but uh node js packages Node.js packages NPM uses the same format I guess and so we require all our forks to contain a package.json which just lists the basic information about the file such as author,

the authors, the file name, a few tags about what the library is, a short description of what the library does. And so each one of our libraries has one of these packages.js associated with it, and we pull that information in to use it on the client side for the website, and tools such as CDNJS command use these packages.js to generate useful information, which helps developers choose which libraries they want to implement. And you mentioned minification in there.

So our policy on minification is that we prefer the library maintainers to take responsibility for that. The reason for that is if we use a minifier that for some reason breaks a developer's library, we don't want to be held accountable for that. So by and large, we much prefer that libraries are sort of minified and preferably in the repository that they specify in their metadata. In some rare cases, we will minify libraries that don't have any modified version available. You mentioned Google's CDN earlier.

On the Google site, you've got a couple different options to reference these applications, or the frameworks you can link to them directly in the head or you can go through their script loader. How can you reference these packages from CDN.js? So at the moment, you have to do it manually. The URLs are included. You have to copy them into your code manually, sorry.

We're working on tools such as Google, well, JavaScript loader to implement them. But at the moment, it's not quite necessary, and you can already implement your own loader and just use the CDN URLs to load the scripts, I guess. We will actually be working on a tool that lets you download the local files also. So if the CDN ever goes down for some bizarre reason,

like Google CDN has gone down before, for example, we're making a tool that lets you back up the local files, and if the CDN link fails, it'll fall back to the local script. And HTML5 boilerplate by Paul Irish actually implements this for the jQuery. If the jQuery CDN fails, it implements the local jQuery file in the HTML5 boilerplate. How are you guys handling versioning? Yeah, so this is another thing that we prefer library maintainers to take responsibility for. Most scripts will generally have a version number.

For example, with jQuery, we're up to 1.6 point something right now. Almost every other script that we have on 2DNJS right now has that sort of a version number. And, I mean, that's available as part of the URL. So, I mean, it's sort of, I guess, it's fairly obvious which version of the script you're using. What about older versions? How long are you going to keep older versions around?

So Cloudflare, our sponsors, they will be hosting the files indefinitely. So any files that are uploaded at any stage will remain there forever. So you can think of it as a write-only file store. Anything we put in there is going to be in there forever, essentially. What about package management or dependencies among these? I noticed that MicroJS tends to be getting a lot of play in the JavaScript community lately, and with Ender you can basically roll your own little micro framework. Any plans to mix and match and cache those versions?

So personally, CDNJS will probably already be enough for us to maintain. Building a dependency package manager is possibly too much work for us to handle and update. So, again, we would prefer it be a community initiative. So, things such as CDNJS command built by RSTA

CRUZ, he may possibly implement dependency management, but we'll probably prefer the community-generated tools that handle such things. So you've got to be doing something with JavaScript to get into this particular project. So what are you guys actually doing with these frameworks?

We've been working on a product of ours. It's a web application, but we'd prefer not to announce it on here but basically it's made exceptionally heavy use of quite a few of the libraries that we host on CDNJS and it was our initial inspiration

for sort of creating the service. So it's a single page web application built using Backbone.js by Jeremy Esquinas. And we use Node.js for the server and we use CouchDB for the database. And CouchDB relies on JavaScript for the views and queries.

So it's pretty much our entire code base is JavaScript at the moment, 100% on GitHub, actually. So yeah, it's JavaScript all the way down. Don't want to announce it on here. What are you waiting for? Wake up Sydney? Well, it's only in beta, and we're possibly ashamed of it at the moment, but it's called

Proposal, sorry. It's pretty much a fresh book for proposal generation. So instead of generating invoices, we generate proposals. And we like to aggregate the accepting and decline rates of your proposals. Doesn't seem that embarrassing to me. It looks pretty all right. From two developers, I mean, it looks just as good as CDNJS. Well, I mean, yeah, we have a fantastic designer here.

I'm not trained in design at all. We might have to pull him to the side and have a drink with him and teach him about SAS and Compass and frameworks and stuff. Speaking of drinking, that's your cue. What are you guys doing on the server? Node? Yeah, so the server is Node.js, and basically we're trying to make it a

RESTful service and effectively build our service such that we're using our own API to work with the client side. I mean the client side and the server side are completely sort of de-integrated so to speak. So at the moment Ryan actually is working heavily on Node.js

and I prefer to stick to the client side. And we prefer to make our projects independent so that my client side can interact with anything Ryan throws at me through his API. Is that API documented anywhere, or is that something that's public that we can kind of trudge through? No, that's absolutely not at this point in time. It's still very much in beta and very much for internal use only at this point in time.

But that's definitely something we plan to look into releasing in the future. So I haven't driven into CDN.js command that Jim available to ping in there. How is he kind of pulling back different things? Or is he just hacking the URL and pulling back different data? Yeah, so he's actually pulling back the packages.json, which is included with each library. Okay. So he's using that information.

There's a concatenated version. There's a concatenated file which contains every single package.json in one file called packages.json, and you can actually access that through cityandjs.com. It's one of the resources that get loaded in. So I hear that you guys have a pretty good uptime. I guess this kind of leverages into what you're doing, Ryan, with Node and what you're doing in the front end as well.

But I go to your pingdom stats, and it's basically 100% uptime for quite a while now. What is it that you think that attributes to this percentage of uptime? Yeah, so up until now, we've been using CloudFront as our CDN. So essentially, CloudFront's just been rock solid. Yeah, really, that's essentially it. They're doing all the hard work for you?

Yeah, I mean, so with this service, we wanted to sort of stand on the shoulders of giants, so to speak, so to use sort of the best of breed sort of software and services out there to ensure that it's the best possible thing. Ryan and I actually live together and we argue for hours and hours on every decision we make. I'm surprised I haven't killed him yet, but it actually works out for best practices, I guess. So if, I guess, building a system like this, where are the common places, you know, a CDN in general, where are some of the common places it would break, and what are some of the things that you're using that mitigates and prevents that breakage? Yeah, so if we had decided to roll our own sort of servers or something, that would have been a massive task to undertake.

We would have had to maintain sort of the servers, do all that sysadmin stuff. So that was really impractical. We needed some way to focus on sort of focus on the product rather than focus on all of the administration behind the product. And sort of things such as Amazon Web Services have given us the ability to focus on sort of the product itself rather than the management and the housekeeping behind it. So that's really only been an option in the past sort of couple of years, which is really exciting, actually, that you can do something like this. But I was curious if you want to chime in with some questions about the recent outage

and how they're handling that. Yeah, so you're probably talking about the Amazon EC2. Yeah. Yeah. So that was a massive outage. But luckily for us, it didn't roll over into any of their other services. So Cloudflare and, sorry, not Cloudflare, Cloudfront and S3, they were completely fine, rock solid all the way through.

But again, I'm working on it right now. We will be implementing the local fallbacks. It's good to always prepare for any situation. And we'll be including the HTML5 boilerplate code for every library instead of just jQuery. And we will make it accessible to any users or developers who access cdnjs.com to download their files instantly and get the code that provides a local fallback.

And that will always at least be a fail-safe for any CDNJS outages. So I guess in full answer to your question, yes, if the infrastructure or the service that we're using to serve our files does go down, then all of our links will go down. But the fact of the matter is services like CloudFront and CloudFlare can do a much better job than we ever could. So we'd prefer to leave it in an expert's hands. I think at the moment CloudFlare is actually serving 2 billion or 3 billion page views a month.

Something like 65,000 requests a second or something. I'm not sure. So they're definitely capable of handling this did cdn as it is so let's talk about traffic for a bit here in terms of you launched in january it's now june so we're looking at just even six months um i can see your stats and i can tell the listeners what's what's going on here because you're actually linking to it. But give us a gist of what's happened in terms of the traffic and just general hits, I guess, files hits, page hits, and just overall traffic of CDNJS. Yeah, so, I mean, when we launched in January, for the month of January, we only got about 107,000 hits.

But since then, it's kind of taken off. We've had double-digit month-on-month growth. Sort of February, we were serving 500,000 scripts. March, almost a million. And by the time we got to the end of May, we're serving around 2 million scripts a month. This month, we're set to go way past that. So we understood the exponential behavior of a CDN that provides JavaScript libraries. So we've never actually publicized or advertised CDN.js

as with the first six months we considered to be like an iteration period, a bug finding period. And we've actually nutted out bugs in the past, which has been great. And it's better that we didn't advertise it to begin with. Otherwise we would have had 5,000, 10,000 websites going down just for a simple error that we would have encountered in the first week or two. We've come a long way since January, 3,000 hits a day to today about 90,000 or 91,000 hits a day. It's pretty exciting growth.

That's pretty good. I mean, this is obviously good growth. I mean, you're looking at over a million hits this month here alone, which is quite nice. The whole point of a shared CDN like this is the more people use it, the better it is for everyone because the chances of me hitting a site that's got a cached resource are better if you've already hit that site, right? Definitely. So if you look at the S3 stats that we have,

it actually gives you a number of three or four not modified. And what that means is how many times has a file been requested but is already cached on the server. And I think at the moment it's about 20%, 25% of requests are actually already caged on the clients. So the more that spreads over the internet, yeah, the better. So you guys have any overlap with the Google files or is it in everybody's best interest not to duplicate files they're already hosting? Yeah, so up until recently we hadn't, and that was one of our mission statements,

but we've actually sort of changed our opinion on that. We do offer the scripts that Google hosts and Microsoft hosts right now. I guess, I don't know, we're sort of turning into a more one-stop solution than an augmentation that we were in the past, because now we have sort of far more resources available in terms of bandwidth and hosting capacity. I was going to say, I mean, this was a non-profit started at first, but up until Cloudflare kind of picked it up and said, we'll host you for indefinite, like I should mention before,

I mean, that must have cost money. Was that something you guys were doing for the community? Were you paying for that at first and just hoping that sponsors would eventually pick it up? Yeah, actually, we were. So up until now, we have been personally funding this project. We went out of our way to actually approach lots of different CDNs, such as Amazon themselves, to seek funding.

And if that was going to fail, we were going to get community funding like possibly S.A.S. kind of plans for anyone who wants to use the CDN just to keep it alive. But besides that, yeah, we were going to fund it ourselves. Yeah, so luckily we had a few companies that were receptive to sort of sponsoring us. And, I mean, we had other options available, as Thomas said, community sponsorship. So it was never a particularly dire situation. It's just that long term we probably didn't have the capacity to personally fund it forever. But it's actually convenient.

Cloudflare is probably the most synonymous mission statement with CDNJS. They want to accelerate the web, and it's exactly what we want to do. They're rapidly moving ahead and we'd also like to rapidly move ahead. So we're synergizing at the moment, and it's great. So Thomas, you'd mentioned you're

on the front end with Backbone and Ryan, you're on the back end with Node.js, but I guess you guys can choose who will go first. But I'm just kind of curious, on the open source front, besides those two, what projects are out there that you're really either wanting to play with or have dabbled with a little bit? What's on your open source radar

in terms of what you want to play with? Ryan, I guess you can go first. At the moment, I'm really just interested in playing around with everything to do with? Ron, I guess you can go first. At the moment, I'm really just interested in playing around with everything to do with Node.js. Up until recently, JavaScript hadn't piqued my interest that much, but now I'm absolutely loving it. All to say,

I really love the asynchronous aspect of Node.js, so that's something I'm really interested in investigating and just getting to know and wrapping my head around programming in an asynchronous fashion rather than a typically procedural fashion, as you would in PHP or something like that. Anything in the Node world in general besides just Node as the platform?

What else has got your interest? Well, to be honest, CacheDB, Anything in the Node world in general besides just Node as the platform? What else has got your interest? Well, to be honest, CouchDB, that's something I'm really interested in. I really like working with information systems, and CouchDB is something that I consider to be really cutting edge, and the fact that we're using it is sort of another reason it's got me interested. But, yeah, I mean, sort of working with that with a web application such as ours, it gives you quite a lot of flexibility. And just to clarify, we're talking about Protosalia. CDN.js is actually a static website, in case

there was any confusion there. So yeah, from my perspective, Node.js, and specifically its interaction with CouchDB, is what I'm interested in at this point in time. Thomas, how about you? No, I like to stay away from databases these days. If I'm going to talk about databases, key value stores such as Redis and CouchDB, well, not CouchDB, but any other key value stores, I like to mess with.

But I definitely love client-side at the moment. I'm trying to improve my usability skills, but I'm getting there slowly. But probably my favorite technology at the moment, and I'll give a shout-out to it, I guess, is Brunch. You can find Brunch with coffee in Google. And what Brunch is, I don't want to define it too much because I don't own it, but it collaborates all the latest technologies such as CoffeeScript, Backbone.js, Eco, Stylus,

jQuery, and Stitch. And it takes care of the entire JavaScript, CSS, HTML rendering and using the best technologies that we have available. Well, I see one fun thing in here we've covered on the ChangeLog, which is stylus, and you mentioned getting into usability more. So that must mean that you're wanting to do something with preprocessing style sheets and some other fun stuff, and jQuery and Zipdoor

are both thrown in there, along with Underscore. Yeah, definitely. We were going to use CSS precompilers with our latest startup. At the time, though, I was going to say Ryan wasn't efficient at CSS, so I wanted to just use CSS for both of us to get on a clear pathway of understanding the CSS of the application. And I guess that's one of my main concerns with things such as CoffeeScript and pre-compilers because I don't like the idea of if I wanted to introduce a new developer to the project, they'd have to understand the technologies

that even compile the CSS. I wouldn't say it's completely fair to say that they don't understand CSS. It's just that they maybe don't understand Stylus or Eco, for example. I can hear you on that because I've worked with people that don't know SaaS, and I hate to keep mentioning it because

I think Wyn and I have a small stack of drinks on our side to take because of our continuous rants on it, but I've had to work with training people to come into that too, and it's the same kind of chicken and egg. You want to get them into this different world of doing it better but they have to kind of learn the syntax or different changes to it that in the end they're going to spit out javascript or css and sass or

stylus this case but you know you want them to use this new cutting edge technology but it's it's kind of difficult so all i really press for at the moment, I'm not sold on CoffeeScript or I'm not sold on the CSS compilers, but I definitely like JavaScript frameworks. So there's Backbone or Spine.js or you can use the big Cappuccino and SproutCore. I do like the idea of JavaScript frameworks because I love single web page application development.

But besides that, I only support JavaScript frameworks because I love single web page application development. But besides that, I only support JavaScript frameworks. So final set of questions here. Put you guys on the spot. And so I'm assuming both you guys were born in the 90s, right? Actually, no, we're children of the 80s, 1989.

There you go. Yes. Still youngsters by today's standards. So you're closer to college than we are. That's for sure. Yes, fresh out of college, in fact. There you go. So what are the college kids these days learning about computing

in regards to the personalities involved in this space? Who are your programming heroes programming heroes um to be honest um i'm not quite sure well you don't have sports heroes we've already established that so i wouldn't i couldn't really even tell you what kids in university like to learn these days. I think over here it's a lot of C and C++, Python and C Sharp, I guess. And a lot of people are into Apple and any kind of mobile development. But my heroes on the internet, there's definitely quite a few.

I like all the main celebrities like Paul Irish and Jeremy and Damien Katz. But the other people who I look up to, like the brunch developers, I like what they are doing. Yeah, and I guess I'm going to say my favorite guy on the web right now is one of the original authors of Catchouch to Beat, Damien Katz. The reason for that is he's a really smart guy, and he looks like he weightlifts every now and again. I'm kind of a little bit interested in that, so I like the merging of health and programming. We both go to the gym five days a week, so we're like anyone else who goes to the gym and programs.

Well, I think that's about all we want to talk to you about I know we're pretty excited to have you on the show we certainly enjoyed the fact that you guys are so young and so adamant about doing something fun for our community and the fact that also that not only is it cool for our community but it's a non-profit you've got some good support

from things and if that support didn't come around you were still willing to shell some of your bucks out. So if I'll say to the audience that if you meet them up at a conference or a meetup or something like that, buy them a beer or coffee or whatever. Maybe a supplement

drink or something. I was going to say, there's too many carbohydrates. There you go. But thanks for coming on the show. It's been too many carbohydrates. There you go. There you go. But thanks for coming on the show. It's been a pleasure to talk to you guys.