Error and performance tracking with JD Trask from Raygun
Interviewed by Christophe Limpalair on 10/13/2016
How can we track errors in production in real time and how can we implement performance tracking to find and fix bottlenecks? In this episode we focus on how Raygun, a platform that provides an answer to the previous question, is built from a technical point of view, but I also turn to JD for business advice. Whether you are technically oriented or have business aspirations, we can learn from someone who started from a technical background, co-founded multiple companies, and is now the CEO of Raygun.
Let Hired find your dream job for you, and get a $2,000 hiring bonus in the process by signing up here. Need to brush up on your skills first? Linux Academy now has a free trial which includes hands-on labs!
Links and Resources
What is Raygun and what do you offer?
The way I describe it is: a software diagnostics and performance tracking platform. We have two products under the Raygun brand:
- Raygun crash reporting is sort of like your black box flight recorder. It's tracking everything that breaks. It's aggregating data providing insight into patterns. It's making sure it doesn't kill your inbox by smartly grouping things together, and then sending you things as rates change and things like that.
- Raygun Pulse allows you to measure the way users are using your software. That might be the time that it takes them to transition through a workflow on your website, how long pages are taking to load, what's slowing down the pages, and things like that.
We do support mobile, web, desktop, backend and everything. We are a full stack provider of tools to provide software teams with insights into what's going on with their software.
How did you get started with computers and how did you end up becoming CEO of this company?
I started programming computers when I was nine years old. My family got a computer and we had DOS with Windows 3.11 on it, and I was literally going through every DOS command I could find. I got to the letter Q and stumbled onto QBASIC. To me, it was like finding a Lego kit with unlimited pieces. The only limiting factor was basically my own brain, on how I could achieve whatever I wanted. I could build anything in there.
That captured my imagination from that point, and I started buying the time off my siblings for time on the computer for a dollar an hour to make sure I got more programming time. The passion blossomed from there.
Christophe: That's hilarious. I remember having time slots. I don't think I ever bribed my brother. That's brilliant! I definitely should have done that! I wasn't programming when I was nine years old. I was probably playing video games instead and eventually moved onto programming and playing around with hardware and things like that. It's always interesting to hear how you got started, where you got the passion from and how that got you to where you are today.
When you look back on businesses, you can say, "Hey, this is a really good idea. I can definitely see something like Raygun being a big success in the market." It's always easier to look back to successful companies than it is to find those ideas in the future. Did you always know that Raygun was going to be a big success? How did you even stumble on the idea for this product?
The idea was something I had been "kicking around" ever since we started the company. It really went back to the three years I worked in the industry, where software would break, and you would write your own code to send yourself an email, and that was useful that you could debug things a little quicker with the downside being that there was no sort of grouping.
You'd get overwhelmed with emails. There was no smarts to it, no work flow, no integration with the other tools, and largely, you'd move off onto other projects and not want those emails anymore. Once you de sensitize yourself to them, you'd actually miss when something severe turned up.
We had been talking about how there must be a better way of handling that scenario and that other developers must have that same problems. Having said that, we've bootstrapped our business, and we've done a bunch of services for other people and we've built a range of other businesses.
We built a website to help New Zealanders donate money online. We sold that. We did all sorts of different things. We built other products that didn't sell nearly as well, and we eventually got to Raygun. Even though it was something we wanted to build since the very start, it took us a while to get around to building it.
It turned out to be a really great product and a lot of people really like it.
When did you realize that you were very interested in building these kinds of businesses and working around business and not just working on products themselves and writing code, but actually trying to sell the products themselves?
I've sold commercial software for quite some time. I started selling software when I was about fourteen at my high school, and I always think I've been into business and technology. I love what technology can do. I think it's mankind's sort of superpower, but, at the same time, business allows you to get more people involved and get more achieved.
Business and technology are all about amplifying human capability. So, when I was younger and started writing code, I started thinking about what the opportunities were out there. It became fairly evident when you looked at the market that software was exploding in the mid nineties.
So it was like, "This is great! What I'm passionate about can equally be coupled to a way to make money."
In the nineties you saw software as exploding. Obviously, it's still exploding today and has been for quite a while now. We hear a lot of talk about AI(Artificial Intelligence) and Augmented Reality. Do you see that as also something that's going to explode in the future? If so, going back to when you were younger and trying to find the opportunities, do you have tips for people who are trying to find opportunities in that ... how to "wrap their head around" the possibilities?
I think it's a mistake to try to think up something and expect that you're going to nail it. We built other products. They sold, but not as well. We learned a lot about that process about what works and what doesn't. I think that's the important thing.
If you are having your first "dipping your toe" into your own business, one of the things you need to realize is that what you're actually getting out of it is an education. You're learning about how to run a business, how to operate, and what marketing looks like.
As engineers, we typically have that belief that if we build it, they will come. Every engineer I've talked to kind of thinks that, but you have to do marketing. It's like, "Umm, yeah," but everybody still thinks, "Maybe I'll just be the one that makes it so damn good that everybody will just fall in love with it."
I've had some friends that have built businesses that haven't succeeded, and usually, once that initial pain goes away, they appreciate everything they've learned from it.
"It's much more than just trying to make a pile of money."
Is it just a matter of trying until you find something that sticks to the wall and then you just run with that?
I think so. The saying is, "Failing is fine as long as it's not fatal." You don't want to kill your business or jeopardize your own life in any way by being held to make the first or second idea work. We were fortunate that we had built up the products. We were fairly well respected in the New Zealand development ecosystem, so we got various service contracts that we were working on while we were building up products.
One thing I'd say was really valuable was, by building the other products that didn't resonate as much with the market, it really emphasized to us that when Raygun was meeting the market, how different it was.
For example, we launched our product in 2013 and within about two months, we had people emailing us saying, "Hey, we really like your product. Can I do a case study for you?"
It was like, "Wow! That's quite different. People that normally reach back to their provider and say, "Hey, can I do this for you?" That was the first time that we were onto something.
Then the actual growth of the product in terms of people signing up and talking about it has been phenomenal.
What about pricing? A lot of times when you talk to technical founders or co- founders, they have a problem with trying to charge for their product, where they think that by using the freemium model, they will get that bigger traction in the beginning. Or maybe they start charging initially and they want more growth, so they cut the costs, or they introduce a freemium model with upgrades or ads. What do you think? Did you charge from the beginning. Do you think that's the way to go?
We charged from the beginning. I believe that if you're providing value, you should charge for it. That's the way to make it sustainable. It still blows my mind how often(particularly endemic with software engineers) they say, " We put something out that was free." We're like, "That won't be around long."
I can't count the Hacker news threads where people are "boohooing" over some company that's going out of business. Nobody was paying them. Of course they're going out of business!
My favorite thing is when I lack a service and I discover they have a sensible pricing model, I have a lot more confidence that they'll be around the next day.
You mentioned that someone might go freemium to try to get their growth going. You certainly won't accelerate your revenues. You'll have a really great vanity metric. I've talked to a lot of other business owners and it's interesting how many people (when they talk about their customer count) have a definition of customer that doesn't include them giving you money, which is always weird to me.
They'll say, "I have a (this many) thousand customers." "How many of them give you money?" Not that many. I think Freemium can work, but you've got to be honest with yourself that you're not doing it for vanity metrics to make yourself feel good.
You've got to have a really big market. You don't really want to do Freemium unless you honestly believe you can still get a hundred thousand paying customers. That probably means you have about ten million free users.
It's a hard place to be. I think we engineers sort of shy away from billing the things. We say, "I'll do that once the product is really great." Truth be told, you can't really trust someone when they say they really like your product until they part with their money. If you say, "You give me some money for it and they say Well, actually.....," that's the test. You don't have any product market.
"Money is a great decider."
Where do you start with the pricing. You say, "Let's launch this product and try this price," and if a lot of people buy it, we'll raise the price. If we don't have that many customers, maybe we'll lower the price. What do you think?
You have to start somewhere. There's a great book written by the cofounders of Red gate software called Don't Just Roll the Dice: A usefully short guide to software pricing (Neil Davidson). It's a free ebook. If you're charging anything and thinking, "I'm not getting enough customers. Maybe I should lower the price." That's very rarely, in my experience, the right approach.
It's better to think, "How can I improve the value that I'm providing for those dollars?"
That's really how people at least subconsciously think. "Am I getting enough value out of this?"
I see people tweeting about how people should increase their prices because they get afraid. We're all quite emotional. We don't like to feel rejected, so we think we're taking away barriers by charging a very small amount.
You really have to look at your cost to serve.
Go back to the Freemium model. If I have a million people that are not paying me and they seek support, as much as you want to say, "We don't provide support free," you're not going to commit them to pay if you don't support them in the first place. It's a bit of a "catch 22." That can really increase your costs of operating.
This is a really tricky question, so I appreciate your feedback. The question actually comes from a podcast that I've been listening to recently, called a16z Andreessen Horowitz: Software is Eating the World.
They talk about Freemium and charging. If you don't know where to start, that might be a good place to start and hopefully, this discussion also helped a little as well.
Christophe: A few more business questions and then we'll talk about technical details.
Thanks to Hired and Linux Academy for sponsoring and offering deals to viewers!
I've heard a lot of software engineers and sys admins say that the job market is hot and they don't need to try hard to find a decent job. I couldn't disagree more.
First, do you want a "decent" job, or do you want a great job you're excited about each and every day? After all, you spend most of your life working, so I would hope you have fun in the process.
Second, many of the best jobs never make it out to the public. A lot of it is word of mouth and knowing someone who knows someone who's looking for someone. Blasting out your resume won't find you those jobs.
That's where Hired comes into play. Hired brings job offers to you. You answer questions so they can vet your skills, and then companies send you offers with upfront compensation so you don't spend time in interview after interview only to find out that the company can't meet your compensation requirements.
Instead of sending you opportunities you're not interested in (which often happens with recruiters), Hired tailors job offers to you. For example, if you're not interested in working in a large corporation because you prefer smaller companies, Hired will send you offers that match those requirements.
Then, once you find the job, if you sign up via this link, you get a $2,000 bonus for being hired.
As you know, continually learning is critical in our industry. Whether that means getting certifications to beef up your resume, or picking up skills in short periods of time, you need a platform that doesn't just focus on concepts, but also focuses on hands-on training and gives you real skills you need to be more valuable.
Now, with Linux Academy's free trial, you can get exactly that and you can make sure Linux Academy's training methods fit your way of learning. If it doesn't, no commitment is needed. If it does, you can continue your learning journey for an amazing price of $29/month, which gets you access to all the content, labs, support, and community available on the platform. It's an incredible deal, so you have nothing to lose by checking it out, but a whole lot to gain.
You guys have had a lot of growth. Can you share some of the stats of growth that you have had over the years?
We're not massive in terms of head count. There are about thirty on staff at the moment. We're probably going to be fifty or sixty by the end of the year. We are a New Zealand headquartered business, so we haven't run the company like a Silicon Valley startup. We're not burning a whole lot of money to have that growth.
It's driven entirely off of revenue expansion, which is good. We talked about this a bit before kicking off the podcast. It's about the culture and handling increase count. When you start off with maybe 3 to 5 people, you've got high bandwidth communication going on. Everybody knows everything. Everybody is probably involved to some degree with every decision.
Somewhere in the mid teens headcount size, you start not wanting to bog everybody down with every decision. At the same time, you have to sort of manage the fact that folks will feel that they're perhaps being cut out of the conversation, which is not the case, you're just trying to maintain agility and be shipping fast.
That's when you have to start looking seriously at the culture. We've done a lot of work to partly improve the culture by getting everybody on the same page and talking about it. So we established our company values. They're up on the wall. It took a lot of work shopping around there. A book I've found really useful for this was called, Scaling Up: How a Few Companies Make It ... and Why the Rest Don't.
To be honest, it's a bit of a dry book and kind of "referency" but it talks about some of the processes you can put in place as a company is growing. It's reasonably prescriptive, but at the same time they qualify that you shouldn't try to roll out everything they say in the book. We found that useful for developing out the initial values and the core mission and how we communicate that with everybody on the team. We put in place other things to make sure everybody still feels like they are "heard." That's been really helpful.
That sounds like it's coming a little bit more from the side of management where you're trying to keep agility and trying to keep people involved and things like that. What about from the other side of an employee who is more technical oriented and who works on the code base and infrastructure, for example, but they also have aspirations to help set some of the strategy? Do you have recommendations for people who are in that position?
The view I take on that is that sort of position is earned, not "given" and there are certainly folks that would say, not necessarily in acrimony, "If I were just given the chance to have input on this ...." I'm a big believer in just sort of jumping in and providing written suggestions even if it's semi "above your station" if you will.
I remember in the company I worked for (before starting Raygun) writing this big write up because the company was growing quite rapidly and there were a lot of challenges going on as it was growing. I wrote out my theories on ways we could approach things, and then provided that to my manager at the time.
It obviously wasn't part of my job description to suggest how to change things, but you just go ahead and do it. Once you are behaving that way, people will respect it and appreciate it. There may be some push back on it, but usually it will be constructive push back unless they are a terrible manager. I'm a believer in "Just do it."
Let's say we were planning another product, and somebody on the team was particularly passionate about it, but they weren't the director of product. If they came in and said, "I've spent some time thinking about this. Here's how I think we could structure things, and here's what I've seen in the computer landscape." It would be lapped up, appreciated and reflected positively in any performance review.
I really, sincerely hope this helps other people listening to this if they're ever in that kind of situation ... where if they're in a growing startup where you have some cultural changes that many of us have seen, hopefully, this advice really helps you out. If it does, please leave a comment and thank JD for these business answers.
If you're working in an organization where you think, "There's no way I could do that," I'd find another organization. People should appreciate people going above and beyond, but if they get offended or upset about it, that would be a worry to me.
Christophe: Going back to where you're saying that could be a bad manager, in the case of if you do have some data and real evidence to back up your claim or say, "I think we should go this direction because of x,y,z," and your idea is just brushed aside for no reason at all, maybe it's time to look at a different job or company where the managers are more receptive to that kind of thing.
Christophe: Before we move on, there are a lot of first time founders and it's not necessarily that they are not listening to your input, or that they don't value your input. It might be that they are just learning as they go and they are going to make mistakes. Nobody is perfect, as we all know. So, sometimes it might be a matter of working with the founders and trying to figure out where the friction is.
I can assure you that first time founders are sitting there hoping that maybe we're just a chapter ahead in the book from where "we're there." Usually, any kind of input is appreciated. Again, it's about being collaborative and sharing information.
I have questions about how we can implement something like Raygun in any kind of application. You can plug this in in most languages and apps, I assume. How does that work? How do you plug it into your application and where does the data or errors go?
For example, if you are using .net, you grab the NuGet package. If you're using Java, there's a Java file; whatever is the native implementation for any given language or platform, and then, usually, it's one or two lines to get about 80 percent of the capability up and running.
The crash reporting side operates like a blackbox flight recorder. So it sits there quietly doing nothing, not consuming any resources until something blows up. Then, it springs into life, grabs all the data, sends it off to our servers. We are a cloud based offering. That's all encrypted over the wire, so we can support customers who are in the healthcare industry and finance based. We take security very seriously. Then, we do analysis of that, and send off those notifications to give you a beautiful dashboard where you can login and see everything.
Are you using Amazon Web Services?
We are presently entirely hosted on Amazon Web Services. We use a range of their capabilities.
This is a question I saw someone asking recently. How can the cloud be more secure than on premises data centers where you have more control over how things go. With Amazon services you may not have as much control, but you are saying that we do have that ability to have encryption from end to end (from the client all the way to our internal resources so we can have all that protected. Is that correct?
Yes, I feel more confident using a cloud provider. At the end of the day, AWS is going to be employing a whole bunch of people that take this stuff super seriously. We are fortunate that my cofounder and our CTO is very security minded, but we also pay for things like quarterly penetration tests to be run against the servers. We have a bounty program. There are all sorts of things in place to try to make sure security is taken seriously.
We do internal audits of the security setup we actually have inside of AWS.
You might be getting some sensitive information like maybe users' information, payment information, healthcare information, and things like that. If you have an error or anything being tracked, than it might pull that out and send it to your services. I'm sure you have some kinds of Scrubbers that go through data that can hide that kind of information, Right?
Yes, absolutely. All of those providers that you can integrate with your code, you can actually do filtering at that level, and any of the identifiable information can be removed. We do have a really cool feature, where we can handle it with an anonymous id, that's fine, but of you can share an email address and name, you actually get a full view of all of your users, their sessions, what they did in those sessions, what errors they've been impacted by.
You can run into scenarios with that, for example, where you might want to contact the users that were impacted by an error. You can do that directly within Raygun, and say, "Hey, we're really sorry about this. We've resolved this problem."
That kind of blows users' minds these days because they're not used to a software company really caring that much that something broke. It's a great way to turn at risk users into huge advocates.
We also do a lot of work with customers who have sensitive data to make sure they eventually get paired up with one of our engineers to make sure that when they are setting things up in the first place, that they are scrubbing things correctly.
What kind of services in Amazon Web Services are you using, for example, for load balancers, web servers, queues, databases?
We use their Auto Scaling around the API side of things. We have peaked at hundreds of thousands of requests per second being processed through the platforms, so having Auto Scaling is brilliant.
We have Elasticsearch in the mix. We use S3 storage a fair bit. We've written our own storage engine that sits over the top of that as well to help minimize the cost associated with that as well as improve performance.
I'm curious to hear more about your usage of Elasticsearch. You said you use databases in RDS like MySQL, etc, when does Elasticsearch become useful and what kinds of data do you deal with when it comes to Elasticsearch?
We use Elasticsearch with error data. That allows customers to search through their own data. Put in context, nearly every customer thinks they won't have that many errors when they sign up for a trial. Then they are usually blown away with, "Wait, what? 400,000 errors a month? I had no idea!" But, we collect a lot of information on every error. They might be looking for:
- a particular method name that's appeared in the stack trace.
- a particular user.
- a message on a string.
- a URL.
So, we index all that data, and they can actually do very sophisticated filtering and searching to understand what's going on with their software faults. We are using Elasticsearch for that searching.
You are able to do this in near real time, right, where an error triggers and gets sent via your API, through, I assume, the Elastic load balancer, your Web servers and things like that? Some kind of processing happens, you store the data and some of the databases, you index it with Elasticsearch ... How do you do that in near Real time?
Normally, we will have processed an error once it hits the API. From the Api to the point of notifying the customer is usually about a hundred twenty milliseconds. So it's pretty quick. There are people who joke that they get the Raygun notification before the error page is loaded in their app.
We have done a fair bit of work to make sure our processing speeds are as quick as possible. That includes things like the storage engine that we've written ourselves.
We've optimized that inbound processing. We've done a lot of work to make sure it's very very scalable. Knock on wood, but we haven't had an API outage basically at all. We've worked really hard to make sure that's very resilient because customers depend on that..
That means that if the load does go up, things just scale out. We have done a bit of work to insure that if we had, say, one customer going absolutely berserk(for example, someone generated 200,000 exceptions per second), to make sure we don't have a noisy neighbor type scenario arise where it slows down your error processing. So, the way the queuing works with the way the striping works across those queues means that while the queue could go up, it won't slow the processing on your queue.
If somebody is in a similar situation; maybe they have some kind of API they want to build out and they want to make sure it scales, and it has an amazing up-time like you just said, what are some recommendations? You mentioned queues, and things like autoscaling. Are there any other ways to test your infrastructure while it's in production to see if you have any bottlenecks, weak points, etc?
We do load testing for various things. We also do a lot of performance work on various components at development time. I love when I see developers running a profile. I like for code to be efficient. When something is going slow, it's fairly evident to ask to track all the metrics on our platform. Once something needs too much processing time, that's a candidate to pull down and simulate.
For example, right now we're doing some work with some of the Pulse data. One customer's data is about 300 gigabytes worth of database space, and so that's useful for us to do some performance testing and actually sit down on a machine, run the profile, and see where the time is going.
Are there any specific tools you use for performance tracking or how can you tell how long something takes and then trace back to the culprit; this is why it's taking longer than usual, etc?
We use a mixture of tools around our operations. Obviously, we use Raygun tracking big parts of Raygun. We also have our home built monitoring system that we have our own custom app for the iPhone so the team knows what's going wrong and when. It tracks things like queue lengths and worker timings, etc.
We also make a lot of use of StatsD for time various operations and counters. We pump all that into Librato and Datadog. We've found Datadog to be very handy for that. That allows us to understand what the health of the platform is. Generally, we can build out dashboards and monitor what's going on.
I like how in tune you are with the technical aspect of it. Sometimes I talk to CEOs and they sort of know what's going on with the technical details, but not so much. They are focused more on the operations and don't necessarily come from a technical background. You seem to know a lot about the nitty gritty details of the actual technical side of it. Do you do something to stay in touch with that side of the business? Do you still do technical work? Do you still write code or do you just keep in touch with all the engineers?
I think it goes back to the start of the conversation with my overall passion for technology, so I still write a little bit of code; usually more on the weekends. I like to hack around with things. I've got all sorts of Oculus Rift (virtual reality), and I like to write some code to make that render up. I like to play with the database tools. I've been playing with .NET Core on Linux. I'm passionate about the tech side of things. Usually, even if I overhear a remark, it goes in there and gets filed away.
I'm also very fortunate that last year we hired an excellent general manager. She has taken a lot of the administrative burden off of me. Obviously, as we've been growing, I used to do a lot more broad work. She's taken that off me which has given me more time to look at the technical aspects of what's going on.
I also work closely with our director of product around where we're taking the product based on things I think we should be putting in there, what I hear from customers, and that sort of thing.
I'm spread pretty thin, but they'll pry my keyboard from my cold, dead hands one day.
Going back to some of the performance testing we were talking about earlier, you have a lot of data going through your platform for both error tracking but also performance tracking. Are there any specific performance bottlenecks that you see a lot of applications running into that need a little bit of tweaking?
We do see that a lot. With the posts for the Web story, all of us devs talk about "I'm using Angular or I'm using Backbone or React." The amount of time that's going into the front-end around rendering and the DOM manipulation stuff get all that timing. It has been semi alarming to see how consistently across the board with modern web apps, the amount of time being wasted on that rendering part is a consistent thing.
The other one is how undependable a lot of third-party script files are. Whether it is that they are incredibly slow to respond or they don't have any cache headers or how often they actually go down. So, we see the time outs that occur trying to load certain resources, so you go, "Such and such a company (without naming names, a hundred billion dollar plus tech company), should be serving those script files a lot more reliably than we are seeing."
Those are big ones we see consistently.
I don't know when this is going to air, but we are just about to drop a capability into Pulse for the Web story where we automatically run page speed tests on every asset we see or every page that we see coming through Raygun Pulse so we can then say to people, "This asset is missing ETags, this one's doing this," and you can watch the changes over time and how they impact performance.
That's an exciting addition that's about to come out to highlight to our customers exactly what their common performance problems are.
As an example, you've probably had a web page that's been slow in the past. You go and feed it through YSlow or PageSpeed and you see what's wrong and fix them up. Because it's automatically running over all of the pages in your system, we could actually say, "This resource is missing." Maybe it's not even a page, it's a resource that's missing like an ETag, caching, or an attribute, but because it's referenced from every single page on your website, it's actually dragging down the performance of your entire site.
It allows people to better rank what they should be fixing. It allows people to rank what they should be fixing because they can have the biggest impact.
It almost sounds like a large part of the issues come from caching or the small tweaks you were just mentioning as well as the rendering time on the client side rather than maybe some back-end performance issues related to the database, web server, or the application itself. Does that sound right?
Yeah. We do track the amount of time the server spends generating the pages, but if it has just been a case where we've been looking at the data we've been receiving, and we've been able to say that it's fairly frequently well optimized, and that just might be a function of the fact that server hardware is pretty good these days.
Or developers are more likely to notice that the server response time is slow and they're running things on a Dev Machine, but they might not notice latency problems because local host is pretty low latency.
We don't see too many problems with the server side.
The other thing with performance that can be really tricky is that you could be testing it from your computer, even if it's not the local host, and you may be getting very fast performance, but that could be because you are very close to a CDN (Content Delivery Network) or the main server data center where the application is hosted; whereas, if you cross the Atlantic Ocean or go somewhere that's far geographically, that may not be the case. So how do you test for those differences in geography and other devices like mobile devices that have slower CPUs and can't handle some of the same rendering and things like that?
Christophe: I assume that the answer to that is using some of those tools that give you the visibility as to what's going on at what time, from which clients, and from what part of the world.
Raygun Pulse does exactly that. It breaks down the performance by geo, by browser, by operating system, and that's part of the value proper of haw we sell that to customers, and we use it ourselves. We also have the dubious benefit of having our headquarters in Wellington, New Zealand, so we're almost as far as we could be from our production hardware.
Therefore, if it's fast for us in New Zealand, then it's blindingly fast for almost everybody else.
Our headquarters are in Wellington, but I'm building the sales office up here in Seattle. We also go up to Denver, Portland, and San Mateo (between Palo Alto and San Francisco).
Christophe: Thank you, JD, for doing this episode. If people have curiosity or more questions about performance enhancements etc. for applications, I do have an episode with Ilya Grigorik from Google where he specializes in performance and things like that.
If someone wants to reach out and say, "Hi" or thank you for your time, how do you recommend that they do that?
I'm a big fan of Twitter, so they can reach me at @traskjd or they can email me directly at jdtrask at Raygun com.
How did this interview help you?
If you learned anything from this interview, please thank our guest for their time.
Oh, and help your followers learn by clicking the Tweet button below :)