Hey, welcome to Ruby Rogues. This week on our panel we have Valentino Stoll.

 

Hey now.

 

I'm Charles Maxwood from Top End Devs and this week we have a special guest, it's Elia Schito. Elia,

 

Oh,

 

do

 

thank

 

you want

 

you

 

to

 

for the

 

remind

 

pronunciation.

 

people who you are? Yeah. Well, I lived

 

Yeah,

 

in Italy

 

I'm

 

for

 

kind

 

two

 

of

 

years,

 

low.

 

so I have practice.

 

Really good. And well, I'm kind of know for having maintained Opal, I guess it's almost eight years now. And Opal is this Ruby to JavaScript compiler. And well, it's targeted toward browser development and it's really different from the recent Ruby Wasm, I guess maybe we'll have a chance to speak about that. And it's super efficient, and super fun to use.

 

Cool. Yeah, we've had you on to talk about Opal before. So rather than kind of go into the fundamentals of what Opal is, again, we're going to refer people back to that. But can you just give people kind of the two minute explanation of what it is and what it does? And then I'd like to get into, hey, what's changed since the last time we had you on?

 

Sure. So basically, Opal is a source to source compiler. So it doesn't try to have a virtual machine or anything. For example, a string in Ruby translated to JavaScript will be a string in JavaScript. That's the basics. The same goes for arrays. Methods will be mapped to functions. Same class, in JavaScript classes. So it's really efficient in its compilation. super tiny runtime and we also ship all the code library so you get like the feeling of being fully inside Ruby. The main difference I should mention is that strings are non-mutable in Opal. That's a big difference if you're using through three strings and do less things like that. So I guess it's less of a problem.

 

Yeah,

 

Um...

 

I've seen some stuff in just regular Ruby where a lot of people are opting to freeze their strings. There's also the comment directive you can put at the top of your files that is frozen string literal, something I can't remember that

 

Yeah,

 

does

 

nowadays

 

some stuff with that.

 

all the people using Rubybog for example would be like

 

Yeah.

 

pushed to use that by default. So it's

 

Mm-hmm.

 

less and less. Actually a few maybe years ago it seemed like Ruby was moving toward frozen strings by default and that got backtracked at some point by MATS, I guess

 

Mm-hmm.

 

for implement that. Just wait until Ruby comes to the same position.

 

right?

 

Anyways, it's only an issue whenever you try to port an existing gem and

 

Mm-hmm.

 

make it work in Opal. That's usually the one thing you need to to change your patch. code it's barely any sense you don't notice yeah that's Speaking of porting gems, one new addition we had fairly recently is that we released the Opera Spec 1.0. and

 

Is

 

that's

 

that different

 

basically...

 

from our spec?

 

yeah the big difference is that it runs in the browser or on Node if you want. So

 

Ah,

 

you can

 

okay.

 

run it. You can run specs, you write Ruby, and you access whatever the DOM, or like any JavaScript library, and but the environment in which you move is the usual RSpec environment, and I think we run almost all the original specs from RSpec. So RSpec has its own specs, and we are able to pass most of them. As I mentioned, in many cases, the problem is just, like one spec is using multiple strings and expect that to change, but apart from this stuff, we are more or less on par in features. And let me add, we even have more features because another recent addition is support for async await from the JavaScript world.

 

Mm-hmm.

 

would be familiar, but that's like syntax sugar around promises in JavaScript. That's really cool because in JavaScript you can block the code for waiting for something else and you just need to use callbacks or promises. But with the sync await you get the same like effect of blocking, waiting for a return more linear. That's really good and we didn't have initially support for this, but now we have support. You can just switch on a flag like the frozen string magic comment at the top of the file and you'll be able to call double underscore await double underscore. That's sort of primitive or magically awaiting stuff in JavaScript. So the interoperability is very easy. Like you can, you'll be able to test, I don't know, jQuery or React with

 

Mm-hmm.

 

RSpec.

 

So

 

So I was

 

good.

 

gonna say how does that work is is

 

Hahaha

 

the is the interpreter waiting on the request son in those cases for async

 

So the interpreter is the JavaScript interpreter. We don't inject any interpreter in between. We just have a runtime support library, which is exactly for support. It's helpers, it's setting up basic objects and stuff like that. For sync await, we basically just translate to await in the sync in the JavaScript code the JavaScript engine we're using. So most of the time for development, for example, I use Node, which is faster from the terminal. But for application, you'll use a browser. And that's it. It will translate. And the work it does is to translate to async, await, and propagate the async to all the containing functions. That's basically what you need to do. for a simple way to work. And that's it, more or less. So.

 

So I'm relatively new to Opal. I imagine many people are that haven't played with the kind of trans compiler kind of thing with Ruby. Where's a good place to get start for most people? What do you recommend people start looking at?

 

