Let's get started. I really can't see any of you. This is super glaring stage. OK. So this is my talk. So when Bundler came out in 2010 or whenever it finally came out, it did something really cool. It installed your gems. And it let you use those gems in your application. It was great. Today, Bundler does something really cool and installs your gems. Let's use them in your application. Still pretty great. But in the eight-ish years since then, Bundler has needed thousands and thousands of hours of development work. And it's maybe not super clear to most people why that was necessary if the starting point and the ending point are so similar. So kind of what happened between then and now is mostly what this talk is about. Before we dive into that, let me at least introduce myself. I'm Andre Arco. I go by indirect on the internet things. That's the tiny picture of my head that shows up next to Commits and GitHub issues. I work at Cloud City doing Ruby and Rails consulting. We mostly that means that I join teams at other startups that are already doing web development work and participate in the team as a senior dev and make suggestions and architect things totally hit me up if that's something that your company would like. I also wrote a book. I'm super fond of this book, and I keep talking about it because it makes me really happy that I learned Ruby from the Ruby way first edition in the early 2000s. And I got to update the Ruby way for the modern Ruby world. I think the third edition covers up through Ruby 2.3, so it's even kind of relatively still up to date, which is cool. My other company is Ruby Together. Ruby Together takes funds from companies that use Ruby and uses those funds to pay for development work on Ruby open source like Bumler and Ruby Gems. I will talk a little bit more about that as we get to that part of the history, but of course, the reason why you're here for this talk is Bumler. I've been on the Bumler team since 2009-ish, and I've been the lead developer since 2012-ish. And so, in this talk, it's going to be kind of a combined historical retrospective and walkthrough for Bumler's advanced features, which were almost all added after 1.0 came out as we discovered things that people needed or cool things that you could do. So by the end of this talk, hopefully, you'll have a better understanding of why Bumler has needed so much development over time, exactly what we managed to do with all that development and know about some of the cool Bumler features that you can use to do fancy and complicated things. So, here we go. When Ruby was first released, sharing code with other developers meant copying files that ended in .rb, and then using require, maybe after having edited the load path variable. It was a lot of work. There was no idea about versions, except maybe if you put a comment in the file and said this file is version something. It was not great. Later, Jim Warrick and Chad Fowler, who just gave the keynote last night, and Rich Hickey worked together and created RubyGems. And with RubyGems, you could install things with just one command, which was super great.  It was so good. And after a few years, we noticed that installing gems was easy, but changing the gems that you were using after you'd written code that used them was really hard. And this is not obvious up front, when you're like, oh my God, I installed this gem so fast. And then three years later, you're like, oh my God, I installed the gem and it was the wrong version and I couldn't tell why my application didn't work. So, this caused a lot of pain where installing gems would sort of suddenly and unexpectedly give you different code than you thought you were going to get. And it meant that very briefly, the most popular approach to having dependencies was to take all of the gems, put them in your applications, get repository and commit them. Which, please don't do that, it's a really bad idea. But for a while, that felt like the only way that you could put your app on another machine and actually be confident that it would run. So, there's actually a lot more details about that kind of history in an entire talk that I gave a couple years ago at RubyConf called, how does Bundler work anyway? It's pretty great actually to kind of realize the context that Bundler came into and solved the problem of if that wasn't something that you had to live through, made me really happy anyway. So, despite being used in nearly every Ruby application and script today, Bundler was developed in response to a super specific developer need originally, which was web applications that have tons of dependencies. When Bundler was first prototyped, it meant web applications that were written in a no longer existent Ruby web framework called Merb. Merb had kind of pioneered this idea of splitting up your framework into lots of tiny gems so that you didn't have to use the whole thing. Rails at that point was still only like five gems total. And so, Bundler was needed super badly when Merb was like, oh, there's 20 gems and now you have to make all of them work together. And as time went on, Merb and Rails teams agreed to merge. Bundler kind of switched from targeting Merb applications to targeting Rails three applications. And Bundler existing meant that Rails apps can now kind of like out of the box need dozens of gems rather than just needing four and life is still okay. So, there were like two specific insights that drove the development of Bundler as a tool. The first insight was that you needed an install time dependency resolver, which was not a thing that Ruby had. And the second insight was that the resolution process needed to produce a lock file so that you could reuse the results of that resolution on other machines as you went to install the application on a new developer's box or on the next server you've spun up or whatever. So, what is a dependency resolver? It takes a list of gems that you asked for, asks those gems for the gems that they need, asks those gems for the gems that they need, et cetera. And eventually it has a complete list of every gem that you could need and then it checks every gem's list of version requirements to make sure that they all fit together. For example, something depends on rack 1.0, something else depends on rack less than 2.2 and those requirements are compatible, like rack 1.1.1 works but you have to do a bunch of work to figure that out and be sure that that's true. So, how about install time? Well, if you do your dependency resolution while you're installing gems, it means that you know in advance whether your application can actually start up. And if you do dependency resolution at runtime, you start requiring gems and everything seems great until you hit something that isn't compatible and then your application crashes. Less than ideal. As you can probably imagine, finding out about these problems before your application starts up is a large improvement. So, third thing, how about the lock file? So, that just means that we, after figuring out the list of gems and versions that actually can work together without crashing, we write it down in a file and those gem names and version numbers together make up the bundle that gives Bundler its name. Amazing..(audience laughs loudly.) Installing and running Ruby software in a deterministic and repeatable way on different computers is basically the entire rationale for Bundler's existence. So, all of that tooling comes together and it's pretty recognizable even across the 10 years that this project has existed. You put your gems in a gem file, you run bundle install, your gems show up, you have a lock file, you bundle exact something to make sure that you're using the right version. Pretty cool. At the time, a super nice new feature way back then was the idea of being able to use gems straight out of Git repositories which was not possible before Bundler let you do that. Using a gem that like forking a gem and making changes to it before Bundler allowed Git repository gems was a gigantic, unbelievable hassle. You had to like fork the repo, make your changes, build a new gem, put it somewhere you could install it, maybe change the name, maybe give it a weird version number so that it didn't conflict with one of the public version numbers was a giant hassle. Bundler made it way better. Another new thing that happened was the bundle gem command so that you could make gems that worked inside Git repose with Bundler. At the time that Bundler came out, the most popular gem creation thingy was jeweler but jeweler made gems that didn't work in Git repositories so we were like, oh no, we have to do something so that this all works together. And Bundler also makes managing gems easier. So I guess today it might feel kind of obvious and natural to use Bundler to manage your gems but at the time it was really, really, I cannot stress this enough, really controversial to use Bundler to manage your gems. And the entire concept of Bundler was really met with a lot of resistance by existing very experienced devs who were like, well, we already have our crappy workaround for how to make sure that we can install gems somewhere else. I'm not really sure why I would want to use this tool that has a different workflow that I don't know yet.  And this talk that I gave at RailsConf in 2010, the first slide is why Bundler? Like I actually had to convince people that Bundler was a good idea in 2010 and it was a lot of work to do that. Fortunately, within a couple years people actually used Bundler and eventually they were like, oh, actually, this is really great. And so Bundler was kind of like a really popular, mostly used by most devs tool. And then once people started using it, we immediately had new things to argue with people on the internet about like, why is it so slow? So at this stage it was kind of like, no one's arguing that Bundler is a bad idea anymore, now it's just people saying, okay, fine, it's a good idea, but I don't wanna use it because Bundle install takes millions of years and that makes me not wanna use it. So part of that was because just making Bundler 1.0, we had been very focused on making it actually work. We rewrote Bundler like completely different UI, different commands, different internal implementation of how the Bundle worked like three times in a row, like 0.8, 0.9, 1.0. And so when we shipped 1.0, we were mostly just really excited that it actually worked. And on top of that, when Bundler first came out, there weren't any giant five-year-old applications with 750 gems using Bundler because it was brand new. And so as Bundler got more popular, either applications grew over time until they had tons of gems or people started retrofitting Bundler onto their old applications that already had tons of gems. And we suddenly wound up in this state where we were like, wait, you have how many gems in your application?  And I can say with absolute certainty that when we shipped Bundler 1.0, we could not have imagined that there would be a single application with 600 gems. Like, and that is not that uncommon today. Sadly for totally unrelated reasons, you might think that since installing big applications was really slow, that installing small applications would be really fast. Also not true. Even if your gem file only had one gem in it, Bundler still had to download a list of every single gem in existence, just to make sure that it knew about the gem that you were going to install. As you can imagine, downloading that list maybe took some time. It really takes a long time. And so we were in this place where small gem files were slow to install because of downloading more data than we needed and big gem files were slow to install because we had literally never imagined you would install hundreds and hundreds of gems in one bundle install. And so we hadn't optimized it at all. So this is about the time where the Bundler team was sitting around saying, man, this really sucks that we have to download so much data all the time. And then Nick Quaranto was just like, oh, hey, I added a new API to RubyGems. It lets you ask for only the data that you want. Here you go. It's live in production. Go. And so it was pretty great. If you're interested in the details of that particular moment in history, Terence Lee and I gave a talk at Ruby on ALES 2012 called bundle install, why are you so slow? And we talked about the technical details of the API and the changes that we had to make to Bundler to make that work. The very short version is if you had a fast connection, or I should say accurately, if you had a low latency connection to the RubyGems servers, the new API was amazing. You could ask for just the information you knew you needed and then find out you needed some more information and then ask just for that and then find out you needed some more information and ask just for that. You downloaded a lot less data overall and as long as the latency was low enough that that multiple round trip thing didn't take too long, this was a lot faster. Unfortunately, it meant that you needed to make a lot more requests to RubyGems and if you didn't have a low latency connection to rubygems.org, like say you lived outside the US, there are a lot of devs that live outside the US. Even if you just had a wireless connection inside the US, you could, it wasn't any faster. If you were very lucky, it was basically a wash and you just downloaded less data but if you lived in South Africa, forget about it. I talked to some South African devs and they talked about how they would run bundle install after getting to work so that they could go make their coffee, drink their coffee, come back, wait a few seconds, watch bundle install finish and then get to work. It was like a multi-minute process to just run bundle install once when your round trip time to RubyGems is, I don't know, a second and a half. So the slowness was a huge problem and in response to these issues, we actually started working on a new index format that would mean we didn't need to make tons and tons of round trips to RubyGems but it took like three years to get done with that so I'm gonna have to talk about that quite a bit later. Hang on, we'll get there. At this time, we also continued to develop Bundler. We added stuff, we made it better for people. Some especially notable things from this era include the clean command which lets you get rid of gems that you aren't actually using anymore. This was a super big deal for CI or for Heroku where you push many versions of an application and you change the gems that they're using and so before Bundle Clean existed, your CI setup and Heroku had to choose between the crappy options of either install all the gems again every time there's a new version which is very slow or commit to letting your application have infinity space for gems because there was no way to get rid of gems after you stopped using them. Bundle Clean meant that they could do both and it was great. We added Bundle outdated so that you could see what was out of date without having to actually update it. We added support to the cache command to let you cache git repositories as well as just dot gems and we added git local development where you could check out a git repository and make changes to the git repository gem at the same time as you made changes to your application and Bundler would watch the repo and automatically update the commit in the lock file to make sure that you always got the right code. I'm gonna talk about that in more detail later. We also added support for application Ruby versions where you could put in your gem file the version of Ruby that your application worked with and it would raise an exception if you were trying to run it on a different version of Ruby which especially when which version of Ruby you were running was sometimes confusing was a really big help. You would never accidentally run your app on the wrong version of Ruby and then have really weird confusing bugs later. So this feature wound up causing some problems but I'm also gonna have to talk about that later. So for now let's move on to the next section of history where we find out all of the ways that we caused ourselves problems with the stuff that I just talked about. So the biggest thing that happened in 2012 to 2014 is bundler adoption really really really took off. Bundler 1.0 in 2010 averaged like 8,000 downloads per day. Bundler 1.1 came out a couple years later and averaged like 20,000 downloads per day and then by like August of 2012 it was averaging 30,000 downloads per day and that's when we discovered that we had executed a distributed denial of service attack against RubyGems.org. Yeah, basically the servers just couldn't handle how many bundler users there were and all those bundler users were like I wanna install gems, tell me about the gems, RubyGems and then RubyGems ran out of server capacity and crashed and no one could install any gems at all and everyone was very sad. So to at least let you have access to gems again we had to turn off the API that bundler was using to make installs fast and installs went back to being slow. And now we were back where we were two years ago. So at this point a team of people including myself, Terence Lee, Larry Marburger some other people built a new standalone application that served just this API and we actually got the RubyGems team super cooperative and with some help from Evan Phoenix and David Radcliffe we actually got the old URLs to keep working with this new completely separate application that we could scale independently of RubyGems itself. As you may have guessed, while this did provide an API for bundler users it provided a new completely different set of problems that we had never had before. One of the problems was that we had a completely separate database from rubygems.org and so if you pushed a gem we still had to find out about that gem somehow before you could install it in a bundle and we tried web hooks, we tried database replications and we tried scraping the API, we tried importing database dumps. There were problems with all of these options as I'm sure anyone who's had to deal with this kind of distributed data synchronization thing knows already automatically. We were young and naive and had never had to do this before and we were like, how hard could it be? It could be very hard, it could be very hard. My favorite problem that this caused was propagation delay between pushing a gem and then being able to install it because you had to wait for a RubyGems to finish processing and then send that information over to the Bundler API and then you had to wait for it to finish processing and then you would find out that even though you'd waited long enough for that to happen the CDN that we were using at the time would just kind of randomly not update depending on where you lived in the world and so if you were Canadian every fourth Wednesday you couldn't install new gems for three hours and there was nothing that anyone could do about it. The other downside of the standalone API is that we built it in Sinatra and SQL because it was super tiny and hyper focused and just returned some JSON and Marshall data but despite it being a completely reasonable decision I think at the time it meant that not as many people were familiar with Sinatra and SQL in comparison to the RubyGems.org app which was written in Rails with ActiveRecord and so we wound up with a lot less contributors to the Bundler API I think partly because people didn't know it existed but also partly because even if they did know it existed they weren't familiar with the framework and tools that we had built it on top of. There are entire talks about this process of ddossingrubygems.org building a new API and optimizing that API until it was fast enough to actually support all of the Bundler users in the world. I gave a talk called Deathmatch Bundler versus RubyGems and Terrence gave a talk called Bundler Install Why You So Slow Server Edition both in 2013, if that's interesting to you you can check that out for a lot more details. On top of working on the API we did still make some cool new stuff in Bundler including multi-threaded installs which was awesome you no longer had to wait for the last gem to download and finish installing before you could start installing the next gem. In those mythical 600 gem applications this makes a really, really, really big difference. We also switched to a non-recursive resolver. Smitsha kind of showed up in the issue tracker one day and said, I've never done this open source thing before am I doing this right? I completely rewrote Bundler's resolver. And I said, wait, you did what? And it actually worked. This was a really big deal because on JRuby in particular the old resolver was recursive and would call itself again and again and use the arguments to the function to retain the state in each iteration. And unfortunately on JRuby, every time you call a function there's not just a Ruby stack with arguments there's also a Java stack with arguments and Java stacks are big and basically maybe every, if you had a big application or at random every fourth time when you ran Bundler install on JRuby it would crash because of running out of memory for all of the recursive call stacks. So that was not cool. This fixed that. And Smitsha went on to become a core team member on Bundler after his first PR.  We also added HTTPS support. This is like when around the same timeframe that GitHub was saying, oh hey, you can actually connect securely to GitHub and download things. So got that put into Bundler and some uncool stuff. We had Bundler's first CVE security issue. The super short version is don't put source in your gem file twice without making sure that at least one of them is attached directly to a gem. If you have multiple sources, basically someone, because rubygems.org is public, anyone can push a gem with any name. And so if you say kind of blindly, oh just pick gems from any one of these servers, someone can put a gem that you don't want on one of those servers and you might get that instead. And that can be, it doesn't have to be, but it could be very, very, very bad. So to avoid that you should use the block form of source where you say source something, do some gems after the first source and then you're fine. You'll at least get the gems from the source that you expect to get them from. That's a little bit of a simplification but you can read more about it if this alarms you and you use multiple sources and you'll figure it out. This is the point at which having a separate API totally sucked and while the API was an optimization, so you could still install gems if the API was down which meant we didn't like set it to wake us up at three in the morning if it went down. We figured, excuse me, we figured people could install gems slowly until we woke up in the morning. But anytime it went down we did get a lot of people complaining about when we'll install it suddenly being very, very, very slow. And so it was exciting to have this great practice DevOps project, really? What's the downside risk? You're not gonna break anything. But it slowly developed into a huge source of stress because you're thinking about making sure that it's up all the time every day. And no one wants to deal with lots of stress especially while not getting paid and doing it for free. Not very surprisingly at this point, many of the people who had previously been very enthusiastic about working on Bundler and RubyJams became very less enthusiastic. But fortunately as that was happening the Ruby community kind of simultaneously came up with several ways to start funding development on these projects. Ruby Central which organized this fine conference has a fairly regular practice of giving out grants to work on Ruby open source projects. Basically if they have left over money after running the conferences they will pay devs to work on Ruby open source with that money and that's pretty cool. Grants to myself and other people on the Bundler and RubyJams teams meant that we were able to finish releases, keep working on the new Compact Index, bunch of other stuff. Around the same time Stripe started their program where they give open source grants to let people work on open source for I think the Stripe program does three month grants. And one of the grants went to a college student who was named Sam Giddens and he worked on Coco pods at the time, the Objective C equivalent of Bundler and they didn't have a dependency resolver yet and so his Stripe grant was to build a dependency resolver for Coco pods. Coco pods happens to be written in Ruby and so we kind of got together and inspired and agreed to have this dependency resolver get used by not just Coco pods but also Bundler and also RubyJams and today it's even used by Berkshaw, the Chef dependency manager and we all share this like good, well documented actually relatively understandable dependency resolver library which let me tell you is a huge improvement over the previous Bundler resolver. This is also the point at which Stripe and Engineyard started funding the Bundler project directly and on top of helping fund some development work that money made it possible for us to incorporate Ruby together. And that's how I have this shirt. And so Ruby together takes funding from the community and uses it to pay developers to work on community projects which is pretty cool. Today we pay for work developer time spent on Bundler RubyJams, the RubyJams Rails app, the gemstash gem server, ops work on the rubygems.org servers and we even started paying Christoph, the developer of the ruby toolbox to start working on the ruby toolbox 2.0 open source project which is pretty cool. So while Ruby Central does give out grants and pays the bills for the servers, they don't fund kind of the ongoing maintenance that means that the servers don't go down in the future. As Ruby together grows, we'd love to pay for more Ruby open source project development time but we can only do that if you and your companies sign up as members and help fund that for us. So please check that out and think about doing it. Ooh, I just knocked my coffee over, sweet. So with support from Ruby Central and Stripe and Ruby together, the Bundler RubyJams project started to see work done by paid devs on a pretty regular basis. We couldn't afford to hire anyone outright but we could afford to pay for a few hours a week from a few people and probably not too surprisingly, paying people meant that they showed up on a regular basis and actually got things done and that was amazing. We were able to ship stuff that had just kind of been sitting around, oh, we should do this someday for literally years. One of the big things we were able to do is finally move every request to rubyjams.org behind the Fastly CDN which was a huge improvement from before because before you would make a request to RubyJams, RubyJams would say, oh, this is a gem that's in Fastly, go talk to Fastly and then you would go talk to Fastly and then Fastly would say, oh, I don't have a copy of this gem yet, let me go talk to RubyJams and then RubyJams would send the gem to Fastly, they would say, anyway, it was terrible. This is much faster. We were also able to move the Bundler API back into rubyjams.org. It's no longer a standalone application and thanks to having people actively doing ops for rubyjams.org, we were able to, the new rubyjams can handle the 10x increase in traffic that comes from having this API and it's not a big deal, which is super cool. We finished the Compact Index which is a way of telling Bundler users about gems without having to do that like infinitely recursive round tripping API thing and it's a big improvement. You can just keep a copy of the list of gems on your computer and you don't have to get it again every time. For a bunch more detail about that, check out my talk, Extreme Makeover RubyJams Edition from RubyConf 2013. Bundle install, finally, sometimes, now fast. Couple other notable things that we did in this period of actually having people working on stuff. We made it so that you don't have to use the gem file if you are not a fan of file files. We also made it so that you don't have to use the gem file .lock if you are not a fan of files named .lock that can't be deleted. There is a ticket on GitHub from, I think, eight years ago now, right after Bundler 1.0 came out that says, .lock is the wrong extension for this file and we were like, we believe you, it's too late. To be clear, this change is optional even in Bundler 2.0, we're not getting rid of either the gem file or forcing you to use gems.rb, it's just an option that possibly makes life nicer for you. We also added Ruby version locking because after adding the Ruby version to the gem file, we discovered the problem was we didn't know things like which patch release you were locked to and we didn't have the ability to let you change that version between, I don't know, .1, 2.2, .1 to 2.2, .2, now you can and it's better. We added a bundle lock command which now lets you add platforms so if you want to install on an additional, like if you want this bundle to work both on, say, Unix machines and JRuby, you can now opt into that and install on both without a lock file that changes all the time. We added a doctor command from Misty Dimeo that tries to help you figure out why your bundle isn't working, especially if you have gems that are in a weird state or the native extensions haven't been built or something like that, pretty handy. We added a pristine command which lets you, it works just like gem pristine and lets you undo changes that you may have made locally to your installed gems in your bundle. We added options for bundle update that let you say no, only give me major, minor or patch level changes, which is pretty handy. We added mirror configuration which lets you say, oh, whenever I say gems from RubyGems, use this server that I keep locally that's a mirror that you can get to faster and we added checksum validation. So now, Butler knows what the checksums of each gem should be and checks them. That's what checksums are for. It's pretty good. Can you tell that once we started having funding, we started developing a little bit faster. There's another slide. We shipped a plugin system in beta that lets you build command plugins like new bundle commands in their own standalone gems. It lets you build life cycle plugins where you want to do something specific after say, I feel like a great example of this is you can generate C tags from gems that you, in your bundle, as you install them. And source plugins, so in theory, tomorrow, if you want to, you could build a gem that lets you install bundles from mercurial repositories. I don't know of anyone who wants to do that, but if you want to do that, could be you. So today, we just shipped Bundler 1.16 with everything that I just talked about. We're working on Bundler 2.0 with a target release date, very ideally, I'm crossing my fingers of Christmas. And I don't have room in this talk to include details about 2.0 because we're almost out of time. But Colby Swandale gave a talk at RubyKaigi maybe two months ago about just Bundler 2.0. So if that's super interesting to you, check it out. But the very short version is while we do plan on making breaking changes in Bundler 2.0, we think compatibility and stability are both super important, and we're going to make sure that it's possible to have applications on your computer that some use Bundler 1.0 and some use Bundler 2.0 and they will both keep working fine. We're not gonna like force everyone to mass upgrade to Bundler 2.0 because that would be terrible. I cannot even imagine dealing with the support headache that that would cause. But in the meantime, here are some cool things that get you most of the way towards 2.0 but are just config options that you can turn on today. If you turn on only update to newer versions, then the bundle update command will never update you to an older version of a gem. Seems like a good feature, but we can't turn it on by default until 2.0. You can disable a multi-source and then Bundler will stop you from having an insecure gem file and just raise an exception and say, actually, this is very bad and you're opening yourself up to security problems. Also will be on by default in 2.0. You can turn on specific platform which tells Bundler, oh, you should actually do your resolutions respecting the OS and CPU architecture and version that I am running on, which it didn't do before. This will also be on by default in 2.0. And you can turn on global gem cache, which is super cool because it means that Bundler only downloads gem files once and only compiles native extensions once and then shares them across all of the applications on your machine, which pairs very well with another option, default install uses path where every gem gets installed into its own place for the application, but that cache means that those gems don't get downloaded twice and Nokogiri, for example, doesn't get compiled twice. It's super great. These options will also be turned on by default in Bundler 2. Back to the HTTPS thing. Unfortunately, we shipped Bundler with a GitHub option that used HTTP, which isn't secure, but we can't change it because some people don't have open SSL support in their rubies, but you can change it. So, Bundle init creates a gem file that does this and you can overwrite the GitHub option to say, oh, only use HTTPS. We made it, that's it. Now that we're completely caught up on the history of Bundler, I have a few last second tips and then we're totally out of time. So, here's the chaser of workflows. Instead of Bundle execing, you can run bundle binstubs something and that will create a new binstub in bin whatever that you can commit to your repository and then any time you run it, you will only get the correct version of that gem for your application instead of having to be in the right directory, bundle exec, et cetera, et cetera. This is super handy for cron jobs and honestly, my muscle memory of just running bin something is much easier than having a shell alias for bundle exec. Bundle viz lets you see your dependencies in a graph. Wow, that's really hard to read, I'm sorry. You too could have a really hard to read graph of your application's dependencies. If you wanna start running your application on a new platform like JRuby or Windows, you can use that lock option add platform and you'll get a stable gem file dot lock that won't change as you install on both platforms. Pretty cool. The get local development thing that I mentioned earlier, you can check out a gem that your application depends on, start using the local copy, make changes, Bundle will update the lock file to the commit that you've made locally and then when you deploy, Bundle will make sure that you are still running the code that you expect to be running rather than whatever you had actually remembered to push. And if you've ever wanted to write a one file script but that needs some gems, Bundle inline is super good. Most people don't know this exists, but it's so good. You can write a script that requires Bundle inline and then you just put a gem file block at the top of your script and then you can start using the gem, it's amazing. Here's what it looks like when you run it. Even if you don't have the gem installed, Bundle says, oh, I will install that gem for you, now your code can run. This is super great for single file scripts. Kind of came up earlier, you can search your gems using the bundle show paths option which prints out all of the paths that your gems are in and then when you find the gem you want, you can open it directly by running bundle open and then you can edit it, finish your debugging and then you can run bundle pristine to undo the changes that you just made to that gem locally. It's a pretty good workflow. And last, in my personal favorite quality of life improvement, you can turn off post install messages and no one will ever tell you to HTT party hard again. I somehow put that slide in twice. I'm sorry, there's the punchline, the end.


