The Changelog: Software Development, Open Source - Amplify.js, jQuery, CoffeeScript (Interview)

Episode Date: April 27, 2011

Wynn caught up with Mike Hostetler and Scott González from AppendTo to talk about Amplify.js, jQuery, CoffeeScript, Microsoft, the web, and open source.

Welcome to the Changelog episode 0.5.7. 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 thechangelog.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 podcasts. If you're on Twitter, follow Change Log Show and meet Adam Stack.

And I'm Penguin, P-E-N-G-W-Y-N-N. This episode is sponsored by GitHub Jobs. Head to thechangelog.com slash jobs to get started. If you'd like us to feature your job on this show, select advertise on the changelog when posting your job, and we'll take care of the rest. Big Bang Technologies is looking for a desktop class web application design engineer. And for those that don't know, desktop class web applications

are web apps that feel like they belong on the iPad. If you know how to write a fairly large complex SQL query, check your code into Git. Have a few open-source projects and understand the value of social coding on GitHub. You're a perfect fit for Big Bang technology. You have an awesome compensation package. And if you're in Toronto, Ontario, looking for a full-time gig,

check out lg.gd.com. Because they're probably looking for you, and you're probably looking for them. Next up is ELC Technologies. They have a full-time position in Portland, Oregon. Telecommuting is also an available option. They're looking for Ruby and Ruby on Rails devs with strong problem-solving skills, at least one-year experience in building web apps.

So if you're proficient with Ruby, Rails, or mobile development, and you know what the cloud is, maybe even have an understanding of what something should be put into an API and how to leverage existing ones to make your life easier, check out lg.gd.com for more details. Fun episode this week. Talked to the guys over at AppendTo about AmplifyJS, their new JavaScript framework that kind of complements jQuery.

It has no hard and fast jQuery requirements anymore, but kind of a slimmed-down version of Backbone, perhaps, in certain respects, but it does look pretty cool. I'm going to check it out. That sounds exciting. Speaking of exciting, we just got back from Red Dirt RubyConf, a great week up there in Oklahoma City. I did it live on, I guess, Thursday over the interwebs, if a few of you caught that.

We'll be posting that audio in a couple of future episodes with Nick Caranto from jump cutter and Wesley Berry from thought. I'm a, I missed that show, but I heard it was really awesome. It is cool. It was such a cool venue up there. If you ever have a chance to,

to get up to Oklahoma city, to go to anything that Derek Parkhurst and those guys put together, it was really good. James Edward gray. The II was a great host and we just had fun talking with Dr. Nick and Aaron Patterson and a lot of Ruby folk up there, but a lot of JavaScript at this conference too. So kind of right up our alley for the changelog. I thought it was the Ruby conference. I know. Dr. Nick pretty much

lambasted us there in his keynote talking about why we're having so much JavaScript at a Ruby conference. But it was fun times to be had, for sure. Good stuff. Speaking of, should we get to it? Let's do it. We're chatting today with Mike Hostetler and Scott Gonzalez from AppendTo to talk about AmplifyJS. But before we begin, Mike, why don't you introduce yourself, your role at AppendTo, and then we'll let you introduce yourself, Scott. My name is Mike Hostetler. I'm the founder and CEO of AppendTo.

We're the company dedicated to jQuery and supporting the jQuery community through a variety of business services. We currently focus on training, development, and support. So we offer on-site and remote training to companies that are interested in sort of improving their skills with jQuery. With our development, we do a number of architecture reviews and performance reviews and Kickstarter projects. So we'll participate on a team and help get that team up to speed with either putting together the architecture of a project through a prototype and then handing it over to the team to finish out.

But we really focus on some cutting edge and pushing the boundaries of what you can do with jQuery. And then we also offer corporate support contracts to those who are interested in just getting that extra, they know who they can call. So that's what we do. Scott? I'm Scott Gonzalez. I am an architect at AppendTo, and I'm one of the development leads for jQuery UI.