So just to sort of mess around with things, the easiest, super easy way is to go to the Opal website, which is opalrb.com slash try. And that is an in-browser compiler. So you can write some Ruby code, see the results on the right side and the compile code below. That's the fastest way to try it around. But if you want to dig a little deeper, you can just install the gem. It's super easy to get started with that. You gem install Opal, and then we have an Opal command, which is, it tries to be as much as possible, one-to-one with the Ruby command. So dash uppercase I will be the include command. path, you append a file name, it will try to compile to run that file name. If you want to compile, you can add the minus C, like for compilation, and you can dash dash help and get a list of flags you can use for different things. Just today, I guess the episode will come out after we release the full version, released the release candidate one for 1.7 which includes a minus minus watch flag so you can even like start a watching process and have a bunch of files and get the thing compiled.

 

Oh that's awesome, so you can see kind of real

 

Hmm

 

time how you're working. That's great.

 

Yeah, but

 

っ

 

on the common line, there's also this... There's also this concept of a runner, in which you can select which runner you want to use. And that could be node or the browser. And if you select Chrome, it will start a server and you open the address. Oh, sorry, you can use a server runner for that. It will start the server. You can open the browser and see things live. And that will already change as you change the files, like you refresh and get the updated code. you

 

So you're, usually when I see the Double Dash watch on JavaScript or front end resources, it's basically when you change something, recompile, right? And so are you imagining this could be used in like Rails or something where I effectively have it recompiling as I go, like you said, and then refreshing the page?

 

Yeah, yeah, about the race, we had this Opel Race gem, which is kind of old fashioned with sprocket

 

Mm-hmm.

 

support and everything from the old guard, I would say.

 

I

 

And

 

like sprockets, so.

 

me too, I spent countless hours reading the source, maybe too many, but yeah, anyway, if you install race nowadays, it's a bit different. So just a few weeks ago, started working on JS bundling. And

 

Mm.

 

part of the reason we were releasing the dash watch option is to better support a JS bundling option. I hope it will be managed like a local API. The project is straight. It's pretty simple. Like it's a few

 

great.

 

lines. The only big difference with everything else in there is that would be the only integration but I don't see that as a big problem. especially relying

 

The end.

 

on one watch command and one beat command. That's it.

 

That makes sense. I'm just going to drop in here. I think we talked a little bit about this when we had DHH on a while back about some of the asset pipeline stuff. We went from sprockets to Webpacker and now we've got the JS bundling rails, which is the ES build-based and roll-up-based stuff. It just works a little bit different. It's interesting that you can pull it in that way without using sprockets and stuff.

 

With that I find super interesting how that probably came from Miedlmann. I'm not sure about the origin, but Miedlmann

 

Uh-huh.

 

used to have the external asset compilation with more or less the same concept. And

 

right.

 

yeah, I guess that's the easiest way to integrate anything.

 

Yeah, one other thing that I'm assuming some people are going to be wondering about is does this mean that I can write my front-end code in Ruby?

 

Yeah, that means exactly that. And actually, I used to have production applications with even millions of visits per day and running on... Like, we developed a sort of internal framework for front-end code. It was

 

Mm-hmm.

 

somewhat similar to what Stimulus ended up being, Less refined, I admit, still is really streamlined. We just had, I guess you're familiar with that, we just had the selectors, the CSS selectors

 

Uh-huh.

 

for targeting elements that was inside the Ruby code instead of having hooks in the HTML and like a more pure code for the controller. basically the same. And the other thing that's really interesting is that if you have some herbifies, you can actually compile them in the browser. So you can share some views, you can share models that are not attached to the database, for example, if you have frequent, like there are just a few things you share, some logic you implemented in Ruby, but like to me the pleasure of writing Ruby, like the clearness of the syntax, the ability to reuse all my object-oriented skills I acquired over the years, I hope I acquired them, was the greatest thing. really pleasurable.

 

Very cool. Now one other thing you mentioned is Ruby Wasm. So yeah, so what's the difference there? I mean, I get that you said, I think this translates from Ruby to JavaScript and the other probably compiles to the Wasm bytecode, whatever it is. I don't know exactly how to describe it, but is that the only difference? And does it work kind of the same otherwise, or are there more meaningful differences than that?

 

Yeah, I think that two projects are thought for different purposes. My understanding, and I could be wrong, but my understanding is that the Ruby Wasp support is more for Lambda style situations, like in which you will have some environment in which you can only run JavaScript or that's the only supported options, stuff like that. And that allows you to run actual Ruby code. through that. Doesn't seem to be a viable option for a production website, unless your, I guess, unless your only objective is to allow people to compile Ruby and try out like some inline examples. I can see an option for that in a learning site or something like that. But otherwise for your application, JavaScript application code, good option. Like it's several megabytes of code and it's also it's not too fast. Yeah and like if anyone wants to have like the feeling of the difference, Opal is officially featured at the try.rubylang.org page. you'll get an option to play around with both Opal and Ruby Wasm. And Opal is the default because it's faster. Even if in that page it loads the parser and the compiler, which is not necessary to have in any production application.

 

