The Magic of RubyLLM with Carmine Paolino - RUBY 676

In this episode, we had the absolute pleasure of sitting down with Carmine Paolino — an AI innovator, Ruby enthusiast, and all-around tech wizard. From his early days automating PC games at age five to building cutting-edge AI tools in Berlin, Carmine’s journey is as inspiring as it is impressive.

We dove deep into his latest creation: RubyLLM, a Ruby gem that simplifies working with large language models (LLMs) like GPT-4, Claude, and Gemini. Think of it as an intuitive, plug-and-play toolkit that lets Ruby developers tap into powerful AI features — chat, image generation, embedding, tools, and even multi-model support — with just a few lines of code. And yes, it’s as awesome as it sounds.

Key Takeaways:

• RubyLLM is built for simplicity and power. Carmine wanted a tool that “just works” — one unified interface for chatting, streaming, tool use, image generation, and more. It abstracts away the API mess and keeps things Ruby-friendly.
• Tooling support is next-level. RubyLLM allows for agentic AI by letting devs define tools (like checking the weather or sending a calendar invite). The gem handles when and how to use them — magic! 
• Support for multiple models and providers. OpenAI, Anthropic, Google — RubyLLM makes it easy to switch between them seamlessly, even mid-conversation. Carmine also teased a future integration with a smarter model registry via an AI-powered API called Parsera.
• Streaming and performance? Covered. Carmine shares clever architecture tricks using Turbo Streams and async Ruby for blazing-fast, lightweight responses — even when handling many concurrent users.
• Real-world use case: ChatWithWork. Carmine’s app lets users “chat” with their docs from Google Drive, Notion, and Slack. RubyLLM is the backbone, and it’s got real startup traction. (Oh, and he DJed the night it went viral on Hacker News.)
• Embeddings and image generation are just as easy. Need vector search or auto-generated podcast art? Just call .embed or .paint — seriously, that’s it.

Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.

Episode Transcript

Speaker 1 (00:04):
Hey, folks, welcome back to another episode of the Ruby
Rogues podcast. I'm your host this week, Charles max Wood,
and I am here with Carmine Paulino.

Speaker 2 (00:14):
And you said you're from Berlin, from Italy, Southern Italy.
I always get excited when I have Italian song because
I lived in Italy.

Speaker 1 (00:21):
For a couple of years, and I'm like, oh, all
the good memories anyway, and the good memories are the
good food and good people anyway. But yeah, you live
in Berlin and you wrote the Ruby llm jem. I'm
sure there's a lot more to know about you. What
else should people know?

Speaker 2 (00:36):
And go, oh, Carmine is so cool.

Speaker 3 (00:39):
Well, thank you very much for the introduction, Charles. It's
a pleasure to be here. So I started using technology
when I was really, really young. So at the age
of five, I started to write my first batch scripts
to automates launching my favorite games, and damn, moment of
making a computer do exactly what I wanted felt like magic.

(01:01):
So that sparked lifelong fascination with technology. And at the
moment I am building like AI tools, you know, I'm
building chat with work, which is this retrieval advantage generation
app that you can connect to your Google Drive and
Slack Notion accounts essentially chat with all your documents, just

(01:24):
as if Chgpt or Claud.

Speaker 4 (01:27):
Would know anything about them.

Speaker 3 (01:29):
I also co founded fresh Flow, which is also an
AI based startup that helps supermarkets reduce food waste and
maximize their profits. And yeah, I've done a bunch of things.

Speaker 4 (01:40):
Essentially.

Speaker 3 (01:42):
I graduated in computer science from University of Bologna, then
did my master in AI from Free University of Amsterdam,
and then I've been a data scientist ever since. But
I think relevant to this podcast is that my last
project at the Universe Still Bologna, which was for Internet

(02:02):
and Web Technologies, was actually in Ruby. And the story
goes that, you know, it was supposed to be in
PHP and at the time, mind you, yeah, at the time,
I was already.

Speaker 2 (02:20):
It's a great.

Speaker 3 (02:20):
Story because I was already looking at acer News and
at the time, all my team, you know, we were
four people, they all knew PHP and I didn't, right,
But I followed after News and I saw Ruby on
rails and this was, I believe, if I remember correctly,

(02:41):
was twenty ten, so you know the era, right, And
I was like, so intrigued by Ruby on Rails at
the time that I convinced my entire team to switch
to Ruby and rails and we all had so much
fun that actually some of us went to work for
other companies that use Ruby and rails. In fact, one

(03:02):
of my friends I went to work for SoundCloud here
in Berlin. I even thought about doing that, I even
went through the application, but then I thought, hey, I
want to have a master degree and you know, maybe
look at something else as well. And that's where I
started looking at AI. And I was a data scientist
for many years. Whenever I could do anything that was

(03:24):
related to the web, it was Ruby on rails anyway,
but mostly Python, mostly machine learning engineering, you know, trying
to scale also systems, so between you know, the DevOps
to the modeling level, right, So it was kind of
a full stack, let's say, machine learning person for a
long time. And then well I decided to go back

(03:47):
a little bit to academia. So I went to the
volunteering Institute in the UK, mostly helping out with an
organization called that as Signs for Social Good. And then
I received a call from entrepreneur first and they told
me like, hey, you have a profile of a potential founder.

(04:07):
I was like, really, because that's that was my dream
and I never thought I could do that. So I
went for it and then I found it fresh Flow
and now I'm actually.

Speaker 4 (04:18):
Doing my own thing.

Speaker 3 (04:19):
I'm a slopreneur and I'm building chat with work and
so to connect back to rubylm since now I'm completely
free and I'm doing you know, like a web app essentially,
it was obviously done in Ruby and rails and at
the time and maybe I'm jumping too far, but at

(04:39):
the time, I wanted to do it because.

Speaker 4 (04:44):
It's all connected.

Speaker 3 (04:46):
I was searching for like libraries for building chat with
work and I saw some of the libraries out there
and I wasn't so satisfied with them, so I decided
to build my own.

Speaker 2 (05:02):
Right Yeah.

Speaker 1 (05:05):
So yeah, it's it's interesting kind of getting into that
a bit. And some of this reflects, you know, with
my own background, right, you know, with you know, I
was kind of a solopreneur. I had a couple of
virtual assistants, but I mostly just you know, ran things
myself with the podcast network for I don't know, like
eight years, and you know, I built most of the

(05:25):
software that the podcast run on and you know, just
just on and on and on and on. I'm not
going to get into kind of the emotional wreckage that
I went through the last few years, especially with you know, now,
I'm in a full time job and I love the
people I work with, and I love the projects I

(05:45):
work on. But there's just something about working on your
own thing and having it, you know, come together in
that way.

Speaker 2 (05:51):
So yeah, yeah, I really identify with a lot of
what you're talking about. But yeah, I wanted to.

Speaker 1 (05:59):
I wanted to jump in and just start talking about
Ruby LM, and I know that the like the AI
space and the LLM space is pretty hot right now.
And that's one of the things that I've been wanting
to put together for a while. Is specifically you said, hey,
you know, you can get in, you can chat with.

Speaker 2 (06:17):
Your dropbox or your Google Driver or whatever.

Speaker 1 (06:20):
And for me, I want the same thing, but I
want to be able to do it with my podcasts.

Speaker 2 (06:24):
Right It's like, hey, you know, change the host out right.

Speaker 1 (06:28):
So like on Javascriptjbver, we just had somebody, you know,
he's like, hey, I've got to take some time away
and write, so things like that. You know, he's the
last guy that's one of the originals besides me, Right,
so chat with it about that, or Hey, how's the
traffic look, or you know, publish this episode on this
date instead of that date and that kind of a thing.

