Remote Ruby

Cracking the Code: Marketing, Security, and Startups in Rails with Wafers' Ryan and Mike

Jason Charnes, Chris Oliver, Andrew Mason

Imagine if you could master the art of marketing in the Rails development world, or understand the nuances of web application firewalls (WAFs)? Well, look no further. We had an insightful chat with Ryan and Mike from Wafers, who shared their journey in Rails development, security, and their unique marketing strategies. They spoke about their presence at Rails Sassalay and RailsWorld conferences, where they stood out with their code-themed Cards Against Humanity game and a custom Lego set of DHH's car. Quite the creative spark, wouldn't you agree?

Now, let's debunk a myth: developers hate marketing. Is that really true? Ryan and Mike argue that it's not about hating marketing, but about disliking inauthentic and irrelevant tactics. They brought this authenticity to their open-source web application firewall, Wafers, and their testing process was as real as it gets. They touched on the crucial role of WAFs in managing bot traffic and improving website security - knowledge that is valuable for businesses of all sizes.

Our conversation also took us down the challenging road of starting a company that leverages Redis for different ecosystems. We shared our experiences with Redis and Lua scripts, and the intricate decisions about memory usage and performance. But, it hasn't all been about the technical side. Ryan and Mike emphasized the importance of customer feedback in product improvement and how engineering can be a unique tool for marketing. At the end of the day, it's about creating a balance and finding what works best for your startup. So, whether you're a Rails developer, a security enthusiast, or a marketing aficionado, this episode promises to serve a feast of knowledge.

Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.


Speaker 1:

This is remote. Have you any remote ideas?

Speaker 2:

to the meaning of the word, Chris. I don't even know how to start anymore. It's like a game of will Andrew show or will he want and we've lost, I guess I don't know. Not having Andrew here feels like a loss, because I don't know.

Speaker 1:

Yeah, it's a bit empty.

Speaker 2:

Yeah, and you're listening, probably thinking I know that's real sweet and really it's because Andrew's the only person I'm comfortable giving shit to and so without that this week I feel like I'm empty inside.

Speaker 3:

So it's a solid question. He was like an antelope canyon, like looking over stuff and things.

Speaker 2:

Yeah, that dude takes the craziest pictures or, excuse me, someone else takes the craziest pictures of him, and yeah. So I'm like I kind of want to go visit him in Phoenix, but I'm scared that when I get there it's just like he's invited me just to take pictures of him and I don't know that I can do that for that trip.

Speaker 1:

Your only purpose there.

Speaker 4:

Is he like offroading it? Is he like jumping fences and just living on the edge?

Speaker 1:

Running from the law. You'll have to be fast enough to get away from the park rangers.

Speaker 2:

I don't think he's off road because he drives a Mustang, but I do know he is. He's hopping fences because Colleen was like here's the same picture I took at the Grand Canyon and there's a fence here and that made me think that man either photo shot that picture or he jumped the fence and I think he probably photoshopped it.

Speaker 1:

but it's all dolly generated. He's never left his house. He doesn't have friends Just an elaborate excuse.

Speaker 2:

But he 'll listen to this one day and it'll be the end of our friendship. But until then, today we have Ryan, and do you go by Mike or Michael, cause I call you Mike. Mike, yeah, sure, all right, we have Mike. Well, they are from Lafres, w-a-f-r-i-s. Super excited to kind of dig into what that is and just talk rails, web application security, all the fun things. So thanks for coming to join us, y'all, thank you. I'm going to ask both of you to maybe just give a brief kind of like introduction of yourself. We'll start with Ryan, if you don't mind.

Speaker 4:

Sure, yeah, I've been in the rail side for the last 15 years. I kind of came up at this consultancy called we Are Titans, where Andrew Culver and I and a number of other people worked at, and we learned rails together. After that, did a bit of consulting for a while in like the biotech industry and some security stuff, then did some full-time gigs and then eventually Mike and I had saw this opportunity so we started working together on this Cool.

Speaker 3:

Mike, similarly long time rails developer. We live in Virginia Beach. There's a large US military base here in the Navy's. Here, I think I put one of the first Ruby on Rails apps in the Navy in production and did a lot of work there for a number of years as a contractor. I wasn't in the military and left, did a bunch of Silicon Valley startup stuff and eventually through that and my consulting, really started to specialize in security. I launched a number of services that work in the Heroku ecosystem for doing SSL certificates and then web application firewalls and through all of that sort of found the need for what we've started to move on to with WAFRIS.

Speaker 2:

So very cool. Also, you're going to punch me in the stomach the next time you see me, probably, but I can't not talk about you and not talk about for a good STRFF time. Like the most useful website in the world and if you're listening, I probably don't even have to introduce it. If you've ever tried to format a date in Rails and you can't remember, or Ruby and you can't remember any of those bleeps us out fucking tokens Gosh. So yeah, thank you. Thank you for saving at least two and a half hours of my time.

Speaker 3:

Yeah, so that's a website that helps you with the STRFF time date formatting functions and that was actually something I did as an exercise in like how to use Rails really quickly to quickly put types of stuff. That was a talk for the local Rails group a long time ago when we were still meeting up, and just kept that up ever since.

Speaker 2:

It's a fun little side project, and it's also weird to think that we used to like have Ruby and Rails meetups. I'm sure some still exist, but, god, I haven't been to one in six years.

Speaker 4:

So yeah, yeah, you're really showing our age here. That was our bread and butter, and then we would go to conferences and then, yeah, then we went away for a little while.

Speaker 3:

Yeah, it's been really exciting to see the conferences come back in such a nice way, like such a positive, energetic way. That's where we met Jason at Rails Sassalay. So that's right and that was a wonderful conference and I love the small conferences, like we were in Rails world but the small conferences are always so nice to just hang out and get to know people better and unique venues and things without a doubt, before we get into security and Wattress, let's talk about some of the cool marketing stuff you all did at Rails world.

Speaker 2:

Specifically, I left my hotel room. I got there Wednesday, I left, went out, came back and my wife said there's a box on the table with your name on it. And I was like, oh cool, not weirded out that this is a bomb or anything and opened it up and found a code-themed cards against humanity game and, as a speaker, a bunch of cards with my face on it, sponsored by Waffras. And I would just love to hear how that came about, because that was such a cool idea.

Speaker 4:

So prior to this, mike and I had also worked together at that a security company called Veronis, and so they were doing everything like at the enterprise level and we were both part of the marketing group there and so a lot of the marketing plays that we kind of come up with we cut our teeth at Veronis. So we always wanted to figure out ways to kind of make events better or like enhance events in some sort of way, so also like just not stand, like giving out, just like hats or shirts and stuff like that, like something that people can take away and be useful and be memorable. So the card game was something that we had done before at Veronis and so this was just a different spin on it. But then, talking to Amanda, we were trying to figure out like how can we make this even more special for the speakers? And there was this idea of like maybe there could be like a postcard where people went to every conference and then they got it signed by a speaker or something like that and then show that they went to all these different conferences. And we're like what if we took our card game and then we try to create an expansion pack? So every time we went to a different conference. There would be like a different cards for the speakers and people could collect them.

Speaker 4:

And the theory behind that was that people could go to the speakers and they could engage with them and give them praise and say like, hey, that talk was awesome. Or I had this question about this. And then the speaker would be like, hey, that was great. Thank you for the compliment. Here's a card. That was the intention. The execution was like far from that. You mentioned getting a box in your hotel room. Those cards came in late. So I think the conference set was on Wednesday and I had just flown in that morning. And so we're like how do we get the speakers these cards? Like how do we get them the notes? Like how do we explain all of this? It just arrived too late. So I think during the happy hour, mike and I literally took a cab to the speaker hotel and this was with Amanda's blessing and we were like in the lobby like stuffing bags and stuffing cards and writing notes and stuff like that. And so some speakers were starting to show up and they're like what are these two guys doing in?

Speaker 3:

the lobby here. Package the lobby of this boutique hotel in Amsterdam Like this is how things are supposed to go.

Speaker 4:

So you guys were like some of the better ones to actually kind of know what the game was all about. But some other people had, like had no idea, like it just kind of like completely went over their heads and some of the boxes.

Speaker 3:

So I think US people know cards against humanity the game a lot more than Europeans, which was something we didn't realize. Just learned that right now. Yeah, so we got the boxes made as an expansion. It's called Code for Insanity and it's actually. It's all done in Ruby, so we wrote up what all the black and the white cards are supposed to be. But then I have a script that Ruby script that pulls in like a text file, then uses image magic to spit out all these images of the correct size, that then there's a company in Singapore that does all like the Kickstarter games and so you can go there and get this like uploaded, then all the images, and then get the boxes delivered. But this takes a long time, which is why everything was so late. I still have in my office like hundreds of packs of these code for insanity cards.

Speaker 1:

In total? How long did it take to do that? Because it seems like a lot of work.

Speaker 3:

It was a lot of work. It took basically, I think, between this we haven't talked about the other efforts it took basically a month, I think, to prepare for Rails world. We wrote up a post, sort of, about it, and we're small. I mean, you're talking to the company here, but the other vendors in Rails world because we we did purchase the sponsorship are like GitHub and Shopify and we cannot compete with them money wise or throwing bodies at this. So we have to compete by trying to be creative, trying to be a lot more about developers even then, you know, then they could be Ryan said it really well like trying to do things that really help improve the experience of people at the conference, because everyone that went to Rails will got a little envelope with these of registration that had a couple cards in them that try to like use as an ice breaker with other people and things. So just trying to be helpful and part of the community.

Speaker 2:

It's definitely memorable for me. I know you said it was like a last minute thing, but I would be honest, coming into my room made it unforgettable. Just having like it just show up in my room was, oh, this is something else. So they scared me and now I'll never forget. So maybe it's a maybe it's to your advantage.

Speaker 1:

The five bites of Freddy's marketing strategy of slightly terrifying you next time the box, I'll have a little timer counting down flashing light.

Speaker 4:

I'll be in the closet with the box.

Speaker 1:

And as soon as like, just like pop out in the closet it'll be a real busy day, as every person gets in.

Speaker 2:

You got to run to their room, unlock it, get in the closet it was cool, though you could just tell there's a lot of effort and it was memorable. I have no swag policy in my life now, because I remember at Rails comp, kansas city, getting ready to leave the night before and having to throw away a ton of swag A because I wouldn't use it and B because I had no room and after that I was like this is just wasteful. So now I'm like really like selective, and that thing of cards made it back with me like read it when I got home, need programmer friends to come over so I can play it. So yeah, it's cool. And that wasn't the only adventure thing you all did as well. I mean, obviously you had hats and stuff, but there's also a Lego set that was pretty fancy.

Speaker 4:

I'll let one of you talk about man, I can't even remember how this came to be. I think we decide that we wanted to raffle something off, and we're developers, but we're also marketers and salespeople, and so the key goal of going to every conference is to get as many contacts as possible, and so the question became is like we have the cards and we have the icebreaker, those are the things that will drive people to the booth, but how do we actually capture their email address after that? And so, like the idea was like oh well, well, maybe we'll raffle something out or maybe we'll do a demo and they'll get their email address. And then we knew that DHH was going to be there, and I think an article might have come out recently about DHH's car, and so we were like okay, well, is there something that we could give DHH? We don't want to just give them something fancy, we want to give them something creative. And so, honestly, don't remember which one of us came up with a Lego idea.

Speaker 4:

But at first we were like oh, what does buy him a Lego set? And we'll just buy a second copy of that Lego set. Then it became well, what if we could actually get his car made? And then we started researching into the car. And then, lo and behold, there was like someone in Amsterdam who actually built custom car Lego sets and it was just like this is just perfect. And then after that it was just a matter of just negotiating with the guy, making sure that he was actually going to come out and show up, make sure that he could provide instructions and those kind of things, and so ended up being a win overall. I mean, dhh seemed delighted with it. He's given us a couple of callouts since then. I'm not sure if him and his son have actually built the Lego set, so we'll see how that goes, but it ended being a very positive experience for us on multiple levels.

Speaker 3:

It's a big model I mean, it was probably like a foot long and this very custom sports car and he's a mechanical engineer and just does this as a side fun thing, where he 3D prints some of the parts and uses Lego parts and designs and it's really a sculpture. But it's funny. It was my first time in Amsterdam and I had installed WhatsApp, because I'm American, I don't use WhatsApp. And so he WhatsApps me and says oh, I'm going to come drop it by. I'm biking over, which also. I'm like oh, this is, how much more Amsterdam could this be? And so he biked over to the hotel and dropped it off in the lobby for us the night before. He was a really good guy and did a great job.

Speaker 2:

Well, I think you all you nailed marketing for your company at Railsworld and it's very memorable and it's cool to hear kind of the behind the scenes of that stuff because I'm very impressed.

Speaker 4:

So we've been doing products for a while now, and so the worst thing that you could do is like go into a corner and just build a product and not tell anyone about it, and so our philosophy for years has been like any marketing is better than none. But then with each time that we've gone out and announced something, we'd say like okay, how can we one up this? How can we be better, how can we be more creative? Like Mike said, we're bootstrapping this, so we're not using VC money to fund our marketing efforts, so we've got to be really creative. We've kind of got to hustle and like spend a month coming up with creative ideas and tearing it apart and building it up again, and it's worked out for us in multiple ways.

Speaker 3:

It's almost a meme like developers hate marketing. But I don't think that's true. I think they hate inauthentic marketing and they hate. I think we've all been to conferences where they're like people giving away drones or they're giving away these things that aren't. They don't reference the community. That are obvious. It was just like yeah, we just picked a thing out of the air and decided to do this. Maybe it's cool and maybe that's something nice, but it doesn't really speak to the community. And like lots of games are given away and stuff, but they aren't from the community. I always want to encourage developers to do more marketing, at least speak for myself. Like I have had lots of other projects and things die because I just worked on them in darkness and never, never, tried to show them to anybody.

Speaker 1:

Definitely been there and that's the thing I felt.

Speaker 1:

The same way do that many projects and what you did at Rails world was like connecting with people on a personal level.

Speaker 1:

David sees, hey, it's a Lego kit of my car, the thing that I'm like proud of, or whatever you know, so he's going to really appreciate that. And then for us, as speakers, getting our own cards that we can share with people, it's like it's really cool and thoughtful. And I mean, frankly, been to I don't know how many conferences but rarely, if ever, have we seen personalized stuff like that that's come from sponsors. So it really helps make you stand out. And it's one of the things that I like when I'm supporting, and that was the theme to the Rails world. Amanda got up there and was like, hey, if we're using any non-rail software that you catch and there's a Rails alternative, we want to support that and switch to that. And it's the same thing that we all feel when it's, yeah, we want to support you guys and see you be successful and we end up as friends, cheering each other on, which I think is achieved and did an excellent job with, and it's probably exactly what you were hoping for, right.

Speaker 3:

It is. But also I think this is sort of my tradition in talking about WAFRIS, which is like the joke I always make, is that? So? Wafris is this open source web application firewall. It's built on top of Redis, and I always joke about like, oh, people do open source software out of optimism, but other people use this and find it useful, and I built this, and my ideas about this are all based out of hate, which is that I hate all these jerks that are attacking websites and messing up the lives of my fellow developers, because that's my day-in-day-out experience.

Speaker 3:

Running Expedited WAF is getting on calls just like this with other developers who are just like destroyed because they have to deal with these like horrible problems, and so that's just a real frustration that, like, all these sites are getting attacked, all these sites have all these bot problems, and as a community we're just sort of okay. Yeah, it's almost a joke. Yeah, there's 10,000 weird bot requests in my site every day. Nothing to really do about it. Maybe it's doing something bad, maybe it's not, I don't know. So to try to stop all of that and change things is really what we're trying to do with WAFRIS.

Speaker 2:

Well, that's a great segue. Let's get into it. So you've mentioned your background in security. I'm curious when did y'all sync up and how did this specifically come about?

Speaker 4:

This has been a long time kind of coming. Before I switched to Rails, I was in Java and I was at a biotech company and I just kind of wasn't happy because I think I was like on the leadership track and I said I kind of trained in all this to be a developer and I didn't feel like I really got that experience. So before moving to Virginia Beach I quit that job and was like I'm just going to do Rails, like everyone's talking about Rails. One of the guys in Richmond was one of the first GitHub employees and he was talking about it and it just seemed like there was so much cool stuff happening. And so I wrote this long Google message thing to the Rails group in Virginia Beach talking about like hey, I'm doing this career switch and I really want to learn Rails and all this other stuff. And then Mike was like he sent a message like hey, welcome.

Speaker 4:

And then a couple months later we met at a meetup and then we found out that our wives knew each other and next thing I know I was like the godfather of his son.

Speaker 4:

And so then we like then we found other ways to just like work together over the last like 10 to 12 years and I had done some product stuff on my own and the consulting and Mike has had seen like the success that he mentioned through the Oracle Marketplace, and we just kept on finding ways in which we could collaborate and so Wafers came about. It started out as a small idea and we kind of used conference to prove whether we should keep on doing it. I think at Rails Mike gave a talk and the concept there was like we're going to announce Wafers and see how many people are interested. If people are genuinely interested, then we're going to build a prototype. All right, once we got the prototype, we're going to see how many people are interested in using that and then let's take it to an actual product. Yeah, so I think that's just like how this came about. It's been a long time friendship and now it's a business relationship sprinkled in there, but we both consider this kind of like our life's work, our life's project.

Speaker 1:

Did you have other ideas in the interim, or was this kind of the one that you're both had honed in on? This is an opportunity that we should just. It makes sense we need to do this.

Speaker 3:

There's certainly been lots of other things we've spoken about and, like, ryan has helped me with a lot of the expedited stuff as well, which is the existing enterprise web application firewall and things we thought about it as like timing. This worked out well in a number of different ways and I think there's a size to the problems that you're solving. That. Is this something you can do on your own. Do you need to raise money for this? Do you need a co-founder? And I think this just made a lot of sense for us to work on together for all of that.

Speaker 3:

Another piece of this is that, unlike a lot of other things we could be doing, I think there's a real satisfaction to working on security software. It's just very easy to feel good about. Well, if nothing else, we stopped 10,000 attacks on this site today. I don't know if that's going to make us a bunch of money or if people are going to really dig into this, but at least like it feels directionally positive to other people and to ourselves and tell my mom about it. Like without, if I was writing SEO software or something would be like oh yeah, I tricked Google into getting our site better Like that's not as satisfying.

Speaker 2:

So monitoring, like web development and lots of other things, can be complicated.

Speaker 2:

There are tons of tools and techniques, but you just want to know that your app is up and that your customers are happy. When your customers encounter a problem, you need clear, actionable intelligence, not walls of charts and reams of logs to tail, and that's why the team at Honey Badger built Honey Badger, the monitoring tool that they always wanted, a tool that's there when you need it and gets out of your way when you don't, so that you can keep shipping, know when critical errors occur in which customers are affected, respond instantly when your systems go down, improve the health of your systems over time and fix problems before your customers can report them. Honey Badger is the application health monitoring tool built for you, the developer, who cares about a quality product and happy customers. Start monitoring today at honeybadgerio and, best of all, honey Badger is free for small teams and setup takes as little as five minutes. Once again, that's honeybadgerio. So you mentioned that it's an open source, but in the case of firewall, so I'm curious how that plays into the business aspect of it.

Speaker 4:

We talked to Tom Rossotti and he gave us some advice and coming up with business values. One of our core business values is we're a business first, but we have a strong belief that security should be elevated for everyone. So that's where the open source angle came into. All this is hey, can we make this readily available for not only the Rails community, but like the Laravel community and like all the different web application communities or framework communities? And so we drew a lot of inspiration from Sidekick, and so the idea was always like, hey, we're going to build something that's open source to a degree and then we're going to build the business around it.

Speaker 4:

So it just made sense to build the gem that acts like as middleware, similar to Rack but RackTec, and in that gem it basically passes request data over to Redis and we use Lua within Redis to kind of unpack all that data into like Redis data objects, and so that's the open source component, the data capturing. And so if people use the Redis CLI or they use our eventual like open source CLI, they can create all the rules and stuff like that. But the business side of it comes in with like the web application and being able to visualize the traffic and set rules there and really like lean on our expertise, take advantage of role sets and country blocks and those kind of things, things that would be really hard to make, like open source, because it depends on other data.

Speaker 2:

Yeah, that makes sense. It's a cool model too. Like your business first and you're giving back.

Speaker 3:

It has two things. One I mentioned Exprided WAF is the enterprise product. It's enterprise pricing. If you want to, you can go into the Huroken marketplace and see what it has, but it starts at like hundreds of dollars a month because it's an enterprise thing, which is good, except that everybody gets hit and it's not just the big enterprises that can afford that. And so part of this is having something that I can feel happy about. Anybody can use this Like. This is just a default that you can put this into any web app. It will improve the operational security of it and that's again something just to feel positive about.

Speaker 3:

And if we can get to the point where we have a profitable business around this, that lets us do more of that.

Speaker 3:

That is sustainable in a way that, like, definitely there are other I think open source web application firewalls out there, and that's a very fuzzy term. What is a web application firewall? There's some applications and this isn't to say anything bad about them, because I think they're all again directionally positive, they're all better than not having them. But there's some that are just like a list of rules put in these five regexes to each of your requests coming in and hey, that's a web application firewall, and that doesn't really, I think, get to the core problems that I see people have, which is trying to really understand the traffic that's coming into your site. Being able to make decisions about that and then being able to see the results of those decisions and to have that really tight feedback loop is really what makes, I think, wafrs useful in a way that some of these other tools and even my enterprise tool is not to have all of that together in one spot.

Speaker 1:

Yeah, that's always. The hard thing is, if you don't have any of this, it's well, you can go into nginx configs and add a little route to deny this IP address, but you write that once you get attacked a week later it's different IPs, hundreds of different IPs, whatever, and you don't have any context when you're looking at these config rules. That's what I've done in the past, very simply, but it's not going to really be effective, especially if you're building something that gets attacked a lot or whatever, and it doesn't even have to be.

Speaker 3:

I mean, we're entering a weird space with web applications, and by that I mean one. No one's ever taken the bet that like, oh yeah, next year there's going to be fewer web attacks than there are this year against your applications. There's just more and more bot traffic to like an insane degree. And the other thing that's really set this off is now all the AI stuff, where the secret of all the LLMs and everything else is that they're based upon massive amounts of data. So now every AI startup, every Silicon Valley fang is before anyone gets wise to this, we need to hoover up every website on the internet and have that data to feed our models, because it's going to get denied and that's just something that's happening. So we have a friend who was running pretty non-commercial websites really a passion project and 95% of the traffic to it was bots and it wasn't even like Googlebot, it was some of these AI bots. It was some of these like SEO bots that are trying to like reverse engineer Google and it was just nothing helpful, nothing useful. And having that much traffic that's just bot.

Speaker 3:

Dark traffic then obscures all of the real stuff, like how much resources do you actually need to run the site.

Speaker 3:

Is there an actual attack happening?

Speaker 3:

Can we actually see what's going on? And two simple things that Wafers does that are a challenge in a lot of other contexts are one it gives you a list of here's the IP addresses that are making the most requests to your web application and here's a list of how many requests they made, what country they're from, and then we have like a little reputational grade to them. But even just like seeing like here's the number of IP addresses and how many requests they made in the last 24 hours. It's a very simple sort of report. That is not an easy thing to get out of a massive log file or your systems as they are in most cases, and, like Chris was saying, it's really hard to block an IP address, because you block one and then there's six more, and so we have a lot of contextual tools that say like maybe instead of blocking this IP, you should block this whole network, or maybe you should block this whole country, or do these other sort of rules that will really help you better manage your traffic.

Speaker 1:

Yeah, and people are getting pretty crafty. There was, I don't remember, somebody in the Philippines had stolen a bunch of credit cards and had attacked. I know we got hit by that person too, but, like Peter Levels and a bunch of famous like Andy Hackers got slammed with an IP in the Philippines that was testing fake credit cards. And then you're on the hook for those refunds and other things if they go through, and it's like important to be able to analyze that and you're not going to get the same sort of information out of like analytics tools which are going to give you, like the homepage had this many page views. It's like sort of the same data, the requests that are being made, but like from a different avenue that you're looking at it instead of an analytics tool.

Speaker 3:

The term I use is dark traffic because, like image and analytics tools and I think the unspoken word there is those are marketing analytics tools where they very deliberately try to filter out bot traffic, filter out stuff that's not using JavaScript on your site and things, but it's not even credit cards. It's all sorts of resources. So, very common thing you have a site, you have a login and you send a confirmation email. No credit cards, that's just it. So what people do is they will say I'm going to target Ryan, I'm going to hijack his SIM card, but I want him to be distracted when I do that so he doesn't get the alerts from AT&T. So I have a script that goes out and it hits 100 different websites and subscribes his mobile number at AT&Tcom. Do that, so he then gets hit with a hundred. Hey, please confirm yours, sign up to such and such, and that's a different resource thing than testing credit cards. But that's also a huge problem. Like none of us, I don't want my sites to be complicit in that.

Speaker 3:

Something else that happens a lot that I've been trying to get people to do is if you have a sign up format, it's like first name and email address and then you submit it. What bad people will do is they will put a URL into the first name because the hope is that you will then send that confirmation email. Ryan or whoever it is gets that, and then they click on it because you have to URL on this weird email. And then they go to the site and put installs malware or something else that it's an attack. So it's a whole ecosystem and we're trying to help other frameworks as well, not because we don't love Rails, because we're both Rails developers and our apps are built on it, but there's just so many attacks that cross websites and cross frameworks and systems that kind of feel like we have to raise the water level to raise all the boats. So we're all doing better with security.