Yeah, you know, I was just going to ask you about the TriRuby. How did that all come together? I'm super interested. Because I remember seeing the announcement for the WebAssembly version of TriRuby coming out. I didn't know that they also supported an OBL backend. How did you get involved in that?

 

So I wasn't involved personally, but I think one of the main contributors that is doing the bulk of the work lately, let me say this before anything else, I'm sort of the maintainer, but my role nowadays is mostly to reviewing, and merging, and releasing these kind of things. Like I will be the historical memory and stuff. I should give credit to HMDNA. Anyway, it's a bunch of letters, but you can like, you'll see his handle all over the place in the repository. He's doing a tremendous work. And I think at some point, the tri-ruby was sort of broken or maybe the playground was broken and he fixed it using Opal and it was working fine. been in Opel for several versions and surely before the Ruby Wasm thing was released. So Opel was there before and then they added the option to use the one you prefer which is like nice the more the better.

 

So what is that transition like coming off of a big project like this to the more backburner review? Do you miss being involved in the maintenance and kind of feature work or are you happy to let somebody take

 

Thanks for watching!

 

over?

 

Yeah, I'm super happy to have someone take over and help. And my role is more like removing blockers as much as possible. And it kind of has been for a while in the sense that we had several contributors. I'm sorry. I guess you can cut this.

 

Yeah,

 

Some Alexa status

 

we definitely

 

or something.

 

can.

 

Thanks for watching! So I'll go back to the question.

 

Yeah, I mean, how how do you like first, how do you find somebody to to take over a project that you're maybe I don't know if you were overwhelmed with it or not, but maybe you want to take a step back from it. Like, how does that whole process work? I'm super curious. And like, are you happy with that decision to write?

 

Yeah, I'm super happy to welcome new contributors. And this is a kind of project that sort of gets involved people with this kind of love for puzzles, because you get like the Ruby spec, which is like a fully ready spec suite and you can just implement stuff one thing, one more feature. So it's a big puzzle. And if you have that kind of mindset, it's super interesting. I was personally more involved in writing code, but over time, the family grew and I just had the last kid last August. So it's,

 

Congratulations.

 

thank you. I find it harder and harder to spend like the nights doing that. And at some point I was staying in the kids' room, keeping them quiet for getting to sleep. The moment they shut up, they fall asleep. So I was using that time for doing open source, but time goes by. Anyway, over time we had several great contributors with the project and I'm happy with that. Like I don't even need to know the name or whatever. I'm happy to provide this like mutual relationship in which they are loved, they have the chance to have the project in the way they want. And everyone gets something that has more features, more back fixes and so on. Yeah, one of our alumni is Ilya Bilić, who's now maintaining the parser gem. And I think his transition in this case went through Opal because Opal uses the parser gem to parse Ruby code, which is the same gem that's being used by a RuboCop, for example. And so he started fixing bugs and maintaining that side and eventually he became the main maintainer there. So I'm super happy about that. It's all good.

 

I'm curious about the use of the parser gem. Are there talks about switching to the new syntax tree work that Kevin Newton is working on?

 

I'm not sure I know which is, but if it's the one I think about, I tried out the formatter, could be that they have a format. Okay, that's really good. No, for now we didn't talk about that, but we have sort of other priorities. tool version which are really strong support for ES modules and complete that part of the work. The Parcel Jam is working pretty nice for us so we don't have many grievances with that and lately we also implemented, and when I say we, I mean HMD and A also implemented So now the compilation is super fast. It's barely milliseconds. And that's also caching, so the combination of the two makes it like a brainer. After the first pass, it's

 

you

 

really nothing.

 

That's awesome.

 

So I'm also wondering, because it sounds like you're implementing Ruby spec and you're mostly finding compatibility issues between, I guess, the standard Ruby and Opal. Are there things that Opal can't do that a lot of Rubyists may want to do?

 

Well, I already mentioned multiple strings. That's a big one, I think. Otherwise, lately we... Was also implemented, for example, binding.IRB, which I didn't thought it was

 

Huh.

 

possible. And, yeah, and we support refinements, which I don't know anyone that uses them. So we added even like... exotic features like that.

 

Mmm.

 