Speaker 2 (06:49):
And so yeah, I got excited about it.

Speaker 1 (06:53):
And then the local meetup the last like three months
have all had presentations on how to through API's hit.

Speaker 2 (07:03):
LLM end points basically.

Speaker 1 (07:05):
And you know so, and I've been playing with some
of that, and we've had Obi Fernandez on to talk
about Ray and so I got everything hooked up and
was figuring all that stuff out. Ray is our AIX
for the people who are listening and trying to go
find it, and he talked about it before, but I

(07:26):
found that the documentation didn't give me clear direction on
how to get everything together the way I wanted. And
he kind of implies that you can stream the response back,
but he basically says it's in my book, and I went,
I have the book, and I went looked in the
book and I got lost. So but but I did

(07:46):
have a fundamental thing working to do the presentation at
the meet up last night, and I was doing a
chat bot and I just hooked it up to OpenWeatherMap
dot org and so it was just you know so.
But then I was showing him, Look, you don't just
ask it, hey, what's the weather. Here's the latitude longitude.
But I put in, is a good is it a
good time right now to go have a picnic?

Speaker 2 (08:07):
And right?

Speaker 1 (08:07):
It came back and said the weather is right. So
it figured out my cities at this latitude longitude and right.
And this is the power of the AI, right, is
that it's smart enough to figure out some of the context.
And I'm being really long winded and I'm sorry, but anyway,
what happened was, for some reason, the open router gem

(08:28):
it was working Tuesday night, and then Wednesday morning when
I was fiddling with it, it just wouldn't connect and
it was given.

Speaker 2 (08:36):
Me a four or four error.

Speaker 1 (08:37):
Of course, the error also said that my JWT token
was wrong, but I was just using an apikey and
so I think something must have changed on their end
or there was something funky going on between me and them,
because it worked fine one day and was broken the next.
I'm like, I really want to show those guys something working.
And then I was like, but I'm talking to Carmine tomorrow,

(09:01):
and so I just went and grabbed it and within
an hour and a half I had the exact same
thing working. And so, anyway, this is cool stuff, cool
cool gem. Anyway, So I'm just curious. I mean, if
you had any other people come to you and basically
say this stuff is great, save my bacon. I don't
know what's been your feedback on Ruby LLM.

Speaker 3 (09:26):
It has been absolutely overwhelmingly positive. I couldn't have imagined
how good this would have been. So when I released
the gem, I was like sitting on it for like
two weeks and on you know zero point one point
zero pre forty nine or something like that.

Speaker 4 (09:45):
Right, I had to release a lot of pre release.

Speaker 3 (09:47):
Versions for myself, and I thought, hey, maybe I should
release it right now instead of waiting until I get
everything downe with chatwood work and you know, doing it
let's say the DHH way where you released it after base, Right,
that was my original plan. I was like, well, what
can go wrong? And so I released it and I
made some write posts and immediately in two days we

(10:11):
got to two hundred and sixty style and my goal
was to get to three hundred, so already kind of
achieved my goal in no time at all, and then
someone posted it on Accre News and I remember that
night I was playing in a club.

Speaker 4 (10:31):
So I'm also a DJ onlands, you know, my free time.

Speaker 3 (10:36):
And yeah, and I come back home, I go to sleep,
and around like six am in the morning, I get
so many notifications of discord, which for some reason I
could hear. I didn't like mute my computer and I
go and check and people were saying like, oh my god,
you made it to a front page of Accre News.

(10:58):
How amazing. And in one we got to one point
seven thousand stars. Wow, which was absolutely overwhelming. Yeah. So
the reception has been fantastic. I've made new friends. There's
some people that I talked to now kind of regularly.
I have an audience on Twitter, which I didn't really

(11:18):
have before. So it has been absolutely fantastic. Just mostly
I would say ninety nine point nine nine nine percent
and everything has been super positive.

Speaker 2 (11:28):
Very cool, very very cool.

Speaker 1 (11:30):
Yeah, I have to say, yeah. I mean my feedback
is is that it's really simple to use. I think
a lot of people get worried that oh it's AI
and I have to know all these things and.

Speaker 2 (11:44):
No, you just tell it. I want to chat, you know,
you have to do a little.

Speaker 1 (11:48):
Bit of setup so that it knows how to connect
open ai or something. But that was for me at least, literally,
here's my API key go crazy so.

Speaker 2 (12:00):
Great.

Speaker 3 (12:01):
Yeah, that was exactly the type of design that I
wanted to have. So basically the reason why I made
Ruby l LAMB is because when I looked at the
other libraries, they essentially fit in two different categories. Right,
So you have the libraries that are mostly done by

(12:21):
Alex Rudahl. Shout out to him, Oh.

Speaker 1 (12:24):
Basic, great guy, that his library is amazing. It does everything, yes, exactly.

Speaker 3 (12:34):
So his library is his main library is Ruby, open ai, right,
and then he has also the Entropic gem. They are
lightweight layers on top of the HDCP calls, right. So
what that means is that it's really easy to support
every single function from the l lamps, but it's also
really hard to then switch between different l lamps.

Speaker 2 (12:55):
If you have to switch.

Speaker 4 (12:56):
And one of my use cases for chat with work.

Speaker 3 (13:01):
Exactly, and all of the response objects, right, they're all different.
So when I was designing Chat with Work, I wanted
to have something that could make it easy to switch
between models and I was thinking either mid conversation as
a you know, north star, and so I needed to

(13:22):
have something that was a unified interface.

Speaker 4 (13:25):
So I looked at the other.

Speaker 3 (13:27):
Type of libraries, you know, so like lang chain RB specifically,
and I saw that I wanted to have some other features.
The design wasn't exactly what I would have done for
a library, but I implemented it. But then I wanted
to have the pricing information, the model information, and listing

(13:50):
of the models. So I started modifying it, and I
started to go into the code of lang chain and
it is quite a big jem. It's not as it
has a lot of code. Yeah, so already you know,
it was quite difficult to orienter yourself around, and it
is quite I would I want to say, it's a
little over engineered for my taste, right, Okay, But I

(14:14):
started modifying it, and also like, it depends on the
Alex's gems, right, so in order to have that same feature,
I need to modify the entropic jam. Then also lun
chain and also lun chain or be rails right, because
there's a separate JEM for the rails integration.

Speaker 4 (14:32):
I was like, is this really what I want?

Speaker 3 (14:34):
Also, I noticed other things that I didn't like about it,
which is that it put the providers first. And I
think philosophically speaking, we don't really care about providers, right,
people care about models.

Speaker 4 (14:50):
Where do they come from?

Speaker 3 (14:51):
Maybe it's interesting in terms of pricing, But if you
want to just chat with a model, you want to
just go like Ruby lam or Chat model and just
go with it, right. I think that's the that's the
beauty and why people have been finding Ruby LM so interesting.
So one question I have puts the models first?

Speaker 4 (15:15):
Yeah, one question I.

Speaker 1 (15:16):
Have on that real quick is so initially I was,
like I said, I was using open router and open
router it kind of does the you can switch models
on their service, right, so you're you can pick them,
but you don't have to set up all the different
service providers. So why not go with something like that?

Speaker 4 (15:37):
That's a good question.

Speaker 3 (15:39):
Well, the open router basically locks you in into that environment,
so you need to use open router. What if open
router dies or if providers like alge my Little Story
or you four four errors right exactly. So I didn't
want to be locked in into anything. I wanted to