And I spend almost all of my time at AppendTo working on open source projects, working on jQuery UI and working on Amplify, working on some smaller projects that we have, and occasionally working on client projects. We'll jump into jQuery and jQuery UI, I'm sure, in a moment, but what's the elevator pitch for Amplify? So Amplify is a set of components for solving common web application problems.

So basically, as we work on client projects at AppendTube, if we run into a problem over and over, we recognize that there is something consistent here, and we try and find a solution that works elegantly across all of our projects. So that's the goal for Amplify, is to just solve the problems that we're commonly hitting. So it's nothing like solving some niche problem or trying to be really, really clever about a solution. We try and make something as simple as we can to solve some kind of common problem that we're facing and probably many other people are facing.

So let's talk specifics for a moment. I'm looking at the documentation site. So you request, store, and PubSub. What's this all about? So request separates out making a request and actually, so asking for data from a request and actually making that request, like actually going and getting the data. And the reason that's important to us is because we're frequently working with companies where we're writing all the client-side code and they're writing all the server-side code. So when we have to integrate with the server-side code, if we're calling into a service, that service may or may not be built yet. And so we want to separate out the fact that we want to call into the service and how we actually call into the service.

So if we say we need to get a list of movies, we don't really care, as the person asking for the movies, how we got that list of movies. So we separate out the actual request from the actual implementation of the request and that way if the server-side implementation changes or if we want to mock out the implementation because the server-side code is not written yet the front-end code doesn't actually change like the code that says go give me a list of movies and I'll handle that list when it comes back to me, stays the same regardless of how many times we change the implementation of how do we actually get those movies.

So that's the main thing that Request does. It also handles things like if the services return data wrapped in some kind of envelope, you know, so it says the status was successful or error, the request object can decode that and return just the actual data, and it can also determine that even though it was an HTTP 200, that it was actually an error, which lots of services do. Pretty much all the popular services always return a status code of 200, and then they tell you some other way that there was an error.

So with amplify.request, you can actually say, here's my success callback, here's my error callback, and then here's a function that decodes it. But as the person asking for the data, you're not specifying how it gets decoded. As the person implementing how that request works, you define the way that it gets decoded. So again, it's abstracting away all the details for you.

So I see on the options that you can pass into this thing so that XHR, the XHR object, the XML and HTTP request object, can be specified. So does this mean that you're decoupled from jQuery's transport and can use any transport you want? Yeah, so when you define a request, you define the type of request. So AJAX requests are just one type of request that we support. We don't have built-in support for anything else yet. We do want to have AJAX polling and something to normalize across different types of streaming

data, so like WebSockets, you know, and then if WebSockets are not available, maybe you fall back to AJAX polling, but the API that's exposed to you as the user of that request looks exactly the same. You can also do requests that are just functions, but the API is exactly the same for the person making the request, regardless of the fact that the request is just a function or it's an AJAX request. So we're really trying to just completely separate the fact from I'm making a request for data, and this request for data is handled in a specific way because we want to have the flexibility to change how that part's implemented

and not have to ever worry about going back and changing something else. So in the same way that request abstracts transport and decoding network requests, I assume store abstracts the same thing for local storage and different mechanisms for persisting data? Yeah, so store is a layer on top of any synchronous web storage system, any synchronous persistent web storage system, any synchronous persistent web storage system. So that's basically what local storage is, but older browsers don't have local storage. So you know in older versions of Firefox you have global storage, in older versions of IE you have user data. So it handles all of that, it

figures out what's actually available, and it just uses that. And it also adds in expiration, which none of these systems have. So you can store something in local storage and say this is only valid for 10 seconds, and then if you try and get that data, it'll be there for 10 seconds, but if you try it 11 seconds later, it'll be gone. So that's a nice feature that it adds, and then the main thing it does is just abstracts away the fact that there are differences in how browsers implement persistent storage.