That is of course full support for inclusion, prepending, singleton classes, all that jazz. Like Ruby, today we merged the PR for the support of Ruby 3.2, which I think we'll release around Christmas as well. And yeah, with that, we added a few callbacks for constant definitions, like it was a few things. And of course the Ruby spec is very, really helpful in tracking what we're missing and what we're not missing. But anyone can go to the Opal repo and under the spec, there's a file named Ruby specs and another folder called filters, Former is the list of folders from Ruby spec we run, and the latter is a list of things we're not passing. So if you want to contribute and deepen your knowledge of both Ruby and JavaScript, which is like the likely effect, you can go there, pick any failing you want, and try to make it pass. That's super easy, like super easy to get started, not always easy to do the implementation, BTS.

 

That's awesome, I may try that out. Ha ha ha. It's always great to find a project that has something easy to contribute to, you know.

 

Yeah, yeah,

 

Whoop.

 

you clone the project, being set up and being ready to

 

Where

 

go.

 

were you during Oktoberfest? Or Oktoberfest?

 

Yeah.

 

Oh yeah, I think we missed that one this year. Like I was quite busy. Yeah.

 

So I'm curious, because I mean, a huge pain point of Rails in general is like all its front end portions which are trying to get ironed out, right? Opal seems like a pretty great candidate for using Ruby. Where do you see like kind of the most hesitation for people kind of adopting it?

 

Yeah, that's a great question, which I ask myself many times over the years. Because to me, like since I guess 2011, when I started getting involved with the project, it was a no brainer. And it makes sense. I got involved. That was my take on it. Over time, like I couldn't understand this. And my answer so far. sure, but is that people sort of fall into the trap of using the right tool for the job, quote-unquote right tool, the one true way of doing things. And I kind of miss that time early in Ruby and Rails in which like everything was possible. Like if you think about that, It's quite crazy. Like we came out with dot should equally. It was crazy

 

Mm-hmm.

 

or the Cucumber stuff like it's

 

Yeah.

 

like and okay aspect got more success the other one like it's less of a less used nowadays, but I think it's healthy to be more like free and in thinking about things we can do with Ruby. The other part of that is that many, many Ruby developers are actually Rails developers. And if you're a Rails developer, it's likely that you focus on the database, ActiveRack or backend stuff, stuff and the front end is kind of like something you sometimes have to do, like you hate CSS for those two days in which you have to implement something and then run away back to optimizing some query or I don't know. So that effect I think is pretty strong in the Ruby community. Like it started like oh, it's not actually Ruby doesn't have method missing then we implement method missing So now is it Ruby? Oh, yeah, but There's this other thing and this other thing it wasn't theory,

 

hahahaha

 

yeah That wasn't the actual

 

It doesn't

 

issue

 

have this tiny little feature that no one uses in, that's in the Ruby spec.

 

Yeah, but that was

 

So it's not

 

clearly

 

real Ruby.

 

an excuse. Yeah, it's not real rule. Yeah. Yeah. Like, and, uh,

 

For me, it's real Ruby if I can write the code that I'm writing and not have to think about that it's Opal.

 

Yeah, the big shift in mindset shift is this, you need to think that as you have to know about SQL and databases when you write

 

Uh-huh.

 

Active Record, you probably need to know the domain of the frontend when you write frontend code. So some basic knowledge about the browser, the DOM, the event system, that kind of stuff, you cannot avoid knowing about that. So that's part of it. And it's really a foreign environment if you never dig into it. Like I know personally many people that like just survived with Sanjay query and moved on. So that's also, I guess, daunting for people. And I can just like bring out my experience. fun. It's fun. It's refreshing. If you spend years on the backend, like it's a novel environment, and you can like, come up with new things and do things differently. At least I like it.

 

Yeah. One thing that kind of came to mind while we're talking through this is since it is sort of aimed at or lives in the browser. I get you can run it on Node and stuff too, but we had Amir Rajan on a while back. He did Dragon Ruby. We were talking about building video games and stuff like that. Could you do that level of stuff, that level of programming with Hopl?

 

Yeah, for video games at some point there were a few projects targeting video games with Opal in the browser. They were relying on libraries like 3JS and

 

Mm-hmm.

 

other libraries in that same area. I guess if you need really performant code, like a tight loop for some 3D video games, optimized JavaScript, not even regular JavaScript, but optimized one. Otherwise, I remember developing a few games with my kids. We had an elephant chasing, sorry, a lion chasing an elephant. Then we did Dragon against arrows, something like that. We did that together.

 

right.

 

It was fun. So it's definitely possible. could drive like a huge adoption like race like adoption

 

Right.

 

for sure but for fun it's definitely there.

 

So you're talking about kind of having to know the whole stack, digging into like Rails as an example. What do you think about the frontend component portion, like view component or flex or something like this? What do you

 

Did

 

think

 

you say

 

about

 

flex? Let's rewind our lives about 10 years.

 

PH LEX? It's the new view component alternative. You can use view component

 

Oh, I haven't

 

and

 

seen that.

 

it's pretty neat.

 

I thought

 

It's

 

you

 