(16:01):
use truly open source software just like you know, Ruby
and rails are and that's why I decided, you know what,
this is probably a good idea to do. And yeah,
there were other reasons actually why I thought that the
existing gems were not of my taste. For example, streaming,

(16:22):
even though like line chain or b has, you know,
I unified the interface for most things. Streaming is where
it gets complicated. So whenever you get a chunk, you
actually get a chunk that is exactly the object that
is retrieved from the API itself, So you need to

(16:43):
parse the chunks in a different way. If you have
an entropic model, then you have an opening eye model.
And so all of these problems combined made it so
that I wanted to build my own.

Speaker 1 (17:00):
Nice Well I'm glad you did because it's it's freaking awesome.
So yeah, let's let's dive in a little bit. So
you mentioned models, and if you get into like the
getting started, I mean, I only hooked up open AI,
but it sounds like you want people to be able
to switch seamlessly. So if I put in an open

(17:23):
aike and an Anthropic key, and one or two other providers,
maybe a Gemini key, I can switch between those seamlessly.

Speaker 4 (17:35):
That's right. That's right.

Speaker 3 (17:37):
And the way that this works is that Ruby ALAM
essentially has two different parts of the code. So you
have the clean interface with the user, right, So you
have the chat object, you have the message object, you
have the content object, et cetera, et cetera, and then

(17:58):
you have the mess part of the code, which is
the provider code, right, and what the provider code does
I'm saying messy, but I think it's decent. But it
has all the messy parts of actually communicating with the
provider interfaces and translating between you know, the Ruby LM

(18:19):
internal representation and the provider representation. It sounds pretty straightforward,
and so I implemented it that way so that you
can have a very simple interface but actually change between models,
because then it's just a question of parsing and retrieving
data and formatting it for their for the format not

(18:44):
really about you know, a specific representation that only works
for the specific provider. I definitely didn't want to do that,
and the way to achieve that was to essentially study
the the APIs from you know, open Ai and Entropic,
because that's where I started, and figure out what is
the best way that they implement things, and how would

(19:08):
I implement it in terms of the objects, the Ruby objects.

Speaker 4 (19:11):
That I want to have in my library.

Speaker 3 (19:13):
And so I picked and choose, you know, how to
represent tool calls for example, and that's always now represented RUBYLM.

Speaker 4 (19:21):
And then if the auto.

Speaker 3 (19:22):
Provider that doesn't represent it this way, you know, will
get a different format method in their modules in order
to do that.

Speaker 2 (19:35):
That's awesome.

Speaker 1 (19:35):
So one thing that I'm wondering about is do the
different models have different capabilities that you have to adjust
for or let people know, Hey, you can do this
with I don't know, GPT and Anthropic, but not with
Gemini or something like that.

Speaker 3 (19:52):
That's right, Yeah, that's a great question. So I implemented
them all the registry. That's actually where this whole thing
about RUBYLM started right when I wanted to implement the
model registry for for line chain. And it basically has
a bunch of different capabilities per each model. So for example,

(20:13):
it would know if a model has a function support,
if we would have a Jason mode soon when we
will actually have structured output support, if it will not,
if we will have structured output support, what is the
context length? What is the maximum amount of tokens for

(20:34):
the output, you know, and all that information is put
together in adjacent file that we distribute directly with the library,
because one of the design principles is to be a
turnkey solution. So you just as you as you did,
like you installed it, you put your opening ike and
there you go. You have a chat interface if you

(20:55):
want to write at least in the common line. And
this is exactly the experience that I wanted to have
and I want people to have. So if there is
a model that doesn't have let's say, function calling support,
we will throw an error because we will know it
from the from the models Dore Jason. And the way

(21:16):
that at the moment we make the models Dore Jason
is to query the APIs from the listing model APIs
from open EI, from Entropic, Gemini, et cetera, and then
augmented with our own code that figures out based on
the model family, like that's the model family has function calling,

(21:38):
that's the small family has you know, Jason mode, what's
the context length, et cetera, et cetera.

Speaker 4 (21:45):
And you will find that in the code in the.

Speaker 3 (21:47):
Capabilities dot r B files in the module in the
model sorry, in the provider modules. Now, however, since I've
grown a little bit tired of you know, having to
maintain that code and have you know, also just parsing

(22:09):
the provider's web pages, which is actually kind of costly,
especially when you do it with lams. And there is
some code in Ruby LAM to do that in the tasks,
but I remember the last time I used it, I
spent twenty bucks just to parse all of the new
open Ai model pages. Well, since I grown tired of

(22:31):
doing that, I actually contacted an ex employee of mine
from fresh Flow who now is also an entrepreneur, and
he has a company called Parsera and they're basically doing
scraping of web pages using l lams and then they
returned that as data in Jason and I thought that

(22:52):
that would have been the perfect use case in order
to showcase their product, and we would get like an
API for free in order to just you know, query
about the capabilities of any LM in existence, since unfortunately
the providers they don't provide that at the moment. Right,
Like when you get a list model endpoint response, you

(23:14):
just have most of the time just the model ID
and sometimes the capabilities. I think Google does this and
some other small things, but not the full you know,
model info object that we have inside Ruby ELM. So
basically what Persera is now building and they are like,

(23:35):
I wouldn't say ninety percent. There is this API that
you can just with a get request query and you
have a beautiful interface, you know, a beautiful Jason object
with all of the different capabilities, all the prices, all

(23:56):
well formatted for all the major you know, for providers
that we have in Ruby l M. And so I
will scrap that code. I'm really excited when I remove code.
So I'll scrap that code and simply like called that
that API from from then on.

Speaker 4 (24:14):
So I'm really excited for that.

Speaker 1 (24:17):
So you're not going to have a Jason in your
in the gym anymore. It's going to be an API
call or the APA call. API call will generate the Jason.

Speaker 4 (24:29):
Rather the second.

Speaker 3 (24:30):
Yeah, I still want to have the turnkey solution so
that anybody that installs it, maybe doesn't have Internet, I
don't know, doesn't want to do that API call of
course the Internet, then it can still actually have that
installed and without having an extra API call every time.
And it's refreshed models for example.

Speaker 2 (24:51):
Yep.

Speaker 1 (24:53):
So yeah, let's dive into what Ruby LLM actually provides,
because I think people can now kind of be comfortable
with Hey, look, it does all these models. It knows
which models will do which things, and so if you
try and do something with one model that it just doesn't,
you know, it's not compatible with the model, It'll tell
you and then you can do something different.

Speaker 2 (25:15):
So let's start with.

Speaker 1 (25:17):
The chat because that's where I started, and I was
just blown away that it was that easy, because you
literally just do you instantiate a chat object and then
you do it dot ask and then you get content
back and you can post it. And what I found
was that I had to pull in the common mark

(25:38):
gem and tell common Mark to convert it to HTML
and I was set. That was like, it is there
anything more to it?

Speaker 2 (25:49):
Am I missing it? I mean, we get into tools
in a minute.

Speaker 3 (25:52):
But so in the chat you can also specify contents, right,
so you can send an image with it, you can
send the audio file with it, you can send a
PDF with it.

Speaker 4 (26:06):
And also there I tried.

Speaker 3 (26:08):
To make the design of the library feel super easy
so that if you need to analyze an image it's
just a chat dot ask what's in this image? Come
up with colon open curly braces image and then the
path through your image or the HCP link to your image.

(26:28):
And that also I think follows the same philosophy or
rubylm of convention over configuration and you know, just trying
to make people's life easier. Then you can also stream
the responses in real time, right, and you can simply
use Ruby blocks to do that. So it's super simple.

