Amplify.js, jQuery, CoffeeScript

Foreign. Episode 057 I'm Adam Koviak. And I'm Win Nevlin. This is the Changelog.

We cover expression, new and Open source. If you find us on itunes, we're also on the web@the changelog.com or also find [email protected] explore to find some training repos on Feature Repost blog as well as radio podcasts from Twitter. Follow Changelog show and me I'm Stack and I'm Pick one P E N G W Y N this episode is sponsored by GitHub Jobs head to the changelog.com jobs to get started. If you'd like us to feature your job on this show like advertise on the changelog 1 post your job and we'll take care of the rest.

Big Bang Technologies 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 want to write a fairly large complex SQL query, check your code in the 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, an awesome compensation package. And if you're in Toronto, Ontario looking for a full time gig, check out LG GD AA because they're probably looking for you and you're probably looking for them.

Next up is ELC Technologies at a full time position in Portland, Oregon. Telecom 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 maps. So if you're proficient with Ruby, Rails or mobile development and you know what the cloud is, maybe you don't understand what something should be put into an API and how to leverage existing will make life easier.

Check out LG GD AB for more details. What up? So this week talked to the guys over at pin2 about amplify JS, the new JavaScript framework that kind of complements jQuery. 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. Sounds exciting. Speaking of exciting, we just got back from Red Dead rubyconf. Great week up there in Oklahoma City and 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 Ronto from Jump Cutter and Wesley Berry from Thought. 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 get up to Oklahoma City to go to anything that Derek Parkers and those guys put together, it was really good. James Edward Gray 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 right up our alley for the Changelog.

I thought we'll see Ruby conference I know Dr. Nick pretty much lambasted us there in his keynote, talking about why we're having so much JavaScript at the Ruby Conference, but it was fun times to be had for sure. Pissed off. Speaking of, should we get to it?

Let's do it. We're chatting today with Mike Hostetler, Scott Gonzalez from a PIN two to talk about amplified js. But before we begin, Mike, why don't you introduce yourself your role at the PIN two and then we'll introduce yourself. Scott My name is Mike Hostetler.

I'm the founder and CEO of Pentoo. 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 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 Gonzales.

I am an architect at Appendoo and I'm one of the development leads for jQuery UI and I spend almost all of my time at Appendoo working on open source projects, working on jQuery Y, 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 Share 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, on Appendoo, if we run into a problem over and over, we recognize that there's 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're trying to 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 specifically when looking at the documentation, request store and pub sub.

But what's this all about? So request separates out making a request and actually asking for data from request and actually making that request, like actually going, 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, you know, for calling into a service, that service may or may not be built yet, right?

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, you know, if we say, you know, 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.

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've changed 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 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 HTTP 200, that it was actually an error, which lots of services, 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 XNL HTTP RequestObject can be specified. So this means 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 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 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 isn't 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 the same way that request abstracts transport decoding network requests, 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. 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 exploration, 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 last big piece is Pubsub. So for the developer that maybe their eyes gloss over and they see Live and Delegate and Advent Listener and now Pubsub with subscriptions. What's the use case and benefit of the Pubsub architecture, especially on the client? The thing you normally hear people talk about is performance, how pubsub is more performant than events.

That's not the reason that we built a PUB sub 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 Ajax events, right?

Like before and after events. So you can hook into that and do things like a loading indicator during the 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 documentation.

We publish custom events on an object. If we do it on an object, we push 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 confusing for triggering events on objects. So we decided that building a PUB sub 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 PUB subsystem. 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. Right? 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 Pub subsystem Amplify, we added a priority option when you add a subscription. So when you subscribe to a message, you can say, I want to have a priority of one, and the lower your priority, the higher the run where you are. So the subscription to 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 priority of 9, you'll want 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 we use jQuery on every project. A lot of people use jQuery on their projects. We'll just have jQuery as dependency since we always have it available anyway. That lets us do things like not have to worry about utility methods like each or extend or is function.

So we started with that and for the most part outside of AJAX requests in the request module, that's really all we use it for. And the decision again was only because it's always available to us. Why small utilities like that again? After we released the alpha, we got some feedback from a bunch of people saying this stuff looks really cool, but I don't like the fact that there's jQuery dependency.

So because we're only using it for simple things, we decided to take the tiny file size hit and remove the jquery dependency of everything except AJAX requests. So the pub sub system and amplify Store both have no dependencies now. So store doesn't even depend on amplify core which only contains pub sub and then request depends on amplify core for the pub sub 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, appendix kind of positioning itself as 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 is just as much educated than 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. You know, what happens in a browser, what is struct Mode, what is ES, what is ECMAScript? You know, they, they aren't aware of all that, so we build off of that and then get them up to a 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 to complement injexquer, which is a much larger framework. I'm not sure if you guys have seen the debate in the last couple of days between Yehudis Katz and Thomas Fuchs from Sproutcore and Prototype and respectively talking about these big monolithic frameworks, which I guess Sprout would be more in that category. Sprout, correct. Capcino, 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 small programs together and 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.

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 project. 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 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 we've been solving these problems. We've solved the problems over and over.

And we go back and we look and we say, 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. 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. 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.

So that's why we're, we're not in that build one monolithic framework mindset. Because once you do that, we feel 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's.

