Speaker 1: Hey, folks, welcome back to another episode of Javis JavaScript Chamber.
Speaker 1: I am let me try that again. I am so sorry,
Speaker 1: I am so I don't know anyway, Hey folks, welcome
Speaker 1: back to another episode of the Ruby Rogues podcast. This week,
Speaker 1: on our panel, we have a Yoshinatya.
Speaker 2: Hello.
Speaker 1: Hello, I'm Charles Maxwood from top Endevs Ruby Geniuses dot Com.
Speaker 1: We have a special guest this week that is Steven Margheim. Stephen,
Speaker 1: welcome back.
Speaker 3: Yes, thank you for having me again.
Speaker 1: Yeah, we had you on I need to go look
Speaker 1: exactly when, but we had John. We talked about sequel
Speaker 1: Light last time, and I think it was mostly a
Speaker 1: can you really do all this stuff in sequel Light?
Speaker 1: And the answer was pretty much yeah. So yeah. Is
Speaker 1: there anything else that you want to bring up as
Speaker 1: far as an introduction before we dive in and start
Speaker 1: talking about more even more sequel Light awesomeness.
Speaker 3: No, not much. I'm happy to be back here, just
Speaker 3: braving the cold dark Berlin Winters. So happy to have
Speaker 3: the opportunity to chat with some other Ruby and Rails
Speaker 3: enthusiasts and hopefully maybe by the end of this talk
Speaker 3: convert you into Sequelight enthusiasts as well. Let's see awesome.
Speaker 1: So yeah, let me get the link into the comments
Speaker 1: for the videos. But yeah, we talked quite a bit
Speaker 1: about sequel Light last time. Are there any new developments
Speaker 1: as things go along with sequel Light or.
Speaker 3: Yeah, so there's there's been a one major development. So
Speaker 3: if I were to summarize the conversation last time, it
Speaker 3: would be can we really do this with SQLite in
Speaker 3: a web application built with Rails, And the answer is yes,
Speaker 3: but you need to finesse it. And the big change
Speaker 3: which is really exciting is that the release of Rails
Speaker 3: eight marks the first time that Rails and as far
Speaker 3: as I'm aware, any major web application framework has provided
Speaker 3: a fully production ready experience for a server driven web
Speaker 3: application backed entirely by seqlight. You can drive your cash
Speaker 3: through sqlight, your background jobs through sqlit, your web socket
Speaker 3: messages obviously your primary data, and you don't have to
Speaker 3: fiddle with any configuration. You don't have to fut's about
Speaker 3: with any setup or installation. You get a no compromises,
Speaker 3: high performance but incredibly lean, mean and stable application. When
Speaker 3: you run Rails new like you literally can run Rails
Speaker 3: new and come all deploy and you won't have any
Speaker 3: business logic, so it might not be very useful. But
Speaker 3: the bones of that application are as sturdy and as
Speaker 3: simple as they have ever been in the two decade
Speaker 3: history of RAILS.
Speaker 1: That's awesome. I have to admit that a lot of
Speaker 1: the stuff that's in Rails eight that just kind of
Speaker 1: comes baked in. I am so excited about. On Friday,
Speaker 1: I was how do I put it? I did some
Speaker 1: therapeutic coding and anger, and I thought, Okay, I'm just
Speaker 1: going to pull together this apple. I mean, admittedly I
Speaker 1: use postcris QOL, but I literally, yeah, I did the
Speaker 1: exact steps you were talking about. Other than that, and yeah,
Speaker 1: I had to deploy an accessory on Camal for the database,
Speaker 1: but then I only had one other accessory to deploy,
Speaker 1: and that was my Rails app. I mean, that was it,
Speaker 1: and it's it's so refreshing to be able to do that.
Speaker 1: And then I was looking at search and I was thinking,
Speaker 1: so I have to do elastic search, and it turns
Speaker 1: out that I am figuring out how to do the
Speaker 1: vector search in postgress. So even that's awesome. And I
Speaker 1: think there's a vector extension for sqlight isn't there. So
Speaker 1: there is I mean, it's it's I mean, this is
Speaker 1: the beautiful thing, right and so if you want to
Speaker 1: deploy it and make it run and all of that stuff,
Speaker 1: you definitely can. I have a question just to throw
Speaker 1: that out there. You said you can just do the
Speaker 1: camal deploy. Do you set up an accessory for sql
Speaker 1: I or do you just store it on a volume
Speaker 1: so that when you kill and restart your dock or
Speaker 1: it just connects to the same sequel light file.
Speaker 3: The latter.
Speaker 1: That's awesome, so then you only need one container, Yes, exactly.
Speaker 2: That's the cleost thought about sequel lighter thing is it's
Speaker 2: literally just a file. You're literally reading a file. I
Speaker 2: love that.
Speaker 3: Yep.
Speaker 2: Just a quick question about like the changes from RAEL
Speaker 2: seven to eight which kind of made a sequel light
Speaker 2: production ready. One thing that I know is something called
Speaker 2: a busy handler that was I think baked into the
Speaker 2: connection now and there's a couple other bits above that
Speaker 2: I remember reading a long blog push from music. Could
Speaker 2: you just summarize what are the changes from sys RAEL
Speaker 2: seven two to eight that now make sequel light production
Speaker 2: ready That wasn't the case earlier.
Speaker 3: Yeah, so there are two foundational changes that take rails
Speaker 3: from being You can sort of use it, but you
Speaker 3: need to work around some pain points to it works
Speaker 3: out of the box. So the first one concerns how
Speaker 3: sequalites transaction management system works in the context of a
Speaker 3: multi threaded web application. So I'm going to try to
Speaker 3: do this as succinctly as possible. But the default way
Speaker 3: that seqalite works with transactions, it calls working with deferred transactions.
Speaker 3: So to give one piece of context, seqalite only allows
Speaker 3: one writer to be doing a right operation at a time,
Speaker 3: so it has linear rights. Now, you can open up
Speaker 3: multiple connections to the database, and you can have connections
Speaker 3: reading in parallel, like that's totally fine. You can have
Speaker 3: five connections and they're all doing red and they can
Speaker 3: just do that at the same time. But if you
Speaker 3: have five connections open and they all try to write,
Speaker 3: have to line up and go one at a time.
Speaker 3: And when you use a transaction, the default behavior so
Speaker 3: if you just write begin transaction, some seql commands and
Speaker 3: then commit seql light doesn't attempt to acquire the right lock.
Speaker 3: This is the way in which it figures out which
Speaker 3: connection is able to write, like there's a lock, and
Speaker 3: each connection has to pass it around, so it doesn't
Speaker 3: attempt to acquire the right lock until it sees a
Speaker 3: right operation inside of your transaction. So if you do
Speaker 3: begin transactions select star, select star, update set from select,
Speaker 3: at that third operation, it will say, okay, let me
Speaker 3: try to acquire the right lock. And the problem that
Speaker 3: you hit and this is where anybody who tried to
Speaker 3: use seqalite in a Rail's application before Rails eight saw
Speaker 3: this error in their logs database is locked. You know,
Speaker 3: you got that error all the time, and that error
Speaker 3: was happening so often because when you begin the transaction,
Speaker 3: that is when seqalite takes a snapshot of your database
Speaker 3: to use for that transaction right to keep the isolation guaranteed.
Speaker 3: And so when you have a right operation inside of
Speaker 3: that transaction in order to ensure that isolation guarantee right
Speaker 3: for our acidic guarantees of this relational database, Sequalite does
Speaker 3: not allow that attempt to acquire the right lock to retry.
Speaker 3: So you get one shot. If the right block is
Speaker 3: being held by another connection, you immediately error. And so
Speaker 3: when you have a multi threaded web and you have
Speaker 3: many rights, there's no retry mechanism. It's like you either
Speaker 3: are able it's the lock is free and you can
Speaker 3: grab it, or it isn't and you error. And so
Speaker 3: the first change was to ensure that when RAILS generates
Speaker 3: transactions forceqlight, it explicitly makes them what seqlight calls immediate transactions.
Speaker 3: And all that that means is that you attempt to
Speaker 3: acquire the right lock at the begin transaction statement, not
Speaker 3: at the update statement. And the begin transaction statement is
Speaker 3: when you capture the snap shot, and so if the
Speaker 3: lock is being held, then we retry the begin transaction.
Speaker 3: So we retry taking a snap shot, and it's not
Speaker 3: until we can acquire the right lock for that particular
Speaker 3: connection that we begin the transaction. And then we have
Speaker 3: the right lock for the entire of the transaction, everything
Speaker 3: will be fine and we pass it along. So that
Speaker 3: immediately solved the major problem of just like getting a
Speaker 3: ton of databases locked aerrors by allowing our connection pool
Speaker 3: to deal with transactions. The second problem crept up thereafter,
Speaker 3: which is okay, now when you are retrying, so retries
Speaker 3: are happening at the sequlite level, and they're happening often
Speaker 3: in our multi threaded rails application with decent right tripe
Speaker 3: right through. But how does seqalite retry stuff? And it
Speaker 3: uses a very simple mechanism. Connection A has the right
Speaker 3: lock connection B attempts to acquire it can't seql. It says, okay,
Speaker 3: just sleep for one millisecond and then try again. So
Speaker 3: it sleeps one millisecond, tries again. It's still being held
Speaker 3: by A. So B is told sleep for two millisec
Speaker 3: and try again. And it has a kind of polynomial
Speaker 3: back off.
Speaker 1: It sounds like my kid's dad, Yeah, Dad, Dad.
Speaker 2: Are we there yet? Are we there yet? Are we
Speaker 2: there yet?
Speaker 1: And then they sit there and listen for a second. No,
Speaker 1: he's in there, dad, Right, that's the backup exactly.
Speaker 3: And this is simple and it works incredibly well, right,
Speaker 3: Like you can serialize concurrent operations like without the application
Speaker 3: needing to do any custom logic. That's great, right. The
Speaker 3: problem that's when I eventually go what yeah, exactly. The
Speaker 3: problem came from how Ruby and sequelite work together. Because
Speaker 3: the magic and the beauty of sequlite is that it
Speaker 3: is an embedded database. It's not a client server database,
Speaker 3: and this means that it runs inside of your application process.
Speaker 3: You don't spin up a Sequalite process that's running next
Speaker 3: to your Rails server process. It is code that's executed
Speaker 3: inside of that process. And what that meant for Rails
Speaker 3: or Ruby more generally is that, by default the way
Speaker 3: that Ruby is integrating with Sequalite, the Ruby interpreter did
Speaker 3: not see sequel lighte connection sleeping as io that it
Speaker 3: can release the GVL on. So the GVL gets retained
Speaker 3: as Seqlite retries. And so what that meant was if
Speaker 3: you spin up ten Puma workers and one Puma worker
Speaker 3: acquires the right lock and it's doing a little bit
Speaker 3: of longer running work, another Puma worker could and should
Speaker 3: theoretically be able to do Ruby work while Sequalite is
Speaker 3: doing Seqlite work, but they weren't able to coordinate correctly.
Speaker 3: So this is the busy handler thing. So what we did, I'm.
Speaker 1: Just going to back up for a second because you
Speaker 1: mentioned the GVL, yeah, which is something that we've talked
Speaker 1: about at length on this show before, but not for
Speaker 1: quite a while. So the gvl's the global vmlock and
Speaker 1: it says essentially, hey, I've got this thread that's trying
Speaker 1: to do a thing, and what Ruby does is when
Speaker 1: it's doing IO. Right, So if it's sending off to
Speaker 1: the network and waiting for a response or talking to
Speaker 1: the database and waiting for a response, what it does
Speaker 1: is it releases the GVL and lets something else, another
Speaker 1: thread pick things up and work. And so what Steven's
Speaker 1: talking about is essentially Ruby didn't detect this as IO
Speaker 1: is what he said, which meant that it wouldn't release
Speaker 1: the GVL. In other words, it's going to sit there
Speaker 1: and it's just go, I'm still waiting instead of you know,
Speaker 1: letting another thread pick up work and go do work.
Speaker 1: Because if it's not doing iowork that it has to
Speaker 1: wait for, then it can do other things, right. It
Speaker 1: can calculate stuff or you know, sort your raise or whatever,
Speaker 1: right because that all happens in the VM. And so yeah,
Speaker 1: so what Stephen's talking about is you would have things
Speaker 1: essentially just hang there until they got an answer.
Speaker 3: Yeah, and this is particularly important for typical rails applications
Speaker 3: because your typical rails application is using Puma. Puma's going
Speaker 3: to spin up a number of worker threads. Let's just
Speaker 3: say it's ten. And the way that it is expected
Speaker 3: to work is that you are increasing your throughput by
Speaker 3: having high saturated concurrent work. So one Ruby thread can
Speaker 3: take an incoming HTTP request and do Ruby work to
Speaker 3: like parse the stream like get a sense, let me
Speaker 3: get the rails request object, and then it makes a
Speaker 3: call to the database. It's like okay, now that worker
Speaker 3: is going to wait for the database. So the next
Speaker 3: worker over can start and pick up the next request,
Speaker 3: and so your CPU can be doing work constantly. We
Speaker 3: can really saturate our resources, take advantage of all of
Speaker 3: our cores, and do high through put work by really
Speaker 3: leaning into concurrency. That's like essential to how Puma is performant.
Speaker 3: And you could imagine that if talking to your database
Speaker 3: did not give the opportunity to your other Puma workers
Speaker 3: to do the other parts of the web request processing,
Speaker 3: you have ten workers, but effectively you have one, Like
Speaker 3: you have removed the advantages of the concurrency. And so
Speaker 3: what we needed to do was instead of using sqlightes
Speaker 3: built in mechanism for retrying, we wrote they expose a
Speaker 3: lower level API to write your own and then that
Speaker 3: allows us to write our own in Ruby. And so
Speaker 3: instead of calling the OS level sleep, we're calling Ruby sleep,
Speaker 3: and Ruby sleep does properly communicate to the interpreter, Hey,
Speaker 3: I am just sleeping. That is IO, you can release
Speaker 3: the GVL. And the third related thing, just to finish
Speaker 3: off the triad is when we were doing that rewrite
Speaker 3: and writing it a Ruby, I was doing benchmarking and
Speaker 3: I saw that sequelights implementation had a sort of subtle
Speaker 3: nasty side effect that I call punishing older queries or
Speaker 3: older connections, where because it was a polynomial back off
Speaker 3: what that and it's just like telling you don't ask
Speaker 3: me again for another five seconds. If you had high
Speaker 3: right throughput, once a connection needed to retry two or
Speaker 3: three times, so now it's waiting five milliseconds and then
Speaker 3: ten milliseconds. New connections have a much higher likelihood of
Speaker 3: acquiring the lock because they will retry more immediately and
Speaker 3: then one millisecond than too, so they get to try
Speaker 3: four times before my older connection even checks in again.
Speaker 3: And so if I have a steady stream of new connections,
Speaker 3: that old connection will go from the fourth generation to
Speaker 3: the fifth to the sixth, and it'll you'll always have
Speaker 3: one which goes until it errs out. And so you're
Speaker 3: like P ninety nine will have like these big spikes
Speaker 3: because you'll have like one connection that just never acquires.
Speaker 3: So we also rewrote the logic to just have every
Speaker 3: connection every time check in every millisecond, so there's no
Speaker 3: penalty for being quote unquote older having more retries as
Speaker 3: compared to younger having fewer retries. And this flattened out
Speaker 3: the latency that we saw well at like P ninety
Speaker 3: nine and P ninety five. So those three fixes are
Speaker 3: the major changes in the Rail's eight release that make
Speaker 3: rails production ready out of the box. You're not going
Speaker 3: to get these database lock airs, You're not going to
Speaker 3: see these latency spikes in your P ninety five or
Speaker 3: your P ninety nine statistics. You're going to get a
Speaker 3: high performance, stable experience by running rails new.
Speaker 1: Awesome. So I have another question. I seem to remember
Speaker 1: seeing somewhere that you were fairly involved in a lot
Speaker 1: of this. So when sequel light exposed the lower level thing,
Speaker 1: what was that for rails, Like, did you or David
Speaker 1: or somebody else go and actually talk to him and say, hey,
Speaker 1: we have this problem, can you let us do this
Speaker 1: other thing? Or was that something was already there?
Speaker 3: That was something that was already there. This is one
Speaker 3: of the things I have come to really appreciate about Syqalite.
Speaker 3: You know, it's thirty years old at this point, and
Speaker 3: it's used everywhere, and so it really is today like
Speaker 3: very feature rich and very powerful. The big difference that
Speaker 3: trips people up, because it's quite uncommon in our modern
Speaker 3: software culture, is that Sequelite cares far more about backwards
Speaker 3: compatibility than it does about enabling newer, better defaults and features.
Speaker 3: And so what that means is that if you don't
Speaker 3: do anything, if you don't do any configuration or any tuning,
Speaker 3: when you are using Seqlite today, you are effectively using
Speaker 3: Sequlite as it existed in two thousand four, which is
Speaker 3: when version three was released. And so these myths and
Speaker 3: sort of fears that have grown up in the web
Speaker 3: development community like seqlite is not a production of any database,
Speaker 3: have a root in reality, because in two thousand and six,
Speaker 3: seqlit was not a good database for web applications. It
Speaker 3: was squarely built for embedded devices and that context. Over
Speaker 3: the last two decades, a lot of features and a
Speaker 3: lot of work has been done to make it a
Speaker 3: far more flexible and powerful database engine, but literally none
Speaker 3: of those features are enabled by default, you have to
Speaker 3: manually configure seqlite to be properly run in a web application.
Speaker 3: This is the other big thing that rails does. We
Speaker 3: started doing this in rail step two. But it has
Speaker 3: a set of six or eight configurations that it applies
Speaker 3: to every connection you make so that it ensures that
Speaker 3: seqalite is running in a web application friendly mode. So
Speaker 3: this is just one of many features that seqalite has
Speaker 3: had sort of added over the last two decades that
Speaker 3: you can take advantage of to make seqallite run really
Speaker 3: well in the context of a multi threaded web application.
Speaker 3: But you have to do the work to figure out
Speaker 3: how you need seqlite to behave for your context.
Speaker 1: It's interesting that.
Speaker 2: You summarize the connection parameters. Is that going down a
Speaker 2: depravat hold the configuration stuff.
Speaker 3: I can summarize the key points. So the first most
Speaker 3: important one is that the original implementation of sequalite's journal mode,
Speaker 3: so the way in which it deals with stashing data
Speaker 3: to keep durability guarantees, was limited in that it required
Speaker 3: any operation to be linear, so reads and writes both
Speaker 3: contended with each other, so you could only do one
Speaker 3: thing at a time, so you could open multiple connections,
Speaker 3: but it's kind of useless. You were single threaded quote
Speaker 3: unquote at the point of view ofc QUAD. Over the years,
Speaker 3: they added a new journaling mode, right aheadlogging, which is
Speaker 3: the same sort of algorithm that postgress uses, which allows
Speaker 3: for concurrent reads. So that's like major change number one.
Speaker 3: You need to be in right a headlogging mode. When
Speaker 3: you use rite a headlogging mode, you have a much
Speaker 3: naturally safer environment, and so if you don't care about
Speaker 3: like the absolute strictest durability constraints, you can flush to
Speaker 3: disk often and get much faster performance. So the other default,
Speaker 3: like by default sequelite after every right flushes to disk,
Speaker 3: so you're doing the file system calls on every right,
Speaker 3: which adds a lot of overhead. So RAILS also defaults
Speaker 3: to flushing to disk less often, which is encouraged when
Speaker 3: you're using right ahead logging, so you get better performance.
Speaker 3: It also expands the default size of the in memory
Speaker 3: portion sort of space that sqlight uses. This is another
Speaker 3: misconception people have right like, every database is working with
Speaker 3: data on disc, like that's how we get durability for
Speaker 3: the ACID guarantee. But no database exclusively uses data on disc.
Speaker 3: Every database generates a pool of memory. It's like, here's
Speaker 3: a memory space I'm going to use, and they keep
Speaker 3: all of the hot data in that pool of memory
Speaker 3: such that they can just read and write directly in memory.
Speaker 3: Sequalite does the same, and you can control how big
Speaker 3: that space is. And it's default from you know, ten
Speaker 3: years ago is paltry compared to the memory that modern
Speaker 3: machines have, so we bumped that up. So for a
Speaker 3: lot of databases, you can actually like run your entire
Speaker 3: database effectively in memory like you have. There's literally no
Speaker 3: way any database can beat the speed of Sequelite in
Speaker 3: that context. That's actually what the guys Waprus found. They
Speaker 3: poorted their client from using reddis to Sequelite. He messaged
Speaker 3: me at one point He's like, Hey, I think I'm
Speaker 3: doing something wrong because I ran these benchmarks and it's
Speaker 3: actually faster with Sequelite and we're switched to Sequlite because
Speaker 3: we need like richer query language and we just knew
Speaker 3: we were going to pay that with slower speeds, but
Speaker 3: somehow it's faster. What am I doing wrong in my benchmarks?
Speaker 3: And we dug into it, it's like, no, your whole
Speaker 3: data fits in memory, so Seqallite is a more expressive
Speaker 3: and be faster than reddish in this case. And then
Speaker 3: we do a few other like small little bits and bobs.
Speaker 3: I have a whole blog post on my on my
Speaker 3: blog that breaks down all of the different settings with
Speaker 3: links to the documentation and explanations. Just the last one
Speaker 3: out I'll flag here Rails has been doing this forever,
Speaker 3: though you have to manually. By default, Sequalite does not
Speaker 3: enforce foreign keys, so like do you. Originally when it
Speaker 3: was built, poor and key constraints were just like you know,
Speaker 3: just sugar. The engine didn't do anything with them. They
Speaker 3: added that feature later for backwards compatibility. It's not added
Speaker 3: by defaults, so you have to explicitly say sequel Ie,
Speaker 3: please enforce my foreign keys.
Speaker 2: Interesting with the title of the blog post that you're
Speaker 2: referred to.
Speaker 3: Let me look up the exact title. So my blog
Speaker 3: is at fractalmind dot get habio and I have a
Speaker 3: little search up at the top. So I'm going to
Speaker 3: search for pragmas which is the name. I think it's
Speaker 3: called fine Fine tuning your database.
Speaker 2: Cool, I can see it now. I shall dive into
Speaker 2: that later.
Speaker 1: Yeah, I need to.
Speaker 3: I want to.
Speaker 1: I just want to capture it too so that we
Speaker 1: can put it into the show notes.
Speaker 2: And so let's move on to something a bit more real,
Speaker 2: specifics of a solid trifecta, which I am quite excited
Speaker 2: about because it's like more stuff big into reels rather
Speaker 2: than reaching for third party dependencies. It was obviously kind
Speaker 2: of conceptualized with sequel in mind, which is awesome, but
Speaker 2: there's still quite a lot of postgress out there in
Speaker 2: the world. So my question is, how, like, when you
Speaker 2: think about web applications, how differently do you have to
Speaker 2: think when you're using sequel light and if you're using
Speaker 2: the solid trifector with postgress, are there any things you
Speaker 2: really need to be aware of? Because instantly things like
Speaker 2: solid cable where you're kind of pulling for messages, it's
Speaker 2: making my spidery sense tingle that this is less efficient
Speaker 2: than reddest But is that a misconception when it comes
Speaker 2: to postcast because in sequel light, I know you can
Speaker 2: pull that much. I'll be fine.
Speaker 3: Yeah, So there are differences. The short answer is yes,
Speaker 3: Like I think that your your spider sense there is
Speaker 3: is onto something right. So let's let's start with with
Speaker 3: action cable. So Rails has had a postcress specific action
Speaker 3: cable adapter for a while now, and that adapter uses
Speaker 3: Postgress is in built listen notify functionality, which is faster,
Speaker 3: it's more performance, it will scale more naturally as your
Speaker 3: throughput increases, but it does come with a trade off
Speaker 3: of like a maximum message size of I think like
Speaker 3: eight kilobytes. There's a gem that expands that that max size.
Speaker 3: And if I were using postgress and I wanted to
Speaker 3: keep everything simple, like not bring in Redish just for
Speaker 3: that use, I would one hundred percent use the action
Speaker 3: cable postgress adapter and not solid cable that is better
Speaker 3: tuned to that architecture. Now, if I'm all in on
Speaker 3: my SQL already and I don't want to bring in
Speaker 3: the reddest dependency just yet, and I know that I
Speaker 3: don't have like a ton of web socket traffic right
Speaker 3: like I'm just doing a few basic things pushing down
Speaker 3: alerts when background jobs finishes, and it's like I only
Speaker 3: got six background of stuff. Like It's going to be
Speaker 3: totally fine, but you should go into it being aware
Speaker 3: that you are going to have some different pain points,
Speaker 3: the biggest one being that, of course when you're dealing
Speaker 3: with the client server architecture, your primary bottleneck is the
Speaker 3: network latency. Like every database is fast, really fast, Like
Speaker 3: databases are really magical pieces of technology.
Speaker 1: I want to just interject, So not twenty twenty four,
Speaker 1: but twenty twenty three when David or DHH gave his
Speaker 1: keynote talk, he talked a lot about why the databases
Speaker 1: are fast or and how the disks have gotten faster.
Speaker 1: And you know, you were talking about memory capacity. That's
Speaker 1: another thing that's expanded, and you've alluded to that. So
Speaker 1: I love all of the allusions to you know, modern
Speaker 1: computing and just what the capabilities are. But anyway, go ahead.
Speaker 3: Yeah, And so you are penalized in a client server
Speaker 3: architecture for making a large number of small queries. And
Speaker 3: this is one of the biggest mindset shifts you need
Speaker 3: to make if you want to embrace sequlite, because it's
Speaker 3: really deep in rails developers like limpic system, Right, I
Speaker 3: want to prefer a small number of large queries, but
Speaker 3: when you're working with SQL, you actually want to flip that.
Speaker 3: You are going to get a better performance profile by
Speaker 3: having a large number of small queries. And so that's
Speaker 3: like one consideration. And so if we think about something
Speaker 3: like action cable, the nature of action cable is like
Speaker 3: it's you can't aggregate those queries, right, Like if you're
Speaker 3: just doing the polling, you're just making that get well,
Speaker 3: I'm using an HTTP verb there, but you know we're
Speaker 3: making that reade. Yeah, and you have to eat the
Speaker 3: network latency. You just have to. So for something like
Speaker 3: a solid cable, it's really well tuned to seqlite. The
Speaker 3: way that seqlite is built and the fact that we
Speaker 3: isolated in a separate database like means you don't even
Speaker 3: have to worry about concurrency. Of course, if base Camp
Speaker 3: were to use this like, they would experience very real
Speaker 3: pain because now polling for action cable messages is contending
Speaker 3: with serving all of their other application database needs. Right.
Speaker 3: So if they just use a single big bee feed
Speaker 3: my sql in since and they're doing all of their
Speaker 3: application reading and writing as well as this website of
Speaker 3: pulling like now their connection pool, the resources of that
Speaker 3: instance are all like being used up for both of
Speaker 3: these use cases. And so you do need to be
Speaker 3: more thoughtful, especially if you're unsure about how your usage
Speaker 3: might scale over time. If you're using something like postgress
Speaker 3: in my squel especially around actually cable for something like
Speaker 3: the cash. I actually think that there are real advantages
Speaker 3: to using a database back cash, regardless of the database
Speaker 3: engine you are using. At the scale of base Camp.
Speaker 3: They through experience and they talk about this in their
Speaker 3: Raales World talks from last year introducing solid cash. Came
Speaker 3: to see, Yeah, that contention is too high, So they
Speaker 3: split out separate my SQL database for their cash, and
Speaker 3: that I think is going to be the case at
Speaker 3: really sort of ity decent size for your cash. But
Speaker 3: the point that they make, which is like when you
Speaker 3: just massively expand the size of your cash, I can
Speaker 3: just keep way more things in the cash, and I
Speaker 3: can keep them in the cash for longer. Then your
Speaker 3: cash becomes more useful because you just have more hits. Naturally,
Speaker 3: you just there's more things to hit against, and that's
Speaker 3: what the database offers you. And because of modern computing,
Speaker 3: because like the file systems are faster, the RAM is faster,
Speaker 3: the networks are faster, the difference that you have between
Speaker 3: even some of your cash hits, like needing to go
Speaker 3: to disc to fetch the data to send it back,
Speaker 3: is much smaller than it used to be, So I
Speaker 3: would recommend looking at solid cash for any application, regardless
Speaker 3: of the database engineer using for solid q. If you
Speaker 3: are all in on postgress. This is another case where honestly,
Speaker 3: probably good job is a better fit, like it's explicitly
Speaker 3: tuned to postgress and using its features. The really nice
Speaker 3: thing that makes solid q quite competitive is that just
Speaker 3: it has more useful features out of the box, like
Speaker 3: recurring jobs. That's just that they are, and they have
Speaker 3: done a ton of work to make it super performant
Speaker 3: on postgress in my SQEL. Obviously, base Camp and thirty
Speaker 3: seven Signals use my SQL, and they are using solid
Speaker 3: q in production doing like tens of millions of jobs,
Speaker 3: so it's totally production ready at really large skills as well.
Speaker 3: So I would also feel very comfortable using solid q
Speaker 3: with my SQEL or postgress at larger use cases. But
Speaker 3: in general, all three of these gems, like lean on
Speaker 3: pulling and sequel, it's just the best sort of perfect
Speaker 3: fit if you want to use a database engine and
Speaker 3: you just want to pull all the time, because those
Speaker 3: reads are effectively free, I mean, they're so fast and
Speaker 3: there's really no contention or penalty, So it's it's like, yeah,
Speaker 3: just pull all the time, like you basically have real time.
Speaker 3: There's not a ton of complexity and there's not really
Speaker 3: a ton of trade offs.
Speaker 1: So one thing that I'm wondering then, is because I
Speaker 1: just switched over to solid que and it has a
Speaker 1: plug in that like you fire up Puma and it
Speaker 1: runs all your So everything just runs on the same
Speaker 1: server essentially, right, you just tell it run the server
Speaker 1: and runs the server. It's the workers and it does everything.
Speaker 1: So what you're telling me is is if I'm still
Speaker 1: really in love with PostgreSQL, I can do that for
Speaker 1: all of my I guess primary level data, and then
Speaker 1: for the queue and the cash and the cable stuff,
Speaker 1: I can still use squeal light and just avoid all
Speaker 1: of that network latency on these tiny polling queries. Is
Speaker 1: that what I'm hearing?
Speaker 3: Yeah, So the if you just run rails new with defaults,
Speaker 3: you're going to get seqlite everything. You're going to get
Speaker 3: all the solid gems. And the way that it will
Speaker 3: be structured is that Rails will create four different database files.
Speaker 3: It'll create a we'll just talk about development. A development
Speaker 3: that's sqlight three, A cash, A queue, and a cable
Speaker 3: that sqlight three.
Speaker 1: So yeah, four different I find that I was using
Speaker 1: Postgress and it's still created the other three with SQLite,
Speaker 1: I believe.
Speaker 3: Yeah, that might be true. I honestly haven't spent a
Speaker 3: ton of time initializing rails applications with anything about postpress
Speaker 3: those details as well. But so what that means is
Speaker 3: that a so SQA has this constraint of linear rights.
Speaker 3: That constraint is at the file level, So you can
Speaker 3: right to your primary database, add a job to the queue,
Speaker 3: add a message to the backlog for cable messages, and
Speaker 3: add a cash entry in parallel. You can do all
Speaker 3: four of those operations at exactly the same time, so
Speaker 3: there's no contention across the different services. And all three
Speaker 3: of those additional services will run directly inside of PUMA
Speaker 3: if they need a separate process, like solid q does,
Speaker 3: and so you don't have to set anything up and
Speaker 3: you don't need anything more than that one single machine.
Speaker 3: So like I build and deploy my applications on hatchbox
Speaker 3: on a single Digital Ocean droplet, and I have. I
Speaker 3: had the big first app that I really went all
Speaker 3: in on seqy with and led to a lot of
Speaker 3: these additions to rails. It's still running in production and
Speaker 3: it is on a twenty dollars a month droplet, and
Speaker 3: that app has made multiple millions of dollars in revenue
Speaker 3: in the last four years. It's it's it's really kind
Speaker 3: of beautiful how cheap you can run these applications like this,
Speaker 3: Like this is a targeted B to B application that
Speaker 3: just isn't going to have ever more than a thousand
Speaker 3: concurrent users. And so I just I don't need a
Speaker 3: huge box. I don't need to run a whole bunch
Speaker 3: of things. I can. I was a single dev I
Speaker 3: built it and maintained it for years. It was super straightforward, lean,
Speaker 3: easy to operate, easy to deploy, easy to evolve, super
Speaker 3: fast for those kinds of applications. So I think, like
Speaker 3: particularly B to B applications are like a great fit.
Speaker 3: Like you have a certain kind you typically have a
Speaker 3: sort of geographic boundary, right, Like you're building a business
Speaker 3: in the UK, You're mostly going to have UK customers.
Speaker 3: You're building a business in Europe, you'll mostly of European customers.
Speaker 3: You're building a business in the US, you'll mostly of
Speaker 3: US customers. You're going totally virally successful. It means like
Speaker 3: maybe you have ten thousand customers, right, Like, it's just
Speaker 3: totally different than trying to build the next TikTok. SQL
Speaker 3: Light and vertical scaling are such high leverage decisions for
Speaker 3: those kinds of businesses. You can operate your business so
Speaker 3: efficiently and add so many high power features to your
Speaker 3: application so quickly and so cheaply. That's where I get like,
Speaker 3: particularly passionate. It's just like that more people appreciate that. Yeah, objectively,
Speaker 3: Postgress is a great database. I have nothing negative to
Speaker 3: say about it, but the idea that it is the
Speaker 3: only viable option for a database in twenty twenty five
Speaker 3: and production is objectively laughable. Sequelight, in my Sequel and
Speaker 3: Postgress are all really great databases that there are very
Speaker 3: legitimate use cases for in twenty twenty five.
Speaker 2: Yeah, that's quite a pitch, and I'm not surprised to
Speaker 2: yet that from you, But how passionately you've been kind
Speaker 2: of waving this flag for the last couple of years,
Speaker 2: and I'm giving sequel Light a go on a side
Speaker 2: project I've got just started looking forward to diving into that.
Speaker 2: How do you feel about the architecture that Chuck briefly
Speaker 2: mentioned by a primary database is Postgress, but you're using
Speaker 2: sequel Light for jobs and cashing and solid cable or whatever.
Speaker 2: How do you feel about that kind of architecture.
Speaker 3: I think that it makes sense and it can work,
Speaker 3: especially if you have an existing application and you want
Speaker 3: to start exploring some of these things. I think that
Speaker 3: solid cash driven by Sequelite is a really great place
Speaker 3: to start. Like, take an existing application, leave your Postgress Heroku,
Speaker 3: well not on Heroku. Sequel doesn't work on Heroku, so
Speaker 3: not on Heroku. If you're using Heroku, just hug Reticent
Speaker 3: Postgress and you'll be fine. But in a context where
Speaker 3: you're not using Heroku. Yeah, just like spin up a
Speaker 3: cash database with seqle it can get really huge, not
Speaker 3: can have any problems. There's zero need or reason to
Speaker 3: go all in on one immediately. It's totally fine to
Speaker 3: mix and match the For me, one of the primary
Speaker 3: benefits of sqlit is the opportunity to have a maximally
Speaker 3: operationally simple application. So for me, I start all new
Speaker 3: applications going all in on sqlight because it's like I
Speaker 3: don't want to run two machines. I don't want to
Speaker 3: figure out how to secure and network two machines. I
Speaker 3: don't want to, Okay, I'll just do one machine. And
Speaker 3: it's like, let me make sure I'm running the two processes.
Speaker 3: Let me make sure I'm doing that resiliently. Like what
Speaker 3: happens if my postcrest process goes down? How do I
Speaker 3: have my app process handle that gracefully? How I need
Speaker 3: to have another process running that watches the postcress process
Speaker 3: to bring it back up when it goes down. Like
Speaker 3: it just it gets a little bit out of hand
Speaker 3: rather quickly. But if you have an existing application, this
Speaker 3: is not in any way and all or nothing. I
Speaker 3: think cash is a great place to start. Cable can
Speaker 3: also be a good place to start, though, if you're
Speaker 3: already on postgress the action cable postgress adapters, I would
Speaker 3: start there. You still don't have to reach for rettis.
Speaker 3: But yeah, mixing and matching is one of the core
Speaker 3: philosophies of rails, right, This is O my case, at
Speaker 3: its best. So I do embrace it and encourage it,
Speaker 3: particularly for migrations. But I will beat the dead horse
Speaker 3: once again if you're starting something, if you're running rails new,
Speaker 3: like just give it one month, give it one month.
Speaker 3: Just try it for one month, That's all I ask.
Speaker 3: And if you say, you know what, I just really
Speaker 3: really love postgress, awesome, go use post But if Mordv's
Speaker 3: just tried, I think we would see a real change
Speaker 3: in the makeup of RAILS applications in production, because there
Speaker 3: are very real benefits for bootstrap businesses to lean on
Speaker 3: this technology.
Speaker 1: So I got a couple of questions here. One is
Speaker 1: is you've talked about some of the optimizations that you
Speaker 1: can use in postgress. You know, whether you're enforcing foreign
Speaker 1: keys or you know, some of the other pragmas that
Speaker 1: you can turn on to kind of tune your database.
Speaker 1: And it sounded like Rails does some of this for you. You
Speaker 1: can correct me if I'm wrong there, but I guess
Speaker 1: that's my question is do I effectively get all the
Speaker 1: goodies for free or do I have to go in
Speaker 1: and set up seqlight and or rails in a particular
Speaker 1: way to get any you know, to optimize for whatever
Speaker 1: I'm doing with it.
Speaker 3: You get all of the essential goodies for free for
Speaker 3: having a production ready experience on day one. All of
Speaker 3: that is by default. You don't have to touch anything. But
Speaker 3: like with most of Rails, you have levers available to you.
Speaker 3: So for example, there are dozens of sequel like pragmas.
Speaker 3: You can configure all kinds of things about seql Light
Speaker 3: runs the database EAMO file accept a pragma's key and
Speaker 3: you pass a nested hash and you can just set
Speaker 3: whatever pragmas you want in your database YAMO. So that's
Speaker 3: built into rails now. So you can add configuration. You
Speaker 3: can overwrite configuration. If you're like, hey, I've got I'm
Speaker 3: looking at my VPS, I know the services I'm running
Speaker 3: on it. I can commit way more memory to my
Speaker 3: squel database. I know I have four I know I'm
Speaker 3: going to do five connections each. I know I've got
Speaker 3: this much RAYM, I know all the other services. Like,
Speaker 3: let's give every single connection like one gig. I'm on
Speaker 3: a big beef server. Let's give them all one gig.
Speaker 3: Overwrite that I'm huge memory addresses for every connection. You
Speaker 3: can do that, but there is not a single required
Speaker 3: action that you need to take. You can literally run
Speaker 3: RAILS new and put it on a production server and
Speaker 3: everything will be good. So it's just just write your
Speaker 3: business logic. But you can do extra things. So you
Speaker 3: can also pull in. I have a jem to provide
Speaker 3: access to the SQLite extension ecosystem and make that easy
Speaker 3: to bring into your application. So you can bring in
Speaker 3: Squalite extensions like the vector search extension and integrate that
Speaker 3: into your application very easily doing backups. That's not something
Speaker 3: that is like a Rails default, but there is a
Speaker 3: gem to do that easily. So if you really like
Speaker 3: take it seriously, like if I was building a business,
Speaker 3: there are a few extra steps that I would take.
Speaker 3: But that's true of every Rails application right Like you,
Speaker 3: there's like the Rails plus subset of like gems that
Speaker 3: everyone turns to to really solidify an application for showtime.
Speaker 3: But the core fundamentals with Rails eight, every single essential
Speaker 3: detail is packaged into Rails New and requires no additional
Speaker 3: work to get a production ready experience.
Speaker 1: Makes sense. The other question I have is I'm just imagining.
Speaker 1: I'm trying to think through some of the apps that
Speaker 1: I'm either built or in building or things like that.
Speaker 1: I mean, one of them you mentioned that, I guess
Speaker 1: I'm worried about workload, right, and I know that we've
Speaker 1: talked in the past about hey, it can get you know,
Speaker 1: you can get pretty large workload. But let's say I
Speaker 1: do hit some kind of limitation, right, I don't know
Speaker 1: how likely that is, but let's say that I do
Speaker 1: hit some kind of limitation. So I want to shard
Speaker 1: my database, or you know, maybe I want to break
Speaker 1: it up by tenant because I'm doing a multi tenant
Speaker 1: database or something like that, or a multi tenant app.
Speaker 1: Like how hard is it to do that kind of
Speaker 1: a thing and how likely am I to even need
Speaker 1: to consider it?
Speaker 3: Yeah, I'm going to start with the second question first.
Speaker 3: So the team at thirty seven Signals did a lot
Speaker 3: of different load testing for the Campfire application, and the
Speaker 3: camp Fire application uses Squi for the primary database and
Speaker 3: reddis for all of the accessories. This is because they
Speaker 3: built it in reales seven one days and it's harder
Speaker 3: to all the sologems didn't exist and as various reasons,
Speaker 3: but I took that code base, swapped out all the
Speaker 3: reddis for SQL. I ran my own benchmarks, and like
Speaker 3: everything was at least as fast, if not faster in
Speaker 3: their benchmarking in a chat application using the primary chat
Speaker 3: sending messages and getting the responses back, so right, heavy, right,
Speaker 3: not like a typical eighty twenty read write when they
Speaker 3: got the when they benchmark their beefiest server. In their benchmark,
Speaker 3: you can go and find their posts to get the
Speaker 3: details of that machine. I don't recall at the top
Speaker 3: of my head. They supported fifty thousand concurrent chat participants. Wow,
Speaker 3: So imagine that's basically like a fifty to fifty read
Speaker 3: write split and that's fifty thousand. So you go eighty twenty,
Speaker 3: you can get to one hundred thousand concurrent users. I
Speaker 3: am one hundred percent confident and application can support one
Speaker 3: hundred thousand concurrent users on SQL eight. So just I
Speaker 3: want to be very clear about like where the limit is,
Speaker 3: because like I know, I understand it. I have the
Speaker 3: impulse too. I had the impulse for a long time.
Speaker 3: It's like, ah, like maybe just maybe I'm building the
Speaker 3: next Facebook, you know, and then what am I going
Speaker 3: to do if I have like a billion users? It's like, okay, yes,
Speaker 3: but I promise you you aren't, Like I can mathematically
Speaker 3: guarantee you you're not going to win the lottery and
Speaker 3: you're not building the next Facebook. And the odds of
Speaker 3: your application having one hundred thousand concurrent users is astronomical.
Speaker 3: So just that's step one to really state very clearly
Speaker 3: you aren't going to hit a performance limit. You won't.
Speaker 3: Now that being said, let's imagine you did accidentally build
Speaker 3: the next Facebook on top of a sequel add on
Speaker 3: rails application. I'm welcome to you do. Then well, I
Speaker 3: think that sharting is indeed like the natural place to go.
Speaker 3: And if you will permit me a bit of gentle teasing,
Speaker 3: I happen to know that there is a project underway
Speaker 3: right now that will make the sequelite sharting story much better.
Speaker 3: Right now, it would be a fair bit of manual
Speaker 3: futzing about to get it set up right, and at
Speaker 3: some point in twenty twenty five this project will be
Speaker 3: released and it will be way simpler. So as long
Speaker 3: as you don't become the next Facebook, as long as
Speaker 3: you don't have more than one hundred thousand concurrent users
Speaker 3: in an eighty twenty read write crowd application before the
Speaker 3: end of twenty twenty five, you have nothing to worry about,
Speaker 3: because it will become really straightforward to sharred to the
Speaker 3: level of giving every individual tenet of your application their
Speaker 3: own Seqlite database. So the sky really is the limit
Speaker 3: and by the end of twenty twenty five, I think
Speaker 3: there will basically be no performance problems aside from hitting
Speaker 3: the bottleneck of I have vertically scaled to the biggest
Speaker 3: possible machine that exists, and I still have too much traffic.
Speaker 3: Like I'm Facebook going from one billion to two billion
Speaker 3: people now, and now I need to horizontally shard my application.
Speaker 3: But there are a number of tools in that space.
Speaker 3: They're all necessarily younger than tools in the Postgress and
Speaker 3: my squel space, and that we're like built in that
Speaker 3: world from day one, but they do exist. They are
Speaker 3: getting more more battle tested each year, so there is
Speaker 3: a story available to you to horizontally shard. Whether that's
Speaker 3: using lib sql, which now has a Ruby adapter and
Speaker 3: an active record adapter, whether that is waiting for the
Speaker 3: Limbo project, which the Turso team, you know, they are
Speaker 3: basically rewriting sequalite in Rust with acinc built in from
Speaker 3: the ground up, waiting for that to fully come to maturity,
Speaker 3: whether it's using light fs to get console driven cluster
Speaker 3: multi node cluster management for seqoid databases. There are a
Speaker 3: number of tools here in this space, all sort of
Speaker 3: maturing at their own sort of pace. With their own communities.
Speaker 3: So there is a story to be told for horizontal
Speaker 3: sharding as well. So short summary of the answer, you
Speaker 3: aren't going to hit computational limits on the sequlite statistically,
Speaker 3: I can say that almost with a guarantee. If you did,
Speaker 3: there are paths available to you, whether that is sharding
Speaker 3: your database so that you can deal with more right
Speaker 3: throughput and you can get a BEEF server and the
Speaker 3: BF server will handle your users just fine. Or you
Speaker 3: go super nova and you have a million concurrent users
Speaker 3: and you start horizontally sharding your application and you pick
Speaker 3: up a tool like light a fasts and bring a
Speaker 3: distributed sequel architecture into the mix. There are tools and
Speaker 3: communities and solutions on all of these points that are
Speaker 3: present and open source and available to us all. So
Speaker 3: there really is not an actual ceiling.
Speaker 2: So one thing where I would still be a little reticent,
Speaker 2: and you can tell me if I'm wrong. And it's
Speaker 2: not necessarily for my own projects, because I completely get
Speaker 2: where you're coming from that I'm not going to be
Speaker 2: building the next Facebook. But if you're using sequel light,
Speaker 2: then I think I would I be right in saying
Speaker 2: that schedule downtime is something you kind of need to
Speaker 2: just accept if you're making big changes, because like hundred
Speaker 2: percent up time is not a thing, but if you
Speaker 2: need to be as close to that as you can
Speaker 2: possibly be, when you kind of need to do bluegreen
Speaker 2: de plost, bringing another sever up, making sure it's accepting requests,
Speaker 2: and then taking the old one down just to make
Speaker 2: sure you don't go down. That kind of system is
Speaker 2: not great for sequel light. Would I be right in
Speaker 2: saying that.
Speaker 3: A little bit? Not quite in the generic way that
Speaker 3: you said, but you're you're getting to a core point.
Speaker 3: So at the generic point, like I use hatchbox from
Speaker 3: all of my hatchbox uses the old Capistrano style deployment
Speaker 3: where you just add another directory to the releases directory
Speaker 3: and your rails server process is running and you just
Speaker 3: swap out the sibling and that one hundred percent works.
Speaker 3: Like I have zero downtime deployments. I've not you know,
Speaker 3: oh I'm deploying. I have to bring it down for
Speaker 3: five minutes. So that is totally fine. When you embrace
Speaker 3: vertical scaling. If your machine dies and you need to recover,
Speaker 3: then yeah, you have downtime because your machine went down
Speaker 3: and you need to recover. So it's not so much
Speaker 3: around deployment as it is around disaster recovery, where you
Speaker 3: will have downtime. But that's much more a factor of
Speaker 3: embracing vertical scaling than it is a factor of sequelite.
Speaker 1: Though.
Speaker 3: If you embrace equal, I recommend you embrace vertical scaling
Speaker 3: as well.
Speaker 1: When you say vertical scaling, you're saying you add memory
Speaker 1: ad disc Yeah, you on your application everything.
Speaker 3: They're getting a bigger bucks as you need it. Yeah, exactly.
Speaker 3: But on the deployment front, it is worth being explicit
Speaker 3: about the fact that if you have an old successful
Speaker 3: application with Sqli that has some very large tables and
Speaker 3: you make certain kinds of schema migrations to those tables,
Speaker 3: you're gonna have some pain because if you if your
Speaker 3: migration requires making rights, the migration rights contend with the
Speaker 3: application rights. Seql I only allows one right operation at
Speaker 3: a time, and the way that we typically write these migrations,
Speaker 3: they're very, very greedy, so they will tend to beat
Speaker 3: out your application rights, and so your application will suffer
Speaker 3: and very likely experience some form of downtime. So there
Speaker 3: are migration situations in which the simplest way to avoid
Speaker 3: any angry pain from customers is to do schedule downtime.
Speaker 3: But that that situation is doing rights against a very
Speaker 3: large table, and by very large, I mean like over
Speaker 3: a million rows let's say, which, of course it is
Speaker 3: not crazy to get to.
Speaker 1: But adding an index or calculating a value on a
Speaker 1: new column for every row.
Speaker 3: Yeah, so yeah, adding an index would be the most
Speaker 3: common one. Supplying like a new default value, backfilling data
Speaker 3: to a column that you added work like that, Yeah, exactly,
Speaker 3: So it's a little bit more nuanced. But it is
Speaker 3: true that vertical scaling means if you need five nines
Speaker 3: of uptime a you don't. I should start there, like,
Speaker 3: if you need five lines of uptime, you have been
Speaker 3: sold marketing from AWS. That is a lie. Literally, AWS
Speaker 3: is the only service that needs five mines of uptime,
Speaker 3: and they lie in order to keep it. So even
Speaker 3: AWS doesn't have five nines of uptime, it doesn't exist,
Speaker 3: so you don't really need it. But let's say you actually,
Speaker 3: like truly need three nines of uptime, if that is
Speaker 3: essential to your business, I would not recommend a vertical
Speaker 3: scaling approach. I would recommend going in the complete opposite
Speaker 3: direction and distributing your compute and your persistent data to
Speaker 3: the edge, and really recognizing like for you to be
Speaker 3: successful in your business, you're going to need to solve
Speaker 3: the distributed systems problem. I will make the note though,
Speaker 3: that seqlight is particularly good if you need to push
Speaker 3: compute and data to the edge. It's not going to
Speaker 3: help you any if you put one big postcress server
Speaker 3: in Virginia and you put ten application instances in every continent.
Speaker 3: In fact, it's going to kill you because you're going
Speaker 3: to make one HDTP. Your customers will make one HDTP
Speaker 3: request from their laptop to your service which is right
Speaker 3: next to them, and then your application will make probably
Speaker 3: on average, ten HTTP requests to your server for all
Speaker 3: the different queries. And it would have been much better
Speaker 3: for your customer to make one long network request to
Speaker 3: Virginia and then your application be right next to the
Speaker 3: database and do ten really short queries than the opposite
Speaker 3: way around. But if you're going to the edge, you
Speaker 3: have computational constraints, and it's really perfect actually to just
Speaker 3: have a file on disc And so just as one example,
Speaker 3: we can find the blog post and add it to
Speaker 3: the show notes. There was a company that's doing authentication
Speaker 3: as a service. They're called OsO and as a part
Speaker 3: of their business success, like A, we need three nines
Speaker 3: of uptime and B because our customers will be hitting
Speaker 3: our API for every one of their customers web requests,
Speaker 3: our P ninety five needs to be ten milliseconds. So
Speaker 3: how do we do that? Like, well, the only way
Speaker 3: that we do that is we put ten application instances
Speaker 3: around the globe, So we just have to do distributed service.
Speaker 3: So then the question becomes, well, how do we do that? Well,
Speaker 3: obviously I don't want to put one database in Virginia
Speaker 3: that'll destroy my There's no way I have a P
Speaker 3: ninety five to.
Speaker 1: Ten milli seconds. You can't make that round trip that fast, right.
Speaker 3: And you're going to make ten of them. So I
Speaker 3: have to put my data right next to my application.
Speaker 3: Now I'm going to have ten instances of my application.
Speaker 3: So what is going to allow me to have all
Speaker 3: of the sort of data access patterns I need from
Speaker 3: my application but will work in the constrained environment of
Speaker 3: the edge instances I'm using SQL? It will be great.
Speaker 3: So then how do I solve the problem of distributed Sequlite.
Speaker 3: They did a home grown solution, so they build on
Speaker 3: top of Kafka, and so they distribute the Sequelite data
Speaker 3: and get to eventual consistency across all of their instances
Speaker 3: through COFCA. So anyway, all that to say, I really
Speaker 3: think that the world is moving towards the edges and
Speaker 3: that the sanest thing to do moving forward is to
Speaker 3: either fully embrace vertical scaling, like I'm building a business
Speaker 3: in Germany for Germans, I don't need I just need
Speaker 3: the one server in Frankfort and it'll it's going to
Speaker 3: be great, or embracing the other extreme and saying like
Speaker 3: I'm building a global business, I'm going to have customers
Speaker 3: that are as valuable to me in Japan and in
Speaker 3: South Palo and so I just need a fully distributed thing.
Speaker 3: And I think that sequel I is fairly uniquely positioned
Speaker 3: with the set of trade offs and value propositions that
Speaker 3: it makes to be a really solid choice in those
Speaker 3: two extreme scenarios and post press in my sequel we're
Speaker 3: really well positioned for the middle case, where you're trying
Speaker 3: to have as much of both as you can. But
Speaker 3: my sense is that the world is moving away from
Speaker 3: the middle case and embracing the edges and the extremes
Speaker 3: is going to be likely a better business decision, and
Speaker 3: so really thinking about the kind of application you're building
Speaker 3: and what kind of architecture makes most sense. But seql
Speaker 3: I is kind of weirdly perfect at the extremes. Nice.
Speaker 2: I have one last burning question regarding database backups. And
Speaker 2: I know, if I remember correctly, the last time you
Speaker 2: were on the show, it was before my time, but
Speaker 2: I remember watching the video. I think you deleted a
Speaker 2: production seql light database by accident. If I recall correctly,
Speaker 2: I think with sequel Light it's easier to do that
Speaker 2: than with any other database system because it's just a
Speaker 2: file and you can quite easily delete it. I know,
Speaker 2: I know light stream is a thing. But let's say
Speaker 2: you're me and allergic to dependencies. Because I hate putting
Speaker 2: stuff in my gem file and I want to do
Speaker 2: I'm like, it's just a file. All I need to
Speaker 2: do is make copies of this file to do backups.
Speaker 2: I'm sure I can write something myself. What's the recommended
Speaker 2: way to do seql light background You just copy paste
Speaker 2: the file out or is there some kind of native thing.
Speaker 1: To do backups the fantom ability CP.
Speaker 3: Exactly. So I just I just provided a link here
Speaker 3: in our little chat. We can add it to the
Speaker 3: showtes as well. But one of the other great sequeled
Speaker 3: enthusiasts in the Ruby community old mo As. He goes
Speaker 3: by on Gethue. So he has a great blog post
Speaker 3: on different backup strategies for sequel I, and he he
Speaker 3: really covers them very thoroughly, but just to just to
Speaker 3: hit you with a few things. So sequel like comes
Speaker 3: with three different backup strategies you can call backup, you
Speaker 3: can call dump. These are slightly slightly different. They also
Speaker 3: have like the Seql command vacuum into. So he breaks
Speaker 3: down those differences. I won't reatrat of that right now,
Speaker 3: but indeed genuinely you can call CP. And one of
Speaker 3: the points he makes, which is I will reiterate here,
Speaker 3: is that most production Linux servers are running file systems
Speaker 3: that have copy on right functionality available, and so if
Speaker 3: you do CP with the opten ref link always you
Speaker 3: get actually like a really really fast, very very space
Speaker 3: efficient backup of your database. And then of course you
Speaker 3: do have something like light stream. So the benefit of
Speaker 3: light stream is that you can get really fine grained backup,
Speaker 3: so you get point in time recovery, but it does
Speaker 3: come at the cost of you have to pay for
Speaker 3: the S three compatible bucket stores service that you're going
Speaker 3: to use. Pay for that storage, you have to run
Speaker 3: another process. So if a light stream process to copy
Speaker 3: over the data. If you don't need like resolution to
Speaker 3: the second level for backups and you just want to
Speaker 3: set up a crime job, you absolutely can use one
Speaker 3: of the other four methods. And his blog post really
Speaker 3: breaks down the pros and cons, like which ones are
Speaker 3: more space efficient, which ones have faster restore performance, what's
Speaker 3: the complexity to use them, what's the level of durability
Speaker 3: that you get. So I would just read through that
Speaker 3: article and think about like your use cases. But if
Speaker 3: you don't want to bring in a dependency, whether at
Speaker 3: the file system or at the SQUL light level, you
Speaker 3: have four different options for generating a backup that have
Speaker 3: different pros and cons around durability, restoration speed, and space efficiency.
Speaker 1: Yeah, for me, the thing that I'm concerned about, and
Speaker 1: granted what my first job out of college, I was
Speaker 1: working for an online backup company, right it back up
Speaker 1: all of your pictures of your kids, the cloud kind
Speaker 1: of thing.
Speaker 3: And.
Speaker 1: So I'm imagining, I, you know, if a meteor hits
Speaker 1: the data center and I want to deplay it somewhere else,
Speaker 1: then I need that file in the cloud somewhere. I
Speaker 1: guess I could just have it on my local machine,
Speaker 1: but anyway, I need it somewhere that's not the data center,
Speaker 1: and so that's that's what I'm imagining. But yeah, I mean,
Speaker 1: this gets me a file that I can push to
Speaker 1: the cloud. So do you just I guess I'm wondering
Speaker 1: what those options are. Do you just extract the file
Speaker 1: as long as you have whatever time granularity you like,
Speaker 1: and then figure out how to get it up int aws.
Speaker 3: Yeah, So if you just wanted to use one of
Speaker 3: these sort of simpler built in services and you want
Speaker 3: different levels of durability, the basics that you have is like,
Speaker 3: let me put it somewhere else on this machine. So
Speaker 3: it's in the totally different director. So the way in
Speaker 3: which I accidentally deleted my directory, there was a feature
Speaker 3: in hatchbox which has been changed by the way, where
Speaker 3: in the WebUI you can rename an application. And so
Speaker 3: I was just fuzzing about. It's like I'm going to
Speaker 3: standardize all my applications because I'm OCD, not clinically I
Speaker 3: should say, that's a colloquialism. But so I just changed
Speaker 3: the name of the application. And the way in which
Speaker 3: they pushed that change to the servers they ran RMRF
Speaker 3: on the application directory and then ran a new deploy
Speaker 3: And so the fact that my sequel like directory lived
Speaker 3: in the shared subdirectory did not help me at all.
Speaker 3: So I could have a backup to just some other
Speaker 3: place that's not likely to be accidentally RMRF. But then
Speaker 3: it's like, well, if my machine goes down, that's not
Speaker 3: so great, so I want to put it somewhere else.
Speaker 3: You can use network attached storage. Now, like all of
Speaker 3: these services provide volume storage. So the other thing you
Speaker 3: can do is you just CP it onto the volume storage.
Speaker 3: So now it's on a different machine, but it's in
Speaker 3: the same data center. So if the data center goes down,
Speaker 3: it's not so great. So then you could set up
Speaker 3: a third layer to pick up those files and put
Speaker 3: them on some other service. Right, you could just set
Speaker 3: up back blaze probably on those levels machines however you
Speaker 3: wanted to do that, or you could also just you're like, well,
Speaker 3: I really want the durability, then I would embrace the
Speaker 3: dependency of light stream, like it's a really low overhead dependency,
Speaker 3: and so now you can get your backups a fine
Speaker 3: grained but most importantly be in a completely other service,
Speaker 3: in a completely other data center that has no relationship
Speaker 3: to your application service, data center or machine. But generally
Speaker 3: that's like the layers of a durability that you have
Speaker 3: available to you, and you can you know, however far
Speaker 3: you want to go for your use cases, you can
Speaker 3: work your way out without a ton of effort.
Speaker 2: Cool. We've spoken quite a lot today about like you
Speaker 2: won't need this, like you don't need three nines of
Speaker 2: our time and stuff. So from my point of view,
Speaker 2: when I was thinking about this for one of my
Speaker 2: own projects, I was like, all I need is a
Speaker 2: head snow box with an attached volume, and I'll just
Speaker 2: ride backups to the attached volume of course the data center.
Speaker 2: But for my small scale I think that's fine, Like
Speaker 2: would you agree with that?
Speaker 3: Yeah, I mean so for most things, I think that
Speaker 3: the trade off for if the if everything goes to shit,
Speaker 3: everything has gone to shit, right, it's like just presuming
Speaker 3: things don't go to shit and not take like you know,
Speaker 3: it's it's the old adage that it's the last twenty
Speaker 3: percent to finish something that takes ninety percent of the time.
Speaker 3: That really is true. And most services do not require
Speaker 3: the level of resiliency that would take the next ninety
Speaker 3: percent of effort. And so just saying, like, you know,
Speaker 3: how actually critical is this. And so for anything where
Speaker 3: I'm not trying to make money, you know, it exists
Speaker 3: until it doesn't, right, And so I'm not going to
Speaker 3: put a ton of extra time and effort and money
Speaker 3: for things that are trying to make money. Then you
Speaker 3: do need some durability because like you have to keep
Speaker 3: making money if something bad happens. But that's basically it.
Speaker 3: That has been my own rule of thumb. So every
Speaker 3: single non money making application I have, I don't do
Speaker 3: fancy live stream backups for all of those applications, I
Speaker 3: actually don't do any backups, to be honest with you,
Speaker 3: because I know the one way in which it failed,
Speaker 3: and I talked with Chris Oliver and he changed it.
Speaker 3: And so unless I manually go in there and r MRF,
Speaker 3: like my data is fine, it's all set up correctly.
Speaker 3: So I don't even run CP or anything for anything else.
Speaker 3: I personally just jumped to live stream. But like network
Speaker 3: attacks attached storage with CP great. You know it's a
Speaker 3: nice metal ground.
Speaker 1: So is light stream a paid service or is it just.
Speaker 3: No, it's an open source utility. You have to pay,
Speaker 3: so it pipes your data to some bucket storage service
Speaker 3: like S three R two Digital Lotion spaces, so you
Speaker 3: have pay for that storage, but the tool itself is
Speaker 3: a MIT open source utility.
Speaker 1: Awesome. One other thing I just want to throw in,
Speaker 1: because we've mentioned it a few times now. I did
Speaker 1: a quick Google search on like how many minutes or
Speaker 1: how many hours of downtime per year is five nines?
Speaker 1: So five nines is about six minutes of downtime per year,
Speaker 1: and yeah, I mean no, nobody's gonna notice. I think
Speaker 1: if it's six hours, which three nines is about what
Speaker 1: eight and three quarters hours per year? So you know,
Speaker 1: if you have an outage here and an outage there, right,
Speaker 1: you know for fifteen minutes or twenty minutes, you're going
Speaker 1: to be well over the three nines and you're gonna
Speaker 1: be fine.
Speaker 3: Yeah. And I think the other key point that I
Speaker 3: like to preach on is that there is a massive
Speaker 3: difference to the health and sustainability of your business between
Speaker 3: scheduled and unscheduled downtime. Right, true, scheduled downtime is a beautiful, simple,
Speaker 3: powerful tool in your business is tool belt. It is
Speaker 3: not very difficult to commune, nicate to your users in
Speaker 3: a way that makes them feel respected and appreciated to
Speaker 3: take thirty minutes of downtime to deal with a complicated
Speaker 3: database migration, or to vertically scale your single machine up
Speaker 3: to a bigger instance. And so I feel like we
Speaker 3: sort of in a lot of ways, the conversation around
Speaker 3: web development has gotten to a place where we have
Speaker 3: sort of simplified things and we just talk about downtime
Speaker 3: as if it's all the same, and it isn't. And
Speaker 3: attempting to again like swallow all of the complexity to
Speaker 3: have a system that theoretically never ever ever goes down
Speaker 3: is a really deep rabbit hole of complexity. And we
Speaker 3: can win back so much time and so much mental
Speaker 3: space if we just accept the leverage available to us
Speaker 3: to say I am going to control my application goes down.
Speaker 3: And it's true, like a vast majority of applications have
Speaker 3: really regular usage patterns and as a part of their
Speaker 3: usage pattern, have multiple hours where no one is using
Speaker 3: the application, like you have time available to you to
Speaker 3: just like go down and literally no one will ever notice.
Speaker 3: And even if you have people using it all the time,
Speaker 3: like you're going to have low periods and you can
Speaker 3: just let people know, Hey, I'm going to be down
Speaker 3: for thirty minutes two weeks from now, and everything will
Speaker 3: be fine, like you can continue making money.
Speaker 1: Yeah, well, it also in my opinion, I mean, you know,
Speaker 1: I don't remember if it was you or I. Usually
Speaker 1: that brought up five nines, but the diminishing returns, right,
Speaker 1: I mean, because you go from what six minutes to
Speaker 1: almost an hour for four nines. It's just you're optimizing
Speaker 1: away just a tiny bit of unplanned outage. And you know,
Speaker 1: I don't know, I feel what you're saying there. Yeah,
Speaker 1: if you know that you might cause it, then you
Speaker 1: just let people know, Hey, you know, we're doing a
Speaker 1: scheduled maintenance and hey, maybe you get lucky and your
Speaker 1: index doesn't take more than a few minutes to build anyway,
Speaker 1: but just letting people know it might be slow or
Speaker 1: go down. Yeah, you get a ton of grace out
Speaker 1: of that. One other thing I wanted to ask you about.
Speaker 1: So the word is is that you're building a course
Speaker 1: or you've built a course about some of this stuff.
Speaker 1: Do you want to tell us about that?
Speaker 3: Yeah, so you might have been able to tell But
Speaker 3: I'm pretty passionate about the general concept of giving individuals,
Speaker 3: giving small teams leverage. And I personally think that RAILS
Speaker 3: eight and sequel Light, when paired together, are a really
Speaker 3: powerful lever for making things on the Internet. And so
Speaker 3: I partnered with the Internet's favorite dad, Aaron Francis, and
Speaker 3: I recorded at the end of last year about sixty
Speaker 3: video video course called High Leverage Rails. So you can
Speaker 3: find it at high Leverage Rails dot com and it
Speaker 3: will be coming out in a couple of weeks. And
Speaker 3: it is a course to walk you through everything that
Speaker 3: you need to know, but nothing you don't. So try
Speaker 3: to keep it as like lean and focus as possible
Speaker 3: to build applications with RAILS and SEQLI. So we walk
Speaker 3: through like an introductory sort of module onlike all right,
Speaker 3: active record and SQLA, what is really happening here under
Speaker 3: the hood. Feel comfortable with how Squalite is working and
Speaker 3: sort of some of these differences around preferring a large
Speaker 3: number of small queries to a small number of large queries.
Speaker 3: And then we just start building a simple application to
Speaker 3: go through all the details, like to really understand what
Speaker 3: is solid Q, what is solid cable, what is solid cash,
Speaker 3: how are they set up with squal light, what are
Speaker 3: the trade offs? What are we doing? So we just
Speaker 3: we step through the whole process of building a basic application,
Speaker 3: focusing on giving people the knowledge and the tools and
Speaker 3: the confidence for them to then go and do this themselves,
Speaker 3: and we go all the way to shipping it to production.
Speaker 3: So we use hatchbox is the tool that I use
Speaker 3: most and think is perfectly well suited to sqalide on
Speaker 3: rails applications, and Chris at gorails has actually sponsored the course,
Speaker 3: which is exciting. So from from rails new to running
Speaker 3: and production, we build a whole host of different features
Speaker 3: to really exercise all of the sort of functionality available
Speaker 3: to us in the rails application. So we set up jobs,
Speaker 3: we have a cash, we send action cable messages, We
Speaker 3: do Jason some fancy Jason stuff. We do full text search.
Speaker 3: We take advantage of sequalize full text search engine dig
Speaker 3: into all these different details. I think it's going to
Speaker 3: be a really excellent resource, particularly for people who are
Speaker 3: interested in a lot of these kinds of philosophies. I've
Speaker 3: been harpening on here on this call around, like I
Speaker 3: want to find leverage, I want to generate value. I
Speaker 3: want to move fast, but I care about quality. I
Speaker 3: care about understanding what I'm doing, right, Like, sure, AI
Speaker 3: can help you move really fast, but in two months,
Speaker 3: when you need to make a change or there's a
Speaker 3: bug and you're wading through the mountain of slop that
Speaker 3: makes no sense to you, and you really don't know
Speaker 3: any of these tools, you're going to be in for
Speaker 3: a world of pain. So really, I really want to
Speaker 3: push this idea that you can just master two very approachable,
Speaker 3: simple tools. Right, It's super easy to get started. There's
Speaker 3: it's straightforward to really genuinely master these tools, and then
Speaker 3: you have the world at your fingertips. Because not only
Speaker 3: can you move fast, can you leverage AI with tools
Speaker 3: that have been around for decades, right, Like there's all
Speaker 3: of these ais have been trained with like millions and
Speaker 3: millions and millions of tokens on these topics, these tools,
Speaker 3: But you can be a true craftsman. You can have
Speaker 3: full control over what you're doing, such that your system
Speaker 3: and your your business can evolve over time without you
Speaker 3: feeling anxious about like what the hell's going on. So
Speaker 3: this middle ground of like finding your leverage, mastering your tools,
Speaker 3: but still moving fast, being responsible and adapted to the market.
Speaker 3: I think this is my sense for like where the
Speaker 3: future of the sort of web economy is going, and
Speaker 3: this is my attempt to sort of help as many
Speaker 3: people as possible to get their foot in the door
Speaker 3: and start making noise on the internet for the betterment
Speaker 3: of us.
Speaker 1: All awesome. So where do you get the course?
Speaker 3: Yep, check it out at high Leverage rails dot com.
Speaker 3: You can sign up for the waitlist. We're going to
Speaker 3: have a early bird discount, so get on the waitlist.
Speaker 3: Planned release is February eighteenth. All the videos have been recorded,
Speaker 3: we've done the first passive editing, so we're just doing
Speaker 3: our final passive editing right now, so I expect that
Speaker 3: it'll come out on February eighteenth, and if you are
Speaker 3: on the waitlist, you get a nice discount. So high
Speaker 3: leverdrails dot com check it out, and I look forward
Speaker 3: to hearing everyone's feedback.
Speaker 1: Awesome. All right, Well I was going to go to picks,
Speaker 1: but you mentioned that you're going to be speaking at
Speaker 1: some conferences in April before the show, so you want
Speaker 1: to just let people know where those are. Two and
Speaker 1: then we'll do our picks.
Speaker 3: Yeah. I literally just before the show found out the
Speaker 3: third one. So in three straight weeks in April, I'm
Speaker 3: going to be bouncing from South Paolo, Brazil. We're obviously
Speaker 3: speaking at Tropical on Rails, then hopping back over the
Speaker 3: ocean to Poland to speak at Fratslavarb and then the
Speaker 3: week after that I have to fly over to Japan.
Speaker 3: I'll be at Ruby Kaigi this year and speaking there.
Speaker 3: So three straight weeks, three different continents. It's going to
Speaker 3: be a fun and take a month. Awesome.
Speaker 1: Well, yeah, if you are going to be at any
Speaker 1: of those conferences, definitely look for Steven. Let's go ahead
Speaker 1: and do some pics. Are you have some picks?
Speaker 2: Yeah? I do. It's funny. Last week I was so
Speaker 2: distracted for about half this podcast because I broke production
Speaker 2: for my client.
Speaker 4: And when you didn't, the database did delete the database
Speaker 4: just causing some mile errors, not the best, and I
Speaker 4: did a pick for my app which I relaunched called
Speaker 4: scatterg on that email.
Speaker 2: And neglected to say what it was about what it
Speaker 2: actually does. So I'm just gonna go ahead and repick
Speaker 2: scatter Gun that email, which is a mailing list platform
Speaker 2: with a focus on privacy and simplicity. So it's like
Speaker 2: my take on stuff like mail Jim, but without all
Speaker 2: the extra marketing stuff. Is like, literally, all you want
Speaker 2: to do is drop a subscription box on your website
Speaker 2: and and email that list. That's kind of what skadagun does.
Speaker 2: So you can just drop a web component into your
Speaker 2: website to collect email addresses, and then scadagun will give
Speaker 2: you an email alis and just fire up your favorite
Speaker 2: email editor and send an email to that alis. My
Speaker 2: app will receive it. It will tack on an unsubscribed
Speaker 2: link at the bottom and send it out your list.
Speaker 2: That's literally all it does. To be honest, it's fairly simple.
Speaker 2: It's always going to be fairly simple. It's never going
Speaker 2: to have fancy marketing features. But if that's the kind
Speaker 2: of thing that you fancy, then give that a go.
Speaker 2: So I've done the proper sales which this time, so
Speaker 2: I'm going to leave that to the side. For next
Speaker 2: picks because last time it's just like after I got
Speaker 2: the college, like I mentioned it and then I forgot
Speaker 2: to say what it actually did. Yeah, that's what breaking
Speaker 2: production will do to your brain. And I'm going to
Speaker 2: do another couple of picks. I'll do a music pick.
Speaker 2: So I think I might have mentioned them on this
Speaker 2: podcast before, but I love a band called Solstice. There
Speaker 2: really grassroots level band here in the UK, and they
Speaker 2: do kind of folk kind of music mixed with rock,
Speaker 2: mixed with progressive rock, weird shit. They've got a new
Speaker 2: album coming out in a couple of months and I've
Speaker 2: got early access to it and i've pretty much I
Speaker 2: got it two days ago and i've had it on
Speaker 2: loop pretty much ever since. There's a track on there
Speaker 2: called twin Peak is the most hauntingly moving piece of
Speaker 2: music I've heard in many, many years. So if that
Speaker 2: sounds vaguely interesting, maybe go check out the last album,
Speaker 2: which is Light Up. And their upcoming album is called Clan,
Speaker 2: which will be out in early April, I believe. And
Speaker 2: I've been going for quite a lot of comedy gigs
Speaker 2: in the last week. So there's a comedian called Robotton
Speaker 2: who I really like He's got a YouTube, an older
Speaker 2: special effice on YouTube for free. So if you like
Speaker 2: we had stand up comedy, then go check out Robot
Speaker 2: and the Time Show. It's on YouTube for free. So, yeah,
Speaker 2: those are my picks.
Speaker 1: Awesome. I'm gonna throw out a few picks here. So
Speaker 1: I've gotten really deep into the launch for Ruby Geniuses
Speaker 1: and JavaScript Geniuses, so just to give you a quick
Speaker 1: rundown on those, and then I'll do my board game
Speaker 1: pick and stuff like that. So and I'll try not
Speaker 1: to be too long winded. When I got into programming
Speaker 1: and the times where I felt like I was really progressing,
Speaker 1: I had a handful of things really going for me.
Speaker 1: I had meetups that I could go to and people
Speaker 1: I could talk to with the meetups. I had a
Speaker 1: mentor that I was working with at the time, I
Speaker 1: was watching rails casts. Anyway, there are a bunch of
Speaker 1: things that I wanted. We kind of did book clubs,
Speaker 1: I got some mentorship from the guy I was doing
Speaker 1: Ruby Rogues with way back in the day. There were
Speaker 1: conferences and anyway, So what I'm looking to provide to
Speaker 1: people is that kind of experience because a lot of
Speaker 1: these things have kind of gone away or I've just
Speaker 1: kind of advanced to the point where I'm not working
Speaker 1: with anybody who really pushes me on tech or anything
Speaker 1: Ruby or anything like that. And so you know, I
Speaker 1: get a certain level of that from this show. You know,
Speaker 1: because we're talking to Steven. Stephen knows way more about
Speaker 1: Sequelight and some of this stuff that I do, right,
Speaker 1: so I can ask them all my questions. But what
Speaker 1: I wanted to do was just put together this system.
Speaker 1: And so I'm scheduling meetups right now. We'll do a
Speaker 1: meetup every week. One of the meetups every month is
Speaker 1: going to be something about AI because that seems to
Speaker 1: be where people are at. And then we're going to
Speaker 1: be I'm going to be putting out videos on how
Speaker 1: to do stuff, primarily with rails. Like I said, I'm
Speaker 1: also doing in the cell on the JavaScript end, and
Speaker 1: so that'll probably focus more on React. But yeah, we're
Speaker 1: going to have a place where you can come and chat.
Speaker 1: There are going to be premium podcast episodes, and you'll
Speaker 1: get discounts to any of the summits that I put out.
Speaker 1: So last year I did a summit on just where
Speaker 1: Ruby was headed, and so this year I'm looking at
Speaker 1: doing some more of that stuff, probably in the summer,
Speaker 1: and you'll also get discounts on retreats. I want to
Speaker 1: start doing retreats where you know, we kind of get
Speaker 1: like a big giant Airbnb that has a room that
Speaker 1: can hold twenty or thirty people and invite you know,
Speaker 1: a handful of people, so you know, maybe Steven or
Speaker 1: maybe a USh or you know, if we can get
Speaker 1: Uncle Bob Martin or DHH or Aaron Patterson or some
Speaker 1: of these folks that you all know, right, so we
Speaker 1: all get into a room and just talk about how
Speaker 1: we can program better. But you kind of get that
Speaker 1: FaceTime with somebody who's I guess sort of at that
Speaker 1: higher level of access, and also you know somebody that
Speaker 1: you want to sit and pick their brain. So anyway,
Speaker 1: that's that's the deal. You can go to rubygeniuses dot
Speaker 1: com and sign up. I've also been sending out emails
Speaker 1: to my email list. I signed up for the system
Speaker 1: I'm using before I knew about scattergun. Sorry I usual,
Speaker 1: but anyway, so just go to rubygeniuses dot com if
Speaker 1: you sign up before Valentine's Day February fourteenth. I'm also
Speaker 1: throwing in a one hour coaching session, and my coaching
Speaker 1: rates about two hundred dollars an hour, and so that's
Speaker 1: a two hundred dollars value right there. And then the
Speaker 1: other thing I'm throwing in is either over WhatsApp or
Speaker 1: something similar, I'm offering text and voice coaching. So you'll
Speaker 1: send me a message, hey, I got stuck doing this right,
Speaker 1: and then I'll get back to you and say, Okay,
Speaker 1: this is how I would do it, or you know,
Speaker 1: these are the things that I would look at or
Speaker 1: you know whatever, right anywhere up and down the chain
Speaker 1: from performance to how do I do this particular thing?
Speaker 1: And if I don't have the answer, the nice thing
Speaker 1: is is I've been doing things like Ruby rogues long
Speaker 1: enough to where I probably know somebody who knows the answer,
Speaker 1: and so I should be able to track it down.
Speaker 1: So anyway, that's what that's what we're putting together with
Speaker 1: rubygeniuses dot com. You can sign up for a month,
Speaker 1: you can sign up for a year, or you can
Speaker 1: sign up forever. Those are the prices, So go to
Speaker 1: the website check that out. And yeah, I'm super excited
Speaker 1: to be collaborating with people I did leave off. We're
Speaker 1: going to be doing a monthly book club as well,
Speaker 1: So we're going to be picking up something like Pragmatic
Speaker 1: Programmers or my book, yeah, or your book. We might
Speaker 1: do that, right, and so then it's you know, you
Speaker 1: show up, so you've read the book, probably worked through it,
Speaker 1: and then you know, we show up. Usually the authors
Speaker 1: there because I know a lot of them too, and
Speaker 1: we'll do that so that that's all part of the deal.
Speaker 1: Some of them might be combined with the JavaScript group
Speaker 1: if if the book is more generic programming. But I'm
Speaker 1: not going to shy away from picking you know, a
Speaker 1: solid Ruby book or a solid JavaScript book for the
Speaker 1: other group, and we'll probably do both of those in
Speaker 1: the same month so that we can have separate meetings.
Speaker 1: But anyway, that's what we're pulling together. I just people
Speaker 1: are looking to connect. A lot of times people find
Speaker 1: jobs through these things. There's going to be some level
Speaker 1: of career growth, job hunt content to it, just because
Speaker 1: I've talked to a whole bunch of people are looking
Speaker 1: for that. But that's what we're putting together. So Rubygeniuses
Speaker 1: dot Com. Now, as far as board games go, I'm
Speaker 1: trying to remember I think last week, No, I don't
Speaker 1: think I did pick it last week, so I'll pick
Speaker 1: it this week. I played a game with my my friends.
Speaker 1: So one of my friends is teaching the hot games
Speaker 1: at SaltCON, which is a conference in March in Layton, Utah,
Speaker 1: north of Salt Lake where you show up and you
Speaker 1: play games with people. I went last year. I'm probably
Speaker 1: not gonna be able to go this year. But anyway,
Speaker 1: he's teaching the game, so he's trying to learn the games.
Speaker 1: And we played a game last week called Cascadero, and
Speaker 1: Cascadero is you're effectively placing a little horseman and they're
Speaker 1: carrying word about the new king's ascension to the throne.
Speaker 1: Not that that has any bearing on anything, it's just
Speaker 1: kind of the premise of the game. And then yeah,
Speaker 1: so when you place your piece next to a city,
Speaker 1: then if it's part of a group, so if it's
Speaker 1: your second piece in the group or higher, then you
Speaker 1: get to move move up the progress track. And as
Speaker 1: you move up the progress track, you get points and
Speaker 1: you win at the end of the game if you
Speaker 1: have the most points and you've gotten your color of
Speaker 1: your marker all the way to the end of the
Speaker 1: board board game. Geek weights at at two point five
Speaker 1: to three. I liked it. I don't know if I
Speaker 1: would go buy it, but I did like it. It was fun.
Speaker 1: I kind of want to play it again, just because
Speaker 1: some of the mechanics were a little bit odd to
Speaker 1: pick up, and now that I understand them, right, I'd
Speaker 1: like to play it again and see if I can
Speaker 1: do better. It says it's age is fourteen plus. The
Speaker 1: community says ten plus can play it. That's probably fair.
Speaker 1: We played with three players. It's two to four players,
Speaker 1: and anyway, it was kind of a fun game. It's done.
Speaker 1: It's made by what's his name, Rainer Kenitsia. I'm sure
Speaker 1: I'm destroying his name. I think he's German or something,
Speaker 1: but anyway, his he's done a bunch of other games
Speaker 1: that you've probably played if you're in the board game.
Speaker 3: Area.
Speaker 1: So another one that I picked was lem. Anyway, he's
Speaker 1: put out dozens and dozens of games, and so Lost
Speaker 1: Cities I think I've picked on here before. So anyway, yeah,
Speaker 1: go check it out. I'll put a link into board
Speaker 1: game Geek where they have that rating, and then I'll
Speaker 1: also put a link in for Amazon so you can
Speaker 1: go buy it on my affiliate which doesn't count cost
Speaker 1: you anymore, but I get a kick back if you
Speaker 1: use my link. So anyway, I've gone on way longer
Speaker 1: than I wanted to, so I will let Steven do
Speaker 1: some picks.
Speaker 3: Yeah, so my first pick a little bit of a
Speaker 3: I don't know play, I guess on the word. But
Speaker 3: my first pick is going to be the city of Philadelphia,
Speaker 3: and there are two reasons why. The first reason is
Speaker 3: that I am picking the Philadelphia Eagles to become Super
Speaker 3: Bowl champions this Sunday in Super Bowl fifty nine. Just
Speaker 3: for a quick bit of context, Born and raised in Louisiana,
Speaker 3: but lived in Philadelphia for about eight years before I
Speaker 3: moved to Berlin six years ago, and I just can't
Speaker 3: I don't know how anybody lives in Philadelphia and doesn't
Speaker 3: become an Eagles fans. I think they put something in
Speaker 3: the water. So I'm a big Eagles fan. But the
Speaker 3: second reason that Philadelphia is my pick is that I
Speaker 3: am super excited for Rails Comp this year. For anyone
Speaker 3: who doesn't know, this is the final Rails comp. Ruby
Speaker 3: Central has been putting on Rails Comp for over a
Speaker 3: decade now, I don't even know how many years, and
Speaker 3: they have decided to focus their efforts on a single
Speaker 3: conference each year, and so this year they are doing
Speaker 3: Rails Comp but not Ruby Comp, and then moving forward
Speaker 3: they will only be doing Ruby Comp. And so the
Speaker 3: very last Rails Comp ever, is being hosted in Philadelphia, Pennsylvania,
Speaker 3: which will be the only time that a Ruby Central
Speaker 3: conference has ever been in Philadelphia. I know the hotel
Speaker 3: that the conferences is happening at, I know the area
Speaker 3: where the conference is happening. There's like really great food options,
Speaker 3: really great experience. It's going to be an absolute blast.
Speaker 3: I am really looking forward to that. The call for
Speaker 3: papers just opened up and that's going to be open
Speaker 3: for all of February. I recommend everyone to take the
Speaker 3: time to like sit down and gather your thoughts, try
Speaker 3: to present a interesting, cogent narrative for something that you
Speaker 3: have thought about or done recently. Like all of us
Speaker 3: have done interesting things, all of us have had interesting experiences,
Speaker 3: and there is so much value in even just preparing
Speaker 3: a proposal, let alone you getting get accepted and then
Speaker 3: preparing a talk and getting involved in that side of
Speaker 3: the conference experience. So big year for Philadelphia. Let's go
Speaker 3: Eagles and hopefully I'm not too sad on Monday, but
Speaker 3: that's going to be my first pick. Just for a
Speaker 3: technology related pick. I have been using a couple of
Speaker 3: gems from my friend and elaborator in the open source world,
Speaker 3: Joel Drapper for some of my more recent projects, and
Speaker 3: I just want to shout them out because I've really
Speaker 3: enjoyed using them so too. In particular, for those who
Speaker 3: don't know, Joel Drappers, the creator of flex. Flex is
Speaker 3: the view library in Ruby that allows you to write
Speaker 3: HTML with pure Ruby, so no templating string, templating syntax ERB,
Speaker 3: you just write normal Ruby. That's a great project. But
Speaker 3: he also has a library called Literal, which we're going
Speaker 3: to be talking more about at Bratslav in Poland in April.
Speaker 3: It's called Literal and it's a really really fascinating project.
Speaker 3: So I'm just going to tease more of the details
Speaker 3: of our talk there. The name of our talk is
Speaker 3: going to be Ruby has always had types, and for
Speaker 3: those of you who don't know, Ruby has always had types, uh,
Speaker 3: and Literal sort of finishes the type system that has
Speaker 3: existed in Ruby for a long time and the way
Speaker 3: that it does that and the way that Ruby has types.
Speaker 3: Is that there is a run time type system. So
Speaker 3: what does that mean? What can you do with that?
Speaker 3: How is that different from a statically typed language, a
Speaker 3: compiled time typing system. There's a lot of interesting stuff
Speaker 3: to stay there, and I'll just leave you teas. Come
Speaker 3: check it out at bratslall RB in April, or just
Speaker 3: go check out literal dot fund read the documentation. That
Speaker 3: is a really excellent library. And then a newer library
Speaker 3: that is still sort of in beta but is really
Speaker 3: exciting is called quick draw. That is a testing framework
Speaker 3: and test runner, so basically a direct competitor to urspec
Speaker 3: and mini test. And the big selling point is that
Speaker 3: it is built from the ground up specifically for our
Speaker 3: modern multicore environment, and so it has a highly optimized
Speaker 3: handwritten test runner that distributes your tests as efficiently as
Speaker 3: possible across all of your computer's cores, and so it
Speaker 3: runs at you know, if you have like a ten
Speaker 3: core machine, about ten times faster than the equivalent in
Speaker 3: ourspec and it is just incredibly fast. It is so cool.
Speaker 3: It has a watch mode and you can just like
Speaker 3: leave it on and you're just saving your files and
Speaker 3: it just finishes. I am working on a sequel like parser,
Speaker 3: and I have a test suite currently at about thirty
Speaker 3: five thousand assertions and I just leave watch mode and
Speaker 3: it runs in like on my M one Mac in
Speaker 3: like seven hundred milliseconds, so I just am refactoring away
Speaker 3: and letting it sit in watch mode. So really, really
Speaker 3: awesome projects. I've I've really enjoyed working on them with
Speaker 3: him and using them in my work for the last
Speaker 3: few so I definitely recommend people check those out.
Speaker 1: Very cool. Yeah, a lot of stuff to check out there. Well,
Speaker 1: thanks for coming. I'm not gonna talk about the Super
Speaker 1: Bowl because I like both teams. I'm trying to decide
Speaker 1: which way I want to go, So anyway, thanks for coming, Steven,
Speaker 1: thank you so.
Speaker 3: Much for having me. It was a blast to talk
Speaker 3: about all this stuff with y'all. Yeah.
Speaker 1: Absolutely, Well, let's wrap up until next time, folks. Max
Speaker 1: out