Scroll down to the description below this blog and I've created two events in DeMore Global Running and the DeMore Global Running crew. Okay so I'm feeling real good it's getting real but I I have to pack as a daily vlogger I need to pack in two ways my running gear and the camera gear so this is the running gear I'm laying it out making sure I have all the essentials in the plane with me just above my head in the in the overhead bin and then what is not quite as essential can go under the plane in my check-on but now camera gear Kipchoge's first and then I'm second in Amsterdam so I don't want to I want to make sure I don't forget any chargers and just oh tip of the day don't forget your watch charger I'm just gonna double-check that it's in my backpack because you know it's fun to be able to time yourself get the stats but more importantly share your story of running on Strava or whatever app you use with your crew your family members your friends that might be the first way that they figure out how you did in your race so that's why I like to use Strava it's just fun all right let's get the camera gear for the non essentials in this okay feeling real good about the situation I will add a few more items tomorrow to the suitcase and not the question of the day but is it even allowed to bring four pairs of shoes to a marathon I think it is I think it is two racing shoes the next percent of vapor fly four percent flying it's an easy day shoe now I am gonna be over there for ten days so that's why easy day shoe the beacons you better believe it and then a little more of an up tempo shoe because I don't want my legs to fall asleep while I'm over there I'm gonna do some yeah just tempo runs me you know strides of course and so the zoom fly threes from Nike will be the fourth pair of shoes so anyway I know it's a little it's a little much but I just don't want to I don't want to I don't want to miss out on this opportunity to do what I think I can do if you know what I mean all right let's get the and then yeah I'll add a few more items here tomorrow okay feeling good everybody I here we go everyone feeling real good about the packing back in the studio I've got I've got updates for you so I'm gonna look at my phone because I don't want to mess anything up all the details first of all from yesterday's question of the day just gonna raise us up a little bit from yesterday's question of the day thank you for everyone that's chiming in about what to pack for a marathon I can't hold my phone when I talk what to pack for a marathon shout out to Adam and Janet first of all Adam is on the ground in Amsterdam giving the updates on the weather thank you Adam and it sounds like it's been very rainy the past three weeks in Amsterdam which definitely influences what I'm packing as far as warm weather gear rain gear and yes the Nike next percent so thank you Adam shout out to you and then to Janet who sent me this incredible message both of these were messages on Facebook Janet sent me a message basically in his dovetails to what Adam is saying she said don't forget to bring a rain slicker or a poncho so I'm on the hunt for one right now to the starting line in case it is raining and then I can just toss it to the side so great work Janet and she also had one other recommendation let me find it here throw away jacket hold on oh she also had the idea of make sure I actually bring especially if it's raining or the potential to rain my green hat to help keep the rain out of my eyes you know who knows what's gonna happen also great job Janet thank you so much alright now for the details for the meetups the group runs in Vienna and Amsterdam so I said this about two months ago on the vlog for Amsterdam the meetup in Amsterdam are you ready are you gonna be in Amsterdam at the marathon here are the details for the group run in Amsterdam and all right I had to just pick a date and pick a time and pick a location I just had to do it all right so this is this is what I came up with Friday October 18th so two days before the marathon all right so then Saturday I'm just gonna chill out and rest so Friday October 18th at 10 a.m. local time so whatever you know in Amsterdam local time Friday October 18th at 10 a.m. local time in Vondelpark however you spell actually I'll put it on the screen in a title Vondelpark all right but the park looks pretty good size so where in the park are you ready for this we're gonna meet at the statue of just Vanden Vondel Vanden Vondel so I'm not saying that right but that's okay here's a picture of the statue so we're gonna meet at this statue at 10 a.m. on Friday October 18th all right there you have it it'll be on Friday the two days before the race in Amsterdam in that park now if you're on Strava scroll down to the description below this vlog and I've created two events in demore global running in the demore global running group for the Amsterdam group run now on to Vienna okay according to weather reports on my end it's looking like it's looking like Kipchogi's gonna do it on Saturday like the weather is looking very good Saturday October 12th whichever day Kipchogi makes the sub two-hour attempt we are going to do a group run the following day at 10 a.m. so if it's Saturday then we will do the group run Sunday at 10 a.m. if it gets but if Kipchogi's sub two-hour attempt gets pushed to Sunday because of inclement weather bad weather on Saturday then we will do the group run on Monday at 10 a.m. that's just how I have to do it we have to remain flexible until we have an official start time official start date I will keep everyone updated on Strava in the demore global running event again it's down below in the description just click on that link and we will meet so it'll be 10 a.m. and we will meet at the finish line of Kipchogi's sub two-hour attempt again in the Strava event I tried so it's in that park that long straightaway park that looks amazing for running and by the way I will do eight miles pretty easy on Sunday and if you if you only want to do four miles with us perfect if you want to do if you're if you're in for a Sunday long run you want to do 15 to 20 or whatever you want to do that's great but we will meet at 10 a.m. in that park and again I tried to find the address for the that exact point in the park it's all listed in the Strava group run down below and I think I found the correct address for that but it's all subject to change depending on the actual attempt by Kipchogi okay also it'll just be the next day at 10 a.m. at the finish line the INEOS 159 challenge finish line will meet right there I'll have of course I'll have my green hat on and hopefully it's not like hopefully it is Sunday that we meet it might be Monday hopefully it's not Tuesday and I and Wednesday I really hope it's not cuz I'm I'm planning to fly to Amsterdam on Wednesday and then of course the group run in Amsterdam will be 10 a.m. no matter what in Vondelpark at that statue we will meet and I will only do four miles on Friday in Vondelpark because it's only two days until the Amsterdam marathon does that sound good everyone oh it's I can't wait to meet all of you it's gonna be amazing we can take pictures and just have a good time of course I will have my camera with me and it's gonna be epic so question of the day are you going to Vienna to watch or are you going to Amsterdam to cheer or are you going to Amsterdam to race or if you're not going to Vienna or Amsterdam because you live somewhere else in the world which is I would say probably most of you how are you planning to watch the Ineos 159 challenge and or the Amsterdam marathon a couple people were asking on Twitter today was a Twitter I forget it was somewhere they were asking how no Strava how to watch the Amsterdam marathon and frankly I didn't know but it sounds like they're gonna live stream it on the I believe okay I'll just put the I'll put the website right there that is the TCS Amsterdam marathon.com I believe is it so I'll put it right there in a title love you all okay vlogs not quite done we're going out of the studio going on date night with true love get an update on that baby boy and yes try and hunt down this poncho okay here we go here we go true love here we go did not hunt come look in the back here remember our mission hold on me unlock here here poncho right open that up I know that's falling off boom grab that orange right there orange orange orange orange orange orange there it is perfect aren't we set we are ready yeah so all right let's go get an update in the car I know it's crazy it's a crazy crazy world we're just make it making it happen I just gotta make it happen be decisive we had a big day true love true love had a big day it's been crazy remember the remember the situation yesterday we won't even go into it huh how are you doing how's a baby boy now we can tell now we can tell the vlog and move in and he's perfect and I love him oh you can feel some kicks little more so a little more often more just as I'm like laying down for bed yeah and I love it and we decided to wrap it up in the parking lot was struggling with the sun but we got it all right true love group runs I don't know if you know this but group runs in Amsterdam and Vienna oh yes so everyone that's coming to watch Kipchogi and or race Amsterdam we're gonna do group runs and again the links to the events are down below on Strava that is so cool is that amazing we should invite Kipchogi hey Kipchogi Kipchogi does anybody out there know Kipchogi what do you think come on or after Vienna or so what we're doing is the group run in Vienna we're doing it the day after Kipchogi's attempt so yeah nice cool down right it's gonna be good it's gonna be good so we love you all thank you for everything thanks for being here and we're off to a delicious dinner so amen alright shout nice throwback to yesterday's vlog on the right which is all about marathon packing what to pack for your first marathon in my case the road marathon and then on the left we're gonna toss it back to London where Kipchogi threw down so all right everyone see beauty work hard and love each other we'll see you tomorrow see you tomorrow