basically

 

were talking

 

just...

 

about Flash.

 

It gives you a DSL for creating the containers themselves. for the view. But what's your take on that trajectory and architecture for conceptualizing and binding together the view and the front end and back end portions with some kind of middle stack? And how would you maybe differentiate that from how Opal sees it?

 

Yeah, just to be sure, flex is the one that is in the tradition of markup being, like you write blocks in Ruby to represent HTML nesting.

 

Yep. Yep.

 

Okay. Yeah, something like that could be run easily on both the server and the front end. So like, if anyone wants to build a library in which you dehydrate the stuff after you render from the server, the same things, it's definitely possible. And about the general question, I just came out of, in September I switched from client work within Nebulab, which is my employer, and working on open source on Solidus, like the last client I worked on, we had this stack with view component, and we had the folders for each component, and each folder had both the Ruby file for the component HTML and ERB, the JavaScript, the CSS translations, and even the spec. And I have to say that's a wonderful way to approach this kind of things, because for example, if you get rid of one piece of the UI, you can just delete that folder and you forget about that. access to the component, like for style components in the React world. That's really like a... complete simplification of the problem. So that's really tiny, except for a few times, like we barely had a time which one class had an effect on children and things like that. It was really a way to think about things and in an isolated way. So that I completely, I espouse that approach. tried it, it's super helpful. And in relation to Opal, we had over the years, several projects doing React-like things and also several projects attempting that same, attempting and doing that same approach in Ruby generating HTML and CSS. The one that's more like the, the latest survivor, like that's still maintained and so on, is called Pagio, which is an Italian word for translation. But anyway, and that supports both HTML and CSS, and it's the default implementation for our browser, which is a wrapper of and rubification of most of the browser API APIs. So if you want to treat and work with the browser in a rubbish way, you can surely use Opal browser and with that comes Pagio and you'll have more or less the same situation as Flex.

 

That's really cool. So how do you think about reactivity? Because the push seems to be the whole HTML over the wire to handle updates to the DOM. Are you in favor of that? Or do you prefer a more client-side approach?

 

No, I like that. And for the general case, that's a great solution. There are a few cases in which you want to have things happening in the DOM directly, and that things react to a click, a mouse movement, and that needs to happen instantly. And even the tiniest overhead over the wire is too much. So I can see like a hybrid solution. I used a lot of symbols in the project I mentioned. And for some things, we actually implemented the stuff in JavaScript. But figure a way in which you can just have the same template on the browser and you can re-render it with local data send the stuff out of the wire, like have the confirmation of what happened. Stuff like that is it's surely possible and easier if you use something like Opal and Sheraton plates. That's of course it's possible even without just a little bit less easy.

 

Yeah, anytime I get started with these new things, I always, you know, hit a hiccup with browser events and having to handle stuff like that. Or even just other browser API things like file or something like that. I always run into something. The downside of working on the edge. So you mentioned solidus. quite a lot and I know Solidus kind of like took over from some bad practices. I think they first advertised it as the more secure spree.

 

Yeah, they forked from spree, didn't they?

 

Yeah.

 

What's your takeaway from working with Solidus? Do you like it? What's, have you worked with Spree before? And maybe do you like some things over others? What are some pain points for you?

 

Yeah, well, I definitely work with Spree. five to seven years ago, something like that. And we actually had this big multi-tenant e-commerce site. And we started from Spree 2.4, which is the same place from which Sol2Sport, and we customized everything to get this multi-tenant support. And we ended up copying all of the code inside the application, like an event or thing, just to reduce the monkey bashing and have a clear vision of things. So the history of Solidus is yes, at some point the spree was really unstable and breaking changes all over the place with each release, even minor releases. And from there it started I think as a forko spree, like internal for StemBolt. I think that was the company that did it. And at some point they just released a new version saying, okay, we're not breaking stuff as much, we're respecting Samver. We are giving a better service to our clients. And given this is a premise, Solidus is doing a lot of work for improving Spree, which is the basic Spree, and is I think 10 to 12 years old, So the challenge there is to move forward without breaking things and have sensible migration paths. And I think over time we became really, really good in the, in to like taking and choosing how to migrate things, the deprecation cycle. So every release is really upgrade and that's one of the core values of the project. And of course, at the same time, we're moving forward with all the other things and new features and trying to sometimes trying to get away from legacy habits or implementations. So that's, yeah, that's the gist of it. a bunch of things that are coming along in these days with the new releases, which are really exciting. In some cases, those are completely changes in the mindset, like the way we approach things, and more in tune with the modern environment in which we live.

 

That's cool. Way back when I used to do spree quite a lot.

 

Hmm

 

That's kind of what I started my Rails career in. I know the pain points there. I was glad to see somebody come in and kind of help take over a lot of the problems that were created. It's a huge code base and there are a lot of people working on it. It's just nice to see that there's still an open source ecommerce system that you can take on and plug in and go basically.

 