(26:49):
It's just a chat dot ask whatever you want to ask,
do chunk and then print chann dot content and the
chunk is a chunk object and it looks like a message.
In fact, if you look at the code is pretty
much exactly like a message. I think it's just inherits
from message and that's it. And it will if you

(27:10):
just print the contents, it will simply print that chunk.
But then in the background we're actually accumulating the response
and so the result of that chat dot ask would
actually be a full, fully blown message and it will
be also persistent in the background in the in the
memory that Ruby LM do chat has about messages, Yeah,

(27:35):
what are capabilities that have? So it can also generate images.

Speaker 2 (27:40):
Because I mean you have so you have the capability.

Speaker 1 (27:46):
Yeah, and it just does it in a do loop
and yeah, it has the chunk content and it has
like a print or puts.

Speaker 2 (27:54):
In kind of your just general Ruby application.

Speaker 1 (27:57):
But I don't know, people who listen to this show
know that I'm totally in love with Turbo.

Speaker 2 (28:04):
It was like, where have you been on my life Turbo?

Speaker 1 (28:07):
But you have examples on how to push the stuff
out to Turbo as well, right, So one one question
that I have with this because it shows a job
and the job uses the Turbo streams channel broadcast right
to update the message, which is you know what you want?

(28:31):
I'm just I'm trying to figure out exactly where this
gets called from.

Speaker 2 (28:38):
Does it just run periodically? And then so.

Speaker 3 (28:47):
How it works in chatwood work is that there is
a job. It's not called chat stream job, it's called
slightly differently, but there is that job similar to the
job in the guides, and what it does is to
stream via Turbo, essentially appending the chunk content to a

(29:10):
div that is hidden, and then I use mark dot
j as in order to doing the rendering of the
of the actual message. The reason why I do this
is because I used to have everything server side and
do all of the rendering of markdown server side and

(29:33):
then send you know, the HTML over But the problem
is that when you get to really big messages is
starting to stream every single time you have a new chunk,
which may be even every single word, or you know,
even sometimes less than one word, And you can imagine

(29:55):
that refreshing the message so fast and and doing it
so many times it actually bogs down your connection. So
at some point I noticed that my connection was downloading
like multiple megabytes per second right of HTML. So it
didn't make any sense to me. So what I'm doing

(30:15):
is to simply append the chunk to that specific dive
and then marked will look at that div and it
would actually do the rendering in an udative.

Speaker 4 (30:24):
That I actually displayed to the user.

Speaker 3 (30:26):
And that also gives me the possibility to do a
copy functionality in which the when you copy the message,
it would actually copy the markdown version of the message,
which I think is so much more useful than getting
the full blown HTML from the page. And so how
do I call that job? Well, I call it from

(30:49):
the the actual controller. So whenever the user asks something,
you know the controller, which is fire that job in
the background, and the job will simply process whatever comes
from the OLM.

Speaker 1 (31:06):
Okay, so in the controller then I have something that effectively,
I mean, do I tell it I'm streaming it? I
guess I just have the do block and so then
every time gets executive executed, sorry, it calls the job

(31:26):
or how I'm just trying to wrap my brain around this.

Speaker 3 (31:34):
Right, So basically the controller would simply you know, maybe
you want to create a message in the controller, do
whatever you want, but in the end it needs to
call that chat stream job so that you can process
the streaming in the background because you can't have that
running in the controller because it's such a long running thing.

(31:58):
And that's exactly how I do it in chatwood work.

Speaker 2 (32:04):
Okay.

Speaker 1 (32:06):
So basically what you've got going on is, yeah, you've
got your and it shows it in the chat right,
So you do the chat dot ask with the do
inside the do you call the job the job is
streaming stuff out through turbo and then you have marked
basically putting it in. Yeah, that's cool, that's correct. When

(32:30):
your controller action finishes, then it renders a turbo stream whatever.

Speaker 3 (32:38):
Yeah, so if you set up your turbus, your broadcasts,
you know, inside your application record, you know, on your models. Basically,
it would also update the whole message when it's finished,
and you can also tell it to you know, update
of typing indicators and perhaps the button you know that

(32:59):
has to change from a send to a stop. All
of that you can do actually really really easily with Rails,
and no wonder because Rails is so fantastic for these things.
One thing that I think is interesting about the jobs,
if I may, is that what I noticed, especially using

(33:23):
things like solid que which use threads, is that you
have a certain number of threads that you can use maximum, right,
So you need to set it up and you have
one worker per process as far as I remember, and
then you need to set up how many threads per

(33:45):
process you have as workers.

Speaker 2 (33:47):
Right.

Speaker 3 (33:48):
So even if you set it up in a way
that it will process many many connections at the same time,
many many chat streaming jobs at the same time, you
will always be limited by that. And the limitation is
that every single thread in Ruby is eight megabytes. And

(34:09):
also you're occupying a whole slot, right, So you can
imagine an application like chat with work it has not
only the chat streaming job, but it also has the
process document jobs, right, and the discovery document jobs and
all of these and there's many, many jobs running at
the same time, but they're all very lightweight, right that
they're not doing much CPU wise, they're mostly like sending

(34:34):
things back and forth through APIs and then you know,
the grant of the work is probably done in postcris,
you know, because I use postgris also as a vector storage.
So they're all io bound, not CPU bound, and they're
consuming one thread every single time there is a job

(34:56):
running at the same time, and so that was not ideal.
And in the Python world and in the JavaScript world,
you know, for io bound operations, everybody would use a
syn ko for example in Python, right, or a sync
wait in JavaScript. And so what I noticed is that
now I came back to Ruby, there's a bit of

(35:19):
a lack of understanding or you know, knowledge about using
concurrency instead of using parallelism, well fake parallelism with threats,
And so I delved deeper into it. And actually there
is a beautiful ecosystem of asynchronous gems such as a sync,

(35:42):
a sink cable, ACNK job, anything that is built by
Samuel Williams I aquatics, you know, also called socketry, is
absolutely fantastic. And what I also noticed is that Ruby
is probably the best language to do concurrency because in

(36:04):
most other languages you need to uppend these or prepense
these keywords like a sync await every time you need
to do such an operation, But in Ruby you don't
need to because if the C level operation actually is
fiber aware, then you get fiber awareness for free. So

(36:26):
you just need to essentially use or wrap whatever code
you have into let's say on a sync block, and
if you do it right, it will work in parallel
in concurrent.

Speaker 4 (36:41):
Actually awesome.

Speaker 1 (36:43):
So one question I have on that is, because I've
never even used this before, can you run this and
solid que side by side and then just throw the
acinc jobs at one and any irregular stuff at the
other or do you just put everything into an acin job.

Speaker 3 (37:02):
At the moment, how I'm using it is everything is
in a saying job, but you can totally right random
side side by side. I think there is a Q
adapter that you can use in each single job, so
you just you know, you have the que as the
fault for example, right, so you can have a Q

(37:23):
adapter and you just say solid Q for certain jobs,
and you can do a saying job for your jobs.

Speaker 1 (37:32):
That's a good tip because yeah, if I'm going to
build a podcast assistant, I'm probably gonna run into the
same constraints, and so that is really helpful.

Speaker 3 (37:43):
Right, Yeah, Yeah, I'm no, it's just saying that I
basically discovered this this fly, and I think that it's
really a matter of communication to the Ruby community out
saying like, hey, there's not just this way of doing