Okay, I don't know if it takes some time to load but I don't see the live. Oh, I think something's going. I see an advertisement. We're live. We're live. No. All right. Hi guys. Hi everyone. So welcome to our live. This live is meant to be interactive for us to go back and forth. So make sure to use the chat as much as possible, drop your ideas and on what we're discussing today, whether you agree, disagree, like, dislike, or have anything to add to the conversation, please do so in the chat. This is meant to be fully interactive. Yes. And if you don't know what topic we're talking about today, we're going to be talking about family relationships since the holidays are just around the corner. And we're coming to a time where more family gatherings are happening, whether in person or virtually. So we're going to be talking about family relationships today. So by the way, we added a new cool feature to our live streams. It's called super chat. You can send us some love by donating a small amount to our channel to help fund our videos so that we can keep creating helpful contents for you. Your donations help us reach more people who need help dealing with mental health, because as you know, we create content on our channel for mental health, especially young people. For anyone who donates more than $25 in the super chat, we will schedule a separate 15 minute one on one session with you on something more specific that you're wondering about in regards to mental health and mental wellness. So if you don't know where it is, it's that dollar sign in the square underneath where you type your responses for the chat. So if you click that, then you can send us some love through the super chat. Yes. So our live today is going to be an open discussion about family and family relationships. So in your own words to whoever's here, how would you describe your family relationships? You know, they can be great. They can be stressful. We all have our family things that we go through. And the holidays and more family time is coming up, which means families are getting together. Usually it's in person, but it might be on zoom this year. So either way, families meet during the holidays and that could be a very good thing or a very stressful thing as well for some people. So please in the chat, if you're here, please say hi where you're from. And if you have any thoughts about family. Anything's okay. Toxic. You're not the only one. Trust me. Anyone else where you guys all dropping in from, can you guys leave a comment in the chat where you're dropping in what your thoughts are on your relationship with your family? So while you're writing that, you can also think about what factors do you use to determine what that your family relationship is good and what factors do you use to determine that your family relationship is not so good? So that could be another question you can reflect on and see because family is really the closest people to us. Most of the time. So what factors determine if it's good for, you know, you feel good about it or not. And where does that come from for you? I see Lita types of me in the chat. Hi, Lita. Hi, Jersey. So she says mostly based in support and loving, but also very codependent and lack of deeper communication. You're not the only one. Yes. I'm sure maybe some of the other people in here can relate to that kind of family setting too. So don't be shy. Please share what you guys feel about your family, whether it's good, the bad, the ugly, the really great. Anything's okay. We just want to get some dialogue going about your relationship with your families that we can expand our conversation from there. So you guys can keep typing and I'm going to just say my two cents about families. So as Gabby mentioned, family, they're the closest people to us, literally connected by blood and DNA. And because they're so close to us, the people who are the closest to us can give us the most joy in our lives and sometimes the most pain. And I think that's a very interesting thing to know. Why is it the people that we love so much are the ones who give us the most pain are the ones that give us the most suffering. And I think something to kind of just talk about and discuss in terms of family, because I think everyone goes through those highs and lows of being with family. I think the reason why we get the most joy and pain from family is because we are all emotionally attached to the people that we are the closest to us.  So when there's emotional attachment, we unknowingly demand certain things from these people to feel validated and secure, because every single person has this desire, this innate desire to be validated and feel secure in their community and their society from their peers. So I think we subconsciously kind of want the people closest to us to make us feel that way more so than other people. Like if you just had an acquaintance, you don't really care that they validate and accept you because you don't have that emotional connection as much as you do with family or people closest to us. So I think we just have really high expectations from our family members to make us feel the most loved, most secure, most validated. And when our families don't provide that sense of validation, whether it's through their actions or through their words, through their little snooty comments sometimes that our family members say to us like passive aggressive comments that make us don't feel that validation security that we seek from them, then we feel so hurt, so disappointed because the expectation of how we want them to act towards us is not met. And our needs of feeling secure and validated is not met. So does that make sense? Can you guys relate to that kind of situation?  And so if you have a room full of these family members who all expect the same thing out of each other, that sense of validation and security, it becomes a brewing pot for attention. And it's because we all instinctively in that family setting, whether we realize it or not, we all want to feel validated and secure through our family members, words, actions, behaviors, and thoughts. So are you guys following with following me so far? Yes. Yeah, please type in the chat if you have any comments about this too, feel free to just put your two cents whenever Gaby and I say something. I see there's people who wrote in. So Lila wrote, I have had successes and challenges with families, especially my family of origin and my stepdaughters. And also Lila wrote, there are also people in my family that don't talk at all and cut each other off. I'm known as the peacemaker, but lately not so peaceful. Lila, just to side note, I relate to that too. I also have family members that we got, our families got like this and we don't speak to each other, but I think it's such an unfortunate thing. But anyway, just to side note that you're not alone in that kind of situation. Exactly. Rand says I'm almost homeless. My older brother is off the grid and my mom is in rehab. So that's a difficult situation. Lila also says it is hard to be in a family and feel so judged for thinking differently. That's true. Yeah. It can be a very lonely and isolating thing. When your family members don't think on the same, same wavelength as you. And so they don't give you that sense of feeling like connection and validation because you feel so removed from these people. So I feel you. Claire says my parents are kind of narcissistic and had bad childhood and teen life. So it seems like, oh, so they had a bad childhood. So they, if they, if that's what you meant, then they could have, you know, that's what made them the parents they became like they're upbringing and things. So, you know, dealing with those kind of things is very difficult to sometimes. Okay. So I'm going to also from what Linda said. So if you approach your family members and spend time with them during the holiday season in a way that makes them feel loved and validated and accepted through your words, your actions and your thoughts, like Linda said, that's those are the things that we want validation for from our family members. Then it can create an environment where your family members needs will be met. And instinctively when our basic needs are met as humans, we have no choice but to feel happy and content in that environment. So we also have to see our family members as just human beings, but rather than labels of my mom, my dad, my uncle, my brother, because all those labels come with expectations and there is not a single person in the world that can satisfy all your expectations. And especially if you're someone who has high expectations, but if you look at them with more empathy and understand that there's someone just like you with all these thoughts and emotions and feelings.  So if you look at them with more empathy, you can, it can help you create a happier environment if you, you know, maybe put yourself in their shoes and see a little more where they're coming from. If you don't see eye to eye all the time, things like that. So, and then removing the labels to not have those high expectations of what they should be because it's something you saw in movies or, you know, you like heard about that like this is how a parent should act. You should try to remove those labels if you can. Yeah, Gavin, I love what you said about the, like comparing your parents to what you see in the movies. Right. You know, this is kind of a personal story for me, but my parents, my family, we immigrated from South Korea. And so I came here when I was very young. And so I faced a lot of like culture clash because like the parents in there, like traditional upbringing of how they were raising me clash with what I saw from my American friends being raised, like, and seeing so many comparisons, like, why can't my Korean parents just be like the American parents that I see from my friends? And why can't they let me do what the American families like, let me do. This is America. Like I would like fight with them all the time, you know, because I didn't appreciate the subtle, subtle actions of care and love that they were showing me from their cultural perspective, from their eyes, from their upbringing. So that caused a lot of tension and a lot of anger inside of me when I was growing up because I said, why can't my parents just be American? Like, why can't my parents just let me be like the American kids?  But, you know, now looking back, I really appreciate the things that they did and like the restrictions that they placed on me. So for example, like, I was never really allowed to have sleepovers and that really made me mad when I was young because, you know, American kids, they have sleepovers all the time. And it's kind of like a, like a fun thing that American kids do. But for whatever reason, my parents would not let me have sleepovers. And that made me so angry. And I didn't understand the, the logic behind that when I was young, but then growing after I grew up, I realized that, you know, in Korean culture, it's not, it's not, it's considered kind of rude to sleep in someone's house because it's like you're burning someone else. And they don't want to cause that burden on other people.  But anyway, just an example of trying to compare your parents to what you want them to be and what you see in the movies and what you see out there in society. Because even though the families that you envy, perfect on the outside, you don't know what's going on behind closed doors in their own home. Right. Yeah. So I just want to share that little moment about what Lila said in the chat. She says, thanks for the validation. Yeah. Yeah. I have a need to feel validated. Yeah. And then also happy vibes says, I think it hurts way more when the people closest to us don't understand us. So happy vibes. You bring up a really good point because are you, and it hurts when they don't understand you. And even this need for me to be understood by others is validation. Because if I want to be understood by someone that is, and it's not something that I don't want to be understood by others, but it's actually close to me. It's this innate desire for me to feel from their actions and behaviors. That I'm okay. That my thoughts are valid. That my, that my words are valid and it's understood. So that's also a desire for a patient. Yeah. But I totally get it, like, especially if you want to share your passion with your loved ones, but if you want to share your passion with your loved ones, then that could be very painful. Yes. All right. So please keep chatting in the, in the chat box and we'll get to those in a little bit, but I just want to add a little bit more of, to the topic of our discussion today. So this holiday season, whatever holiday you celebrate based on your culture, try to see your family with that kind of perception. As Gabby mentioned, we have a lot of expectations about the. In the future. The most important thing is subconscious expectation. We carry with the word mother. And this subconscious expectation, we carry with the word sis or brother or father, uncle, grandma, those labels seem. Harmless. But in p minds, when you're grandma, you have expectations of what a good grandma should do. just seeing them as human beings who just like me have the same need and desire for validation and security. So if you help, if you see your family with that kind of perception through your thoughts and actions and words, you would want to help your family in your holiday setting, feel validated, safe and accepted. So try to think of it like this, how when you gather with your family, how can I act, how can I speak, how can I think, how can I send out some kind of energy to make my family members feel validated, safe and secure because that is a basic human desire that I want and what other people want to on a human level, beyond family on a human level. So if you bring the energies of acceptance and love, then it creates an environment where other people create energy of love and acceptance too. Have you ever experienced when you're in a really bad mood but then someone was really nice to you and all of a sudden that changed your energy and then the next person you met, you don't know why but you acted nice towards that person?  That's no coincidence, that's no unplanned action. Energy transfers. So when I create an energy of love, acceptance and validation for my family, then your environment, your family, when they feel this validation and acceptance from you, then for whatever reason, whether they realize it or not, they're gonna pass on that energy to someone else in that room, someone else in that setting. So if you, for those of you who energy is something that's difficult to understand because I know energy is available, so it's kind of hard to like, what is this energy she's talking about? Think of energy as vibes. You all know what vibes are, right? So vibes is kind of like what you feel when you just sit next to someone and you don't have to talk to them, you don't have to like even make meet eyes with them necessarily. If you just sit next to someone, some people who you just feel comfortable with, even though you're not talking, something, you feel comfortable with this person or this person feels good, then you say, oh, this person has good vibes.  You can't explain it, but something just doesn't feel right. So, and when we meet people who are like that, we say, oh, this person has bad vibes. So vibes, that is the energy you feel resonating, whether good or bad, resonating from that person. So if energy is hard to understand what I'm talking about, then think of energy as vibes that you feel off of people. Yes.  Most of the times girls run to their mom. That's true. Rand says positive thoughts. Francine says, true, we all need validation. Yes. And Francine says, acceptance and let go of expectations, difficult to do, but we have to try, exactly. And getting rid of those labels and expectations of their role, exactly.  That's so beautiful and amazing that you have a very strong mom. I think maybe some other families can relate to that statement too. Yes, me. So as you're still commenting or if you have any thoughts, I think it's best now to, we're going to show you a way to send energy, whether it's virtually or in person to a loved one or a family member. So basically energy is like Linda explained the vibes next to someone, how you feel next to someone. But it's also all around us and it fills the space around us and can move around us with our mind, intention and our focus. So that means we have the power to focus our energy on using our brain, by using our brain. And we can focus it towards a person, a place or a thing. And so since we're talking about family relationships, let's learn how to send energy towards a person. So, and this is probably especially very nice if because of COVID you can't be around many people or your family. So this is a great way to show them your love and care. So the first thing with sending energy is to recognize that you are a transmitter or a channel of energy.  So you're not using your own body's energy. You're using energy from the universe that comes down and you can transfer it that way. So then if you don't do it that way, then you get really drained if you use your own personal energy. So, yes, so you have to basically receive body first and then send it to somebody.  So you receive and then it goes through you and you send. So everyone who's in the chat, I think it'd be great if you can think of one person, one family member or one loved one that you'd want to send some loving energy to. And you can type it into the chat so it's clear in your mind and clear in your intention who you want to send it to. And I'll wait a little bit and then we'll do a little exercise and meditation. So if you want to get in a little in a comfortable spot where you can do that, we'll wait a tiny bit if you type who you want to send your energy to. I'm curious what people type. Can we send energy to some politician to win an election? I mean, you could send energy to anybody you'd like. Anybody. Oh, and this person doesn't even have to be alive. Right. And it, well, we're doing a person now but you could send it to a place, a thing like you can really you can really if you focus send energy to where you want. Okay. So as you keep typing, I think we can get started. We have some people who wrote down their intention of who they'd like to send to. So I'm gonna lead and then you can watch Linda to see how to do it as well.    So now imagine above your forehead, there's an energy sun or a bright, bright ball of energy that's going to come down into the top of your forehead and you can actually tap this area. So gently raise your hand and just tap the very center of your forehead or of your the top of your head to stimulate that area of it. Okay.  Separate your hands into a ball kind of shaped with your hands not touching and feel the heat in between your palms and focus your mind to in between your palms. So you can move this energy around a little bit by expanding and making the space smaller but you may feel heat here or a tingling sensation or magnetism or even some coldness just focus on the sensation in the center of your palms. That is energy.  And imagine that from the top of your forehead there's bright energy from the universe that goes in through your forehead, goes down to your chest and then down to your arms and comes out through your palms and goes to the person that you're imagining. And if you're able to imagine a bit more, imagine this energy is surrounding their whole body like an energy capsule that's protecting them from any negative or dark energy and thoughts and emotions. Just imagine they're in a golden bright ball of positive bright energy.     All right, so how did it go for all of you? Can you share what you felt in the chat and what you experienced and if when you were connecting with a family member, maybe you could visualize, some people can visualize more than others. So maybe you could visualize their facial expressions or them doing something or things like that. So if you experienced any of that or just whatever you felt, if you felt warmth between your hands or warmth sending, please share that in the chat box. Francine asks, can we do this to someone who we want to try to accept but fully haven't? Absolutely, you can do this to anyone you'd like and you could send them loving energy, showing that you're putting in effort to accept them. Definitely, that is a very, very positive thing to do. So Francine says, I saw their face and warmth. I saw a golden light around him. That's really beautiful. Lila said, really wonderful experience. Thanks for the guided meditation. It was a beautiful visualization. Thank you. And Lila says, very clear and revealing of what I wanted to express to them for my heart. I saw her brighter and healthy and felt energy in my hands, especially left. That's so great.  Does this even really work? How do I know that this is having any effect? So energy is different from our physical bodies. Our physical bodies can only be in one place. We can only be here right now, but our energy can transcend time and space. Energy is very free. So that means with our energy, we can go into the past, we can go into the future, we can go to Korea, we can go to Japan, we can go to Africa, we can go anywhere we're not bound to time and space compared to our physical bodies that can only be here, only in the present moment in this exact location. So using that principle of energy with the power of your mind and your intention, you can channel energy to go wherever you'd like because as Gaby mentioned, in this space all around us, it seems empty, this empty vacuum all around us, but actually it's full of energy and that energy is vibrating at infinite potential, which means it's waiting for somebody with their brain and intention to move it a certain way. So it's just vibrating here with infinite potential, waiting to be used. So when someone who has the awareness of how energy works and can utilize the energy around their space to channel it from their brain to a certain person, a certain event or a certain person, the energy here moves that way. And this is all based on quantum physics too. So it's not just some spiritual hoo-ha that I'm sharing with you right now, it's all based on quantum physics that energy moves with the intention of the observer, that observer meaning you, the intention of the person who is sensing this energy, aware of this energy around you, has the power to move it to any direction, anything, any place, any person that you want. So based on quantum physics, this is how this energy, we say life particles, the basic building blocks of life can move through us as the transmitter and the channel of this energy. So you can do this through a Zoom or you can do this in person, anything is okay. The person doesn't have to be physically next to you. They can be doing whatever they want, but with you focusing and directing the energy or using the power of your mind, you can always send energy to a situation, person, place or a thing to help them receive better energy, a good energy from you. So this holiday season, do you think that you can have better time with your family by seeing them as human beings rather than the labels that come with the expectations? The labels of how they're related to you, grandma, mom, dad, uncle, aunt, brother, sister, because those labels as we mentioned earlier in our discussion come with expectations. And yes, it takes practice because those expectations are so subconsciously ingrained deeply inside of our minds, but keep trying. And I think someone mentioned earlier in the chat that it's difficult, but we'll keep trying.   So from that space, you can have compassion and resonance that these people have needs just like me. So see from those eyes, not like because you're my mom, you're supposed to do X, Y and Z for me. Because you're my brother, you're supposed to talk to me like X, Y and Z, not like this. They have their own insecurities, fears, doubts, needs just like you. So ultimately, if you want to have better family relationships, it's important to realize that improving your relationship and communication with your family is not really for them. It's actually for you. It's not easy. It's emotionally frustrating, yes, and it's painful sometimes, but the person who grows, the person who gets the reward at the end for learning how to communicate better with your family is ultimately you. It's not them. The person, as I mentioned, excuse me, the person as I mentioned who is gonna grow from that experience is you. And the person who's gonna be the bigger person from this is you.  So this exercise, this practice, this painful agonizing practice of communicating and sending love, validation and acceptance to my family is not to make your family members happy. That's a very important thing. You're not doing this to make other people happy.  That make sense? Yes. So don't ever feel like you're doing this for your family. You're sacrificing for your family because you're not.  Yes. So just a few more comments came in. So you both, Iwa says you both are doing a great job. Thank you, love all your videos. Thank you. Thanks, Iwa. Yes. Rand says, thank you girls. I really needed that cold white light. That's great that you felt something in your hands. And thank you for watching. And then Francine, yes, thank you. I appreciate and love you both. We love you, Francine. Love you, Francine. Claire says, I always thought good for my beloved one, but they betrayed me enough. How should I heal from this? The trail is not easy, Claire. It really isn't. And it's even more difficult to keep trusting people once you've been betrayed so many times, but you have to understand that when we feel betrayed, we go automatically into this thing like it's my fault. Somehow it's my fault. Somehow I wasn't lovable enough. Somehow I didn't do something good enough for them to stay with me. I messed up and that's why they betrayed me. We go into the self-sabotage that it has to be my fault that this person betrayed me. If I did stuff right, they wouldn't have betrayed me. You feel that way, right?  Because how someone talks to you, how someone behaves, how someone acts, it's just their perception of you, which is different from someone else's perception of you. Not everyone looks at you the same way the person who betrayed you looks at you, right? So their perception is just their opinion. It's not truth. But how they act, what kind of energy, how someone treats the other person says everything about the energy that they're carrying inside. What kind of character they have, what kind of energies that they're dealing with inside their body, heart, and mind. So don't blame yourself, Claire. It's not your fault. It's not your fault at all that you were betrayed. It has nothing to do with you as a person or your character, but how they treated you says everything about the other person. So you really have to get away from the self-blame, self-sabotage that I see so many people do, including myself too, if I get hurt, if I get betrayed, I think it's me. I think I messed up. I must have done something wrong for them to do this, but it's not you at all. It says everything about their character. So when someone betrays you, just say, ah, so that's the energy that you have. That's the kind of person you are. It says nothing about me, but it reveals everything about you. That's a good way to look at it. So while we're, Lita said, great, thank you so much. Thank you, Lita. I wanted to mention if you're wanting to see some more kind of meditations or sending energy, meditations that we did today, Linda actually did already a 10-minute routine on our channel on how to send energy and there's other types of meditations there. So in our 10-minute routines playlist, which I'll link in a second in the chat, you can check that out and experience these and use these videos and exercises for your own practice and to learn more and get more connected and learn about sending energy and Linda actually made a video too about life particles, which is basically the little particles all around us that we use to send energy with. So you can also check that out as well on our channel. And then if you notice, it's hard to see today because of my camera angle, but I'm wearing this awesome t-shirts.  So if you resonate with this message and if you wanna join our tribe, check out the Take Back Your Brain t-shirt on our website, which Gabby will link in the description below as well. Yes. The chat. So make sure you get one of these. Maybe next time you guys join our live, you guys can wear the t-shirt with us. Yes. That'd be so awesome. Yeah, they're great conversation starters. You go anywhere, everyone's like, what does that mean? Yeah. So here's the t-shirt link I just put in the chat and then here is the routine playlist, 10-minute routines playlist link. Yay. And then before we wrap up this live, oh nice, Lita. Lita just sent a donation from the super chat. Woo. Lita, Lita, Lita, Lita, Lita. That's so nice. Thank you. You guys see in the chat, there's a little orange thing where Lita donated $19.99 to our channel. So yes, just like that, you can donate a small amount to us in the super chat. That's that square dollar sign and that will really help us fund the channel to create more content for you guys and be able to help our community, especially youth who are dealing with mental health, mental wellness issues, especially on the topics of loneliness, depression, anxiety, and stress. Those are kind of our key terms that we help our community with. So if you love our content, if you love our videos, if you wanna give us a little support, then please donate in the super chat as Lita did. Lita, Lita, Lita, Lita. And send us a little love and we would appreciate it so, so, so much. Thank you. So does anyone have any final questions or comments, concerns, or anything to share about today's topic or their experience on the meditation or anything? This is your time to ask us any final things. Anything at all or any comments about, oh, when I was sending energy to this person, I had this awakening or I had this emotion, or when you talked about this, I felt this way or something like that, anything at all. Lita, he, he, he, he, he, he. Ha, ha, ha. Or maybe like, oh, I can't wait to join your live next month. That'd be nice, a nice comment. So yes, every month we do one YouTube live. So next month we'll decide what the topic is, but you can subscribe to our newsletter on our website and get an email reminder about what the live will be and also follow us on social media channels, Instagram, Facebook. You can also find more information there as well. I think we have one comment. Kaiser, I hope I'm saying this right. I'm sorry if I didn't say it right. Kaiser, I feel my body's divided into two parts. I know what you're talking about. Most people, they feel divided right here, right? Your head and body feel separated, right? That's actually unfortunately a normal thing that a lot of people feel when they don't practice mindfulness. When your mind is racing at a million miles per hour and your body can't keep up with your thoughts. So people who have a lot of thoughts, a lot of thinking, a lot of worries, a lot of anxiety, they feel like cut right here and their head is this way and their body is this way. So I'm actually gonna create a 10-minute routine video sometime next month in December about how to connect your mind and body together to make them in one place. So look out on our channel for a video about that. If you haven't done so already, subscribe to our channel and click the bell so that you can get notified when that video goes up so that you don't miss it. So make sure you click. Yes. Yes. Yeah, Kaiser says, I love you for your video. Thanks Kaiser. Thank you. Thank you for tuning in to our videos. Thank you. Okay, I think it seems like nobody else really has any other questions. If you guys, after this live is over, if you're like, darn, I wish I asked them a certain question, you can always email us. Our email is braineducationtvatgmail.com. So anything that you wanna say is okay, I'll leave it in the chat, educationtvatgmail.com. So you can just email us there with any inquiries, comments, anything that you want. Yes. All right, then with that, I think we can end our live today and as Gabby mentioned, we will come back next month with another topic. So also if you want to stay in touch with whatever topic we're gonna discuss, then sign up for our email list on our site or you can just click the bell on our YouTube channel, subscribe and click the bell so you'll be notified of the next month's topic. So you can join us again next month too. Okay. Yes. Thank you all so much for coming, Claire, Kaiser, Francine, Rand, Lita, Perry, Iwa, anyone who's still here, Lila, I think she left early. Mina. Happy vibes. Yeah, happy vibes, right. D's on dreams. Design our money if you're still here. Yeah, I think that's everybody. Thank you so much. We'll see you next month. Bye, see you. Bye.