Yeah, yeah,

 

Yep.

 

and it's better and better. We're recently working exactly on the out-of-the-box experience so you can start the project, something that you would be willing to put in production because before that, like, the default UI wasn't that great, or maybe it was great a few years ago. So we're working on that things like headless e-commerce are kind of the new things for many e-commerce and migrations from other systems the kind of things subscriptions those are some of the themes we are we we have covered or are covering

 

Yeah. Yeah. I just want to echo what Valentino was saying. Cause yeah, I picked up some contracts a few years ago on, on spree. And this was before anyone was even thinking about solidus, but yeah. Um, some things were not so bad cause you weren't really diving too deep into the code and sometimes you were, you were neck deep and it was kind of a mess. So

 

Yeah, e-commerce is a hard problem. Like you can simplify it probably to a point. And like you can surely simplify for a simple case. Like if you have just one product, you can have shortcuts and stuff. But if you want something that's scalable and that can live with you for a longer time, that complexity at some point. I'm not saying like that every OOP design in there is perfect and can be improved or it's like for sure not, but yeah, the complexity is there. So it's more a matter of putting everything in the right place and allowing people to modify. the biggest feature of Solidus is the way in which you can morph the behavior of the project to your need. So that's like if you want a cookie cut solution, there are plenty and you probably don't need to open, track open any code or anything, just click somewhere and go with it. Buy a theme, I don't know. If you have like anything different which in some cases is the whole point of your business, then maybe that's a great solution which you can really tune it to your needs.

 

Yeah, you know, e-commerce is like that classic feature trap of, you know, you start off, oh, I just want to sell this thing. And then

 

Mm-hmm.

 

you're like, well, I really have like 50 variations of this thing. And I want to track all those things. And then it's like, well, now I need inventory. Well, shipping now I want to ship to different places other than my neighborhood.

 

Mm-hmm.

 

There's extra fees, new carriers. I get just like the features just start piling up out of nowhere. And you end up like with this thing like a simple let me sell this product and now it's like well I have really like 50 different services I'm offering that

 

Right.

 

I want to combine and mediate

 

Mm-hmm.

 

Yeah,

 

it's

 

and marketing.

 

Yeah.

 

like right

 

I've been putting together top end devs and all of the stuff's digital, right? So I don't have the logistics part of it where I'm shipping a thing, physical thing, you know, through the universe. But I mean, even just selling digital products, you deal with a lot of that. It's like, oh, I want a membership that provides it, but I also want to just allow people to buy it one off if they don't want to be part of a membership. And then I've got a couple of different membership levels and these ones I thought,

 

and legacy users.

 

oh, I'm just going to let him sign in and get the thing. And it's just not that simple.

 

No, it's not. Yeah, and then promotions.

 

Yeah,

 

Like

 

yeah,

 

changes

 

promotions.

 

in price over time.

 

Yeah, oh, what if somebody has this happen through Stripe? I'm not handling that webhook yet.

 

Yeah, and taxes. We can go on and on.

 

Uh...

 

I mean,

 

Yup.

 

that's like

 

Yeah, I

 

as

 

mean

 

deep as that.

 

it's so funny, right?

 

Yeah, I want I want my membership to cover this third party service now.

 

Right? Everybody wants a service or this thing that's open source that you can just use if you wanna sell something. And really it's like, no, we want to pick the things that we want out of this whole pipeline of selling something and then chip that, right? And so I was glad to see something else come out that wasn't just like a massive rails that you can kind of select and pick what you needed to. Which I know you could do with spree, but if you didn't fit the mold, it was hard to bend it, as we've been saying. So I'm curious to see how Solidus will survive, really. If it falls into the same traps, right, like as time goes on.

 

Yeah, in some way we are moving away from having a mold of any sort. For example, the front end used to be this huge collection of views, which will be injected in the inheritance chain of your application, so you could overwrite only the views that you want to change. That's never the case. Every e-commerce wants a custom theme. at least wants a custom theme and they want to really customize and their brand shown. So you ended up overriding everything so we trashed that and we now like just write a starter set of views to your application you can just modify that and we focus more on building to enable things and I think in the future we'll move more and more toward that. Like for example we were talking about promotions. Promotions are really powerful in solitudes and they were also in spree. Sometimes they are too powerful. Like you want to start out with something simpler, like you just want to have a sale of something and you don't want all that great candidate for having multiple switchable implementation or options and we already have that for other parts of the system which can swap classes and have your own implementation or something. So that's more or less the direction we're taking and like it's a it's real luck that we with Solus so we can gather the best feedback and have different stages in the scalability and the history of a company or startup and try to grasp the actual pattern rather than coming up with something we thought in an ivory tower as not based in actual problems.

 