(38:03):
concurrency in paralyism that we're all familiar with, you know,
like threads, but there's also fibers, and you know, there's
other software that you could use that even though you
don't have io bound operations, you can simply replace Puma
with Falcon and have you know, five x speed ups.
Sometimes it's really so much faster it's noticeable. I didn't

(38:25):
do any benchmarks, but it's really Yeah.

Speaker 1 (38:28):
I've talked to Samuel before and I got the impression
that some workloads really lend themselves to it and some
don't as much.

Speaker 2 (38:34):
But yeah, Falcon is really cool.

Speaker 1 (38:40):
One other thing that I'm curious about here, So when
I built my app the other night, with the chat.
I realized that in my controller, I was instantiating a
new chat every time writers doing RUBLLM dot chat. And
what I want is I want an ongoing conversation with
you know, so that it kind of maintains the context

(39:01):
and things like that. And there's an example in here
where you're basically what I would do, like in a
RAILS console or IRB or something where you know, it's
like chat dot ask and then you send it another
message chat dot ask and it looks like that maintains
that context. But how do I do that between requests

(39:25):
when I'm hitting the controller anew every time? But I
still want it to be part of that same.

Speaker 3 (39:30):
Chat, right, I think this is really important to say.
So the RAILS integration essentially persistent messages, Yeah, persistent messages
inside active record models.

Speaker 4 (39:47):
So we have essentially some helpers which are called.

Speaker 3 (39:54):
Acts as chat, acts as message access tool call that
you can drop in into your models. You know, if
it's called chat the model for chats, then you just
say class you know chat inheriting from application record and

(40:14):
then just say access chat and you have essentially all
the connection to also the message model. You have persistence
and every single method that we have in the classic
chat interface, you know in plain old Ruby objects.

Speaker 4 (40:34):
You would have it also in rails.

Speaker 3 (40:36):
So if you do chat dot ask, it will first
create a message with the with the user role and
save it and then also call the API for whatever
LLLM you're using, retrieve that and then put it inside

(40:58):
a new message anderson is that and then return that
message at the end. So it looked like exactly the
same interface for PLANEOAR Ruby objects, but you have the
persistence done not just in memory but also in your database.

Speaker 1 (41:13):
Right, what if I'm not using rails or not using
active record, is there a way to do this like
in Sinatra or something like that and that anyway?

Speaker 3 (41:24):
Right, I haven't used Sinatra recently. The last time I
used it was more than ten years ago. Maybe it's right,
So I wouldn't know how to actually build that out,
but it's possible to. If it's possible to make an

(41:45):
adapter for whatever type of you know, storage you have,
it should be pretty easy and people can just look
at the access code and see how we've done it.

Speaker 2 (41:56):
Right, Yeah, that makes sense.

Speaker 1 (41:59):
You can't just look at his chat and then see
what she did. Very cool let's talk about tools for
a minute, because this was one of the other things
I showed off the other night was essentially I created
a tool that just checked the weather, and yeah, I
didn't use the same service you did, but it was
basically the same thing. I used Open weather Map instead

(42:22):
of Medio or whatever you used, but yeah, it was
the same deal. Do you want to explain to people
what tools are and how they work?

Speaker 2 (42:34):
Right?

Speaker 3 (42:34):
So, I think tools, especially with MCP, they became the
most hot thing talked about at the moment in AI. Right,
So for people who are not familiar essentially with LLM models,
you can create a tool in your own language and
then tell them like, hey, this is the way that

(42:58):
this tool works. So this is the description of the tool,
and these are all the parameters that we need. These
are the parameters that are optional, and these are all
the descriptions for every single parameters. And then the LM
will decide when to use that tool.

Speaker 2 (43:15):
Right.

Speaker 3 (43:15):
So let's say you created this tool for weather, but
then the user talks about something else, wants to talk
about MacBooks, right, the LLLM will not actually call the
tool every single time. And I think the fundamental difference
between tools and the classical RAG for example that we

(43:38):
used to have, you know, even just a year ago
at this point is that you don't always do retrieval
advantage generation. So basically you don't always search, you know,
the documents and then put them in the context of
the message every single time you have a new message. Basically,
tools enable agentic aid I because the AI can be

(44:03):
an agent and really figure out if it needs to
use this tool or not. And they are now like
all the age with MCP, So MCP, for it's not familiar,
is model context protocol, and it's a way to bunch
up a bunch, you know, a bunch of tools into

(44:27):
one single interface and give that interface to the l
l M so that the l M can figure out
you know, hey, I can now access the file system,
I can now use VIM, I can now use vs code,
I can now use I don't know whatever API. And
it's essentially an implementation of tools in a way, right,

(44:49):
but just in a different API.

Speaker 2 (44:57):
Yeah.

Speaker 1 (44:57):
Absolutely, So this is where like with my my thing
with my podcast stuff is you know, it's not just
which episodes were most popular or what other thing do
I want you to look up, but it's hey, reschedule this,
or hey, invite this other person or do this other thing,
and it can through the API go and talk to

(45:18):
the other system and make it do something for me.

Speaker 4 (45:21):
That's right.

Speaker 3 (45:22):
So it opens up a lot of possibilities for using
lms for all kinds of disparate features.

Speaker 2 (45:29):
Right.

Speaker 3 (45:30):
You can save things, you can retrieve things from the Internet.
You can imagine for example Google search or like document search,
or creating new blog posts. It's just I think the
possibilities are endless because you're letting.

Speaker 4 (45:49):
The AI use your code.

Speaker 3 (45:52):
Of course, you need to be aware that also ais
are generally benevolent, but you know they could use your
tool badly.

Speaker 4 (46:03):
They could cause wreckage.

Speaker 3 (46:04):
So don't use evolved, don't use system right, but try
to be kind of careful about it. But in general,
it's a fantastic way to make ELM super super powerful.

Speaker 1 (46:21):
Yeah, and I think tool design and security with the
tools and things like that might be outside the scope
of this episode, but yeah, I mean I've had people
ask me too, it's, hey, well, how do you make
sure that the tool is only doing this stuff within
the scope you want? So, for example, in my case
with podcasting, it's how do I make sure it's only

(46:43):
doing stuff on one person's podcast and not another, or
things like that.

Speaker 2 (46:48):
And so.

Speaker 1 (46:50):
Because you know, we've seen people do what looks like
SQL injection attacks except as prompt stuff, and it says, well,
but pretend you can do it essentially, right, they talk
the LM around to Okay, I'm going to pretend I
can do it, and so I'm going to act like
this other user even though I'm not technically supposed to

(47:12):
do that. And there are only so many safeguards you
can put into place. But if you don't have a
tool that allows them to impersonate anyone else, and you've
locked down the access to the user and it's data
to a methodology you can control, like find the current
user uses the session to validate the user instead of
looking the user up by email address, for example, and

(47:34):
it doesn't have a tool to look up the user
by email address unless you need that feature for admins.
But then you use a different chat agent for that
and give it those tools there Now you're getting into
so you have to be careful how you use them.
Like you said, for sure, try and think ahead on
how people may trick your agent into doing something that shouldn't.

Speaker 4 (47:57):
That's right, That's exactly right.

Speaker 2 (48:02):
But yeah, the tools are cool.

Speaker 1 (48:04):
One question I had on this, so I built a
tool for the weather, and then I was thinking about
it and I was like, well, what if I wanted
So then I was showing off, not what's the weather
in Lehigh, Utah, which is where I live, but you know,
is it a good time to go have a picnic
in Lehigh, Utah?

Speaker 2 (48:22):
Right?