So the topic I'm going to be talking about today is RubyGems in general, and the impetus for this talk is that Carl and I just spent a large amount of months writing a wrapper around RubyGems for your own application called Bundler, which is going to be part of Rails. And so we got very, very familiar with a lot of RubyGems. The first pass what we did with Bundler is just to wrap RubyGems as much as possible and not have to worry about trying to push things upstream, but long term we want to try to push a lot of what we did back upstream and make it a sane thing for other people who are doing similar things to what we're doing, so sort of just a feedback of what we've done and how we think RubyGems can improve to make what we've done saner. So first of all, I've noticed that in all the presentations I've been at, there's this huge dead zone, so I've just not put anything in any of that spot. And yeah, I don't know how feasible that is for people, but it seems like a good idea if people can still tweak their presentations. So obviously RubyGems was released in March 2004. I think there's more history before that that I'm not aware of. The public history of RubyGems says that it started in March 2004. It started with version 0.2, so I think there's a good chance that something happened before that, but I just wasn't around to see it. RubyGems is good. Despite I'm going to enumerate a list of problems about RubyGems, RubyGems is actually really good. It may be the best packaging system for a language that exists, certainly up there, and it should not be... There are people who are attempting to say, like, we should have something entirely different conceptually, and I don't believe that. I think that RubyGems right now is a pretty good conceptual fit for what we're trying to do with RubyGems, but there are some specific problems that are not related to the concept of RubyGems, but are more related to implementation or specific details that I'm going to talk about. RubyGems, like I said, worked well for a long time, and I think we have to look at the bunch of years that we've successfully been able to grow the Ruby community with RubyGems as evidence that starting from scratch is silly if somebody would want to do that, and that there's a lot of... This is something I've learned from Rails. There's a lot of embedded knowledge in these projects that have been around for a long time that look disgusting and gnarly inside internally that is very hard to reproduce again without going through the pain again. Merb did this. Merb essentially tried to reproduce a lot of what was in Rails, and what we ended up doing was relearning all the lessons that Rails learned because we didn't have the knowledge embedded in the code. There's a lot of value in looking at code that already exists, and even though it's not the best code in the world, it still has information in it that's hard. Does this work on Windows and how? That's something that if someone started from scratch, they probably would just fail to do until the Windows people bugged them for another couple of years. That's sort of the introduction is I think RubyGems right now has a lot of information and it works really well conceptually, and it's a good starting point for the future.  This is my least favorite of the problems. I think everybody has experienced this problem, and if you go and Google for this... If you go and Google for this problem, you get stuff like this. The problem is somehow related to my having multiple versions of the active port gem installed. I could just try removing the newer versions of all the gems I have duplicates for, but I'd really like to know what's going on, and then never any response to those threats. Because it's conceptually complicated. It's something that once you understand RubyGems works, it's perfectly reasonable what's going on, but it's conceptually complex, and it essentially is resulting from people having a lot of gems installed in their system that are not related to their environment, the application. There's gems in the system that are conflicting. Here's another example. Somebody reported on a bug tracker that they had can't activate RSpec, already activate RSpec 1, 2, and then the result of that was state change from do to resolve can't reproduce it. Because it's a problem that's related to somebody's system. This problem was the impetus to doing bundler to begin with, and actually the precursor to bundler, which is part of Merb, which is just that there is system state that exists in people's RubyGems that is messing with other dependencies in ways that are extremely hard to understand, and certainly the masses of people using Ruby have incredibly hard time figuring it out, and people who are writing gems that have dependencies that are generating these problems almost never can figure out what's going on. That's the biggest problem I think in RubyGems right now is just this usability problem to do with dependencies. Second related problem is just the usage of system gems in general for applications. You might have a dependency in your application for launchy 0.3.3, and it requires configuration bigger equal to 0.0.5. I might have launchy 1.1.0 in my system, and so I'm developing my app, sorry, configuration. I'm developing my app all the time, everything is great, and then I go and give it to you who happens to have an old version of a configuration on your system, and I was depending on some newer feature in my code, and all of a sudden everything breaks, and again, in a way that's not clear to you what just happened, because you don't actually know anything about configuration. You just installed launchy, and when you did gem install launchy on your system, it said, oh, you already have a perfectly valid version of configuration, or there could be any number of reasons why you may end up with 0.0.5 in your system, and then weird things happen. That sort of the symptom is weird things happen. You can never figure out what the weird things are unless you actually know the problem, so this is chicken and egg thing, like how do you figure out what the problem is, what's generating these weird problems. Another related issue is if someone releases a gem between the time you do a test and you actually deploy, so let's say I'm using a version of Noko Geary, and I say my application says I want Noko Geary bigger or just Noko Geary, so I have in my manifest somewhere that tells the deployment server to install Noko Geary, and then in between the time I tested and the time I deployed, they released a new version which broke something, so even though I tested, or ran while I test, I put it on staging, they tested it, everything's great, when I actually go to deploy, the way a lot of people do deploy is that they just reinstalled the gems on the remote system, and now they've updated something that they didn't mean to. Now what people usually say when someone brings up that issue is just hard code Noko Geary, and that actually works for Noko Geary, but it doesn't work well if something depends on something else, because people are not usually in the habit of hard coding the dependencies if they're not conceptually hard coded, and so this is just a general problem of how exactly do you specify your dependencies, and as long as people have dependencies of their gems that are soft, then you have this problem of you tested something, someone doesn't release a new gem and it broke something, and you don't know why that happened, so this is not a problem with RubyGems per se, it's a problem with the way people tend to use RubyGems to deploy, obvious problem is RubyForge being down, which now means gemcutters down, but that's a problem that happens, right, you have, your deploy system requires RubyGems to be up, or I give you a repo, like you check it out of Git, and you go to set it up, and you can't get the gems out of RubyForge because they're down, so that's another thing, it doesn't happen that often, but when it does, it kind of sucks. Another problem is edge projects, and that just means a project that has not yet released a gem of some kind, and an example of that is right now we have action pack 3.0.pre, it's on Git, and rack mount is on 0.1.0, usually the solution that people give to floating gems is just release pre-release gems, which you can do now. The problem is that it's kind of difficult to make sure that you have synced up pre-release gems if you have more than a few dependencies, so there may be a bunch of gems that are being worked on together, on edge, and making sure that you always have all the pre-release gems with the right dependencies set up so that someone can always gem install action pack, let's say, it's kind of difficult when really all you want to say is all the stuff works on head together, right, so there's a bunch of repos, they may be in Git, or Subversion, or some other version of the control system, and they're conceptually being worked on by the same people for the same purpose, and so what you really want to just be able to say is all this stuff works together on the latest release, and you might release some pre-release gems occasionally for people who are not developing to try, but when you're developing it gets pretty messy, and this actually has been a problem for us in Rails. We started adding more dependencies and trying to keep the ones that are on Git in sync has produced problems and has been the impetus to some of the solutions that I'm going to talk about. Another related issue is Git dependencies with gem dependencies, so you may have something that hasn't been released yet, but it has a dependency that's a gem dependency, and so you want to make sure that the general dependency resolution process takes into consideration things that are not gems yet. So again, this is not really a problem of RubyGems, because RubyGems is not intended to solve this problem, but it's a problem with the way people use RubyGems in development right now. So right now when people are developing their gems, they often end up with Git things that they're using as dependencies, and they often have gem dependencies, because they're just pre-gems, right? They're just gems that haven't been released yet, and so making sure that everything is set up correctly, and all the things that you actually need are installed turns out to be a chore, and it works okay if you know exactly what you're doing, but as soon as you don't know exactly what you're doing, it's not really possible to do correctly without people having problems. The reason I know this is that in Merb, before we got a quasi-viable solution, pretty much nobody was able to check out Merb from Git and get it running without trying to follow a bunch of steps that work very hard, and often didn't work. So that's just a general problem of when you end up with a lot of stuff in development. Most people don't actually have this problem because most people use gems, but when people are developing gems, this produces an issue. An example of that would be, I have Rails, some other library that's not Rails decides to use rackmount, which Rails uses, and they're like, I want to use rackmount 0.0.1, and I want to be able to say, I want to use Rails with some lib, and I want to make sure that the rackmount that gets installed is actually the one that works for both of these dependencies. Right now, there's no way for the sumlib, whatever the library is, to tell RubyGems like, I need rackmount 0.1.1, so the other thing that Rails needs, some version that might be looser, make sure you get that one. Sure. Right, so this problem is, you have Rails, which says, I want rackmount bigger equal to, or tilde, weird operator, sperm operator, 0.1, let's say. And you have another dependency that has not been released as a gem yet that you are going to somehow have in your load path. So that might be by checking it out manually and adding if your load path in your rake file or something like that, or somehow you're doing it, but when someone goes to install this in reality as a gem, it's just gonna be a regular gem dependency, it's gonna work. But in development, I have no way to make sure that RubyGems knows that this is a dependency of this git repo, because it's not part of RubyGems. It's just a git repo now. So yes, there's ways that you can work around it, but there's nothing that, this is a common problem of, I have a git repo that I'm using in development, it's not released as a gem yet. Eventually it will be, but right now it's just a repo. Another related problem is Rails and RubyGems. The way Rails works with RubyGems right now, for a variety of reasons, is that it's outside of RubyGems and hacks RubyGems, so you can't, if something requires an active support dependency, even Rails is outside of the RubyGems system, so the active support dependency that, let's say active merchant might have, is not connected to the active support dependency that Rails has. So Rails is active support dependency RubyGems never sees, or might see later or in a different order or depending on how we're hacking RubyGems. So this is actually a Rails problem, not a RubyGems problem, but it's a problem that exists in the world right now. That Rails loads itself outside of the RubyGems system and outside of the dependency system. So that's not good. General problem with RubyGems right now, the tests are very coupled to the implementation, not gonna say much about this other than to say it makes it kind of hard to submit patches, so it's just a thing that exists and needs to be resolved. RubyGems works pretty good as a library, but it's not really built as a library. That's been improved in various releases, but there's still a lot of work to go to make it so that the things that people are tending to do with RubyGems are really easy to do. There's obvious specific examples that I'll bring up later. Runtime speed, the runtime right now is very, is coupled to the rest of the pieces of RubyGems, so there's things in, for instance, the source index that are there for indexing that make the source index slow and hard to refactor that make RubyGems take a second or 1.5 seconds to boot up even more on Google App Engine or JRuby and making the runtime fast would be good, it would solve a lot of problems. So there's some specific attempts at solutions, so projects that are solutions. The first one was Geminstaller, and Geminstaller just tries to say, it tries to solve the deployment problem by saying you can put in your manifest, your list of all your gems that you need. What people realized was that initially when starting to use Geminstaller was that if you specify only the top level dependencies, then you still have the problem of what if Nokogiri depends on something else and then that gets deployed, so when people use Geminstaller today, they end up having to specify all the dependencies and all the child dependencies, which means that you have to know a lot of stuff that you probably shouldn't have to know and you have to do it manually, but it works as a solution, Pivotal has been using it for a while, it works fine. Doesn't solve some of the other problems like your dependency on RubyGems itself at deployment time and it doesn't resolve the dependencies for you, but it solves the, how do I make sure that whatever I tested in my deployment server, in my staging server actually works in deployment. There was an early attempt at solving this problem in Merb, which was Thor and Merb Geminstaller, and what this tried to do was figure out your dependencies for you somewhat recursively, it used a pretty poor algorithm, but it was better than other attempts to do so at the time and what it did was it packed your, it vended your gems inside your repository automatically for you, so the Merb solution was essentially, you say, you list the gems that you need, you run Thor and Merb Geminstaller, it packs your gems and then you could deploy the packed gems to your remote system and then unpack them in the remote system, which solves the dependency problems and knowing what gems you're using solves a bunch of problems. It's still unfortunately because the dependency resolution wasn't good enough, so it ended up resulting in people having to still put their dependencies in an order that was saying, figure out through manual dependency resolution and that kind of, that was the intention was to avoid that, but it didn't actually work in practice. Another solution to the whole problem is just to say, Ruby gems are really just another kind of package, so we'll just take all the gems, unpack them, put them in one directory and let you have an easy way of twiddling the low path, so like eliminate Ruby gems from the picture altogether and what the cool thing about that is that it solves the speed problem because there's no actual Ruby gems runtime that's taking up any time, everything is just in one place. The thing that's not good about it is that it assumes things about the actual, the running of actual gems, namely that they don't require the Ruby gems runtime, that isn't always true and is not true in a lot of cases in specific ways, so a lot of people rely on features of Ruby gems, some very specific ones that make the rip approach not work very well, but would be easy to shim. Right. Another solution is just to have your package manager like Debbie and say, we're gonna take your gem apart, put it into our package system, we'll handle dependencies for you using our native packaging system. Again, that doesn't work so well because people are relying on Ruby gems, they're relying on the directory structure of the gem that they're deploying, so Debbie and people have long had a gripe with Ruby gems and that's because they aren't able to do this, they aren't able to take a gem apart, put the bin somewhere, put the lib somewhere and I'll go into why in a little bit. And then the solution that we now have is Bundler which tries to solve all the problems I outlined. I'm sure it doesn't solve all of them 100%, but it solves a lot of them, a lot of percent and it handles like the get, specifically the get problem. If you may have a gem that's not released yet problem in a bunch of ways that's convenient architecturally sound. The real problem with solving this problem, so it's actually kind of easy to release a solution that looks like it solves a lot of the problems. RIF is the example of that, but when you actually start looking at what people are doing in gems, it turns out that there's all these confounding factors that make it very hard to just say, we'll make a simple solution that solves the runtime problem. So there's a lot of other problems, there's like the install time problem, but the runtime problem is confounded by people doing weird stuff in their gems. So here's some of the weird stuff that people sometimes do in their gems. So first of all, people rescue from gem load error, even though their gem load error inherits from load error, so you can happily do require something, rescue load error, that works fine, that will work whether or not you have RubyGems or some other load path managing system like RIP or Bundler or something else, but people still for some reason do rescue gem load error. And if you do rescue gem load error, and there's no RubyGems installed, everything explodes unless you have shimmed rescue gem load error. Even weirder, people rescue from gem exception, which means they're doing some arbitrary RubyGem thing. Usually they're actually not doing that. Usually they're doing some very specific thing, but they're rescuing from gem exception. People think that instead of putting their dependencies in their gem spec, they'll do them at runtime. So instead of saying that my gem depends on foo, they'll say gem foo at runtime, which means that instead of RubyGems installer being able to resolve dependencies for you, you get runtime exceptions, like that gem does not exist. There's one case where it's actually needed, which is there's no support for optional dependencies, so you can't say, I want JSON, I want JSON, I don't need JSON, but if JSON is here, it has to be this version. Rails has this problem, this results in us having to do this, and we can shim this system. But a lot of people who use gem just use it in lieu of actually putting it in the gem spec. And they do this because they're not having to always release the gem spec, and they're doing development stuff sometimes, but this is essentially something that asks the RubyGems runtime for information that not all runtimes will have, right? So RIP and Debian don't have this information, so these gems just don't work on those environments at all. This is a more common thing that people want is gem.ruby, like what's the command that will execute the same Ruby that I'm running? This is actually valid and probably should be something that Ruby gives you, it should be like Ruby.self or something. That tells you what the command is, and it's actually pretty easy to shim because it's just like a few things in RB config that you have to concat to get the thing, but most people don't want to go dig in to figure out what it is, so they just use gem.ruby, I do, it's valid.  Gem.dir is, gives you like the directory of the gem, I think Sinatra uses that. This came up recently after we shimmed a lot of these other things. There's a few people that use gem.dir and gem.path, it's like, well, I don't really know why you're using that, but people do. Gem.loadedSpecs, I wanna know if this gem is already loaded for some reason, and gem.sourceIndex to be able to search for gems. So all these things are not things that you really want conceptually need to be doing inside of your application most of the time. There are a few cases for a few of these that are valid, but the vast majorities are just people using RubyGems' features for no obvious reason. And the thing to realize about your package is that before there was RubyGems, there was Ruby, and you were able to take your package and add a load path and it would work, and RubyGems is basically just automating that process, so you can package it up, and RubyGems will handle that for you. But there's no reason why, if you reverted back to the old system of just twiddling the load path yourself, why your package should not work. Your package should still work, and if it doesn't work, you're doing something wrong. And the reason why this is taking on some additional urgency is just that there are people now who are trying to do this. There's Debian who's been trying to do it forever, and everybody just laughed at them, but now there's, or grumbled at them. But now there's RIP, which is trying to do it for real, and there's, Bundler would like to be able to do some more intelligent things that we can't do because people are doing strange things in their gems. Even worse strange things are this idiom, which is, go get all my gems inside of, all my Ruby files inside of my current directory, which works fine if you could assume that you control your current directory, but there are package managers that wanna take all the gems and put them in one load path. RIP is an example of that.  People do this a lot in their binaries. They'll go up one level and find Lib and then require your library. This means that you can't take the binaries and put them somewhere else from the Lib path. So basically what is essentially happening is that people are relying very much on the development time structure of their libraries and not giving latitude to the package manager to do same things. And it would be one thing if there was a really good reason for this, but in practice, you can rely on whatever package manager you're using, if it's RIP or RubyGems or Debian package manager, you can rely on it to put things in the load path that belong in the load path.  You can rely on that working. And if in development time, you don't have a package manager yet, you can set the load path yourself. That's very easy. And it basically gives a lot of flexibility to both people like RIP who are trying to do interesting things and RubyGems in general in the future that might wanna do interesting things. So we're kinda stuck now because packages are doing very specific things. And even worst problem is people who put server.rb in their load path. So now they go and they say require server. And who knows who else did that? Like very generic names like initializer. So people put really generic names in the root of their load path and then it could easily be clobbered by some other gem that gets installed that does the same thing. So this is very bad. You should always have a directory with your package name inside of it so if you have your gem, you should have a your gem directory. You can put server in there and then your gem.rb can say require your gem slash server. Very easy solution solves the whole problem. And yeah. Okay, so with given all of those confounding factors, we went back and we wanted to solve both the first set of problems without running the foul of the confounding factors. So the confounding factors, we decided when we started the project they make us emo, but they're like, all right. So our philosophy is the project has to work today. It even has to work with Rails 2.3 which does really weird gem overriding hacks. It has to work for gems that exist today in real life. And you could instead build a system that works with magical unicorn gems that we hope everybody writes. But in practice that will result in a lot of people having to spend a lot of time tracking down a lot of gem authors and changing gems. That doesn't actually work. So we decided to stick with make it work with gems that exist today. So things that we actually did. First of all, automatic dependency resolution. That just means that instead of resolving your dependencies one at a time as you specify them or as you encounter them in the installation process you tell RubyGems or Bundler the list of all the gems you actually need and we will do it at once.  And that completely solves the unable to activate this or already activated that problem because that happens because you're doing them one at a time. If you do it all at once, you can't have that problem. Now you either have a, it works or you have a conflict. Like there are these two things actually conflict with each other. And here's an example of like how it looks in your, there's a gem file and you say, here's the gems. So here's the top level gems. This is in gem cutter. Has these requirements in top level. And then when you actually run gem bundle you can see that there's like net SCP requires net SSH rack maintenance required rack 1.0.1. So it went and downloaded the additional gems. And there's more that says, we'll say installing those gems. But the idea here is that you just say what gems you need at the top level and we do a somewhat sophisticated attempt to figure out what the resolution is. For git, we basically just said git, you can treat git as, if git has a Ruby gem in it you can treat it as an unreleased Ruby gem. So as far as the gem resolver is concerned it's exactly the same as a gem. And so you can do, this is part of Rails gem spec. You can say gem arrow 0.2.3 and then you can point it to git repository. And what that means is that inside of that git repository is something that is equivalent to the gem arrow 0.2.3. And we will even take that into consideration when doing dependency resolution. So if the Rails gem that may actually be released as a pre-release gem says that it needs arrow 0.2.3 the fact that you said that this git repo is 0.2.3 will correctly resolve it together.  So you can specify everything explicitly or we'll just pull it for you automatically. We also support directories of gems. And basically the way that works is that you can say Rails is in the Railsize path. And then what Rails will do, what the bundler will do is it will check us here, there's any other gem specs anywhere inside of that path. And it will create essentially another gem source. So the equivalent of what is a gem source in your system. So you have a gem source in your system, you might have a remote gem source. So we'll make a equivalent of a gem source that represents all the gems that are in your git repo. And then when we go to try to resolve the dependencies against the gems that exist, we'll include the ones that happen to be in paths that you specify. So this is just abstracting the idea of a source from being something that is just a remote source. It has these requirements to an API that you can specify. Here's how you can get a list of gems and here's how you can download them. Essentially how this works is that there's a gem resolver.  And here's the sources that are available but they're just an API so you can specify it. However, you can specify additional ones if you'd want to. And you can also specify for a given source, here are gems that have to come from that source. So you may have like 10 sources, but you might say I would like rails to come out of the git source. I don't want you to pull a newer one that happens to be on Rubyforge. I want this one from git. In the current version of Bundler, the DSL does this automatically for you or will really soon. If you say, I think it does do it now. If you say gem whatever, git, and you pointed a git repo, it'll automatically lock that gem to that git repository. What was happening was that people were specifying git repository and then it was still pulling versions from other sources. So we added this feature of being able to lock a dependency to a source out of an actual need that people were having. But it would be cool to be able to do it in general. Like, yes sir? Can you lock to a tag or a specific shot? Yeah, so to get supports pretty much any ref. So tag branch or shot, yeah. Ruby, the Bundler is item potent. So if you go halfway and then do the other half of the way on the deployment server, it'll still work. Yes sir? Does this work in 1.8 and 1.9? Works in 1.8 and 1.9 and JRuby, except the JRuby cannot compile gems. So the parts of Bundler that handle compiling native gems obviously don't work on JRuby. But it works on all Ruby's that we know of. Yes sir? Can you say item potent? I have to disagree because there could be an ex-cubal Ruby code in the gem file that's definitely not item potent. Can we get a Bundler format that is pure yaml or pure text that can be parsed to create the same thing so I can bundle some of that without loading arbitrary Ruby codes? Yeah, so we should talk about it. I know you guys are working on that. But assuming that you don't have arbitrary Ruby code in your gem file that does random stuff, assuming that you're using the DSL in the gem file. I don't know, I don't do crazy things. If you're like a hosting provider, then it matters that people are not putting arbitrary executable code in there because it could be an exploit or something. So that's understandable. When I say item potent, what I just mean is that if you run through the entire bundle process and then you get ignore or remove the expand. So what the Bundler does is it goes and it resolves your dependencies, downloads all the gems and then expands them including installing native dependencies. What happens if you delete the expanded versions is that if you run gem bundle again, it doesn't go and read download all the gems again because it notices that it has them in the cache and it just re-expands them. So what that means is that you could ignore the expanded versions in your repo and push the entire repository, run gem bundle on the remote system and not have to worry about remote dependencies or spending time re-resolving because it'll notice that everything already still works. There's some other cool features. You can disable Ruby gems. And what we've done here is we've shimmed certain really common things like gem load error. So if you rescue gem load error, we've shimmed that and we've shimmed the top level gem method. But there are still tons of cases like Rails 2.3 cannot run in disabled Ruby gems mode because it still does stuff to monkey patch Ruby gems. So this is something where it's like, this would be a good mode if everybody could run in this mode but we know that today a lot of applications won't be able to run in it so we're making it an optional thing where you can say this and hopefully long term it will be something that most people will be able to do most of the time. More likely something that you would want to do is disable system gems, which just says when you require something, don't include the system gems. Only include the gems that you specified and bundled in your application. And this just means that you can't get into a situation where I'm on my machine, everything seems to work but when I actually give it to you, it doesn't work because there's a gem that I've installed in my system that you haven't installed in yours. Google App Engine is actually already starting to ship with disabled Ruby gems mode so they've taken the bundler, they bundle, they take all the gems that are expanded, put it in a jar and then make it available to your application and they're running without any Ruby gems at all. So that works fine as long as there's gems that don't do strange things and they're the ones that reported the Sinatra using gem.there or gem.path us. Okay, the architecture is really simple. Add some cool stuff. There's basically four big pieces. There's the CLI which is what happens when you say gem bundle. The environment has sources and dependencies and can install cache or list the listed dependencies. That's basic, the environment is basically just the, it's the equivalent of the manifest so it's the object version of the gem file. There's a source which is just, it has gems and you can download a spec and that's any remote system, you can have a remote system or a local directory or anything that supports that API of having a gems method and downloading specs. And there's also a repository which represents the local place where it's cached and so you can have a repository that's your system gems or a repository that's in your local, in your application itself and that has a path and gems and it can install a list of dependencies for a list of sources. Obviously the resolver can resolve so it doesn't really do anything other than take a list of things to resolve and give you back a list of things that you should download. So the nice thing about this is that it already works today. There are projects already using it today including Rails itself. There are gem cutter, it uses the bundler on Rails 2.3 today and there are other applications that are using the bundler on Rails 2.3 today and in Rails 3.0 it will be built in. I know I'm abusing some of this space over here. In Rails 3.0 it'll come in, it'll come built in so you'll be able to do script bundle and it will do all this for you and what we've been able to do is eliminate all the monkey patching of what we're doing with RubyGems and all the work we're trying to do to like re-implement features of RubyGems by just using essentially load path twiddling. The nice thing about the bundler is that all it really does in the end is create a file for you that sets up the load path and optionally will require RubyGems. So depending on whether you've enabled or disabled RubyGems it will require RubyGems but it puts all the information about the path twiddling in a file that will always work. So with all that said I just wanna talk a little bit about what I would like to see in a future version of RubyGems based on what we've done. The first thing is just conceptually there's like this glob that's RubyGems now and it's actually four things. I have at least four things and the server's already broken out in gem cutter. The indexer is actually separate and the installer runtime are really two separate things. So the code that actually runs RubyGems should be optimized for performance and startup time and that may conflict with installation time needs and so the code that actually goes and installs gems turns out to be actually separate and we've proved that because Bunder actually does that. Bunder installs completely separate from runtime and it works and the architecture of RubyGems right now can accommodate that not without much work but it would just be nice to make it explicit. Like this part of the code is the part that installs. Here's the runtime. Anything that's in like the source index object. There's the source index object that's used for runtime and there's the source index object that's used for indexing or installing. What ends up happening now is that there's some objects that like the source index one sticks out like a sore thumb that has a lot more in it that's used at runtime purely to support these other environments. So getting to the point where we have mainly getting a sleek runtime would be good. Architecture, I like what we've done with Bunder. I think the separation of concerns is good but obviously RubyGems already has a pretty sane architecture in a lot of places so that's fine. I think there's some things like the repository object that are really convenient and that makes sense to be patched to RubyGems. For testing, it would be really helpful if the tests in RubyGems were testing the API that was meant to be used, exposed, and the CLI and specifically avoided trying to test internals. That's actually really legacy. Like the fact that it does, that it tests internals right now is legacy in a big way but it makes it kind of hard to make modifications that don't modify the public API but modify internals. A problem that I've had a lot is that the source index object exposes its internal representation of gems to the tests. So source index has a gems method on it that returns a hash but nobody uses that in reality. It's not the API but the tests use it to be able to figure things out. So it'd be good if the tests were actually testing the public API of the source index and not the internal representation. Basically makes it impossible to make the internal representation more efficient without a lot of rewriting. I really like our source API that we did in Bundler which basically just extracts the idea of what a remote source is into an API that can be reused and re-implemented. So I think RubyGems already tries to do this with the fetcher idea but it's not exactly the right abstraction and I think what we've done in Bundler shows that it works in practice for a lot of different cases. So we have a directory source, a directory of gems, we have a git repo, like we've already made it work in a lot of cases that people have actually needed so I think it works. As I said earlier, I think RubyGems should be places where it's not easy to use it as a library that should be resolved and again that's something that people have been working on for a long time so it's kind of lame for me to throw it out like dude you should fix that. But it is the case that there are parts like the factures in particular are very hard to use as a library. There's a lot of hard coded details and looking at them in terms of how people have tended or would want to use them is good. I think this is a no-brainer. I've spoken to Eric about this a lot actually over as I've been working on the problem and have not felt comfortable with the solution enough to get it back into RubyGems but RubyGems should have dependency resolution built into it. It should be able to take a list of gems and a list of sources and give you back a list of the dependencies, a list of the actual specifications that you should download and that should be built into how RubyGems works. There's a ready API for that called GemLock in RubyGems that is just for giving it a list of things and it will give you back basically a list of gem commands you can put in your application. That might be a good place for it but that should definitely be part of RubyGems and runtime performance easy to, actually pretty easy to fix. There's a few possible solutions. One of them is just go to disable RubyGems approach like try to find a way to make it so you don't need RubyGems at runtime at all. There's the rip approach of trying to collapse everything into one directory structure which requires community help and then there's just less invasive approaches of just improving the on-disk format and the internal representation of gems so that the source index is not very slow. Right now the source index, if you say I would like MerbGrader equal to 1.0.1, it has to loop through every single key in the entire source index to check this because if the key is Merb-1.0.1 so it has to go through each key and check to see if it matches Merb and see if it's the right thing or it might now go through all the values and check to see if they have the right name but the point is that it has to go through every single entry. There's no, it would make more sense to have top level keys which are the names so if you want MerbGrader equal to 1.0 it can index in, get the list of things that are Merb and then have a smaller space to search in. What this also means in practice now is that you have to load every single gem into memory so that you can search it and that's the cause of it taking a second and a half to boot applications that use RubyGems.  RIP did that with RIP and VirtualM. We kind of like Bundler handles that by giving you a local virtual environment. Being able to say like I would like to use my name thing. This is already using RIP. RVM has something called name gem bundles. Bundler does it, it seems to be an obvious need getting into RubyGems would be good. Being able to specify extra gem spec properties. This is kind of a minor thing. That's one way to do it, just say like you can specify whatever you want. This is a more likely scenario. Just say like here I can put in some extra properties so other random people who are using RubyGems can check to see if some property that they're agreed on is there or you might be able to provide more details but just some extra space to put things in. The idea of per application requirements in general, like my application actually has these dependencies as opposed to it just being there's a big system gem that has everything in it. Bundler handles that by bundling it but some notion if it's just something like the gem file or something else that lets you say this application has these requirements and could hook into the rest of the system, the dependency resolver, the runtime to actually do things usefully for your application. The API that we've built for, that we've done right now in Bundler, the three pieces of it, I see the dependencies piece of it being a thing that is okay to have as a separate piece like the gem file and the DSL that can be managed by something like Bundler but the resolver and the repository concept I would like to see in RubyGems. So the idea of, like I said, dependency resolution and also that there's an object that represents the actual location on disk where your gems are stored that you can ask it for all the gems, you can ask it's location, you can ask it to store a gem in there as opposed to it being a raw API would be cool. Optional dependencies, I wanna explain what this actually means and what people actually need optional dependencies for. You wanna be able to say this, I can use JSON but I only want greater or equal to 1.4. So what ends up happening is that people don't wanna specify JSON as a dependency because it's not but there's some code in their application that allows you to opt into JSON behavior but it only works with some version and the only good solution for this right now is to use gem in your application, to say gem JSON greater or equal to 1.4 which means that you can't actually use other package managers that don't have gem. So being able to say this explicitly and have it be something that downloads that is there during resolution time would be cool. Yes? Because you have no idea what version. Right, so if you just say require JSON, you don't know that it's the right version but that if you didn't care, that would be fine. So optional dependencies where it's just like I may need JSON, there's a good solution for it right now. Right, if you do that then you're relying on RubyGems runtime which is not ideal. There's a bunch of people that would like to not and basically like what I would argue is that gems should be things that work just fine without RubyGems. They're just Ruby packages and the RubyGems runtime makes it easier to manage the low-taps. If you start relying on RubyGems features at runtime then you can't do something else. Yes. Google App Engine is an example somewhere where they actually can't use RubyGems, it's way too slow in their environment. So, virtual dependencies is also controversial. It's essentially being able to say I required, my app requires JSON, this app provides JSON without it being a name. An example of this might be that MIRB admin says I require MIRB core and then like some other thing says I provide that so you could end up with being able to, the obvious case is namespaces on GitHub but there could be other cases where JSON pure might want to say I provide the JSON API. In general, there's a thing that we need to do as a community that can't really be done as part of the effort in RubyGems which is just better best practices like people stopping to expect the RubyGems environment being available in their library so that we can actually have people experiment with other packaging systems. I know obviously RubyGems as a packaging system is here to stay and it's the way that most people will continue to develop things in the future and will be the most robust solution but there are definitely environments like certain deployment environments or development of certain types of applications where it's convenient to be able to say this is just a package, it's made up of Ruby, it uses the RubyGems API, RubyGems packaging format to store it but at runtime I don't actually need RubyGems, it's just a bunch of Ruby code and getting to the point where that is actually viable requires an effort by all of us to just, if we notice that people are using RubyGems features, rescuing gem load error, doing dirt glob and then requiring entire sections of code or putting server that are being their root, any of these sorts of things just telling people not to do it. Gem is one and it enriches my environment as a developer and as a result I have a very facile plugin system that I can use via gem find files and it's made my code better as a result and by taking that out means that I have to reinvent the wheel for a plugin system every single time I make a new package that is expandable. We should talk about that because I have apparently like 30 seconds but I think that's an argument worth having. So best practices I think we can all agree not to use RubyGems, we can have a longer discussion I'm sure there will not be a blog war about this. We want to get to a point where people are able to actually experiment with things to improve real scenarios that exist in real life and real applications and that is something that is still at this point a somewhat unicorny thing not because of gem plugins but because of people rescuing gem load error which I think I saw Eric shaking his head when I mentioned it as an obviously bad practice. So there might be some cases where we can discuss on the edges that are still where RubyGems you kind of need RubyGems if you wanna support this feature but I think for the vast majority of cases people do not need RubyGems and it would be a better world if package managers that were not RubyGems not because they want you to not use RubyGems on your system but because there are specific use cases for doing something different we're able to treat RubyGems as packages of Ruby code. Thank you very much. I don't actually have time for questions but. Thank you.