Do you find yourself wanting to create a solidus opal wrapper? And just writing all of your solidus code in opal?

 

Yeah, like to be honest, I miss the days in which I was spending much more time on the front end writing Ruby. which at this point, you know, it's a thing. And that was really, really enjoyable. And like coming up with your own framework, which was like really simple. I guess it was under a hundred lines or under 200 lines, I don't know, really tiny. But yeah, it was fun to, to find solutions and like this novel environment. I miss that a little bit. creating an alternative front-end with Opal, like hit two bolts with one stone. So far, I wasn't able to. So I'm trying to lower my aims and just, for example, try to get out the JS bundling integration. And that could be the start of it. younger with plenty of time will take up the challenge and but yeah, maybe over time we'll have more time and like kids will stay like four months old only for a set amount of time, I guess

 

Yep, well, yeah. And that's part of the thing too, is yeah, you just go through these periods of life and... Yeah. I'm going to go ahead and push this into PIX. We're kind of getting to that point in the show. Well not to PIX, we're going to do the self-promotion portion first. But before we do that, Alia, if people want to connect with you or see what you're working on these days, what's the best place to do that?

 

Yeah, the best place is actually GitHub. You can follow me on GitHub. The handle is actually Elia, E-L-I-A. My name, I also kind of, I'm kind of present on Twitter. It's not technical stuff. I use it as like for personal opinions that, so be warned. is a place and I would be happy to meet anyone on the project. And like if you have anything you want to help, even bearing, I'm all for it. I can set up and reserve time for that, setting up the project and so on.

 

Cool. All right, well let's do this self-promotion. Valentino, what are you working on?

 

So I just wrote this article on some source files I found in Ruby. There's a special samples directory in the Ruby source code. And I basically just have been going through one by one, seeing what they are and how they run and what they do. And it's really, it was really fun, really interesting stuff in there. And I had to break it apart because I wrote too long of an article for our blog to handle. This is part one of three, and I'm looking forward to more. It's called Ruby Delights Built Into the Language. So I recommend checking out kind of the wild things in there. One of my favorite is definitely, there's this bio rhythm calculator where

 

Mm-hmm.

 

you just put in your birth date and it says, oh, how's your physical, emotional, mental health? And they have like a bad condition, good condition range. then we'll give you your week at a glance. It's kind of fun.

 

Oh, interesting.

 

So there's a bunch of different things in there. I would definitely check it out.

 

Very cool. I'm going to drop in a few things. One is we still we're still doing the book club clean art clean architecture. Uncle Bob has been showing up to those. So it's been fun to talk to him about what makes good software architecture. And yeah we've been recording them too. So if you sign up for the book club and you're worried about having missed some of the conversations you can join the book club pick up the book. Right. Join the next call and just have read the chapters that we're reading and then go get caught up. I've also been pulling a few people in on the membership and coaching. So the membership includes a couple of What do we call them? Just mastermind calls, I guess, where people get on. We usually have some experts show up kind of like this, and it's kind of somewhere between them explaining to us how a thing works and us asking questions, right? So it's very open discussion forum. A few more people on it than are usually on the podcast, but it's an hour long and we, yeah. So I'm looking to have some of my friends who are experts in productivity right? And then maybe some of the more career-focused stuff like how to network with people or how to communicate better, how to use Slack, GitHub, Visual Studio Code, stuff like that. And then we're going to be putting up next month. And I kept going back and forth. I've decided to do these for free, but we're going to have meetups for each of the language areas we cover. So there will be a Ruby meetup next month. I don't know who the guest is going to be. It's probably going to like 50% presentation and like 50% Q&A. And then what we're gonna do is we're gonna go over to an area that I've set up. It's a virtual like room office where you can go and you can walk up to a group and be part of the conversation or sit down at the table with somebody who's there that says they're hiring and have a conversation and just kind of free form, have conversations like you would after a meetup. And so, looking forward to all that. And that'll be under the topendevs.com slash meetups. I don't have the signup pages yet. The signup is essentially you give us your email so we can let you know where the next one is. And yeah, they may be sponsored, so we might, you know, plug somebody for two minutes at the beginning of the call, but I'm not going to make that very heavy-handed at all. I really want it to be a social thing. But yeah, that's pretty much it. And then yeah, I started my first coaching group. So if you're looking for kind of directed career coaching, where you have somebody that's holding you accountable and answering your questions and introducing you to people you need to know, then you can go sign up for that at topendevs.com slash coaching. All right, Alia, anything else you're working on you wanna let us know about?

 