Speaker 1:

Yeah, we were just talking to Craig from Crutchie Data about offloading your Postgres knowledge to the experts and your database knowledge and stuff, because the same thing applies with WAFRIS is like, yes, we can learn about these attacks and things, but we will be too late, we'll be attacked and then be part of it and then understand like, oh, this is how we need to mitigate what's going on, but it's too late. And it's like another nice way that you guys can see the different types of attacks and then kind of recommend things and then pre-guard against those and we can work on our applications and focus on trying to ship our features and do things for our customers, rather than being attacked and trying to deal with that on top of all that, which is, I think, probably a giant benefit of what you guys are offering.

Speaker 3:

Yeah, and part of what we're trying to do is try to make this more automatic, which is feedback that we've really heard. So we have rule sets that you don't have to come up with everything from scratch, like Rack Attack we again love Rack Attack, I think it's great, but it is a blank config file when you get it and you have to put everything into that, and so we have like preset rule sets. You click a button and here's 500 different rules that will help filter out all these vulnerability scanning bots. You have a site that doesn't have an API? Well then, there's no need to allow, you know, the go-lying user agents to make requests or curl, and that's as simple as those rules are. Those actually are quite effective in a lot of cases because the bar is so low, because so many sites attackers just hit.

Speaker 3:

I'm just going to run the script against a thousand different sites and they don't really care. They just try to find anything on a thousand different sites, so if yours blocks them, they just kind of go on to the other ones. One more you're saying about the expertise is that is something we want sort of, as our pricing is not just that it's the software, but that you can sort of escalate to us in case there's issues when I've done incident response for web attacks for years and so most people have not been in that situation where I'm talking to people every week that are. So I'm able to say like yeah, this will be OK, that we'll be able to figure this out and be able to counsel them about here's some of the rules we can set. Here's maybe some of the application changes or different techniques to stop the different attacks. So I'm rambling, I'm still kind of sick, but yeah, no, that's good.

Speaker 1:

I always like the products that have the ability to we can help you out more than just what is automated in the service itself, Like you can have us analyze what's going on and then provide some rule sets or whatever that are custom for your situation or whatever. It's a nice thing where you write in the customer support and you're like help and they can actually help you, instead of being like sorry, our software doesn't do that and that's where you left off.

Speaker 3:

Again, big changes in the industry. I think another big change in the industry is really role compression, where we're seeing software developers. You have to take on more DevOps, more front and back and more database administration, and in there somewhere is oh, you also need to be the chief information security officer to this application, and that's a really tough spot to be in. So we're able to help in some way with that, either through software that makes gives people security superpowers of some level, or at least insight into what's happening, that they can make better decisions, or we can help directly with it. Those are wins.

Speaker 2:

So how would how would someone listening get started using Wafers?

Speaker 4:

So we have the site Wafersorg. You can go in, you can register and it's going to point you to like the Ruby gem page and the Ruby gem is already like open source. That's at Wafers dash Rb. You can go look at the code. It's pretty simple. On the Ruby side it's only like three or four files. All the heavy lifting is happening in that that the script that gets uploaded to Redis we turned on like signups. Last week I think we announced it to like a lot of the Rails world people and so people have been coming in on boarding and adding their Redis instance so that we can help them visualize their traffic. That's the best place to go for right now.

Speaker 3:

Grace for you install the gem. There's a config file you put into your Rails app that points to a Redis instance and then inside a Wafers hub, which is the web admin, you point to that same Redis instance and it just picks up the data from all the requests in real time. And so what's held in Redis is really just this sliding window of all the request data broken out, so you can go in and filter it in different ways and see the different patterns and make rule changes or apply the rule sets like we spoke about.

Speaker 2:

And then you mentioned you're looking at some other ecosystems as well. Do you have any progress there? You still, right now, just kind of focus on Ruby.

Speaker 3:

Part of the reason to leverage Redis is that it makes it pretty easy for us to hop between these, and I think one real interesting place to go to is working on one for traffic. So you know there's a lot of interest in Ruby right now. About Kamal, which uses traffic. That's a natural place to put this. Caddy's, another one that we have needs a little more testing, but it's actually up and functional now, so that's good. Those are both in go and certainly we have the ones that are going like in progress, like they're a vol and Drupal and some of the PHP ecosystems.

Speaker 2:

That's cool. Yeah, I guess when you get kind of into like the more framework specific ones, you're kind of spilling middlewares, because I mean powering it by Redis and everything else.

Speaker 4:

Yeah, it's just get the request object pass those request headers over to Redis, like when the application loads loads the Lewis script into Redis and it gets a shaw back and as request comes in it just calls the shaw with those arguments and then it passes it into Redis and the Lewis script dissects it all and puts it into the different Redis object.

Speaker 3:

It's kind of like stored procedures in a normal I say normal database, but you know relational database, that's what Lua uses inside of Redis. So that's what it runs, but it's super fast because it's Redis, which is good. And it was an interesting experience for us because neither of us were professional developers. So we're doing a lot of writing Ruby functions, like I know how, I know what needs done. So I'd write the Ruby function, then put it in chat GPT and like just make this an idiomatic Lua script and then come back and like, okay, well, that was better. And then use that as a starting point at least for a lot of our work.