Hooded Cobra Commander 788 here, back to KV, you're a so great cop here, love G.I. Jones. It's water rising! I'm excited! Ready, ready, ready, silence killed. Hey Hooded Cobra Commander 788 here and this is a special video. I was inspired by FormBX257's video about how he makes his review videos and so I wanted to do one of my own and show you my method. This may not be the best way, but this is how I make these videos and I thought you might be interested in seeing how the process works. I also wanted to give some advice to anyone thinking of doing this kind of thing, of becoming a YouTube content creator, particularly in the toy review area. Now of course I'm not the best and I certainly still have a lot to learn but over the years I have picked up a tip or two that you might find useful. It was my intention to shoot this video all in one go, starting at the beginning of a creation of a video and following it all the way through the end. Well that didn't quite work out the way that I intended to just because of my shooting schedule and things got kind of busy so I ended up shooting this video on multiple days so you'll notice like my shirt changes and things get moved around but that's because this wasn't all shot on the same day but I'm going to edit it so that it will follow the process all the way from the beginning to the end so if you watch it in that order it should work out great and you'll see how it is that I put these videos together. Right now I am in my dining room and behind me you see my lighting setup and my green screen. Now this is new, these are new lights and so this most recent video is the first video I've actually used these. I'm still playing around with them finding the ultimate, the best way to set them up but they work a lot better than my old system. My old system was just to put lights on stacks of books to elevate them high enough. That was difficult. This is easy, this is great. I like this new lighting setup, it's working out very well. Now it's not normally set up in this configuration because I moved things around so I would have space to do this but you get the idea though. I mean there are lights to illuminate the green screen there's a light to illuminate me and then there's the camera and over here you can't see it too well. There's my table where I have, that's where I'll actually review the toys against the black backdrop so that's over here, I'll show you that later. But this is the basic setup and with it set up like this I'm really ready to get started. I don't always leave it set up, sometimes I do leave it set up but I will break it down sometimes and put it away I guess when we have company but if I can I leave it set up just because it's quicker and it's ready to shoot when I walk in there I'm ready to hit record and start shooting. So with this setup I'm ready to get started but before I really even start step one of the video making process I look at my shooting schedule I look at what it is I'm supposed to do this week next week and kind of get a bigger picture of how the next few weeks are going to go because I may need to shoot some things out of order so I have to have some idea of what I'm doing in advance. So knowing what I'm going to shoot in advance means that throughout the week I have a quiet moment at work or I'm just relaxing on the couch and I'm kind of thinking about what I'm going to do to make each video special and unique and that's one of my goals is to make each video special because I don't want any viewer to think that he or she can just skip an HCC 788 video because that's just a typical hooded cobra commander video you can just skip that one but no you can't skip any videos because there are no typical videos each one of them should be special so I'm thinking about what I can put in the video to make it special maybe it will be a skit maybe I will create a new character that comes in and does some wacky things or maybe a new segment or some special effects I don't know, just something something to make every video special and make every video unique so you never know what you're going to get when you hit play and you start watching the videos anything can happen so I really want that to be something that everybody looks forward to so I really start out by giving that some thought I really try to think of something early before I even start writing out what I'm going to do now once I've decided what I'm going to review and how it's going to go what special element is going to be in it then I'm really ready to start step one and step one begins with the research every review that I do always starts here in front of my laptop and I start by doing some initial research I check the websites that you would usually check for GI Joe information yojo.com, 3djoes.com those are great sources and I start a text document and for each source that I use I start putting my citations into the text document and that will eventually be copied and pasted into the closing credits of the video so it's always important to cite your sources now I of course am claiming fair use under the copyright statute the federal copyright statute under title 17 and I think I'm pretty safely within fair use based on the federal copyright standard but there are some sources that I will check sometimes but I won't use them as direct sources sources like Joe Declassified because they are kind of picky about how the information they gathered is disseminated now I could still legally use that information and it would still legally be fair use but as a professional courtesy I don't use them as a direct source however sometimes I'll use them as a secondary source not to go see if I can find other direct sources that I can use but it always starts with gathering information and I get as much as I can right at the beginning and of course remember to put all my sources in a text file this review will be for the terror drone the firebat and the AVAC action figure and that's quite a bit to cover so what I do is I create a word document that will contain my notes for the review this one will be broken up into three main sections the terror drone, the firebat and the AVAC figure and of course each of those will have sub sections so with all vehicles I like to look at the parts and the features with all figures I like to look at the sculpt, design and color and the accessories and the file card so there will be sections for each of those and I just start filling each of those sections with information as I'm making my notes I always have a few objects in the vicinity definitely within arms reach including if I'm reviewing a figure I want to have the figure right there so I can move it around I can look at it close up see if I notice anything odd or interesting about it if I'm reviewing a vehicle I want the vehicle to be handy so I can move it around make sure I know how it works and make sure that I know what all the parts are before I review it so all those things have to be handy so I can actually look at it and see it and make notes about it and of course I'll have the file card if I'm looking at a figure I don't always have the blueprints for vehicles but when I do I try to have those handy so I can use those for reference and the reason I have those is if I see anything that looks like it might have been influenced by the real world I will look it up and try to learn more about it also I usually have a stack of comic books around me because I do try to look up the media appearances for each item that I review and so sometimes I haven't read these comic books since they first came out so I'll try to read through them really quickly so that I know what's in them so I have all that reference material and I put all that information into the notes and then once my notes are complete then what I used to do is print them out I've got dozens of these printed out notes here it's usually, I don't know, three pages maybe four pages at the most and it's really a little more than an outline I don't work from a script I just have notes but I do follow these notes pretty closely now I'm not doing this anymore now I am putting my notes on a tablet so I'll be reading them from a tablet rather than printed paper that's something new that I'm doing but it seems to be working out pretty well it's at this stage that errors can start to creep in usually they are errors of omission if I'm pressed for time I just don't have an opportunity to look at all of the sources that I'd like to look at I don't necessarily have time to look up all of the real world influences that I would like to look up but sometimes that's just, I just don't have enough time but I always do my best sometimes errors will creep in for instance, if I end up transcribing information into the notes incorrectly well hopefully I catch that before I start shooting but I don't always but with the notes ready then I need to start setting up so that I can shoot the video I am set up here to record this is my basic setup for reviewing an action figure I have the AVAC figure here ready to review of course it's a little different because I'm also reviewing the pterodrome so I have the pterodrome in the background normally I would just have a plain background behind the action figure but this is the basic setup I've got my bendy lamps here for light I've got my black poster board I've got black in the background now I use this black I started using a black background with my review of snow job I had been using a white background like everybody else but I wanted more of a contrast with the white action figure so I started using black and I've kind of stuck with that I don't use a light box that's something that maybe I will eventually do but I don't do that right now now the black is kind of a style choice it's unique I don't know of any other reviewers who use a black background so when the video comes up you immediately know that it's mine so it's served me pretty well and I'll probably stick with that these bendy lights are very important because the lighting has to be adjusted a lot as I move the camera around and choose different camera angles the lighting has to adjust for the different angles that I'm shooting the video so sometimes I'll need the lighting up here sometimes I might need the lighting right in the guy's face or maybe out of the background or even like behind the figure pointing at the camera so these lights get moved around a lot and it just depends on what is needed for each individual shot of the video I have some important things that are just off camera here first of all I have my notes and because of my notes I know that as I'm talking about the AVAC I'm going to be referencing a couple other figures so I have Wild Weasel I know that I will reference Wild Weasel I also know I will reference Ripcord so I have both of them just standing just off camera so when it comes time to talk about them I can slide them in front of the camera and we can talk about them and then they can slide back off so I try to have all this set up before I get started so that it can just flow and so when it's time when we're talking about AVAC and it's time to talk about Wild Weasel then Wild Weasel just slides in and we go and so I really try to prepare before I start shooting as much as possible there's one part of this set up that you're not seeing and that is the camera and the tripod and the reason you don't see it is because the camera is on the tripod and it's shooting me right now but I'll make sure to drop in a picture so you can see where the camera is in relation to the rest of this stuff the camera that I'm using is a Samsung HMX F90 it is not a high-end camera at all that's one of the things I'd like to do in the hopefully the near future for this channel is to get some better video equipment but for the time being this camera served its purpose and you know it's served its purpose valiantly for more than a year now I don't have a camera at all and I'm very happy to have it so anyway I always work behind the camera sitting in this chair directly behind the camera reaching around to manipulate the object that's on camera now some reviewers do it differently and I think it's a mistake it can be a little difficult and cumbersome to kind of embrace the camera and reach around and move things around that can be a little bit difficult but the other alternative that a lot of reviewers go for is to reach in from the side because there's a lot more space from the side and you can reach things a lot better but there's a problem with that and let me show you what that is I have the camera set up more or less where it would be for the review and I'm sitting behind the camera and I'm reaching around and of course I'm going to show you the articulation on AVAC and all of that and so yes I do have to reach around the camera and it is kind of a long stretch sometimes but there's nothing between the camera and the figure to obscure the view now I've moved around to the side of the camera and I'm going to do what some reviewers do and I think it's a mistake and that is reach around from the side now I'm over here and so now I'm going to reach in and I'm going to manipulate the figure and I'm going to show you the articulation right now all you can see right now is my great big fat hairy arm so this is what happens a lot when you reach in from the side and it's a mistake that a lot of reviewers make I think and really I just think that it's tempting to do that it's easier you can reach it better but a lot of times your viewers are looking at this and that's not what they're tuning in to see they're tuning in to see this another mistake some reviewers make and it's a bit of a pet peeve of mine is when they discover something new what they're reviewing as they're reviewing it and this is a result of them not really looking at what they're reviewing before the camera rolls so you know they'll be reviewing the thing and okay it does this and it's got the missiles on it and then you're playing around with it and they're like oh hey that comes off I didn't know that comes off well why didn't you know that comes off did you not check before you started you should check if this ever if you are a reviewer and this ever happens to you stop the camera right there and then take a look at the thing that you just discovered about what you're reviewing learn something about it and then roll the camera again so you can talk competently about it even though I'm working from notes and I know pretty much what I'm going to say before I get started sometimes it takes a lot of tries just to say it some things are easy to write but difficult to say the words just don't flow out and so many times it takes 5, 10 or sometimes more than a dozen tries just to get the words out and to get through each segment of a review and that's been my biggest struggle in doing these videos it's just the many mistakes that I make of course I cut all those out and I only use the best take of whatever segment that I'm doing but that's why it takes for basically just like a 10 or 11 minute section of video it takes more than an hour sometimes more than 2 hours just to get all of that done just to show you how much I struggle with this here is an unedited clip from my review of Leatherneck I think this vest is a bit I think this vest is a little too slim I think this vest is a little too slim when I had this kid I think this vest is a little too slim I think this vest is a little too slim I think this vest is a little too I think this vest is a little too slim when I had this figure as a kid I thought this was just part of his shirt but this is intended to be a vest I think it I think this vest is a little too slim I think this vest is a little too slim I think this vest is a little too slim I think this vest is a little too slim I think this vest is a little too slim I think this vest is a little too slim I think this vest is a little too slim I think this vest is a little too slim when I had this figure as a kid I thought this was just part of his shirt But this is intended to be a vest if it were a bit bulkier I think it would have worked a little better for example the 1986 cobra viper also wearing a vest. It's a bit a bit I Think this vest is a little I think this vest is a little too slim when I was a I Think this vest is a little too slim when I had this figure as a kid I thought this was just part of his shirt, but this is intended to be a vest If it had been a little bulkier, I think it would have worked better for example The 1986 cobra viper also wearing a vest his vest is a little bulkier and it looks a bit more like a vest Painful isn't it? Well, this is another way that errors can creep into the video Because when I've tried to say the same thing Dozen times a dozen tries to get this one phrase or line out of my mouth and on the camera Sometimes I just say it wrong I'm too focused on trying to get this one part of it Right that I don't realize that I get this other part of it wrong And it's just it's just a mistake of just repeating the same thing over and then just not repeating it the right way And so that happens that's happened on a multiple occasions And of course you guys never hesitate to point that out in the comments. Thank you I call this section of the video the core review now That's the part of the review where we're actually looking at the object that's being reviewed It's essentially everything I do behind the camera and of course after that I'll make sure to get some still photos of the comic book I'll use those I'll get some pictures of the accessories and anything else that I want to look at close up So I get all those still photos And then after all that's done the videos only about halfway done There's still plenty of shooting to do I've got to do the part of the video that I do in front of the camera With the core review done it's time to do the wrap around that's the beginning and the end that kind of bookends the review and Also, I like to do special things I like to put special things in the video sometimes a skit or something like that And depending on my schedule is determines, you know, when that's done. Sometimes I do that before I do the intro Sometimes I do it after sometimes it can be days or even weeks apart. It just depends on the schedule And if my wife is going to be in the video, then it depends on her schedule So the way that works, you know, if Susan is going to be in the video We're going to do a skit or something like that Then if it's going to be something simple and I can just explain what I have in mind And then we rehearse it a few times and then, you know, hit record and hope that it all comes out But if it's going to be something bigger that's going to require lines to memorize Then I'll write out a script and we'll print it off and then we'll rehearse it with the script Until we are comfortable, you know doing it on camera. So that's kind of how that works And there there are some ideas some skits that we have done that for one reason or another Just didn't work out either they ended up not being funny or the camera angle ended up being just wrong And you couldn't see what you needed to see for a sight gag or something like that And you know, if you can't see a sight gag, then it kind of doesn't work. It's pointless And unfortunately because I'm on kind of a tight schedule most of the time If I don't discover that a skit is not working until the editing process It's too late to reshoot it I just don't have time to go back and retry it and see if I can fix it. It's just too late So there are some ideas that have just had to go into the bin of you know ideas that just didn't work out so Once any special things are done skits and things like that special effects and such Once that's all done then I'm definitely ready to do the wrap around so at this point I have already done the core review and I've already done any skits or extra special stuff that I plan to do for the video And it is time to do the part in which I appear in front of the camera talking to you fine people So this is the space. This is my new fancy green screen. Now. I don't have the lighting turned on I wanted to see kind of like the just the ambient light and see more of the room And so this is the space that I have to work with I Mark my spot on the floor usually with a figure stand or sometimes with tape But you know, I have to mark my spot So I appear in the same spot on camera every time I turn the camera on And then I have certain things that I routinely go through I have a standard introduction And then I have notes about what specifically I want to say Now sometimes I run into mistakes. I make mistakes in which I you know, don't read the notes properly Sometimes I'm in a hurry. Sometimes I skip parts of the notes Or sometimes I want to change it on the fly and so that can take sometimes Several takes to get it all done. I'm trying to keep these segments where it's me just talking to the camera To a minimum I'm trying to shorten those now I know that you guys are here to see the toys not to see me I'm trying to keep that in mind, but at the same time. I want to be a host I want to introduce the things that are being reviewed and I want to express my opinion and That brings me to something important and that is my opinion I always express an opinion about what I'm reviewing You don't have to agree with that opinion, but I always stayed one not everybody does But I do and I try to do that every time because I Look at these views reviews as a type of art criticism and for criticism Criticism requires taking a position Not just looking at a thing and describing it but taking a position and forming an opinion about it And that's what I try to do and I really feel like that's what a reviewer should do I mean anybody can just point a camera at something But you know it takes a little bit more effort to think about it to analyze it and to form an opinion That you can express that is clear and fair And so I really think that's an important part of what I do So after standing between the camera and the green screen for a while and talking and introducing the video and Expressing my opinion about everything and probably making several mistakes along the way It's done, you know everything that's supposed to be recorded on the camera is recorded It's all there So now it's time to put it all together into a final video that you can actually watch and that is the editing process I'm back in front of my laptop and it is time to edit the video I have pulled all of the files from the camera and put them on the laptop I'll also gathered any images that I want to use in the video Either photographs I've taken myself or images that I've pulled from the internet always with sources cited And it's time to put those all together and to a finished video that you can see Now the video editing software that I'm using is movie studio platinum 13.0 It is not, you know a top-end video editing program, but it's not free And it's it does really more than I need it to do. It's it does quite a bit And I've you've been using it for a few years. I've gotten pretty efficient at it I've learned a few tricks that I can do with it And I'm still learning more that I can do with this Editing program and so it's worked very well for me. It pretty much does everything that I that I need to do So what I'm going to do now is I'm going to turn the camera around so you can see the screen and I'll show you What this looks like from my perspective, okay? Now we are looking at my laptop screen and it starts of course with this folder This is my Leatherneck folder in my reviews folder So this is going to have all of the files I need for Leatherneck and within the Leatherneck folder I have two other folders I have Leatherneck raw video and Leatherneck uploads and the raw video folder is the video that comes straight from the camera These are all the clips unedited That I've recorded on the video camera and here you can kind of see the order in which I shot them There's you know starts out with Leatherneck here. We go down. We see there. I'm looking at the file card And here is me in front of the green screen and that's just kind of how these look once I first pull them off of the camera And then this other folder here Leatherneck uploads These are the files that will actually be uploaded to YouTube. These are the finished. That's the finished video Right there Leatherneck review. That's the finished video review and then Leatherneck thumb This thumbnail image is the thumbnail image that you will see when you see it on in your subscription feed on YouTube so these are all ready to go and those will be uploaded Now just loose in the Leatherneck folder I have all these images that I'm going to use within the video just loose there I don't create a separate folder for those that just kind of just in there with the Leatherneck general stuff And then also there are two documents in this Leatherneck Leatherneck folder There is the Leatherneck review notes a word document and pull that up really quick and this has All of my notes that I'm going to follow for the review So, you know, that's everything that I want to say in the video Got it all broken down there And so that stays in that folder and then there's one other document here It says Leatherneck review info and this is just a text document and this Really is just things that I'm going to need to copy and paste into the video It has you know the Facebook and the Twitter and the patrons and then we have information and sources here then we have All of our sources for all the different images and other elements that I have used in this review video All the research that I did it's all right here I try to keep this updated as I go so that I will have a citation for everything that I use And then we have my disclaimer here at the bottom and so this is really important This is just kind of some basic information that I will need to go forward with the review So with all of these I Drag all of these files over to the editing software Right over here and this is like I said movie studio platinum 13.0 and this is just kind of how it looks When I'm ready to start editing of course this video is already completely edited, but I'm going to show you how this works Here is the preview screen now here are the Files that I brought over the media files that I will be using in the video and you can see there are some images there Some comic book images the file card And then we have the video clips from the camera And those are all ready to be dragged down here to the timeline Now that has to be done in a certain way in order for it to turn out just right and I want to show this to you They kind of expand this a little bit now the green screen is something that I've been doing for a while now And so there's a particular way to do that now here is me drag this over here easy so you can see it now there's the The advertisement for die-cast enterprise There is the introduction. This is the old introduction. I have a new one now, but it still works in basically the same way It's you know one that something that's pre-shot, and I drop it in there And then I have this I don't know if you can see this this Crossfade right here where it fades from the introduction to The video of me in front of the green screen now the way the green screen works is there is a video effect in here a chroma here and I use the green screen effect to essentially key out the green and make the image but make the green Transparent so you will see whatever is behind it and this line right here is what's going to be behind it Now see here. I've got my hcc 788 logo and so that's going to be what's behind me in front of The green screen see there Now I have a few presets For the green screen because you have to make some adjustments to get it just right And I have some on here where you know if I've got the settings just the way I want them And they look look pretty good. I will save that setting so I can use it again without having to you know Redo it every time so there we have me in front of the green screen here The image that's behind me here, and of course, this is the audio. That's me talking and Here you can see there's a transition It transitions here at this point it crossfades from the hooded cober commander 788 logo to the leather neck File card and so that's kind of how that works once I'm done talking on the camera Then it's time to do the core review It's time to actually get to the review and so we have this crossfade here And then we have the first clip of the review itself So we can see leather neck there now the this first clip is up here The next clip is down at this level It just it just works better if I do the crossfade up at this level rather than down at this level I've played around with it. I've experimented with it and it just works better that way You just have to trust me on that but it's okay for this These clips down here to be at that level me shrink this down so you can see better These clips can be down here because I'm not using the green screen anymore So, you know, there's nothing behind that so these can be right here right next to the audio clip And now we do have to have to do something a little special with the audio When I am In front of the camera. I'm a little farther away from the microphone So I need to increase the volume a little bit in order for you to be able to hear and understand me clearly When I'm behind the camera, I'm closer to the microphone. So I drop the volume down a little bit So I have a separate volume a separate audio Layers here one with a slightly louder volume one was a slightly lower volume And I do my best to you know mix those well so they come out pretty much even I'm not always successful on that But you know, I do try to get them to have about the same volume level Whether I'm in front of or behind the camera and so now let me shrink down some of these layers here So you can kind of get an idea of how many layers we're working with here when I am doing the core review I have to drop in a few things like some images There I got this image here. So there's that and it's you know, it's of the level above The video clip so it's going to be on top and then let's see. What's this? This is the grenade launcher for For leather neck. So that's on this level above. So it's going to be on top. It's going to be on the top layer So every time I drop something in that's what I'm doing So there's there are some other images that we're using and of course I can adjust where they go Using this feature If I can get it to pop up Yeah, see this and I can move this around See and it will position it wherever I want it to be on the screen So there's that and that's basically I just keep doing that until the Video is done. I have collapsed each of the layers and I've compressed the whole length of the video So you can see the entire edited video here and one single shot from beginning to end and all of the layers now This is a pretty simple video Most of them tend to be a bit more complicated than this Because they have special effects or skits or other special things that require Several more layers and just a lot more moving parts This is a pretty basic video and you can see pretty much the whole thing here There's the core review all through there a few images here and there Here is that's me in front of the green screen there That's me in front of the green screen there this long bar up here at the top That is the bug that goes in the corner of the screen the little hcc 788 that goes in the bottom corner I usually do that last wait till everything's Edited because that's going to run through the entire length of the video So once it's done then I can drop that in at the top level So that it it is where it's supposed to be and it doesn't get covered up by anything And that's pretty much it now some of the mistakes that creep in at this stage Or like if a clip gets forgotten like I miss a clip and I don't include it that has happened a number of occasions That's very annoying Sometimes I won't catch it until I'm actually done editing And sometimes it's too late to fix it So I hopefully if everything goes the way it's supposed to it's all in there It's all in the proper order. I haven't made any major flubs, but there it is That is the edited video and it is ready to render to render the video I go up here to make movie and Save to my hard drive. There is the title Leatherneck review I am saving it in the Leatherneck uploads folder and that's a WMV Video type and I just click next and to start rendering now I've already rendered this so I'm not gonna do this right now, but if I wanted to render it I would click next And then it would for the a video of this length on this laptop It takes about two hours to render So the render time is kind of important because if I discover that I've made a mistake After I've rendered it then it's gonna take a minimum of two hours in order to fix it So I try to do it right the first time from my YouTube account I select the upload button and that will bring me to this screen and I will either click there and Select the file or I will drag the video file over here to begin uploading it and from there I will type in the title of the video. I will upload the thumbnail image I will copy all of the information in the text document and paste it In the additional information box for the video And then I will schedule the video to publish at a particular time for these videos It is Sunday at four o'clock my time local time And so then I just walk away once it's done uploading YouTube will publish the video at the time that's selected and I don't have to do anything Now hopefully if everything goes right it will all be done a couple days in advance So if I do discover something is wrong I will hopefully maybe have an opportunity to fix it sometimes though There just isn't enough time to fix a mistake if it's discovered after it's uploaded. I have fixed a few things I have caught a few errors before you guys ever saw it But a lot of the time if the mistake if I the mistake is discovered at this stage It's probably too late to fix it And so I pretty much just have to live with it So you have a video that is completely shot and rendered and upload and ready for people to see on YouTube You're ready to get a million fans and get tons of hits and have your video go viral and be seen by millions of people You're all set So now what happens I'm gonna turn this around go get back in front of the camera So I can talk a little bit about what's next because even though the video is done This is not the end of the process After editing the video and uploading the video I wanted to take a few minutes to address anyone who is new to Making videos for YouTube or who is thinking about doing this kind of thing I wanted to make a few suggestions Maybe you could avoid some of the mistakes that I made and maybe learn a few lessons that I had to learn the hard way So you have a video up on YouTube.  Are you going to make another video? When are you gonna make another video? Now that will depend on your schedule and your resources There are some video makers who upload videos once a day like a video every day to me That is too much The ideal frequency for me has been one per week Well with maybe a little something extra thrown in here and there But the main reviews once a week and that has been really That's working really well for me for a number of reasons for one thing doing a video every day Or even like multiple times a week would I wouldn't be able to make each video special I would have to really cut back on the production value to do videos that frequently So I mean even doing videos once a week with the main videos once a week Even that can run me tight on time getting it getting it all done But if I were to do a video once a day Even if I cut back on the production value and just did really basic Videos just me with a camera. It was no special effects or anything like that I'm still not sure I could keep up with a video per day in your Enthusiasm it is tempting to put out as much as possible as quickly as possible But I think you will find if you space them out more you will be more free to Think about what you're doing To to plan what you're gonna do to Experiment and experimentation is important because nobody starts out being great at this all of us have more to learn and so Experimenting is important and failing is important. You will fail sometimes Some things that you try even if it seems like a great idea will just not work out But you still have to try you have to try and be willing to fail to learn and so spacing the videos out a bit more allows you to experiment to fail sometimes to Take the lessons that you learn from those experiments and apply them to the next video So you're always continually getting better even if your first video comes out exactly the way you want it to I mean you plan out everything you have the best equipment everything comes out exactly the way you planned When you look back at that video three years later, you're gonna think it's total crap Why did people even watch that? I can do so much better now, but that's what experience does that and that takes time That takes experimentation and that takes a willing willingness to learn and grow Subscribers let's talk about subscribers. That's important. How do you get subscribers?  I'd like to I don't even like to reply to those types of comments I just kind of let them go. It's a mistake to try to Correct somebody if they've made a mistake about what you're doing or they don't understand what you did and they've made Comments that are negative about it and you you want to set them straight because you know if they only understood Then they wouldn't disagree with anymore and so everything would be right and they would like you but that's a mistake It doesn't work that way. You can't fix those people There's no level of explaining that you can do that's gonna make those people get it So you have to just let it go now I have replied to some negative comments when I think it's necessary But for the most part I just leave them alone Now if you go through the comments on my videos You won't see a lot of really bad stuff because if there's somebody there and they're just trolling or they're just Insulting those people they get booted fast. They are not around for very long, but there's never a shortage of people who Want to make sure that you know everything that you're doing wrong.  They have no idea what goes into making these They don't know and what you I think you should not do is try to please those people Because the minute you start trying to please everyone who you know is telling you oh you got to do this or you got to stop doing that You please you try to please one person first of all they they're never happy But you try to make that person happy and then you end up pissing off 15 other people who didn't want you to change anything so You just you just have to let that stuff go ignore it It's making suggestions and having constructive constructive criticism is one thing but You're in charge of your videos. You're the one who knows whether or not these suggestions are really helpful So I mean people can talk all they want You're in charge. You know what you're capable of doing You're not you know, you know what you want to produce and the kind of content you want to produce so you have to make those decisions and so Be careful if you're tempted to strike back at people who make negative comments Don't do it. It's not worth it. You're not gonna make them happy and Really, what's the point if you keep all of that in perspective and you really look at all of your comments What you will find is a lot of love There will be a lot of people who just love what you do and that's what you got to pay attention to even though The negative stands out more Pay attention to the overwhelming support that you will get from most of the people who are watching your stuff and Do it for them Do it for the people who love it. Don't do it for the people who hate it.  Do it for the ones who love it.  Some of us have become pretty tight I care about you guys and you guys make a difference in my life.  I guess that's all I have to say I'm kind of freeform here. I know this is gonna be a long video. I'm sorry about that But I wanted to take you through my process show you each step But I also wanted to to say a few things to anyone out there who's new or who wants to try this It's not like I'm a huge YouTube channel, but I have done this for a little while And so, you know, maybe I can help somebody and if you're thinking about doing this try it. It's fun So give it a shot But I guess I got to wrap this up now because now I have to start the process for the next video review I got stuff to do. So that's it for now. I hope you enjoyed this. Thanks for watching. I'll see you all next time