There's also support for session storage, though it never defaults to that, so you can specify which storage system you want to use. Generally, that's really only useful right now for session storage. If you explicitly want to use global storage you can do that but that would be a strange thing to do since it only works in specific browsers and if you needed to use that because local storage didn't exist it would already default to that anyway. But you do have the ability to specify which storage you want,

and you can also change the default storage system. So by default, it figures out what's the best available system. I'm going to use that. But you can change which one it defaults to if you just go through amplify.store. And then you can also add additional storage systems if you want. So the latest big piece, or the last big piece, is PubSub. So for the developer that maybe their eyes gloss over when they see Live and Delegate and Add Event Listener and now PubSub with subscriptions,

what's the use case and benefit of a PubSub architecture, especially on the client end? The thing that you normally hear people talk about is performance and how PubSub is more performant than events. That's not the reason that we built a PubSub system. We haven't actually run into performance issues. We generally end up using custom events in jQuery to do our communication,

but with the request module, we wanted to publish messages similar to jQuery's AJAX events, so like before and after events, so you can hook into that and do things like, you know, a loading indicator during a request. But in order to do that, we were going to publish custom events. But then we got into a debate about should we publish custom events on the document? Should we publish custom events on an object?

If we're going to do it on an object, should we publish them directly on the Amplify object. And we knew from experience that a lot of users get confused when you use jQuery to wrap objects instead of DOM elements. And then they get even more confused when you're triggering events on objects. So we decided that building a PubSub system would be easier for most people to understand exactly what's happening. And so that's the main reason that we decided to build a PubSub system. Then the reason we decided to build one, sort of just take an existing one, is because we wanted to keep it as small as possible while adding features that we would

like to have in events, like the ability to specify an order when you're binding an event. So it's not too uncommon that you bind an event and you say, I really wish I could get this to be the first event handler that runs. But there's no clean way to do that with events. So with the PubSub system in Amplify, we added a priority option when you had a subscription. So when you subscribe to a message, you can say, you know, I want to have a priority of one. And the lower your priority, the higher in the run order you are. So the subscriptions default to a priority of 10. So if you go to a priority of 11, you'll run after anything that's bound

without specifying a priority. And if you specify a priority of nine, you'll run everything that, you'll run before any other handler that runs without a priority. So we did that so we could build the caching layers for Amplify requests and make sure that they run at the very beginning.

So up front it says, Amplify is a jQuery component library. What actual dependencies are on jQuery? When we started building it, we said, you know, we use jQuery on every project. A lot of people use jQuery on their projects. We'll just have jQuery as a dependency since we always have it available anyway. That lets us do things like not have to worry about, you know, utility methods like.each or.extend

or, you know, isFunction. So we started with that. And for the most part, outside of AJAX requests in the request module, that's really all we used it for. And the decision, again, was only because it's always available to us. Why write small utilities like that again? After we released the alpha, we got some feedback from a bunch of people saying, you know, this stuff looks really cool, but I don't like the fact that there's a jQuery dependency. So because we were only using it for simple things, we decided to take, you know, the tiny file size hit and remove the jQuery dependency for everything except AJAX requests.

So the PubSub system and Amplify Store both have no dependencies now. So Store doesn't even depend on Amplify Core, which only contains PubSub. And then Request depends on Amplify Core for the PubSub. And then if you want to use the AJAX request, it depends on jQuery as well. And we support jQuery 1.4 and higher. The reason I ask is, you know,

AppendTo is kind of positioning itself as, you know, a company that supports the jQuery community. So, Mike, what's it mean to develop in shops that have such a heavy jQuery dependency? Are you finding that you're educating people on jQuery or just as much educating them in JavaScript? We found ourselves doing a little bit of both. Oftentimes when we get invited into a company to train their staff