That really underscores the approach we've taken. We've been 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, 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, monolithic framework, really kind of a marketing and branding perspective. The, in 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 and 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've, they're starting to realize that there's more to the JavaScript world than just jQuery itself and they're looking for solutions for, you know, packaging and pulling in other things besides jQuery. So it's something we're very interested in and working on. So 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 and versus Python or Ruby or other frameworks?

You know, 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 backend developers approach the front end from a back end perspective. And we've as a company made the decision when we found it 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, 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, mostly on the enterprise side.

So in my former life I was actually a. NET developer so I think I can speak a little experience around what you're saying there, around approaching it from a backend perspective. The page state, the view state. And they tried to turn the web in the early days of ASP.

NET turned it into more Visual Basic form load programming model which kind of just against I guess the architecture and the nature of the web. Even going as far as the early Atlas project, kind of ported the CLR Lite all the way down to JavaScript. Right. What have you seen now that they kind of shifted course and adopted jQuery has Microsoft done to really embrace the nature of the web with their backend 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 the people that follow the Net backend Microsoft way for how to do it right. Again going back to the conversation, they acknowledge that 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, we kind of take for granted the fact that jQuery UI is several different pieces that build up that, that kind of toolkit where so often people pull down wholesale or a backend 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 we, Damian Edwards on the NBC team recently packaged up all of the different jQuery UI components separately into their NuGet packaging system.

So if you're 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, it's little, 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 JavaScript extraordinaire. It's got just as much JavaScript as he does, as he does CSS. Once he's going to ask him a big question. He wants me to ask your take on rails now, including CoffeeScript by default.

So that's, I think it's very interesting, actually. It's funny, we're at a conference and yesterday I actually had a ask 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 there's the real win is getting making that barrier to entry lower and just making a very tight, robust, obvious way to get in and develop with JavaScript that is a sort of a gateway drug.

I mean JavaScript, everybody 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 understand the power of the language because it's, it's no longer a scripting language. And JavaScript we really experienced it and part of our goal with 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 CoffeeScript's an acquired taste definitely. And I wouldn't set out writing CoffeeScript if you don't really understand JavaScript going in saying that wouldn't want to write Sass without firmly grasping css.

But once you do, there's a couple 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 Ruby background and so you know it's like Rake or make exception coffeescript. So now I can compile a lot of scripts even surgically from a lot of different namespaces across, you know, 10 different files to really keep my concerns separated as I'm coding to get compiled down to one JavaScript that I can send out of the mobile device or into the browser.

It's 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 backend tends to be different, what are folks using maybe in NET World or some of the other stacks 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 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 the dot net world embrace NuGet, which is we really think is a great thing. But that 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 just 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.

It's definitely the way to do it. So we've got two long running drinking games on the show. I'm not sure if you've ever. But every time that we say Hamlin Sass or no jsp, I'll take a drink.

So. Cheers audience. So I can't talk about JavaScript, not talk about Node, just it's one of those things that is just taking fire. So given that you guys love JavaScript and code, JavaScript is your primary focus.

Have you done anything with Node on the backend? So we as yet have not had a client project where we've worked with Node on the backend. We have really fallen in love with it for some internal tooling. So we've been experimenting there.

It's again, it fits very well into kind of 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 the things involved there. And we see just great things, great potential for node on the server side and dropship on the server side.

And so we're just kind of experimenting. We'll. 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've. We'll have little projects that may come out. We host publish a lot of our little projects on code.eventu.com if you'd ever like to look at some of the more experimental things that we're working on.

So we're, 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 the air about some other efforts that you guys have around.

I'm not sure if certification is too strong 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 the 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 was a great year.

We, 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 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 slide slideshow system. We've done screencasts, kind of put together this package of content and then we'll be publishing these lessons onto a website.

And the lessons we organized into courses where you can go through like a JavaScript or jQuery 101 course. And then once, once you've completed that course, then students will have the opportunity to mark that they've completed that course and they'll be given a transcript now. I mean 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 more authentic because you could just go market oh sure, I know this but it's a start.

Again we're kind of agile in the way we release things and but really the goal is that we, we want to help people learn this content the right way and we 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 line the community path to help us improve but in addition to give students a way that they know kind of what they're getting and it's. We're really excited about it that'll be released soon so.

So one last question. Since you deal with so many Microsoft clients and probably have a close relationship with Microsoft through their jQuery adoption, what's the state of open source in the Microsoft world? I mean you guys folks in Open source code indie.com you got some 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 and Microsoft is gaining speed. There's really kind of the web technologies it's really getting some traction. I wouldn't know quite where to say the the focus of it is or where to go look but it's, it's definitely getting some traction and they. I would say that the biggest thing I've realized with working with Microsoft is that organizationally they're beginning to.

Well, the people that we work with are great. They're. 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 musty and oh, down with Microsoft.

But that's, I would say I've really in working with them professionally I have tremendous respect for everybody that works there. We were hanging out with IE19 last night and now IE10 that was announced this weekend. It's. They're just, 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 we were on a call through the jQuery project with one of the Microsoft lawyers. 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, 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 that extra effort in the community. So. Well, I know you guys are traveling out west, hitting some conferences as we speak, so it's hard to catch up to you guys.

Where can folks that want to learn more about the Pintu catch up with you in person? So we'll be at the J Creek 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 [email protected] 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 [email protected] great. Well, thanks for taking the time to join us today.

Look forward to seeing what Guns of Amplify. Thanks so much.