Yeah, I was thinking about this and I want to plug one gem I wrote some time ago, and that is for having helpers in the Raze console. And that's super optimized. You can use that in production. It doesn't load unless you load up the console. And whenever you have lots of models like nested namespaces and stuff like that, that's... I hate typing. That's probably not the right job for this, but I try to be lazy in that and that allows you to have shortcuts like for finding a model by slug or by stuff like that to make your life easier in the console for Raze. And the name is Raze Console Toolkit and yeah, I'll send a link for the notes.

 

Awesome. All right, let's do some picks. Valentino, you have some picks?

 

Sure, I've been following along on Twitter as Shopify has been releasing their early hints in their performance with all their work on Ruby 3.2 and the YJIT and all that. Really impressive numbers coming out. They're seeing kind of like a 10% performance boost across all of their services now that they have pretty much every storefront running the latest Ruby 3.2 with the YJIT enabled. really cool to see you know all of their efforts come out really really really fun. The next pick I got Sorry. Uh... is running Rails from Docker. There's a new Rails repo, Dockered, where they're gonna start supporting running Rails on Docker out of the box. So you'll then have a new command to run all of your Rails commands through and have it all in the container and kind of solve a lot of the deployment issues. Questions is now everything containerize and you could ship it wherever you want to. So really kind of cool to see that come out. I'm excited to play with that.

 

All right, I'm going to throw in my picks next. So the first one is going to be a card game. And the card game's name is The Game. Yeah, it's a terrible name. It's like when you're trying to get information on the Go programming language. So you go to Google and you type in Go and you get everything. So this is kind of the same deal. The Game is a card game. You can have like two, three or four stacks that you're working from. running up from one or down from 100 on each of the stacks. And what you're trying to do is you're trying to put out the entire deck. So if you're going up from one, you can go up. You can put any number that's higher than the number that's there. But if you make too large a jump, then you're making it harder to get rid of the numbers in between. And so you want to kind of keep them close. But sometimes the cards in your hand, you just don't have a choice. play. There's a rule that you can move it back down a number if you go up or down by 10 I think it was. So you can kind of erase some of those mistakes a little bit but it's a pretty well balanced game to where it's not super easy but it's not impossible to win either. And this is a game that I think my We might encourage her not to make certain mistakes, but she knows numbers, and so she knows this one's bigger than that one, so she can figure it out. Board Game Geek weights it at 1.25, so like I said, it's pretty simple. It was really fast, too. We played the game in like 20 minutes. If we agonized over our decisions, it was a half hour. So anyway, this is super fun, so I'm going to pick that. I am getting back into triathlon training. My goal was by the end of next year to have completed an Ironman. So I'm getting back into the training now so that I can do one in the fall. Because if I try and do one now, I just won't finish. But anyway, so the Ironman race I'm looking at is Ireland, Ireland, Maryland. That's in September, October. The training system that I'm using is called Tridot. And as you do your workouts, you get scores and then you do like a monthly fitness evaluation and they adjust your speeds and ranges and stuff, right? So for your bike, you know, it may tell you that you want to start going 10 miles an hour instead of, you know, nine miles an hour. When you're running, it'll set your, you know, an eight minute mile pace instead of a nine minute mile pace, right? As you get better. So I'm gonna pick that. I got a free trial and then they added me to their preseason preview and I got two months of free training. So I don't have to pay for it until sometime in February. And so I'm pretty happy about that too. But yeah, it's good stuff. I'm trying to figure out how to get it to sync the workouts over to my phone and my watch. I guess it does that. It just doesn't I've got to figure that out. But anyway, really digging it. And so I'm going to pick that as well. And then I'm excited to watch 1923, which is the new Yellowstone prequel with Harrison Ford in it. And so I'm hoping it's as good as 1883, which I actually like better than Yellowstone. So there you go. Alia, what are your picks?

 

I'm gonna pick a couple of blog posts from the Hey blog.

 

Mm-hmm.

 

One is a series from this 37signals employee named Jorge. And that's a series on how they develop and do object-oriented design inside 37signals and Basecamp. through some of the posts, read some others, it's great stuff. It's really great stuff. And I'm picking it also because I think for many people will be both refreshing and something new, which like it's a bit different from the prescription we get from like the current race environment and suggestion and tool set. it's good to have that vanilla race approach. And at least know it, even if you want to move toward with service object heavy structured situations. That's really the basis, picking good names and dividing code in the right way. The other one is a blog post from DHH on DEI, a bit of a controversy, I think, on social media, but that led me to a great podcast, which I'm digging really lately, which is called New Discourses. It's about philosophy. So if you're not interested about that, like you can skip it. But I find it really deep and informed. Actually useful for my everyday life and which is surprisingly connected.

 

Cool. I'll have to check all that stuff out. Thanks for coming, Alia. This was really fun and it was fun to kind of jump in and talk about Opal and then slide in a little solidus at the end.

 

Yeah, that was great. Thanks for having me.

 

All right, folks, we'll wrap it here. Until next time, Max out. stuff.