on jQuery or to do a jQuery-based architecture review, they will have adopted jQuery and know that they want to kind of go down this path of building something with the front end, but they often confuse JavaScript with jQuery. So we start by trying to give them a firm foundation in the JavaScript language. A lot of our training is geared that way. We even have training courses that just talk over the basic HTTP interaction.

What happens in a browser? What is strict mode? What is ES? What is ECMAScript? You know, they aren't aware of all that. So we build off of that and then get them up to the place where they can be productive because it's the thing that they're most interested in us helping them with is the ability to become productive as fast as possible. So we do focus on jQuery, but when we get those opportunities,

we do as much as we can to help them round out their entire front-end knowledge, including JavaScript, HTML5, all the latest stuff, while getting them productive and helping their team develop really good quality code in a short amount of time. So I'm looking at Amplify, and it's a really lightweight framework meant to complement JQuery, which is a much larger framework. But I'm not sure if you guys have seen the, I guess,

the debate in the last couple of days between Yehuda Katz and Thomas Fuchs from SproutCore and Prototype and now ZeptoFame, respectively, talking about these big monolithic frameworks, which I guess Sprout would be more in that category, SproutCore, Cappuccino, things of that sort, and these smaller frameworks like Zepto and then now Ender that kind of stitches together smaller frameworks.

What's your take on the, I guess, that spectrum of monolithic versus surgical? So I had this debate with a few people. I think it's really just, you know, do you buy into the Linux model or not, right? You've got these people following the Linux model where you've got a tool that solves a problem and it solves it well. And if you need to solve larger problems that contain many small problems, you get many small programs together

and you glue them together however you need to. There's definitely a place for that and there's a place for, you know, I've got a framework that tells me exactly how to glue those things together and it's already glued them together for me. I don't think one is right or wrong. It really depends on what you're trying to do, who's on your team.

So we tend to take the approach of take the little tools that solve specific problems and use them however you see fit. But that doesn't mean that that's better or worse for any specific – well, just in general. For a specific project, it may be the right or wrong choice. But that's generally how we solve problems. So how much of Amplify has been extracted out of real-world working code? Well, it's all based on real-world working code, and then we go and use it in our projects. So like I said, we encounter a problem in a project,

and we solve the problem in that project. If we encounter the problem in a project and we solve the problem in that project. If we encounter the problem in another project, we may or may not take the existing solution from the other project. So one thing we don't want to do is solve a problem once and decide that that's how we're always going to solve it. And so the idea behind Amplify has existed for a long time. The actual code that we're shipping has not existed for as long as, you know, we've been solving these problems. We've solved the problems over and over.

And we go back and we look and we say, you know, this is how we solved it in this application. Why did we solve it differently in a different application? And we want to find something that works cleanly in both applications, right? So if you're designing something for a specific application, you may not build the most useful general purpose tool. So if you build something that's just the most useful general purpose tool, it may not solve specific problems the best way. So we've been trying to take a careful balance about that, and that's why we're not solving large problems.

We're finding specific problems that occur everywhere and trying to solve those as best we can. So that way we can drop them into the applications, right? And so that's why we're not in that build one monolithic framework mindset. Because once you do that, we feel that you generally end up, you may solve all your problems, but you may not solve them the way that you like to solve them the best. I would completely agree with that, and that really underscores the approach we've taken.

We've, in building our own projects, have seen that there's really a lot out there to solve the problems we need to solve, but it's a matter of kind of piecing it together and focusing in on how to solve it the best, and Amplify is an attempt to fill in a few holes a little bit. There's a lot of other problems, but we wanted to focus and do something really, really well. And from the other side, and kind of this debate going on, I completely understand the argument for a large monolithic framework, really kind of from a marketing and branding perspective. my discussions and we've gone in and talked with clients, there's a comfort level in adopting just one name with one version number. We completely understand that, but we kind of hold to our technical approach. So we're currently talking internally about ways that we could help companies