Speaker 1 (48:22):
And it's smart enough to go, Okay, I need to
know what Lehi is, I need you know. I figured
out the latitude and longitude. I sent it to the
Weather Service. It told me what the weather was, and
then it said, yeah, it's kind of a nice evening
for a picnic, right because it was sixty degrees and
you know, the wind wasn't too bad and it wasn't raining.
But then I was thinking, okay, well, what if I

(48:43):
wanted to ask it what day this week should I
go for a picnic? Then it has to have another
tool that will do the forecast look up. And so
I can imagine that if you're creating tools, you could
wind up with a lot of tools, right, collection of them.
I'm wondering if there's a way to like group them together.
So it's like, hey, here's all the calendar stuff, here's

(49:05):
all the drop box stuff, here's all the drive stuff.

Speaker 3 (49:08):
I think that's exactly what Entropic was trying to do
with MCP. It's probably exactly that use case. And essentially,
as I said, MCP is this way of bunching up
different tools into one single API, and it tells the LLM, hey,
I have all these things that you can do now.

(49:28):
And you can even run like MCP servers in your
own computer for example, in order to you know, connected
the LM with your files.

Speaker 4 (49:41):
Use it more.

Speaker 3 (49:42):
You know, cloud code Sorry, cloud code uses MCP as
far as I know, and maybe wrong on this, but
I think it uses MCP to actually connect to your
files and your file system and to look up stuff
and to change it. So it is a valid point,
you know, and you can win up with a lot

(50:03):
of tools and actually they consume a little bit of
your context window. However, now with the recent models, you know,
I don't know if you heard, GPT four point one
just came out and it has a one million token
context that.

Speaker 4 (50:19):
Is pretty big.

Speaker 3 (50:21):
Yeah, you can do a lot of stuff with one
million tokens and I've been using Gemini two point five
pro extensively lately and it's a fantastic model super bowlish
on on Google lately, and it also has you know,
million context window if not two million, I don't remember that.

Speaker 2 (50:50):
Yeah, that makes sense.

Speaker 1 (50:53):
The other thing that I've seen done and we talked
to Obi before MCP was really a thing, and what
he was doing was he actually had different.

Speaker 4 (51:02):
Agents that had different jobs, right, and.

Speaker 1 (51:04):
So then instead of providing this huge list of tools,
he would he would have one tool that was essentially said,
write a prompt for the calendar agent, right, and so
then it would prompt the calendar agent and say, hey,
can you invite so and so to this calendar event?

(51:27):
And then on the calendar agent would then say, oh,
this means I have to go find the event.

Speaker 2 (51:31):
And update it with you know, with the user or whatever.

Speaker 1 (51:35):
So that that was his way around it. I kind
of liked that approach anyway, because then I really can
kind of box in each of the agents with just
a small set of responsibilities and capabilities. But yeah, that
was his way around it, and I think that's kind
of an elegant solution. But I can imagine if I

(51:56):
have a app tools directory in my application, that I
might have a lot of those in there, depending on
how many capabilities I'm giving to my application right or
to my agent.

Speaker 2 (52:07):
Right.

Speaker 4 (52:08):
However, I think that this.

Speaker 3 (52:11):
Is a totally fine design solution for the past models
that we had, you know, even last year, where two
hundred thousand tokens context windows were pretty big, right.

Speaker 2 (52:26):
Yeah.

Speaker 3 (52:27):
I think we'll probably see in the future, you know,
just having one single model that would actually handle all
the tools you have, because the context window is big enough,
and it would be super powerful and it can do
so many things, it will actually.

Speaker 4 (52:45):
Probably blow people's minds.

Speaker 1 (52:50):
Yeah, with a million tokens. Yeah, I can imagine that
that's that's a ton. It's interesting because I was working
with a model this earlier this year, and I think
the context window had.

Speaker 2 (53:04):
Like two hundred thousand tokens. I think something like that
one hundred and fifty two hundred thousand.

Speaker 1 (53:09):
And the issue that I was running into there was
that I was pulling in bills during the Utah legislative
session and getting summaries done and things like that with it,
and there were like four.

Speaker 2 (53:20):
Bills that were too big. It blew, it blew past
the context window, and so I.

Speaker 1 (53:25):
Tried breaking it up, but ultimately that's the other great
thing about a lot of this stuff is that the
context windows are getting bigger, and what that means is
that the prices are coming down for models that have
larger context windows that were kind of the run of
the mill, state of the art ones before. And so
you can get away with a lot more or you

(53:47):
can just like in your what you're saying here with
the chat is that I can go in in midstreams
it comes back and says, hey, this was way too big.
I can go Okay, just this time, go use bigger
model and pay the extra money.

Speaker 2 (54:03):
Right Yeah.

Speaker 3 (54:04):
I think these are two trends that we've seen so far.
So one is context window becoming bigger. And I think
it's a question of just pure capabilities.

Speaker 4 (54:12):
Right, So, all of.

Speaker 3 (54:14):
The applications similar to chat with work, and there are
a few, they all need to have sort of big
context windows in order to function correctly, because you want
to have as many documents, you know, describing things or
chats or whatever else that is relevant for the topic
that the user asked in order to be first of

(54:35):
all correct in your answer. And Thori and I think
there is always a balance in an information retrieval system
like this, like how many you actually present even to
the LLLM itself.

Speaker 4 (54:48):
But that's a whole other topic.

Speaker 3 (54:52):
But with the big context windows, you can kind of,
you know, relax a little bit that balance. And then
the second thing that you mentioned, which is getting the
prices down, I think this is inevitable. The models are
being commoditized more and more, and honestly, I am finally
seeing what I thought Google would have done, which is,

(55:15):
you know, putting the prices very very low for models
because they have access to TPUs, right, so they make
their own chips for AI. And one thing, you know,
you can use Nvidia cards and they're fantastic, you know,
for for EI usage. But another thing is you know

(55:36):
TPU from from Google. It goes much faster, and you know,
it's it's so much better. They make it in house,
so it's probably cheaper for them. So yeah, I'm really
excited to see where where things will go next with
this in in AI because there seems to be so

(55:57):
much going on at the same time it's kind of
hard to follow.

Speaker 2 (56:02):
Yep, yep, absolutely well.

Speaker 1 (56:04):
Yeah, and every time I see a new model come
out and people are like because it's felt like the
last little while, you know, like Grock came out and everyone's.

Speaker 2 (56:11):
Like Grock is the best and it's doing the best
and blah blah blah.

Speaker 1 (56:14):
And literally like a week later, like GPT four one
was out or Anthropic, I can't remember, but one of
them came out with something and it was like, Wow,
this one has you know, this much more over Grock.
And then it was the other one, whether it was
GPT or Claude or something else, came out and it
was like, oh, now this one right. And so we
keep getting better and better and it feels like this
arms race. But the flip side of it is is

(56:36):
like you said, you know, the models that are powerful
enough are being commoditized to the point where it's just like,
you know what, just just pick the one that's going
to do the thing for you. And I mean, granted,
you know, the latent space some of them allow the
different models to do better in certain contexts. Right, it's
not just the token size, but holy crap, if they

(57:01):
keep pushing it the way they're pushing it, I mean,
we're just going to have some wild capabilities with what
it can do.

Speaker 2 (57:06):
And I for one super excited about that.

Speaker 1 (57:09):
Yeah, we're getting a little bit close to time, so
I'm going to push us to image generation and text
embedding and then we'll wrap up with picks. We've got
about ten minutes to talk about image generation and embedding.
So how does that all work?

Speaker 2 (57:31):
Because I didn't dive into that so much.

