Hey, Welcome back to another Ruby Dev Summit interview. I'm here with Andy Mala. I'm always worried that I'm saying your name wrong. I'll just admit Mali Male Andrew or Andy is the He won the Fukuoka Ruby Award in twenty twenty two for the Glimmer desktop UI. There was an official name, but I can't keep it straight in my head, so I apologize for O libui. Awesome. Yep. And then you have a master's degree from in software
engineering from De Paul University. And yeah, anything else that I missed that's important. I've spoken at Ruby KMF three times so far, twenty eight, twenty twenty two, and twenty twenty three. I've spoken at rails conv twice, twenty twelve and twenty fourteen. Awesome. Well, I'm gonna dive us right in, and anything that you've spoken about at those conferences it's into this question. I'm happy to hear it or any other ideas you have. But
I've been asking everybody what is the future of Ruby? Yeah? Most certainly my presentations at Ruby KOMF were about my open source project, Glimmer, and in twenty twenty three I gave a workshop on how to build desktop applications with Glimmer DSL FORLIBUI. So I certainly see Ruby moving more into the Dusktop in the future and not just being a web only language. So we can, you know, build a lot of tooling and Ruby. Like I've built my
own ID. I have an ID called Gladiator that I've built completely with Glimmer. Oh wow. I've also I know a Japanese developer that built his own internet radio app and I use it every day to listen to jazz music. I really like it, and it was also built in Glimmer. It's kind of like a Ruby version of iTunes in a way. And yeah, so
a lot of so we can build tooling and Ruby. We could build like any you know, like media tools kind of like for playing music, play simple play sorry, build simple games kind of like Tetris or simple board games. So yeah, there's a lot of future for Ruby in the on the Dusktop. I would say, I think it took a while for Ruby to get back to the dusktop because Shoes stopped getting maintained about seven years ago, maybe eight years ago. So fortunately I had time to maintain glimmer right after
that. And I've been maintaining it very actively for the last maybe six years or five years, a little like about a year after Shoes dropped out. So yes, so I do see a future for Ruby on the dustop. Yeah, I remember Shoes did. Did the support for it drop out? When? Why the lucky stuff kind of disappeared? That was the first dropout, which happened in the mid two thousands, and that's what prompted me to
create Glimmer back in two thousand and seven, the very original version. So originally it used to run in Ja Ruby and it was using the SWT toolkit. Eventually I decided that the idea is good enough, like if using a Ruby DSL that I can expand it to all other toolkits. So now it supports tk GTK, Java FX, swing FX, Ruby wx widgets. So yeah, it supports every single toolkit that is available in Ruby today, about seven of them. So I guess in practical terms, does that mean that
I can write say, macapps and Windows apps and maybe Linux apps. Yes. All the Glimmer dsls for desktop development are platform cross platform library okay, supporting yes, Mac, Windows and Linux. The SWT Glimmer library which runs in Ja. Ruby can also let you package your app as a native executable on those platforms. So I can create a DMG aisle on Mac, or an e x E or m s I on Windows, or a Debian file
or RPM on Linux. So that way, when I package the app and I give it to somebody to install, they don't have to install Ruby, they don't have to install j Ruby, they don't have to install Java. Everything is included. That's awesome. That is so awesome. So so yeah, So, I mean, I definitely see Ruby going more into the desktop.
And in my opinion, I think it's a shame that nowadays a lot of Rubis or people that claim to be Rubis, are using id s and code editors not built in Ruby. I mean, some of them work at very big, prestigious companies, uh, and they claim to be you know, Ruby experts, and yet they don't build their own ID or or editor
and Ruby. They use an inferior like they use vs code, which is built in JavaScript, which is an inferior language, a very inferior language in fact, And uh, it's a shame because they could have spent time contributing to the Ruby ecosystem instead. And like the productivity of using a Ruby DSL is way higher in my experience than using something like HTML CSS with JavaScript. So I do, I mean, I do call like bullshit a bit on some of the people that without using Ruby tools or tools built in Ruby,
like desktop tools built. But I think that that is at the same time, that's a great opportunity to go into that in the future. I mean, I did my best to put my money where my mouth is and build my own board editor with Glimmer and Ruby. So I think that's why I see a great future in it. I'm just a very I mean, I would say I'm not an ide building experts. I just built my own as
a first experience and it kind of worked for me. But I would I would hope that, like sorry, like I would look forward to what experts could do then with Ruby start development to help build, to help build better Ruby tooling. Yeah, I think. I think. As I've talked to a whole bunch of different people within the Ruby community for this summit, we've
seen some expansion into other areas. One that comes to mind is Dragon Ruby right where it's mostly focused on game development, but you can deploy your games to pretty much any platform, Yes, are there right. That's another part of my prediction for Ruby. Uh. In the future, it's going more into gaming and definitely and Ruby seems like a great option right now because from what I've seen in demos like at Ruby coff twenty twenty two, it has
great performance. Yeah, but there are other options as well like Ruby two D and go through UH. It also can build very simple games in Glimmer, So I definitely see Ruby getting more into gaming in the future as well. Right on the flip side of that, you know, where we've talked a little bit about Dragon, Ruby was mostly mobile focused initially and then kind
of spread to these other platforms for gaming. Do you see something like Glimmer moving more toward mobile where you know, maybe I'm building my business app for the desktop and then later I have the option to build it for the iPhone or Android or something like that. It's not a game. Yeah, That's certainly a third area that I think Ruby will have a future in as well
as mobile development. I definitely think Ruby Motion Story, which was built by the creator of Dragon, Ruby, is a good option to get people started and building cross platform apps on mobile, so meaning apps that run on iOS and Android. I've experimented with it a little bit, and I do want to eventually have a glimmer DSL to simplify development with it. So I did look into the idea a little bit, but I got pulled into other projects,
but I want to get back into it eventually. I think even without Glimmer like, ruby Motion does provide an interesting option for cross platform mobile development in Ruby. Yeah, I need to talk to a mirror about that, because he acquired ruby Motion and then put all the focus into Dragon Ruby and I'm wondering. Yeah, now that you mention it, if yeah, ruby motion is still an option for the Hey, I'm not building a video game
app. I'm building a whatever mobile app. Yeah, last that I checked, Ruby Motion is still functional and it works, and there are people that are quite pleased with it. However, one thing that it's lagging behind in right now is support for the latest Ruby versions. So Dragon Ruby, for example, by contracts like you said, like they're very active into supporting it.
So it actually already supports Ruby three point two, if I'm not mistaken, whereas I believe Ruby Motion might be still stuck at Ruby two point zero or something like that. So that is definitely something that I I'd like to see them improve upon. But at the same time that like that, that also makes it an opportunity for Ruby expanding into mobile development in the future. Yep. Absolutely. Otherwise, the fourth area that I was thinking about is
basically web development in the front end. So Ruby in the front end was something that Matt's mentioned in his keynote speech at Ruby Comp twenty twenty two, and he said that given that we have options like Ruby wasn't we should be able to now run a real Ruby in the browser and do real full like full front end developments in Ruby. So that means we can have isomorphic, isomorphic applications built with Ruby on the back end with rails and Ruby on the
front end with rubym or another option like opal ruby. So opal ruby usually produces like Ruby wasim will compile the entirety of Ruby, whereas opah Ruby is more like a transpiler to job us will produce much smaller downloadables. So in my opinion, Opal ruby is the more convenient option for using Ruby in the front end if a company does not want to have long like big downloadables like it's only in kilobytes in open Ruby, whereas in was'm it's in megabytes,
so I think. But both of the good news is both of them are options on the table nowadays, so I definitely see what'll be expanding more into front end development and also becoming like enabling isomorphic application fragments, which means I can reuse the same Ruby logic that's in the back end for some business rules on the front end as well, so that way I don't have to re implement the order tax calculation algorithm on the front end again in JavaScript, if
I want to calculate it in the clients, I can just reuse the exact same code from the back end in the front end. I've actually experimented without myself and got that working. In fact, recently I spent the holidays like creating a new Glimmer library to support development on the web with open Ruby using Glimmer DSL, and I was able to have it. Basically. The nice thing about it is you can build HTML using a Ruby DSL, which means I don't need ERB, I don't need GSX, I don't need to mix
multiple languages anymore. We can step a level higher and abstraction and just have one language that handles both structure and logic, so that way I can add if statements or each iterator into the exact same code that is building the HTML GUI, so then the code becomes a lot lighter, and also it enables me to then use like very advanced object oriented techniques for Ruby to do real MBC and MVP development. And the new Glimmer DSL for Web project is basically
the newest one. It started in twenty twenty three and it got finished for a first beta version just a few weeks ago, and it basically enables also the usage of all the desktop data binding features of Glimmer on the web, and I've played around with using it a bit for building samples, and I was shocked by how productive it is compared to something that React. I felt like I was at least double as productive as I am with React, which
I use in my current company. So we've been exploring switching React with Glimmer DSL for Web recently and we're probably going to do a proof of concept of that and implement it soon. So I definitely see a future for Ruby on the web development front end as well. Right and just if people are more interested in either Ruby WISM or OPAL, there are interviews done with Ellie Esquito who does OPAL and with Yah with with Elias a lot about I hit him
up if you will ask him questions about YEP. I also talked to you to Psycho, who's the Ruby cor committer for Ruby WASM. So yeah, if you want to if you want to know more, there's more. Yeah, And and I love the ideas of getting Ruby on all of these different
platforms. It I mean that I don't know it. I remember back in the day when basically your good options for a lot of this development was you would do Cotland development or Java development for Android, and then in anything that ran the Android system in the back end, so things like firestick TVs and
stuff like that. Or you'd use Swift or Objective C to do your Apple stuff and that's so that your mobile phones and your Apple TV and then you know, on and on and on, and then JavaScript kind of broke into those and it was nice because then it was like, Okay, well this is a language, it's a little bit more familiar, and I can mostly do the same thing and have it work in multiple places. But the thing is is like, I don't know. I've written a couple of react native
apps. I've written a couple of other apps with different JavaScript options and they're just not my favorite tools to use. And so yeah, as I imagine, Okay, well, hey I can do this in Ruby, and I can be hyper productive and I can get what I want and it's going to be performed enough for people to use. That gets me really excited that that's what fires me up. And so you know the things that you're talking about, it's like, yeah, well, if those are all the case,
then the sky's kind of the limit. Yeah, definitely. The only area that I left out other than desktop, mobile, web and gaming is AI. So I actually I'm a co organizer of the trall or it's called the Montreal RB Ruby meet up in Montreal, which is a meetup for like basically giving software engineering talks using Ruby or Ruby on rails, but people will usually cover different areas of development like desktop development, web development. And the last
two months we had two AI talks that were very interesting. Both of them involved building large language models, and so one of them was given by let me see the name of the guy. His name was let me see, So I mean the library is called lang chain, and that was the library he presented. His name is Andre Bondarev. He's based out of New or So, Yeah, he gave it an interesting talk about how do you leverage
Ruby more for AI and machine learning development. And then the other guy was called John Sebastian Boulanea, and he gave a talk called building an AI Medical Scribe and Ruby, and that one was very interesting because basically it was like an AI scribe that would accompany physicians by listening on the microphone while they're talking to their patients, and it would basically listen to everything they discuss and then
it would summarize the conversations into the most useful pieces of summary information, which then the physicians can later use to save time and avoid having to read the entire transcript, so it saves them, it would save them hours of work basically. That so basically both of those talks were about using Ruby for AI. So that's definitely another area that Ruby could break more into in the future.
Yeah, we've had Andre on the podcasts. I don't know the the other guy that you mentioned, but we did talk to Alex Rudahl who's been working with the open ai and written the open Ai gem and yeah, it's it's fascinating to see where some of this stuff goes. Now, lang Chain itself is written in Python, but the Ruby libraries and the Ruby bindings, from what I understand, are excellent. And I know that Valentino Stole, who's my co host on Ruby Roakes, has also done a bunch of stuff
with that. And yeah, as the tools get better, I mean, there's there's no reason why. Hey, you know what, there's this awesome tool out there. It's kind of like using postgress, which is also not written in Ruby, right, but we connect to it because it does the work on the back end we need. Yeah, you know, there's no reason why we can't write these apps in Ruby and you know, surface some kind of useful AI to them in rails or something else and take that to
the next level. Super exciting. I'm also talking to Alex incidentally about doing an AI challenge and it'll probably be the middle of March. Is what we're looking at, and leverage some of the open AI stuff. But yeah, it might be interesting to talk to somebody and see about doing something with a lang chain or something like that where it then is not using open Aiyes,
models, you know, large language models, et cetera. And their imaging models, but actually building your own would be really interesting, and maybe Andre's the right person to go to for that mm hm. But so it's it's cool stuff and it's it's so powerful as far as like the different options you have then to give a better experience to your users, which I think is what we all want. It's we want to solve a problem that people have in a way that really fits with what they need. Yeah, exactly.
I mean there there is a place for other programming languages like C plus plus, Swift, c Sharp, see and Java. Like sometimes there are needs to optimize algorithms with types, and for those cases I might use a different linuage from Ruby. But at the same time, if I'm building like highly uh, I would say abstract things that can benefit from object oriented and DSL sorry object oriented programming and dsl's then Ruby is definitely an excellent filelnce for it.
And I personally still think Ruby in my opinion, Ruby could do anything that Python or JavaScript could do, but better or even Pearl. So in my mind, anything that has been available in JavaScript, Python and Pearl should be we could we could use Ruby for it instead. Going forward, Yep, absolutely are there other things coming down the pipe with Ruby that you're excited
about or want to talk about. Well, I mean, yesterday somebody hit me up about my new project, Glimmer DSL for a web and he said that he likes the front end a development aspect of it a lot, that he was curious about how to integrate it with back end developers from rails, and he asked need to expand it so that it would offer an alternative to
RB on the back end as well, using Glimmers Gloomer DSL. So the interesting thing that him and I discussed yesterday that I'm still exploring is basically you could have the same exact components on the front end and back end, so you would develop a component once and it could either be server side rendering for it when the page first renders or it can later be rendered after the Patient's interesting and the interesting part is if it included any JavaScript logic, and like
if we're using Opal, Ruby or WASM, it wouldn't be JavaScript. But either way, if it has a listeners or data bindings, they would not get hydrated and activated till after the page is rendered, So there would need to be some logic that would you know, if I'm running on the front end, it would attach the listeners right away. If I'm running on the
back end, the event listeners are attached after rendering the page. So that's something I'm researching right now, is how to use like how to build isomorphic applications or DSL for both the back end and the front end. Yeah, and if you're looking for a model that does a lot less of the how do I put it the big upfront heavy duty hydration like react or Angular does.
Quick has a really interesting model of doing that where they use web sockets to effectively lazy load in and then eager load in stuff as it goes. Yeah, that web sockets is definitely are definitely on the agenda of things to explore as well to figure out how I can make the life of rail software engineers easier or like sorry, more like more productive whenever they use web sockets
as well. Yeah, and there's so much exciting stuff coming in rails, you know, not to kind of steal the conversation and what you're talking about here with the future of Ruby, but yeah, I think there are going to be a lot of good options for that. I think they also use web workers which is something that EHH says he wants to make first class in RAILS. Yes, that is another thing that I'd like to explore eventually in
the future. So rails offers the new you know, hot Wire and Turbo technologies, which are very interesting because they decrease the need for writing JavaScript manually for a lot of buses, especially cases that are just doing straight AJAX and then you know, putting whatever HTML where received from the server into an element. So there are other alternatives that are doing something similar, like htm X, which lets you to any sort of like element replacement with AJAX calls by
using HTML attributes. So both options are interesting in my opinion. They're orthogonal to a library like Glimmer. Glimmer is just providing a way of writing client side code uh in instead of JavaScript, and it would be interesting to combine solutions. So eventually I do want to spend a bit of time to looking into how to better integrate with Turbo, So I definitely find that interesting as
well. For sure about the future. Yeah, we had Carson Gross on JavaScript Jabber last year, so if you're looking for more info on HTMX, yeah, we talked to them at length about how it works so awesome. Yeah. Yeah, I've been looking at it a bit recently because it is definitely orthogonal and it could be combined with Glimmer, except instead of adding the HTML attributes in real HTML, we can just add them in Ruby instead using the Glimmer DSL. So, because the Glimmer DSL is simply HTML CSS,
there's nothing, there's nothing more to it. It's just the standard HTML CSS, but you're using it from a better language that allows you to be able to write logic and structure in one language instead of having to, you know, use ERB and Ruby or JSX and JavaScript. We don't have that separation anymore. It's not needed, so we can be a lot more productive.
That's cool. I'll have to check that out. Yeah, so I mean that that is one interesting thing on the web that I I'm looking into, is, you know, more improvements to Glimmer DSL for Web, like being able to write components that run on both back and the front end. As far as desktop development, recently, I added a library for rendering charts and graphs and currently supports a line graph and a bar chart. And it's been asked of me by somebody who's building a real application that has bars, sorry,
that has graphs and charts using Glimmer DSL for Libyui. So I've actually helped that person build that application. Once it's completely finished, it'll probably get announced on my blog. But as part of that project, we extracted another library called Glimmer Libui graphs and charts and nice supports two graphs right now, and I'm working on adding a bubble chart soon. The good news about this is it will open the floodgase for people doing more data science and Ruby,
including graphic and charting as opposed to having by fun. So that's stuff for something exciting as well. And another thing I'm working on is improving the support for a few components and Glimmer desktop libraries so that they support slots just like they do on the web. So I'm for working on that as well.
That's awesome, and I, like I said before, I mean, I love the fact that we're getting into a place where oh I need this other kind of app, where I need to target this other kind of platform, and hey, look we've got great options for you know, for doing this. So yeah, yeah, that's super cool. You you mentioned Montreal RB. Are you seeing what are you seeing in the meetup space. So we
got the last two talks where AI talks. Like I mentioned already before that, we had to talk about how to do payments and Ruby on Ruby on rails, any payment solutions like Stripe or other payment gageways like repay or Zoom rails or there are many many payment gateways out there. So it's just a general talk that gave also information about like the business of payment and not just
the development software development of payment. Before that, I had a talk on Rail's few components, and before that I had a talk on Microsoft Coyota, which allows you to be able to build, sorry not build, generate any
Ruby SDKs for rest APIs automatically. So that way, if somebody using the open API spec, so you know, for example, I get the open API spec for uh, let's just say integrating with Azure storage services, I can Let's just suppose their their library is going out of dates or they haven't updated in a while. What I could do is actually I could just use Karyota and it would generate and SDK automatically from their open API spec. I
don't even have to use the library anymore. And the good thing about it is. It can allow us to then add things like repeating like sorry, like things related related to software reliability like repeating calls, recovering from exceptions, reach wise, et cetera. So it's a it's a it's a very interesting library that actually GitHub officially adopted recently in an announcement as the new way of them building SDKs for their APIs. So they're not going to be maintaining their
own custom ap SDKs anymore. From what I read in the announcement, They're going to be using Microsoft Coyota. So that's another interesting technology that got covered at Montreal ARB recently. Very cool. That sounds really handy. So they just generate the swagger dots and they're off to the races. Yep. Yeah. Pretty much before that, we had a Montreal RB talk about how to build command line tools in Ruby that was interesting, and somebody also gave a
talk on optimizing mathematical algorithms in Ruby that was interesting as well. Very cool. Are there places where people can find these talks or are they? Yeah? There? So, I mean, we we announce our talks on meetup dot com. We just have a meetup group, So if you search for Montreal dot RB on meetup dot com you'll find us. And actually there's also a YouTube channel. It's called at Montreal dash RB. If you go to that channel at Montreal dash ar, it'll give you the all the talks recorded.
So we try to record every single talk unless the speaker doesn't want want to. So we have more than ten talks on that channel. Awesome. We re rebooted the group after the COVID lockdowns about two years ago and that that and then that was when we started posting talks in one channel on YouTube. So yeah, we have about we have over ten videos on it. Nice. Yeah, that's we've been trying to revive the one here in Salt
Lake and it just it's been kind of a thing. So yeah, So we definitely had to start small and keep doing it for a while, even if people were coming as much, Like at first, not many people are coming obviously, some people were afraid of COVID still and didn't want to go out as much. We didn't care. We just kept hosting it over and over and over and then it kept growing and growing, and like it's so right now it's a lot like we're filling the room every time. Almost in
the last three times, so it definitely helped you just be persistent. Yeah, I think that's what it's going to take. There was some idea around not holding it at a company's space, but that eliminates like ninety percent of the spaces that are really available to us, And so I think some of the co working spaces might be willing to let us use like their you know,
their presentation area or their conference room every once in a while. But if we don't have any people who are trying to help organize it that are members that the co working space, it gets a little complicated too. So I'm really thinking I might just reach out to some of the companies here in Utah and just say, hey, do you have a space where we can hold the meet up and do you have an employee that will let us in,
and are you willing to buy pizza or whatever. I wonder if some bars can also allow you to the talk, like the bars that have a stage for a band. I wonder if, like if you could project a screen there instead. But yeah, we definitely so for us, we have we've been hosting the talks between two companies, one of them is my company, Lexop and other companies called Potlock. Both of them are based in Montreal and their technology companies that use to Ruby on mails development. So we've been
splitting the hosting locations between two companies and that definitely works for us. Yeah, so the way that our geography is set up, they're kind of three ish more or less business hubs. There's a lot of stuff that happens in Utah County, which is where I live. I live just on the north end almost in Salt Lake County, and most of the business hub around here is right near me, right, So it's almost in salt Lake County, and there are a couple of rather like arch companies that have offices there,
and so we could definitely get away with it. There are some that are kind of in the South Valley in salt Lake County, and then they are a bunch downtown Salt Lake, and then they're a handful in Davis County, which is north of Salt Lake, you know, all along the I fifteen corridor. And so that could be interesting, right, just finding those spaces
where hey, can we post a meet up at your office? And some of them like plural sites office is up in Davis County and they might be willing to host us even though they don't use Ruby on rails, they do have some Ruby content in their subscription and might be willing to host us just out of the kindness of Hey, if people like us, they might sign up for a subscription. So I don't know, but yeah, I think
it'd be worth reaching out and trying to pull something like that together. And like I said, also, there are a few of these companies that I know people at that I could just say, hey, can you, you know, ask around the office and see if they'll let you do it. So anyway, we kind of got a little off topic there, but it's all good. I think the meetup scene is kind of coming back. We're definitely seeing more conferences. Are there other things that you're seeing up and coming
in the Ruby community that you wanted to go over? I'm not sure, I mean, but I definitely feel like Ruby is still a highly effective language. And yeah, I do notice something actually more recently, I noticed that a lot of people that have left Ruby for other overhype technologies are returning to
it now. That's what's interesting. Like twenty twenty four or even the end of twenty twenty three, a lot of people that have left Ruby for Ilixur or Rost for whatever other languages are all of the sudden returning and being like Ruby on rails is way simpler than anything else noticed that recently, and I agree with it. So are there reasons that you're seeing for that or like anything in particular? I mean, the only reason I can think of is
waking up of the hype the hype spell. I personally, I'm a very very like I try to be very realistic and practical about how I think about software. I think about software from a software engineering like pros and cons point of view. I never think of it from the point of view of, oh, this is cool, this is fun, this is something used at a large company x y Z like Facebook. I never think that way. I always think, you know, you know the pros, what are the
cons? Is it making out life better or worse? Development more cheaper or
more expensive, more productive, et cetera. So I tend to guard myself against falling for hype spells to begin with, like I try to, you know when Like so, I think some people might have made the mistake of falling for hype a bit and then they woke up from it, and then they realized, like, because I've heard of people that used Elixir for a while or some other technology it might have been JavaScript, and then they came back to Rails and then they're like, wow, Rails is amazing, like
it it feels so productive by comparison, it's so lightweight. So I think it's just people rediscovering that. Yeah, I think there's something to that. I think also down to some of the points you're making about some of the stronger points of Ruby or Rails and then people, yeah, recognizing that the
other technology is not giving them what they want. So I know a lot of people that yeah, they went over to Alixer or to React for different reasons, right, and some of the promise was there, right, which is why they moved over because they fiddled with it, and yeah, it kind of delivered what it said it did. But as those technologies of mature,
Yeah, they come to realize that a Ruby's becoming more performant. It's you know, Rails is delivering on more and more of the promise and you know, coming back to I feel like Rails is coming back to its roots, which is funny because DH has always been the guy driving it. But coming back to its roots of hey, look, we're going to give you something that just you can build something just awesome, which is kind of the
focus of Rails Composer, which is a project I'm working on. But yeah, you boil it down to those things, and then yeah, people start realizing, hey, this is what I want to make what technology, you know, and yeah, Elixer adds this level of complexity or you know, it's not as nice as Rails has been to do some of this stuff or
things like that. Yeah, I have been following that same exact vision with Glimmer libraries, like I try to give people a way to build the Dusktop up in ten minutes if they need to, right, like a very simple MVP in ten minutes at least most sorry, and then maybe they can even finish the full app in like an hour or a few hours. And I've definitely been trying to emulate what the HH has done in Rails, Right. I think that's a big selling point for sure for Ruby. I do agree
about that, yep. Yeah, I mean it's the same idea behind Rails Composer, where it's there are a whole bunch of things you're going to need for your app, user management, permissions management, payment management, you know, stuff like that, and so hey, pull our pieces in and then work on the thing that you actually care about, which is my customers need something that helps them do whatever it is that your app does, right, so you know, yeah, you get all the boilerplate, all the main
stuff out of the way. And for me, the SaaS has a certain level of boilerplate to it, so you get that all out of the way,
so you can live in your zone of genius. And what I find is that, yeah, a lot of these technologies, especially React, in my opinion, they they've added so many things to it and pushed it in a direction to where you have to be a master of many things in order to get what you want out of it, Whereas in Rails, if you want to boil it down to just the basic NBC framework, you can get
away with that and build a simple app really fast. Yeah, I mean you can still as caffold the full app in one command, which is awesome. Yep, more or less. So yeah, all right, Well we're almost to our forty five minutes. If people want to connect with you or find out more about Glimmer or any of the other things, we've talked about where do they find you online? They probably find me on GitHub Andy Octiva is my handle, or they could find me on my blog, which is
Andy Maale dot blogspot dot com. And I'll make sure to send you the links so that you can include them somewhere that people can clear if they want. Yeah, well, we'll have show notes for the interviews, so yeah, definitely. And yeah, I mentioned a few of the other people that we've interviewed. I think I'm gonna reach out to Andrea, even though I already talked to Alex and see if we can get him on for an interview
as well. And then, yeah, thanks, thanks for joining us, folks, and until next time, Max out