solve that because they're starting to realize that there's more to the JavaScript world than just jQuery itself. And they're looking for solutions for packaging and pulling in other things besides jQuery. So it's something we're very interested in and working on. What's the breakdown of companies that you support or that you consult with as far as their backend stacks? How much of them are Microsoft versus Python or Ruby or other frameworks? The majority of it has been more of the enterprise, Java and Microsoft.

A lot of the open source hackers, either Ruby or Python, PHP. There's a little bit of that, but not as much. Part of that, I think, is due to just the way they approach development. And in our kind of work, we've noticed that a lot of back-end developers approach the front-end from a back-end perspective. And we've, as a company, made the decision when we founded to approach it from a front-end perspective and to really try to shed new light on the way that we were solving these problems and building these applications. And the place we've gotten the most traction with that has been in kind of the big enterprise world

where they are trying to build big exciting things and they kind of see where it's broken down. We often come in and we'll do a review and kind of expose and have a conversation about, you know, you should have done this differently. You know, we can help with that sort of thing. And then we just start there and help them not only learn how to do it better, but show them, write some code, guide them. So I would say it's mostly on the enterprise side. So in my former life, I was actually a.NET developer. So I think I can speak with a little experience around what you're saying there around approaching it from a backend perspective, the page state and the view state.

They tried to turn the web in the early days of ASP.NET, turn it into more visual, basic, form-load programming model, which is just against the architecture and the nature of the web. Even going as far as the early Atlas project, kind of ported the CLR light all the way down to JavaScript, right? What have you seen now that they've kind of shifted course and adopted jQuery? Has Microsoft done to really embrace the nature of the web with their back-end technologies? So I've seen a couple of things. The first thing is I really am personally impressed. I don't come from a Microsoft background of how much they're participating in the conversation.

That, to me, that conversation is as important as the technology itself because the community of web developers, and maybe just throw out all the back ends, there's really a tight community where we all push each other forward and it's a conversation to make the web better because that's what we're passionate about. And that makes a huge difference. Secondly, we've seen a lot of really interesting stuff coming out of Redmond

and just their guidance, their participation in that question and what they're trying to do to, number one, provide the tooling support, but provide the guidance for all of the people that follow kind of the.NET backend, the Microsoft way, for how to do it right. And, you know, they, again, going back to the conversation, they acknowledge that, you know, it's a process to find that right solution, but it's important to have the conversation, to take feedback, to continue working on it. And we've seen a lot of really cool advances with the Visual Studio platform

through just VS Doc support for IntelliSense. I mean, little things, but they're putting effort behind it. The NuGet packaging system, where you can now pull down different pieces of jQuery UI. And again, it's a funny fundamental little thing, but we kind of take for granted the fact that jQuery UI is several different pieces that build up that toolkit. Where so often people pull it down wholesale or a back-end project will pull it in. It's just jQuery UI. Well, why would you want to do anything else? Well, they end up using just an accordion and pushing a lot of extra code to the browser,

and that just doesn't work. So Damian Edwards on the MVC team recently packaged up all of the different jQuery UI components separately into their NuGet packaging system. So if you want to use an accordion, you just pull down an accordion, and it'll pull down the dependencies correctly and make your page more efficient. You know, little things like that show a real commitment to get the details right, and we've been happy to kind of participate with them in that conversation and help out where we can.

So you guys are friends also with Nathan Smith, who I affectionately call the 960 guy, but I think he bristles at that now. I'll call him JavaScript extraordinaire. He's got just as much JavaScript as he does CSS. Once, he's kind of asking a baited question. He wants me to ask your take on Rails now, including CoffeeScript by default. So that's, I think, is very interesting. Actually, it's funny. We're at a conference and yesterday I actually had asked Douglas Crockford what he thought of CoffeeScript.