Speaker 1 (57:32):
I've used other tools to do it, but I didn't
dive into that so much with.

Speaker 3 (57:38):
Ruby LLM, right, So it's a simple call. It's at
the same level as RUBYLM do chat, but since it
doesn't need to have like the context of all the
conversation that you have with the LLM, it's as simple
as RUBYLM do.

Speaker 4 (57:53):
Paint and then you have your message there.

Speaker 3 (57:59):
And also for embedding, so you can just use RUBYLM
dot m bed and just the text. You can also
pass a raise so it will embed multiple texts altogether
and batch them together. This is nice for you know,
pricing and API usage. But that's pretty much all there

(58:20):
is to it. You know, there's some little things that
you can do depending on the model. For example, for
I believe Dali has two different sizes outputs, so.

Speaker 4 (58:31):
You can configure that.

Speaker 3 (58:33):
But and you can choose obviously between all the models
that we support in the providers that we support. But
there's pretty much all there is to it about these
two two things is just a very simple interface for that.

Speaker 2 (58:50):
Yeah, I have to say.

Speaker 1 (58:51):
One of the things that I'm excited about this as
far as the image generation goes, is I want people
to be able to say, hey, I want you to
generate some album of art or some episode artwork or
something like that. And like if I say, hey, use

(59:12):
this episode that we recorded and generate some artwork for it,
I mean I could see it basically using the chat
prompt set up to say you know, and you could
you said you could pass it attachments, so it could say,
here's the audio for the episode, you know, give me,

(59:34):
write me a prompt to get a good image, you know,
cover art image for this episode. And then it turns
around and it goes ruby LLM paint. Here's the prompt
that I made up, right, and then you can see
what it comes up with. And the other thing is

(59:54):
is that on the chat models we didn't talk about temperature,
but you could set the temperature a little bit higher
and get some more creativity out of your prompt. Then
the image generation may give you something a little bit different,
And so I'm looking at changing some of these together
and I'm really excited about that stuff too. But yeah,
the image generation seem pretty straightforward to me.

Speaker 3 (01:00:16):
Yeah, what I'm excited about is to see GPT four
all image generation in the APIs, and I know it's
coming soon. I know it has been taking the world
by storm lately. How many Studio Ghibli memes of your found, Charles, Oh.

Speaker 4 (01:00:32):
Yeah, you have them.

Speaker 1 (01:00:35):
Yeah, so you see wacky stuff with Donald Trump or
Bernie Sanders here in the US, right, you know, not
to pick on one side or the other, but both
of those guys cartoon out really really well, and it's
so fun to see some of them because it's like
it's like, oh, yeah, that's the studio Ghibli that kind
of emphasizes kind of the quirky aspects of either one

(01:00:58):
of those guys.

Speaker 3 (01:01:00):
Yeah, the capability of JUBT for image and it is fantastic.

Speaker 4 (01:01:06):
But returning back to your question, I think the.

Speaker 3 (01:01:10):
Or rather what you said is to me, I'm really
excited about that because it really would combine both the
text interface and also like the image generation in the
same model.

Speaker 4 (01:01:21):
So that we can have.

Speaker 3 (01:01:23):
This capability without even needing to create a new tool.
So right now, how you would do it is that
you create a tool and inside the tool you have
RUBLM dot paint. Right with these types of models, you
wouldn't need a tool anymore, and it would do it
all in the same model, and it would do it
so much better than the previous diffusion models because apparently

(01:01:44):
they're using combination of diffusion and transformers architectures. So in
the end, what comes down to is that is so
much more beautiful, so much more precise. It also understands language, right,
so it also understands out to make fonts so you
can write you know, when it writes it, actually you

(01:02:06):
can read it, and it's not just this garbage that
we used to get like a year ago.

Speaker 1 (01:02:14):
Right, So I have to admit with the embeddings, so
I was flirting with the idea of doing vector searches
for top end devs, and I'm going to move there,
but I'm just using what's built into postgress at this point,
and that's what it pointed me too as one option, Right,

(01:02:34):
I could hand off getting the vectors out of a
text embedding, but beyond that are there are other things
that people do with these because I'm I'm kind of
lost as far as like how useful this is?

Speaker 3 (01:02:46):
Right, Well, you could do so many things, like you know,
cluster things together, for example, and try to have different topics.
So let's maybe start from what isn't embedding. I'll try
to compress it because I know we don't have so
much time. It's basically a very long array of numbers

(01:03:07):
which represents a point in a space which is a
multi dimensional space, and the dimensions are you know, the
length of the array. Essentially, what that means is that
if you projected in three D space, it's just this point, right,
And let's say this point represents a word or a
document or whatever, and the distance between another point is

(01:03:32):
actually significant, and it is semantically significant.

Speaker 4 (01:03:35):
So, for example, if.

Speaker 3 (01:03:37):
You would have the word and let's let's bring it
back to word t K. Right, it's a really really
old model that used to represent words in this embedding space.

Speaker 2 (01:03:48):
Right.

Speaker 3 (01:03:49):
So if we say, if we take the embedding of king, right,
and we take the embedding of queen, we can actually
I believe, subtract from King the embedding of man and
add the embedding of woman, and we will get very close,

(01:04:12):
if not exactly perfect on the embedding of queen. Right,
So they're semantically significant. So what that means is that
you can start to you know, cluster similar data points,
similar documents, similar movies, similar whatever you want. You can
search in them. And searching is a kind of a clustering.

(01:04:37):
So you're basically like taking the query and embed it
and then see where it ends up in the space,
and then you start to expand your your bubble to
see who else is nearby, and then you just take
a limit, you know, the top ten or whatever, because
it could go infinitely. You know, you could get all
the documents just ordered by out.

Speaker 1 (01:04:59):
Close, right you were just yeah, ordered by distance. Yeah yeah, Okay,
So it really is.

Speaker 3 (01:05:05):
Kind of a search type use case, that's right, But
it's more semantic than the typical keyword search.

Speaker 1 (01:05:16):
Right, because if you use the keyword for ruby, well
that's not a great example, but if you make it
you have two synonyms, yeah.

Speaker 2 (01:05:31):
Or yes, sing a TYPEO won't find it.

Speaker 1 (01:05:33):
Or if you have synonyms, right, And so somebody said testing,
and somebody said, uh, tested, and you look for tested,
it won't find testing because it's not doing semantic you know,
it doesn't break it up into tokens.

Speaker 2 (01:05:47):
It doesn't do all of that other work where this does.
And so yeah that makes sense.

Speaker 3 (01:05:52):
Yeah, a typical search engine would have stemming, so they
would separate testing and tested and kind of matches anyway.

Speaker 4 (01:06:00):
But I that's exactly right. I think the genre idea
is exactly right.

Speaker 1 (01:06:04):
Yeah, all right, cool, Well, I'm gonna go ahead and
wrap us up and head us into picks. But this
is terrific. I'm gonna point people to ruby l l
M dot com. But if they want to reach out
to you or connect in some other way, like how
do people find you on the internet and say, dude,

(01:06:24):
this is awesome.

Speaker 3 (01:06:26):
So my blog is at paulinot me and you can
reach me on Twitter as well at x dot com
slash Paulino.

Speaker 2 (01:06:37):
Mm hmm. And for the non Italians, Paulino is p
a O l I n O.

Speaker 4 (01:06:43):
Yes, correct, p l O n I N.

Speaker 2 (01:06:45):
So yeah, it's it's the p a O that might
lose people anyway.