Speaker 4:

Yeah, we also had to like unlearn a lot of our SQL knowledge because it didn't really apply on the Redis side and so we just had to experiment with all their data objects. But the cool thing about the Redis documentation is they kind of give you for everyone who was like in computer science, they give you a big O notation to describe how the different things perform. So we could easily look at that stuff and just say, oh yeah, this is going to perform linearly or this is going to perform like exponentially we can't use that object or we can use this other thing. So that was helpful. But a good part of the summer was spent like experimenting with like different things and seeing like the impact on memory, seeing the impact on performance, and that was really cool. And Mike mentioned the whole chat GPT thing. That was cool as well, but it was a process.

Speaker 3:

I was saying it's an interesting test coverage issue as well, because it's not just did we cover all the lines of code? Because we have to. Also, well, because it's a lot of trade-offs without a really crisp answer as to what's correct where we could double the memory usage in Redis and that would get us 5,000 more requests per second. Is that worth it? Or we could use a very different data structure and it would work very differently.

Speaker 3:

And you can imagine an e-commerce site that has like thousands or millions of visitors, but they all make six requests and then they leave, versus like an API that's like okay, there's a dozen IP addresses that are in factories around the world and they just do nothing but pump out millions of requests to this. That is a really different impact on what those data structures look like. So we had not just the normal sort of test harnesses but also these sort of scenario-based tests that would run and generate data and push it directly into Redis for millions and millions of requests, just to model all of this and then spit out Okay, well, in this scenario, every request that goes in use so much memory and took so much of the overall slice of the time and things. So it was a challenge, an interesting engineering challenge for those reasons as well.

Speaker 1:

How do you balance those rabbit holes of we could go and spend months on those types of problems versus you're trying to build a startup and a business and self-funding it, and how do you guys look at those decisions that you've got to make along the way? Because I think that's a trap. As developers, we're just we'll do the comfortable thing, which is let's just keep writing software, which is not usually the thing you need to do.

Speaker 4:

Yeah, the natural tendency is to want to go build cool stuff, to get that Dorphin rush for like seeing something, like run or have a test pass or just creating something.

Speaker 4:

Because we know that we're susceptible to that, we try to start every day with marketing and sales, like what's something that we can tweet, what's something that we can write, what's something that we can share, and we try to do that every day.

Speaker 4:

And then at the beginning of each week we kind of look at like bigger picture, like targets. We've found that conferences are kind of our bread and butter, like marketing wise, so we're kind of just going to lean into that. So Mike's done a really good job of tracking all the Ruby conferences and some of the other framework conferences that we plan to attend. Then, like, the bigger discussion is like hey, are we going to go to this conference or are we going to sponsor this conference, or what can we do to like help make this conference a better experience for all the 10 D's? I mean, those kind of conversations might happen like once a month and then, as we're like approaching the conference, then we're starting to switch to more conference prep time and less dev time, but it is definitely a balance and every week is different, which is fun and maddening at the same time.

Speaker 3:

I was just going to say we argue about it, but I like Brian's answer better, so that's cool, sure.

Speaker 1:

Yeah, that's great. I wanted to shout out your like ultimate guide to rack attack article, which was a, I think, a good marketing example, where it's like, yeah, you can read the rack attack, read me and stuff, but practical examples and things you can write a blog post that's kind of evergreen, like that that people can find on Google or whatever, and it just stays there as a resource that I mean they could do that in the read me of rack attack, but they didn't, or whatever, and you come up with the sort of staple articles as another conferences. I think you said it was your primary focus, right now at least, and it's neat to see you trying the other things around too, cause those I think maybe take a lot longer but can pay off in different ways or whatever.

Speaker 3:

Yeah, something we deliberately look for is what we call forcing functions, which is just like is this a scenario that forces us to deliver and the conferences are great for that Cause? They're going to happen, whether or not our stuff is done or whatever. We can't say like we'll just keep working on this for one more week. No, we have to have something to show. We have to show up physically and do that. So that's a great motivator and I think, like Brian said, we can chart a very crisp line from like rail Sassel a, where I give that talk and announced Wafras, to the feedback we received there. Then we worked on stuff. I went to Blue Ridge Ruby and demoed this to a bunch of people, and I think we also bought ice cream sandwiches and took some people tubing and stuff. That was fun as well.

Speaker 3:

But you know, from that I think we learned oh, it's not enough just to have these things available. It has to be more automatic, it has to help people better. It just hits different If you stand there and have 20 conversations with people and every single person says that looks nice, but can it just do it for me? Is there a button I can click and it would just everything you just told me would just happen automatically. You kind of think, oh yeah, mike, you're being a dummy, you should do it. These 20 people that very nicely gave their time and gave you feedback, you should do it. And the same thing with Rails world. We had so much great feedback and so many opportunities to hear people's perspective and so many people. So, yeah, I've been struggling with this in this other way, or we've kind of built a half sort of system like this and it's not great. So all of those has just been so helpful to us. Like everyone who's given feedback or taking the time to talk to us, it's been great.

Speaker 1:

I was just going to point out that I think the important piece that you guys just said there was basically like you're going out and having conversations with as many people as possible. You're not just doing like the SEO we spam content out into the world and I hope people come check us out and buy from us. It's like no, we're actually just going and talking to as many people and seeing how we can help them as possible, which I think gives you that feedback. But you wouldn't get that feedback in comments on your blog post.

Speaker 4:

That's a great distinction. One of our things is like we will have a conversation with anyone. If you like schedule a call with us, we will like sit on that call with you for 30 minutes, talk about your application and talk about like security stuff and just learn more about you. And if Wafers helps, that's great. But we just always want to be curious and always learn from people and always talk to people.

Speaker 4:

One thing that I want to say about the previous question about marketing efforts one thing that we have on the board but we haven't gotten to lean on as much is engineering as marketing and I think this is like attractive, probably for a lot of like listeners is Jason brought up for a good SCRF time.

Speaker 4:

That was like a small project. That might have been like a weekend project, but it's been around for such a long time and it's just driven so much traffic to my site. So we look for those kind of like hey, is this like a little small tool that I can spin up and build up? One great example of that is I think in April we launched IP lookup in our site and it was great for us because all the IP lookup services are just okay looking. We thought that we could just kind of take it to another level, but it also served as another piece of capability within WAFRIS itself. When we choose these marketing things we're like trying to look for, like these evergreen or multiple wind kind of things that keep on working for us.

Speaker 1:

Those are really good and they're in line with the open source, you know model that you're starting with too, where it's like we have all these other tools too. It's also a way if you at conferences, you'll meet certain people and then you'll stumble across other people, using these tools, that you may never have run into. Blog posts do the same thing and you're just putting out like not just one area and you're only focusing on that and only capturing conversations with those conference attendees. There's so many people who can't make it to a conference or whatever, so you've got those other feelers out there to like find people.

Speaker 1:

That was always something I struggled with when I was like trying to build ideas and whatever.

Speaker 1:

It was like I can write blog posts or whatever, and that's kind of like I did a free video every other week, like Ryan Bates was doing as my marketing, because I was like afraid to talk to people and stuff.

Speaker 1:

And then over time you're like actually figuring out how to talk with everybody as much as you can. That's really the thing you need to do, and then you figure out what is my product, what do they need to help with? Actually, because what I think may or may not be right, like you're saying with, can we have an automatic set of rules that you recommend and we just jump in, turn it on and we're off to the races? And, yeah, maybe not everything's, maybe you have to go disable something eventually, but like you've done such a good job of here's the basics and getting you started or whatever that feedback is like, you probably wouldn't have thought that yourself because you're like in the weeds and God, this is fun. But those conversations make those like surprisingly obvious. After you have 10 conversations and you're like oh, these 10 people said the same damn thing, so maybe we should listen to that.

Speaker 3:

Yeah, I think that's something that I've only gotten through. Maturity is that we gain skills. I think there's a skill to taking feedback, and I think the biggest thing is just to actually listen to people. If they tell you something, they probably mean it, and not only that, but it's. I really am genuinely grateful to all the people that spoke to us for all this time, because it's tremendously useful.

Speaker 2:

Well, I appreciate you all taking the time to come Chowthas today, share what you're working on, share some of your ideas for marketing as well, because, yeah, my every one of my projects is unsuccessful and there's a correlation to, like you said, I just build it in the darkness and I never like. I'm just like, oh yeah, this is great, but people don't use it because I never said anything about it. So it's cool, it's encouraging and, yeah, excited for what you all are doing.

Speaker 3:

Well, I'm sure you're going to have like show notes and stuff. I like to give you our booking URL. We're real serious about like we are happy to talk to anyone in the rails community about this stuff. So it's just a time you like a Cali. You just book a time with us. We'll get on and happy to talk to you for a half hour about your app or whatever you're up to. We'd love it. Honestly, it's like your own private podcast with Ryan and myself. If you want to make it that there you go.

Speaker 1:

Now you're talking. Is there any links you guys want to share, or anything like that?

Speaker 3:

before we wrap up, Go to the get hub page and we will share that booking URL. One other thing I'm trying to do better at social media. I'm not great at it but we've been posting, for like the last month, little things we found in other people's applications, because I kind of look through and monitor the different sites. So we've been finding like lots of weird stuff. We found like a Chinese botnet that it like proxies through your site to get around the great firewall of China, Like interesting stuff like that. We found for some reason like there was a whole bunch of IPs from Switzerland that were looking for Singrid credentials on thousands of different sites. All sorts of these weird sort of interesting findings we've been putting up on our social media. So maybe an interesting thing to look at too.

Speaker 4:

And those social medias are. Mine is at Twitter, like RM is still RM C A S T I L. Mike is M buck B and the WAFERS Twitter is WAFERS org. At WAFERS org.

Speaker 1:

Got it. We'll include those in the notes and I will say I've been enjoying those tweets because it's like there's all this stuff going on on the internet and it's all invisible at the dark net or whatever, and like it's really fun to see what people are doing and this strange things that are happening that normally you would have no idea any of this is happening. You're probably running what Grails apps right now and have no idea about some of the strange attacks that have hit your apps and it's cool to see all that. So I love it. Keep it up.

Speaker 2:

Right. Well, jason, chris, thanks so much. Really appreciate it, likewise Thanks.

Speaker 1:

Same.

Speaker 2:

Yeah.

People on this episode