And there was a panel with a couple of the other people who worked on the ES5 spec. And just talking through their process of language design and what place something like CoffeeScript has in the JavaScript ecosystem. And it was really a fascinating conversation. And I was actually surprised that they all loved the idea of CoffeeScript and different dialects of JavaScript being built on top of JavaScript. There's obviously a downside of a compile step when it comes to tooling and debugging. But the real win is making that barrier to entry lower and just making a very tight, robust, obvious way to get in and

develop with JavaScript. That is sort of a gateway drug. I mean, JavaScript, everybody's consensus has been it's going to become or has become the most ubiquitous programming language out there. And it's now our job as developers to make it easy for people to kind of dip their toes in, but to understand the power of the language because it's no longer a scripting language. And JavaScript, we've really experienced it, and part of our goal and mission is to just help people ease into it, but to give it the respect it

deserves to help clients and customers understand that this, this really is a important language. You can do a lot with it and you can really just build amazing applications with it. So, you know, I think, well, CoffeeScript's an acquired taste, definitely. And I wouldn't set out writing CoffeeScript if you don't really understand JavaScript going in the same way that I wouldn't want to write SAS without firmly grasping CSS. But once you do, there's incredible power

in just some of the language features that you can do with CoffeeScript. One of the things that I love about using CoffeeScript is the Cake compiler. I come from a Ruby background, and so it's like rake or make, except in CoffeeScript. So now I can compile a lot of scripts, even surgically, from a lot of different namespaces across 10 or 12 different files to really keep my concerns separated as I'm coding,

but they get compiled down to one JavaScript that I can send down to the mobile device or into the browser, which is really cool. So what are you guys doing as far as package management? If you're dealing just with the front-end layer as you consult in these projects, and every back-end tends to be different, what are folks using maybe in the.NET world or some of the other stacks that you see to package up and compile

and serve up the javascript in their projects we haven't done a lot with that with package management there's a lot of different aspects to package management we, on the front end, a lot of what we end up doing is just including what we need to and using a script loader of some sort. We've seen kind of the.NET world embrace NuGet, which we really think is a great thing,

but again, that's more of a back-end thing. We're very familiar with the CommonJS package spec, and we've embraced that as much as it makes sense. But that's, again, it's not so much front-end. So, yeah, there's not so much front end. In what we do in focusing on the front end, we don't end up running into that problem. That problem does exist with our projects, but we let others solve it because it's very particular to their environment. That's definitely the way to do it.

We've got two long-running drinking games on this show. I'm not sure if you've caught any of the episodes, but every time that we say Hamlin Sass or Node.js, people have to take a drink, so cheers, audience. So I can't talk about JavaScript and not talk about Node. It's one of those things that is just taking fire. So given that you guys love JavaScript and you code JavaScript as your primary focus, have you done anything with Node on the back end? We, as yet, have not had a client project where we've worked with Node on the back end.

We have really fallen in love with it for some internal tooling, so we've been experimenting there. It's, again, fits very well into our areas of expertise. We have, amidst having a lot of experience with JavaScript, one of the competencies in the company is infrastructure and a background in system administration. I, myself, and Jonathan worked for quite a while on the jQuery.com infrastructure and scaling that out, all of the things involved there.

And we see just great things, great potential for Node on the server side and JavaScript on the server side. And so we're just kind of experimenting. We'll see where it goes. We don't have any big plans right now. We're just using it where it makes sense. We'll have little projects that may come out. We publish a lot of our little projects on code.appendto.com

if you'd ever like to look at some of the more experimental things that we're working on. So we don't have any big plans for it. We're, again, kind of following our mission of partnering with companies who are looking to solve these problems and helping them solve it. So we're dipping our toes in, and we'll see where it goes. So we were chatting earlier before we got on the air about some other efforts that you guys have around, I'm not sure if certification is too strong of a word,

but some training that you guys provide for those that may be coming to JavaScript just from the influx of jQuery into the Microsoft world. So what are you guys doing to help foster a knowledge of JavaScript? Sure. So we have our one big initiative right now is our Learn site. So we in Boston back last October at the JQuery Boston Conference committed to training 10,000 web developers and open sourcing our training material. We're on the verge of doing that. We had last year, 2010 2010 was a great year. The company was kind of getting off the ground, but we realized that we were falling far short of the need that was out there