Speaker 1 (01:06:54):
Thanks so much for coming. Let's let's jump in on
the picks. I'm gonna be kind of short with mine
just because I don't want to take a ton of
time and I have to jump over to this other
meeting at eleven. But so my first pick I always
do a board game picks. Last week I think I

(01:07:15):
might have picked this, but I'm going to pick it again.
It's kind of like the game that we've been playing lately.
It's called Cult Express, and basically you have a train
on the table and you know, it's just made out
of wood. It kind of all fits together. But it's
unique for a game board, right because it's it's it's
this three D train and your bank your train robbers,

(01:07:39):
and so you're trying to gather as much loot as
possible and whoever gathers the most loot wins. You also
get you get one thousand dollars for being the person
who shot the most bullets. And so you have cards
that represent actions. You can pick up loot, you can
move from the roof to the car, or the car
to the roof. You can move one card to the other.

(01:08:01):
You can shoot your gun at other robbers, and if
you hit them, then your bullet card goes into their deck.
And it's basically no op, no action card. And so
when you drop up a new hand, if you have
those in there. They're just kind of duds. You can
punch other players, and if you punch another player, then

(01:08:21):
they drop a piece of loot, and then you can
pick up loot. And then all the players or all
the characters have different abilities, right, And so the player
that I played, if you punch somebody and they drop loot,
if they drop a loot bag, you can catch it
before it hits the floor and collect it without having
to play a pick up loot card.

Speaker 2 (01:08:43):
Right.

Speaker 1 (01:08:44):
Some of the others were that you could you could
shoot above you or below you if you were on
the roof or in the car. There were some that
had to do with a sheriff, right, because there's a
sheriff on the train and if he winds up in
the same car as you, then he puts a bullet
in your in your deck anyway, So it was a
lot of fun board game. Geek waits at one point

(01:09:05):
eighty six, which means that it's pretty approachable for the
average random board game player that doesn't play the heavy
board games like I like. And uh yeah, it took
us like forty five minutes or so to play, or
maybe an hour, but we were learning the rules and
so I could I could imagine you can play in
forty five minutes.

Speaker 2 (01:09:26):
And yeah.

Speaker 1 (01:09:27):
Anyway, so the way you play your cards is you
go around the circle and everybody plays a card onto
the pile.

Speaker 2 (01:09:37):
Sometimes you play two cards.

Speaker 1 (01:09:38):
Sometimes you play him face down, but you can see
what everybody else is playing on a regular play. And
then you take the deck and you flip it over
and you just play the deck. And so then you know,
he played a shoot the gun card, so if he
could shoot somebody, you shot him. And then the next
guy he played a punch card, so he punched the
guy next to him because he could. And if you can,

(01:10:00):
then you can't write. So if you play it and
there's nobody in the car with you to punch and
you just don't punch. But if there is somebody there
and they're not the person you wanted to punch, you
still punch them.

Speaker 2 (01:10:09):
So that's kind of how it works.

Speaker 1 (01:10:10):
So anyway, it was really really fun, really really enjoyed it.
It kind of reminds me of another game called robot Rally.
The difference is is that with robot Rally, what you
do is you put all of your action cards into
your own pile and then you flip it over and
play them in order. But you play them in order,
everybody goes around and plays them. And so you know,

(01:10:31):
a lot of times you set yourself up to push
another robot into a hole or make them go off course,
but they did something you didn't expect, and so then
you wind up making moves that you didn't expect because
you expected to hit them. And so anyway, it's it's
a lot of fun. It's kind of a it's almost
like mob programming a little bit. So anyway, a fun

(01:10:52):
cult express it. It's really fun. Besides that, at work,
we're doing a Ruby book club and we're reading Sandy
Metz's oh what is it called. It's the Pewter Book,
The Practical Object Oriented Design in Ruby, and it's a

(01:11:19):
terrific book. I don't agree with everything that Sandy says
in it, but a lot of it I do, and
the rest of it every time I read it and
I think about it for a while ago.

Speaker 2 (01:11:29):
Okay, yes, but with caveats.

Speaker 1 (01:11:31):
Right, so right, anyway, if you haven't read it, it
was written in twenty eighteen, the second edition, but it's
still pretty down good.

Speaker 2 (01:11:38):
So I'm going to pick that.

Speaker 1 (01:11:39):
And yeah, in a couple of weeks, we're going to
be talking to the guys that built Ruby events dot org.
It was originally Ruby videos dot dev and so it
had all the conference videos. They were trying to collect
all of those. But yeah, now they're pulling in like
all the upcoming conferences and stuff like that, making it

(01:12:00):
easy to figure all that stuff out.

Speaker 2 (01:12:02):
So I'm going to pick that too, Carmine, what are
your picks?

Speaker 4 (01:12:06):
My picks? Can I go with music?

Speaker 2 (01:12:09):
Yeah?

Speaker 3 (01:12:10):
Yeah, yeah, yeah, all right cool. So I run a
disco collective here in Berlin. It's called Floppy Disco Fun
and what women trying to do is to bring back
the funk a little bit in Berlin. As you know,
it's probably as you probably know, it's a very much
of a techno city. And I want to pick some
friends that have been playing with us that have been

(01:12:31):
absolutely fantastic. Cody Curry, he is a jazz house master.
We play with him actually this Saturday, and he has
releases on Spotify that you know, they have three million plays,
So definitely hitting a spot there with people. Very jazzy,

(01:12:51):
very groovy, very soft jazz kind of style, but in
house music, so really really cool stuff, really chill guy,
also really cool.

Speaker 4 (01:13:03):
RP.

Speaker 3 (01:13:03):
Brown from the same label. Toy Toonics is the label
by the way, it's an Italian German label by an
Italian German guy.

Speaker 4 (01:13:11):
And r P.

Speaker 2 (01:13:12):
Brown is.

Speaker 3 (01:13:16):
More on the UK side of the spectrum. I want
to say, so he combines you know, disco with UK
influences because he lived there for a little bit, uh
and Delphonic different label. He posts on a bunch of
labels actually, and he has been I think one of

(01:13:38):
the biggest disco influencers here in Berlin and DJs and
he plays a lot and he's uh.

Speaker 4 (01:13:47):
Just also just such a nice guy. So I want
to pick these three.

Speaker 3 (01:13:54):
And in terms of books, uh, the Hot Wire book
by Joe Oh, fantastic, fantastic book.

Speaker 4 (01:14:04):
Been reading this and now you're really enjoying it.

Speaker 2 (01:14:08):
Which one is that?

Speaker 3 (01:14:09):
I think it's called All to Our tur Ball? I sorry, Joe.
Why are Native for rails developers?

Speaker 2 (01:14:20):
Oh?

Speaker 1 (01:14:20):
Hot Wire Native Yes by Joe mast Yeah, yeah, yeah, yeah,
that's a terrific book on practprog. We talked to him
a little bit ago and we're going to have him
come back on.

Speaker 2 (01:14:32):
Because there was just more to talk about. So I'll
look for that a month or so.

Speaker 4 (01:14:36):
Awesome.

Speaker 2 (01:14:39):
All right, good deal. Well, thanks for coming, Thank you
for having me.

Speaker 4 (01:14:43):
It's really a pleasure.

Speaker 2 (01:14:44):
This was so cool. I may not sleep for a
week because I'm playing with this stuff.

Speaker 4 (01:14:50):
I'll feel bad and happy at the same time.

Speaker 1 (01:14:53):
Yeah, all right, Well I'm gonna go ahead and push stop.
Stick around because we got to make sure we get
all your stuff uploaded. But to the listener until next time,
max out. M m mm hmmm.