to really train people well on a lot of either JavaScript or jQuery. And so we realized that we had to kind of think outside the box, and that's what this is. So we've packaged up, and we've actually taken our training material, which most of it had existed in keynote files, and packaged it into Markdown using HTML5 slideshow system. We've done screencasts. We've kind of put together this package of content.

And then we'll be publishing these lessons onto a website. And the lessons will be organized into courses where you can go through a JavaScript or a jQuery 101 course. And then once you've completed that course, then students would have the opportunity to mark that they've completed that course. And then once you've completed that course, then students would have the opportunity to mark that they've completed that course. And they'll be given a transcript. That's kind of the first version of it. We've got some other ideas that are baking

about how to make that a little bit more authentic, because you could just go mark it. Oh, sure, I know this. But it's a start. Again, we're kind of agile in the way we release things. But really the goal is that we want to help people learn this content the right way. And we've put a lot of time and effort into making sure that the quality of the content is the best, and we're really committed to that. And so the actual content itself will be on GitHub. We'll be able to take pull requests and participate in aligning the community, a path to help us improve. But in addition to give students a way that they know kind of what they're getting.

And we're really excited about it. That will be released soon. So one last question. Since you deal with so many Microsoft clients and probably have a closer relationship with Microsoft through their jQuery adoption, what's the state of open source in the Microsoft world? I mean, you guys are focused on open source. There's code.appendu.com where you've got some open source projects out there. jQuery itself is open source. Where is the vibrant

community of.NET open source? That's a hard question to answer. I'm not quite sure how to answer that question. I think the concept of open source in Microsoft is gaining speed. There's really kind of the web technologies. It's really in the web technologies, it's really getting some traction. I wouldn't know quite where to say the focus of it is or where to go look. But it's definitely gaining some traction.

I would say the biggest thing I've realized with working with Microsoft is that organizationally, they're beginning to – well, the people that we've worked with are great. I, like I said, don't come from a Microsoft background and have been thoroughly impressed. And frankly, my perception of the company has completely changed. I mean, I was, you know, right up there with IE6 must die and down with Microsoft. But that's, I would say, I've really, in working with them professionally, I have a tremendous respect for everybody that works there. We were hanging out with the IE19 last night, and now with IE10 that was announced this week.

They're very committed to what they do. They're very smart people, and it's been just a real pleasure to see Microsoft really push open source adoption. And then with the jQuery project, they have impressively just let jQuery lead the effort because they trust in the process is kind of my perception of it. And that's really impressive to me. I think the moment I realized that is we were on a call through the jQuery project

with one of the Microsoft lawyers to just – we were talking about some copyright issues. And the conversation was just, they were, you know, very, very open. And it was just, it was impressive. My perception of the company entirely changed during that conversation. So I would say there's a really exciting future for Microsoft and open source. We're doing what we can to help participate in that conversation. And I think that's really what I would ask all the other web developers to do is just to really participate in the conversation. They're committed to getting it right. And, yeah, it's exciting to have another – have all of that extra effort kind of in the community. Well, I know you guys are traveling out west, hitting some conferences as we speak, so it's hard to catch up with you guys. But where can folks that want to learn more about Appentoo catch up with you in person?

So we'll be at the J. Craig conference this weekend in Mountain View. Past that, we are planning to hit Big Omaha in May and then have a couple of other conferences. We'll be just doing various events. You can follow us at appendto.com, and there's links to the team's Twitter pages. A lot goes out on Twitter, and we have a list of kind of what events we'll be at. So I would say definitely go look at appendto.com. Great.

Well, thanks for taking the time to join us today. We'll look forward to seeing what becomes of Amplify. Thanks so much.